网站建设方案之目标网站建设执招标评分表
目录
1.SQL Injection(SQL注入)
2.Cross-site scritping(XSS):(跨站点脚本攻击)
3.CSRF:(跨站点伪造请求)
4.Email Header Injection(邮件标头注入)
5.Directory Traversal(目录遍历)
6.exposed error messages(错误信息)
1.SQL Injection（SQL注入）
（1) 如何进行SQL注入测试？
- 首先找到带有参数传递的URL页面，如 搜索页面，登录页面，提交评论页面等等。
注1：对 于未明显标识在URL中传递参数的，可以通过查看HTML源代码中的"FORM"标签来辨别是否还有参数传递。在<FORM> 和</FORM>的标签中间的每一个参数传递都有可能被利用。
| <form id="form_search" action="/search/" method="get"> <div> <input type="text" name="q" id="search_q" value="" /> <input name="search" type="image" src="/media/images/site/search_btn.gif" /> <a href="/search/" class="fl">Gamefinder</a> </div> </form> |
注 2：当你找不到有输入行为的页面时，可以尝试找一些带有某些参数的特殊的URL，如HTTP://DOMAIN/INDEX.ASP?ID=10
- 其 次，在URL参数或表单中加入某些特殊的SQL语句或SQL片断，如在登录页面的URL中输入HTTP://DOMAIN /INDEX.ASP?USERNAME=HI' OR 1=1--
| 注1：根据实际情况，SQL注入请求可以使用以下语句： ' or 1=1- - " or 1=1- - or 1=1- - ' or 'a'='a " or "a"="a ') or ('a'='a 例子：在登录时进行身份验证时，通常使用如下语句来进行验证：sql=select * from user where username='username' and pwd='password' 如 输入 href="http://" http://duck/index.asp？username=admin' or 1='1&pwd=11，SQL语句会变成以下：sql=select * from user where username='admin' or 1='1' and password='11' ' 与admin前面的'组成了一个查询条件，即username='admin'，接下来的语句将按下一个查询条件来执行. 接 下来是OR查询条件，OR是一个逻辑运算符，在判断多个条件的时候，只要一个成立，则等式就成立，后面的AND就不再时行判断了，也就是 说我们绕过了密码验证，我们只用用户名就可以登录. 如 输入http://duck/index.asp？username=admin'--&pwd=11，SQL语 句会变成以下sql=select * from user where name='admin' --' and pasword='11'， '与admin前面的'组成了一个查 询条件，即username='admin'，接下来的语句将按下一个查询条件来执行 |
- 最后，验证是否能入侵成功或是出错的信息是否包含关于数据库服务器 的相关信息；如果 能说明存在SQL安 全漏洞。
- 试想，如果网站存在SQL注入的危险，对于有经验的恶意用户还可能猜出数据库表和表结构，并对数据库表进行增\删\改的操 作，这样造成的后果是非常严重的。
（2）如何预防SQL注入？
从应用程序的角度来讲，我们要做以下三项工作：
- 转义敏感字符及字符串（SQL的敏感字符包括“exec”，”xp_”，”sp_”，”declare”，”Union”，”cmd”，”+”，”//”，”..”，”;”，”‘”，”--”，”%”，”0x”，”><=!-*/()|”，和”空格”）。
- 屏蔽出错信息：阻止攻击者知道攻击的结果
- 在服务端正式处理之前提交数据的合法性（合法性检查主要包括三项：数据类型，数据长度，敏感字符的校验）进行检查等。最根本的解决手段，在确认客 户端的输入合法之前，服务端拒绝进行关键性的处理操作。
从测试人员的角度来讲，在程序开发前（即需求阶段），我们就应该有意识的将安全性检查应用到需求测试中，例如对一个表单需求进行检查时，我们一般检验以下几项安全性问题：
- 需求中应说明表单中某一FIELD的类型，长度，以及取值范围（主要作用就是禁止输入敏感字符）。
- 需求中应说明如果超出表单规定的类型，长度，以及取值范围的，应用程序应给出不包含任何代码或数据库信息的错误提示。
当然在执行测试的过程中，我们也需求对上述两项内容进行测试。
2.Cross-site scritping(XSS)：（跨站点脚本攻击）
（1）如何进行XSS测试？
- <!--[if !supportLists]-->首先，找到带有参数传递的URL，如 登录页面，搜索页面，提交评论，发表留言页面等等。
- <!--[if !supportLists]-->其次，在页面参数中输入如下语句（如：Javascrīpt，VB scrīpt， HTML，ActiveX， Flash）来进行测试：
| <scrīpt>alert(document.cookie)</scrīpt> |
注：其它的XSS测试语句
| ><scrīpt>alert(document.cookie)</scrīpt> |
- 最后，当用户浏览 时便会弹出一个警告框，内容显示的是浏览者当前的cookie串，这就说明该网站存在XSS漏洞。
- 试想如果我们注入的不是以上这个简单的测试代码，而是一段经常精心设计的恶意脚本，当用户浏览此帖时，cookie信息就可能成功的被 攻击者获取。此时浏览者的帐号就很容易被攻击者掌控了。
（2）如何预防XSS漏洞？
从应用程序的角度来讲，要进行以下几项预防：
- 对Javascrīpt，VB scrīpt， HTML，ActiveX， Flash等 语句或脚本进行转义。
- 在 服务端正式处理之前提交数据的合法性（合法性检查主要包括三项：数据类型，数据长度，敏感字符的校验）进行检查等。最根本的解决手段，在确认客户端的输入合法之前，服务端 拒绝进行关键性的处理操作。
从测试人员的角度来讲，要从需求检查和执行测试过程两个阶段来完成XSS检查：
- 在需求检查过程中对各输入项或输出项进行类型、长度以及取 值范围进行验证，着重验证是否对HTML或脚本代码进行了转义。
- 执行测试过程中也应对上述项进行检查。
3.CSRF：(跨站点伪造请求)
CSRF尽管听起来像跨站脚本（XSS），但它与XSS非常不同，并且攻击方式几乎相左。
XSS是利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。
XSS也好，CSRF也好，它的目的在于窃取用户的信息，如SESSION 和 COOKIES
（关于SESSION 和COOKIES的介绍请参见我的另一篇BLOG：http://www.51testing.com/？49689/action_viewspace_itemid_74885.html），
（1）如何进行CSRF测试？
关于这个主题本人也正在研究，目前主要通过安全性测试工具来进行检查。
（2）如何预防CSRF漏洞？
- 请参见http://www.hanguofeng.cn/archives/security/preventing-csrf
- 请 参见http://getahead.org/blog/joe/2007/01/01/csrf_attacks_or_how_to_avoid_exposing_your_gmail_contacts.html
4.Email Header Injection（邮件标头注入）
Email Header Injection：如果表单用于发送email，表单中可能包括“subject”输入项（邮件标题），我们要验证subject中应能escape掉“\n”标识。
<!--[if !supportLists]--><!--[endif]-->因为“\n”是新行，如果在subject中输入“hello\ncc:spamvictim@example.com”，可能会形成以下
Subject: hello
cc: spamvictim@example.com
<!--[if !supportLists]--><!--[endif]-->如果允许用户使用这样的subject，那他可能会给利用这个缺陷通过我们的平台给其它用 户发送垃圾邮件。
5.Directory Traversal（目录遍历）
（1）如何进行目录遍历测试？
- 目录遍历产生的原因是：程序中没有过滤用户输入的“../”和“./”之类的目录跳转符，导致恶意用户可以通过提交目录跳转来遍历服务器上的任意文件。
- 测试方法：在URL中输入一定数量的“../”和“./”，验证系统是否ESCAPE掉了这些目录跳转符。
（2）如何预防目录遍历？
- 限制Web应用在服务器上的运行
- 进 行严格的输入验证，控制用户输入非法路径
6.exposed error messages（错误信息）
（1）如何进行测试？
- 首 先找到一些错误页面，比如404，或500页面。
- 验证在调试未开通过的情况下，是否给出了友好的错误提示信息比如“你访问的页面不存 在”等，而并非曝露一些程序代码。
（2）如何预防？
- 测试人员在进行需求检查时，应该对出错信息 进行详细查，比如是否给出了出错信息，是否给出了正确的出错信息。