注入


其实注入这种漏洞,基本上是由于对于用户输入过滤不严格产生的,通常所说的注入式SQL注入,也是最常见的一种,


其他几种,出现频率相对较低。



os命令注入


与SQL注入类似,只不过此注入是针对os命令的,及如果有注入点存在,并且有root权限,可以执行OS命令。


XPath注入


基于XMP存储数据的注入,较少见,其中要使用到XPath布尔化查询。


比如登陆检验需要这样



//users/user[loginID/text()=’abc’ and password/text()=’test123’]


如果要绕过验证,使用如下构造

 

//users/user[LoginID/text()=’’ or 1=1 and password/text()=’’ or 1=1]


除了语法不通,其它与SQL注入类似。

 

LDAP注入


LightWeight Directory Access Protocol 也是一种数据存储方式。


不算太了解 > <



SQL注入


最常见的,注入方式,不多费口舌了。


JSON注入


JavaScript Object Notation 是一种轻量级的数据交换格式,入侵者可以通过,JSON插入额外的数据。



跨站脚本(xss)


偏向社工的一种入侵手法,比较被动。


反射式


也称非永久性xss,通常把利用脚本写在URL中,通过邮件等方式进行传播。


存储式


也称为永久行xss,脚本会被存储在服务器中,通常会有自我扩散的特性,如果在社交网络上会形成蠕虫。


基于JS的XSS


由JS引入的xss


基于HTML的XSS


由html引入的xss




会话攻击

会话劫持


使用xss等方法,取得用户的sessionID,进而获取访问权限。


会话固定


自己创建sessionID,诱使用户用此ID进行登录(我对此方法的可行性抱有很大的怀疑)


非直接会话


这种情况,后代代码在验证用户和保存session之间有逻辑错误,而产生的用户验证失败却保存了session的情况。


例如,流程如下,这里如果用户想行终止了最后的转跳,那么逻辑就会出现错误



(1)login.asp 中去除所有session
(2)创建一个新的session,将用户名付给此session
(3)如果用户验证成功,转跳欢迎界面
(4)如果验证失败,转跳到login.asp

其实这种情况还是很少见的>_< 




跨站请求伪造


与xss类似,在用户信任的网站插入恶意代码,不过csrf是引导用户去另外一个网站,如果用户恰巧储存了这个网站的cookie或


session,那么就可以以该用户的身份进行操作。


GET请求伪造


get方式一般比较简单


请求页面



http://www.mybank.com/Transfer.php?toBankId=11&money=1000

js代码


<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

如果前端页面使用的是post,而后端直接使用request来读取,也可以简单地使用get方式。


POST请求伪造


请求页面



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


js代码


<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>


验证码与操作确认

可以较为完美的解决CSRF问题,但是会给用户操作带来负担,安全与方便不能两全。


SESSION令牌


令牌可以解决大部分csrf攻击,但也不能高枕无忧,如果目标站也存在xss漏洞的话(这种概率是极小的)



生成令牌



<?php
function gen_token() {
    //这里我是贪方便,实际上单使用Rand()得出的随机数作为令牌,也是不安全的。
    //这个可以参考我写的Findbugs笔记中的《Random object created and used only once》
$token = md5(uniqid(rand(), true));
return $token;
}
<?php
  function gen_stoken() {
      $pToken = "";
      if($_SESSION[STOKEN_NAME] == $pToken){
        //没有值,赋新值
        $_SESSION[STOKEN_NAME] = gen_token();
      }
      else{
        //继续使用旧的值
      }
  }
?>


表单提交



<?php
   function gen_input() {
   gen_stoken();
   echo “<input type=\”hidden\” name=\”" . FTOKEN_NAME . “\”
   value=\”" . $_SESSION[STOKEN_NAME] . “\”> “;
  }
?>
<?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>



没有限制的URL访问



未验证的重定向与转发