基于Burpsuite的安全测试十：输入/输出模块测试
情景1：SQL注入测试
基本概念
- sql注入就是把SQL命令插入web表单提交或输入域名页面请求的查询字符串，最终达到欺骗服务器执行恶意SQL命令的目的。本质就是修改当前查询语句的结构，从而获得额外的信息或执行内容。
- sql注入按照请求类型分为GET型、POST型、Cookie注入型。GET型和POST型区别是由表单的提交方式决定的。
- sql注入测试方法分为报错型、延时型、盲注型、布尔型等。
- sql注入按照数据类型分为数字型、字符型。数字型不用闭合前面的SQL语句，而字符型需要闭合。
- 数字型注入，一般存在于输入的参数为整数的情况，如年龄和ID等。正常访问该页面展示如下图：
在网址的参数后加单引号或者%27，即可在参数后构造SQL语句。由于SQL语句单引号是成对出现的，添加一个单引号则SQL语句是错误的语句，不能被SQL解释器正常解释。访问如果报错则说明SQL语句被执行了，报错信息举例为：Warning:mysqlli_fetch_assoc() excepts parameter 1 to be mysqli_result...。目前测试网站，没有报错，响应正确。由此可以知道这里不存在数字型注入。 
如果报错了，则可以继续后续操作，接着利用“恒真”、“恒假”的方式进行测试，目的在于发现用户输入的参数是否可影响服务器端查询语句。 
- 字符型注入，一般存在于接收的参数为字符串的情况，如名称、密码等。同理，通过Burp Suite抓取某一页面入参信息，在入参后通过加入'验证是否有报错说明，如果有则又可以通过在入参后加'or '1'='1，执行后可以查看查询到的信息，用sqlmap可以进一步验证漏洞
- 数字型注入，一般存在于输入的参数为整数的情况，如年龄和ID等。正常访问该页面展示如下图：
具体实践
- 从攻击视角来看，SQL注入经常会根据前台的数据是否回显和后台安全配置及防护情况进行区分。先分析前台数据回显情况，主要有两种类型。
- 回显注入，客户端发出的请求结果会在客户端进行展示，如用户信息、文章内容等。
- 盲注，客户端发出的请求不会再页面进行展示，如注册只是提示注册成功并不会返回数据。
- 服务器配置及防护会对SQL注入的影响。
- 数据库是否开启报错请求。
- 服务器端是否允许数据库报错展示。
- 有过滤代码机制。
- 服务器开启了参数化查询或对查询过程预编译。
- 服务器对查询进行了限速。
系统修复方案：
对提交到服务器的客户端页面，对通过服务器脚本生成的页面、提交的表单、发出的链接中的所有请求变量都要进行检查，采用黑名单、白名单等形式对用户提交的信息进行过滤，过滤其中的特殊字符，或对字符进行转义处理。
sql语句关键字 and or select declare update xp_cmdshell等。
sql语句特殊符合 ’ ‘’ ；等。
web系统接入数据库服务器使用的用户不应为系统管理员，用户角色应遵循最小权限原则。
情景2：XSS测试
- 跨站脚本漏洞是应用程序将数据输出到网页的时候存在的问题，导致恶意攻击者可以往web页面中插入JS、HTML代码。一般会利用此漏洞窃取客户会话和cookie，模仿合法用户查看和执行操作。
- 一般分为存储型跨站、反射型跨站、DOM型跨站。
- 存储型跨站，脚本直接写入数据库，主要是在留言板、投诉建议等输入框中输入一段跨站脚本，看能否插入数据库中，如果能插入成功，则查看该留言时跨站语句就会被执行，如出现恶意弹框。
- 反射型跨站，脚本没有写入数据库，主要是在URL上或者输入框内插入一段跨站脚本，如<script>alert(/xss/)</script>，所以是临时展示在网页上弹框之类的内容。
- DOM型跨站，多指通过JS代码实现的。
系统修复方案：
对提交到服务器的客户端页面，对通过服务器脚本生成的页面、提交的表单、发出的链接中的所有请求变量都要进行检查，过滤其中的特殊字符，或对字符进行转义处理。
HTML标签的 < " ' %等，以及这些字符的Unicode值。
客户端脚本的关键字 JavaScript script 等。
严格定义入参
针对对应的请求类型，对应正确的返回内容。
将客户提供的所有数据限制为字母数字数据，即包含</>HTML文档结构类型的输入内容都过滤掉。
修改和使用脚本之前，验证脚本来源
情景2：命令执行测试
- 当应用需要调用一些外部程序去处理内容时就会用到一些执行系统命令的喊声，如PHP的system、exec等。如果将恶意的命令注入到正常命令中，就会造成命令执行攻击。
系统修复方案：
减少执行命令的函数使用，或者在使用函数前对参数进行过滤，对敏感字符进行转义。