对于 “OWASP TOP 10” 的一些理解
最近几次电话面试，都比较悲剧，关于面试者比较关注的地方，总不能很好地把握，对于自己蜻蜓点水式的学习方式，很难在面试的时候给人留下很牛逼，很专业，很高深，很强大的感觉，不过现在亡羊补牢或许还为时不晚。
由于很难一次性整理完全，所以先发上来不定期更新
//-------------------------------------------------------------------格叽格叽------------------------------------------------------------------------------
注入
其实注入这种漏洞，基本上是由于对于用户输入过滤不严格产生的，通常所说的注入式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=1000js代码
<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访问
未验证的重定向与转发