xss、csrf、sql注入快速检测方法
CSRF跨站请求伪造
- 原理
攻击者在受害者不知情的情况下,以受害者的名义伪造请求发送给受攻击的站点,从而在未授权的情况下执行在权限保护之下的操作。
CSRF攻击的对象是那些可以直接产生数据改变的服务,而对于读取数据的服务,则不需要进行 CSRF 的保护。
- 检测方法
1.查看重要操作接口提交的请求中是否包含 csrf_token
2.更改和删除 csrf_token 后提交表单,查看请求是否能被正确响应。
- 修复方案
1.对涉及数据增、删、改操作提交的表单中添加csrf_token,token 参数应校验一次后失效。
2.最好是在容器或框架上全局启用 csrf_token。(很多框架自带的解决办法容易遗漏一次失效的问题)
3.token 应有一定的时效性,建议为30分钟,过期需失效(即:单页面停留30分钟后,用户提交请求需提示“页面过期,请刷新页面后再次提交”)
- 参考
CSRF测试
跨站请求伪造(CSRF)
CSRF 攻击的应对之道
## XSS跨站脚本攻击
### 反射型 - 原理
- 检测方法
检测场景:任何有输入输出地方......
1.使用通用的web扫描器一般的都能发掘潜在的反射型XSS漏洞。
2.手工在一些输入框中或者post参数中加入拼凑过的JS代码,根据返回的页面源码中是否成功嵌入JS代码来判断XSS是否存在。
3.如果注入的代码经过后端处理后,永久性的嵌入到了页面当中,则该XSS为存储型的,反射型的XSS一般依赖于该次请求,且同时只能被用户自己所看到。
- 修复方案
1.输出时统一使用 htmlEscape()转义用户输入的数据,将html、js中涉及到的关键字符进行html编码处理后再输出到页面上。
2.如果存在用户编写文章等类似用户可以自定义页面样式的功能,则限制用户输入,采用严格的白名单来过滤用户的输入,这种过滤应在后端应实现。(很多开源的第三方富文本编辑器,部分编辑器仅在JS端进行过滤,而不在后端进行关键字过滤)。
存储型
- 原理
- 检测方法
检测场景:存在富文本编辑器的地方;用户的输入信息会作为固定的值回显到页面中;后台管理应用中维护用户输入的相关信息。
1.手工在一些输入框中或者post参数中加入污染的JS代码,根据返回的页面源码中是否成功嵌入JS代码来判断XSS是否存在(注入前端转义的情况)。
2.如果注入的代码经过后端处理后,永久性的嵌入到了页面当中,则该XSS为存储型的。
3.如果尝试注入的代码在页面中均被html编码,则再考虑其数据的流转会不会在后台其他应用中处理这些输入数据,如果有,对应的后台应用是否也做了完善的过滤机制。
4.可远程搭建XSS检测平台,如果有XSS测试代码被触发,则自动发起链接到该平台上,这样相对来说可以测试那些未知的数据流向是否造成问题。
- 修复方案
1.输出时统一使用 htmlEscape()转义用户输入的数据,将html、js中涉及到的关键字符进行html编码处理后再输出到页面上。
2.如果存在用户编写文章等类似用户可以自定义页面样式的功能,则限制用户输入,采用严格的白名单来过滤用户的输入,这种过滤应在后端应实现。(很多开源的第三方富文本编辑器,部分编辑器仅在JS端进行过滤,而不在后端进行关键字过滤)。
基于DOM型
- 原理
没啥可说的,可以当成是特殊的反射型。
- 检测方法
- 修复方案
- 参考
XSS跨站脚本 ## SQL_Inject - 原理
开发人员使用直接拼接 sql 的方法来访问数据库,导致攻击者能通过特殊构造的语句控制代码逻辑。典型的代码与数据没有分离导致的安全问题之一。
- 检测方法
- 常规方法
1 ,新建一个1 .txt文件,burp抓包将包含关键参数的请求存入。
2 ,使用sqlmap 进行扫描(python sqlmap [options] [file path])
3、等待结果输出 - 另一种常规方法
使用burp插件SQLiPy我们在跑注入的时候需要重点设置的参数:
方案一(通用):将sqlapi地址配置成 192.168.2.22 2222
方案二:使用sqlipy生成测试语句,然后添加 -p 参数,指定注入参数,然后在 shell 里面运行 sqlmap。
一个指定参数的SqlMap示例语句:
sqlmap -u “ http://xxxxxx.com:80/x/xx?x_id=1507 ” --method = “GET”-- cookie = “SESSIONID = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
--user-agent= "Mozilla / 5.0(X11; Linux_x86_64; RV:60.0)/ 20100101火狐/ 60.0" --delay=0 --timeout=30 --retries=0 --dbms="MySQL" --os=Linux
--level=3 --risk=3 --threads=2 --time-sec=10 -b --batch --answers="crack=N,dict = N" -p "zone_id" --tables
-risk=3
-level=3
--threads=2
--dbms和–os去问开发或者测试
-p 指定阐述减少服务器压力 - 不太常规的方法
1、写一个web界面调用sqlmapapi
2、直接找开发拉代码过来进行审计 - 修复方案
1、使用安全的API ,完全避免使用解释器,或提供参数化界面的接口,或迁移到ORM 或实体框架(通常开发框架里会自带访问sql的方法来预防注入)。
2、做参数绑定,预编译查询。
- 参考
SQL注入
Copyright © 2018 Powered by MWeb, Theme used GitHub CSS, Author is lonelyor
