xss、csrf、sql注入快速检测方法

CSRF跨站请求伪造

  • 原理
    攻击者在受害者不知情的情况下,以受害者的名义伪造请求发送给受攻击的站点,从而在未授权的情况下执行在权限保护之下的操作。
    CSRF攻击的对象是那些可以直接产生数据改变的服务,而对于读取数据的服务,则不需要进行 CSRF 的保护。

  • 检测方法
    1.查看重要操作接口提交的请求中是否包含 csrf_token
    2.更改和删除 csrf_token 后提交表单,查看请求是否能被正确响应。

  • 修复方案
    1.对涉及数据增、删、改操作提交的表单中添加csrf_token,token 参数应校验一次后失效。
    2.最好是在容器或框架上全局启用 csrf_token。(很多框架自带的解决办法容易遗漏一次失效的问题)
    3.token 应有一定的时效性,建议为30分钟,过期需失效(即:单页面停留30分钟后,用户提交请求需提示“页面过期,请刷新页面后再次提交”)


  • 检测方法
    检测场景:任何有输入输出地方......
    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型

  • 原理

没啥可说的,可以当成是特殊的反射型。

  • 检测方法

  • 修复方案


开发人员使用直接拼接 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、做参数绑定,预编译查询。

2018/12/13 15:42 下午 posted in  技巧