Web安全(DVWA)
1. 什么是DVWA
一个用来练习各种漏洞利用的WEB漏洞实验环境,基于PHP/MYSQL的Web应用。官网
2. 主要模块
XSS 跨站脚本攻击 暴力破解 命令执行 CSRF 跨站请求伪造 SQL 注入 文件上传
3. XSS 跨站脚本攻击
Chrome浏览器默认开启xss监听,测试前须命令行启动浏览器,关闭监听。
反射型:非持久化,用户主动点击带有恶意URL,发送请求到后端,后端返回带有恶意脚本的页面。 假设某网站 A.com 的某个输入框存在XSS漏洞,能通过输入框或者URL传入脚本执行。比如它的后端php代码是这样的
那么,就可以在 url中传入参数name。生成 恶意url:
ck.php文件代码如下,将获得的cookie存入cookie.txt。
通过短域名生成网站,将上诉 恶意 url 映射成类似http://dwz.cn/B4l3Ydke 的网址欺骗用户,发送给已经在A.com登录的用户,用户点击之后,cookie信息就会自动保存到 B.com下的cookie.txt中。
通常,后端不会这么如此信任用户输入,会对各种输入进行正则过滤限制。针对各种过滤出现了对应的恶意 payload, 通过事件、通过协议、通过请求。
以下代码通过base64编码,依旧能实现恶意攻击。
有效的解决方法是通过转义,通过 htmlspecialchars,将具有特殊意义的字符进行转义。
存储型:持久型,攻击者提交恶意脚本最终进入到数据库,用户访问加载页面时,恶意脚本执行。
区别于存储型XSS 攻击,脚本因为存入数据库导致危害更大,所有访问该页面的用户都将被攻击。但因为业务需要比如富文本框功能,就不能一味的使用 htmlspecialchars 转义,而应该自定义过滤规则,将内容限制在安全范围内。
DOM型:客户端脚本通过DOM动态输出数据到页面,而不经过服务器。 当前端出现以下代码时,就要小心了,确保等号右边的内容可控。
大部分xss都是为了获得cookie,进行下一步的破坏,因此系统层面也应考虑cookie有效期,HttpOnly等方式。
4. 暴力破解
本质上就是将密码字典的每一种情况,通过自动化工具进行组合尝试,进而得到密码字典中正确的一项。
演示登录破解
安装Burp Suite(以下简称BS),设置代理,使得 BS 能够拦截浏览器请求,捕获登录的数据包。
进入待破解网站A,BS开启拦截,输入账号密码点击登陆,此时请求会由BS控制,如下图所示:
复制Raw数据包到 Intruder 页面,设置数据包中的账号和密码的占位(Add $),在 Payloads 中加载本地字典,Attack type选择Cluster bomb,这样每次请求就会从字典中依次加载字符串作为账号和密码去请求。如下图:
开始攻击之前设置 Option ,便于我们快速找出登录成功的账号密码。经过分析,A网站登录无论正确错误都会返回302状态码,区别在于正确时返回头Location字段为 index.php,错误时为 login.php。
设置Grep Match,新增"index.php",即响应中包含字符串的账号密码组合将被打勾标记。设置Grep Extract,将响应中Location之后的内容都打印出来。如下图:
可见 admin 和 password 的组合即为正确账号密码。
为了快速出结果,演示中账号密码字典仅五种情况,5*5 = 25次即可确定是否能破解,实际应用中字典量远大于此。
防范
5. 命令执行
应用有时需要调用一些执行系统命令的函数。如PHP中的 system,exec,shell_exec 等。
如下后台代码,将前端输入框的值作为参数传入,执行 ping 命令,并将执行结果打印。
此时可构造恶意输入值如下:
baidu.com && whoami baidu.com && cd ../ && pwd baidu.com && cd ../ && ls
实际破坏中原不仅仅是 'ls' 这种无害的命令。 防范
6. CSRF 跨站请求伪造
流程图 摘自网上
攻击流程:
攻击关键 用户在A网站登录的cookie依旧存在于本地,且访问B网站时,如果B网站中存在请求A.com的接口,请求时会将本地cookie带上,这样后端如果仅仅以cookie判断该请求是否由用户授权发出,显然是不行的。
防范 1. token方法
服务端预先生成一个随机数,在渲染具有表单的页面时将随机数以不可见的形式( visible:hidden )插入到表单域,客户端请求时带上这个随机数,服务端进行校验,确定请求确实来自该页面。 对于B网站,即使请求会带上cookie,也由于获取不到该随机数(该随机数每次刷新页面都不一致),导致后端校验失败。
双重 cookie 验证
服务端给 A 网站前端页面设置一个 cookie,页面中所有的请求,都要求在请求 body 或 header 中添加该 cookie 参数(可以通过封装统一的 ajax 请求方法),请求到了服务端,服务端校验请求携带的 cookie,和请求 body 或 header 中的 cookie 是否一致,一致则请求通过。 对于 B 网站,即使在 B 网站请求 A 网站,会带上 A 网站的 cookie,但是 B 网站的请求 body 或 header 中没有 cookie 的值 (B 网站中获取不到 A 网站 cookie 具体的值),那么请求也会失败。
优缺点:双重 cookie 验证,相比于 token 的方法,优点是实施成本更低,不用每个页面都添加 token,而是采用 cookie 的机制,所有请求可以借助统一的 ajax 逻辑。缺点是依赖于 cookie 不可知, 如果已经被 xss 攻击获取了 cookie, 则该方法无效。
7. SQL注入
假如网站后端代码如下:
即 将获得id参数值,组合成SQL语句进行查询,那么就存在SQL注入的风险。
攻击者通过将 id 参数设置为 1'or'1'='1 。'或' 语法使得 WHERE 条件一直成立,结果能查询出users表的所有数据。
id 设置为 1' order by n # ,要求结果以表的第n个字段排序,则当n = 1,2,3...依次执行,出现报错时假设n=5,即说明该表只有4个字段。
通过以下 sql 能挖掘出更多的数据库信息。
````
查询数据库用户,版本信息:
1' union select 1,concat(database(),version(),user()) #
查询所有数据库名字: 1' union select 1,schema_name from information_schema.schemata #
查询数据库的表名,0x64767761十六进制转字符为 dvwa: ' union select 1,table_name from information_schema.tables where table_schema=0x64767761 #
查询表的字段,0x7573657273十六进制转字符为 users: ' union select 1,column_name from information_schema.columns where table_name=0x7573657273 #
查看表的内容: ' union select user,password from users #
通过 mysql_real_escape_string, 转义sql语句中的特殊字符。
限制数据库用户操作权限。
````
8. 文件上传
漏洞利用的三个重要条件:
利用步骤 1. A网站允许上传任意文件,则构建如下一句话脚本,保存为 hack.php 上传到A网站。注意 apple 字符串,该字符串可任意设置。
假设已知A网站上传的文件都在/uploads/目录下,可通过A.com/uploads/hack.php访问该文件。
打开 中国菜刀 软件,该软件被安全软件报病毒,谨慎使用。
右键添加SHELL,填写 A.com/uploads/hack.php 及 apple 字符串(与hack.php保持一致),点击添加。如下图:
如果请求成功,则可以读取服务器任意文件,以及运行虚拟终端。如下图:
9. 写在最后
此时分享参考大量网上博客,在此过程中也是收获很多,基于DVWA工具对Web安全有了更多的认识。介于篇幅并未将所有运行结果截图上传,有兴趣者可自行下载dvwa进行测试。若此分享有知识错误欢迎指正,另附上部分参考资料。
Last updated