【web安全测试case】sql注入

SQL注入漏洞原理和测试case漏洞原理许多与数据库相关联的应用服务，在程序实现时，需要将用户的输入拼接到sql语句中，并提交到后端数据库，从而能够得到正确的返回结果。图1简单登录程序的示例界面例如一个简单的登录程序，如图1所示。需要将用户从页面输入的用户名和密码拼接到以下的sql语句中：Select*fromadminwhereuser=‘TxtBox1.txt’andpass=‘TxtBox2.txt’，通过提交执行sql语句从而能够判断用户输入的用户名和密码是否正确，如果正确则正常登入系统，否则便提示错误。假定图1中的登录程序对输入没有实行严格的过滤，当用户填写的用户名和密码都是:abc'or'1'='1时，那么将导致最终拼接成的SQL语句是：Select*fromadminwhereuser='abc'or'1'='1'andpass='abc'or'1'='1'这条语句是永真式，提交到数据库执行，结果不为空，那么攻击者就能够不需要知道正确的用户名密码成功登陆后台，达到攻击目的。这就是最简单的SQL注入方式。攻击者还可以在输入中注入更加复杂的sql指令，最终能够获取数据库的密码甚至权限。Sql注入的漏洞原理可以概括为：程序没有对输入进行严格的过滤处理，直接将其拼接到sql语句中提交到后台数据库执行，从而可能导致恶意注入的sql命令会被执行。测试思路了解了sql注入的原理，针对该问题的测试思路可以确定如下：1）首先确定可能的攻击点。需满足以下两条件：a.该输入最终会被拼接到sql语句中;b.该输入能够被攻击者控制或改变，否则攻击者便不能任意注入恶意的sql命令了；常见的攻击点，可如表1所示：表1常见的sql注入点攻击点说明Form表单Form表单中的任何变量都是可能被修改；web前端的js验证无法限制攻击者的输入，攻击者可以通过辅助工具直接篡改提交到后台的Form表单数据；Get参数url链接中的参数可以被手工直接修改，例如：=1中的taskid。Cookie改变cookie中的值，使得程序在提取cookie变量拼接sql语句时出错。2）验证程序的输入过滤是否严格确定了可能的攻击点，下面就是针对每个可能存在的攻击点验证程序对于输入的过滤是否严格，是否能够正确处理提交的恶意sql指令。可以构造的输入，一般如表2所示：表2异常的输入列表输入类型样例说明特殊字符‘单引号，用来分割字符串，一个不匹配的单引号会产生错误。;结束一个语句，提前结束查询也会产生一个错误。/*注释分割符，分割符内的文字会被忽略。--%20用来提前终止一个查询。左括号或者右括号括号。用来组合逻辑的判断子句，如果不匹配，也会产生一个错误。a非数字字母主要用来对数字比较的逻辑进行破坏，例如select*fromtablewhereuserid=1-select*fromtablewhereuserid=1a逻辑条件And1=2or1=1使得拼接的sql语句条件为对，或者为错。逻辑运算1+2例如：=3+8sql关键字Select,delete,from,*,union过滤掉这些特殊的sql命令关键字，可以使得攻击者能够嵌入的恶意sql命令大大减少，减轻造成的危害；实际测试中，对于所有的输入样例都进行验证一次，工作量十分庞大，且没有必要。一般来说，只要其中的一个输入能够导致发生sql注入，那么便可以表明该模块的sql过滤是存在问题的。3）如何判断发生了sql注入我们知道了如何构造输入来验证是否存在sql注入，那么怎么根据返回的结果来判断发生了sql注入呢？a.打开debug日志。一般来说通过以上异常输入最后提交的sql语句都可能会造成数据库执行出错，如果打开了debug日志，这些错误信息就会显示在页面上。给一个简单的例子：通过构造异常的get参数，如***.com/main_weblist.asp?key_city=1'页面返回结果可能如下：-------------------------------------MicrosoftOLEDBProviderforODBCDrivers错误'80040e14'[Microsoft][ODBCMicrosoftAccessDriver]字符串的语法错误在查询表达式'web_key=1andweb_city=1''中。/main_weblist.asp，行129-------------------------------------该信息说明：后台数据库是access，发生了语法错误。表明该参数处存在sql注入漏洞。b．如果页面程序针对这种输入不会产生出错信息。我们可以查看系统日志。例如针对java程序，可以查看tomcat日志。分析在提交相应输入时打出的拼接sql语句，查看是否对输入的异常字符进行了过滤，或者逻辑条件能够起到作用。这也要求qa推动rd在开发代码时，对生成拼接sql语句的地方将信息写到日志中，或者留个开关控制输出到页面或其他位置。c．对于逻辑条件和逻辑运算的输入，可以直接查看页面的返回结果。对于逻辑条件，可以分析业务流程处理是否正确。如图1中的登录例子，最后是否能够成功登录系统。对于逻辑运算，例如链接=3+8，查看返回的页面是否为catalog=11的内容。测试case在测试sql注入问题时，需要考虑的点很多，作为QA首先还是需要了解sql注入原理，并掌握该类问题的测试思路。以下，给出了一些测试case的参考，可以给大家作为借鉴。Case1：检查一下参数错误的情况下页面的输出报错信息，是否将详细的报错信息放到了页面上，例如具体到某个类的方法，乃至行号等等。编号websafe_case1功能点参数错误，页面报错信息检查操作1.url中参数值后加入’,例如=1’2.表单中填入’预期结果’用于分割字符串值，常常会作为攻击者试探sql注入漏洞的测试字符,用来破坏查询语句，所以需要对数据库操作中的特殊字符进行过滤。并且输出到页面上的信息要友好。结果记录测试考虑还可以测试其他异常输入：1);2)/*3)--%204)(5))6)非数字字母,例如1a；例如：此时后台会抛出：com.mysql.jdbc.exceptions.MySQLSyntaxErrorException:YouhaveanerrorinyourSQLsyntax…这样的异常。有可能RD会对特殊字符进行过滤，如上述所列出的一些特殊字符，那么怎样去测试可能存在的漏洞呢？以下三个case会针对不同的情况进行SQL注入的测试。Case2：逻辑and测试，这种测试方法较为简单而且实用，并且掌握起来以及实施起来也很快速。编号websafe_case2功能点对url进行修改，加入and，or等逻辑判断操作例如对=1&pagenum=10这样的url进行SQL注入漏洞测试，可以在参数的最后加入and1=1:=1&pagenum=10and1=1成功或者=1&pagenum=10and1=2失败则存在sql注入漏洞。建议最好能对中间的多个参数进行类似测试。如：=1and1=2&pagenum=10因为很可能RD判断漏了一些参数。预期结果这种方法比较简单，也比较实用。结果记录如果RD对”and”这样的输入也进行过滤该如何测试？下面设计了两种语义逻辑上的SQL注入测试case。Case3：数字型逻辑测试。URL的参数中带有这种id=1或者pagesize=10参数，可能RD会在开发中对特殊字符以及”and”“or”这样的字符串都进行了过滤，此时可以采用逻辑测试，逻辑测试的思想很简单：1+1=2的思想，即利用逻辑计算来进行测试，case如下。编号websafe_case3功能点数字逻辑计算进行SQL注入漏洞测试操作如这样的URL：=11可以修改为：=3+8或=3%2b8(3+8)如果返回页面相同，则存在SQL注入漏洞。预期结果结果记录Case4：而对于字符型的参数，也可以采用逻辑测试。url中带有name=abc这种参数，这种参数到后台会被加上单引号’组成查询条件，如：select*fromuseracctwhereusername=’abc’，也可以采用像上个case中提到的方法测试，例如把abc改为ab%2bc，在后台可能会被拼接成username=’ab’+’c’，下面设计了另外两个测试字符型参数的case，主要思想属于同一类。编号websafe_case4功能点字符逻辑计算进行SQL注入漏洞测试操作在SQL中，放在一条select中，’abc’和’ox616263’的查询条件是不同的，但后者却是可以被解释成前者的（“abc”的16进制表示为616263），所以可以针对这点进行SQL注入漏洞的测试。示例如下：将参数中的name=abc改为name=ox616263，检查页面是否相同，如果相同，则存在漏洞。预期结果结果记录Case5：当RD采用了各种过滤方式将以上几种情况，如特殊字符，以及sql的特定字符也都过滤了时，依然可能存在SQL注入漏洞，需要采用一些能够绕过字符验证的手段来测试漏洞，可以采用替换字符编码的方式，下面是相应的case。编号websafe_case5功能点替换字符编码来进行SQL漏洞测试操作将特殊字符通过URL编码替换或者替换成HTML编码提交。例如将空格、and、分号、select等替换成URL编码放在url中，或者替换成HTML编码放在待提交的表单中。利用这些替换后的字符组装成sql语句，如判断语句1=1等来进行访问。预期结果结果记录Case6：SQL注入的形式不单单是通过URL和表单提交，还可以通过cookie进行注入，主要思想也是破坏cookie的内容，如修改cookie的值进行某种注入或者修改过期时间来增加自己使用服务的时间。可能大多数RD开发的时候都会比较注意URL中的参数或者表单提交的数据，如果代码会操作cookie的话，可能会忽略cookie中值的验证，所以这可能也是我们测试所需要关注的一个点。编号websafe_case6功能点利用cookie来进行注入的测试/或者破坏性测试操作1.破坏cookie的内容，检查页面是否报错，是否提示详细错误信息；2.破坏cookie的value，对于IE来说也就是cookie的第二行内容，具体需要利用一些工具来进行修改或者手动修改，思想也是构造如1=2的语句，例如：%27%20and%201%3D2%20，转换后为“'and1=2”。3.破坏cookie中的过期时间，如延长过期时间，获取更长的使用权限等，需要视产品线的功能而定。预期结果结果记录这是目前使用过以及收集到的一些sql注入测试方法，其中的一些比较简单实用，在测试产品的时候也起到了比较好的效果，发现过一些问题。需要提的一点是目前市面上也存在一些漏洞扫描软件，我们可以对一些工具进行试用，也许能够节省不少人力。Sql注入漏洞实例下面简要介绍一些目前在百度产品线上已经发现的sql注入漏洞，使得大家更加深入理解sql注入漏洞以及其危害：1.Unup的登录页面存在sql注入漏洞Unup是百度联盟为网站主提供网站排名信息的一个系统，其登陆页面存在sql注入漏洞。如图2所示：图2unup的登录界面当攻击者输入用户名为“admin'or1=1/*”时，不论输入什么密码，都可以直接登陆up系统的管理端，危害十分严重。2.Union的管理端查询页面存在sql注入Union管理端的查询页面如图3所