一、SQL注入攻击(SQL Injection)
攻击者把SQL命令插入到Web表单的输入域或页面请求的字符串，欺骗服务器执行恶意的SQL命令。在某些表单中，用户输入的内容直接用来构造（或者影响）动态SQL命令，或作为存储过程的输入参数，这类表单特别容易受到SQL注入式攻击。
常见的SQL注入式攻击过程类如：
1.某个Web应用有一个登录页面，这个登录页面控制着用户是否有权访问应用，它要求用户输入一个名称和密码； 2.登录页面中输入的内容将直接用来构造动态的SQL命令，或者直接用作存储过程的参数； 例如：$query = 'SELECT * from Users WHERE login = ' . $username . ' AND password = ' . $password;
3.攻击者在用户名字和密码输入框中输入'或'1'='1之类的内容；
4.用户输入的内容提交给服务器之后，服务器运行上面的代码构造出查询用户的SQL命令，但由于攻击者输入的内容非常特殊，所以最后得到的SQL命令变成：SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'；
5.服务器执行查询或存储过程，将用户输入的身份信息和服务器中保存的身份信息进行对比；
6.由于SQL命令实际上已被注入式攻击修改，已经不能真正验证用户身份，所以系统会错误地授权给攻击者。 如果攻击者知道应用会将表单中输入的内容直接用于验证身份的查询，他就会尝试输入某些特殊的SQL字符串篡改查询改变其原来的功能，欺骗系统授予访问权限。 系统环境不同，攻击者可能造成的损害也不同，这主要由应用访问数据库的安全权限决定。如果用户的帐户具有管理员或其他比较高级的权限，攻击者就可能对数据库的表执行各种他想要做的操作，包括添加、删除或更新数据，甚至可能直接删除表 防范方法： 1.检查变量数据类型和格式 2.过滤特殊符号 3.绑定变量，使用预处理语句
二、跨网站脚本攻击(Cross Site Scripting, XSS)
攻击者将恶意代码注入到网页上，其他用户在加载网页时就会执行代码，攻击者可能得到包括但不限于更高的权限（如执行一些操作）、私密网页内容、会话和cookie等各种内容。这些恶意代码通常是JavaScript、HTML以及其他客户端脚本语言。
例如：如果传入一段脚本<script>[code]</script>，那么脚本也会执行。用这样的URL将会执行JavaScript的alert函数弹出一个对话框：http://localhost/test.php?name=<script>alert(123456)</script>
常用的攻击手段有： 1.盗用cookie，获取敏感信息； 2.利用iframe、frame、XMLHttpRequest或上述Flash等方式，以（被攻击）用户的身份执行一些管理动作，或执行一些一般的如发微博、加好友、发私信等操作； 3.利用可被攻击的域受到其他域信任的特点，以受信任来源的身份请求一些平时不允许的操作，如进行不当的投票活动； 在访问量极大的一些页面上的XSS可以攻击一些小型网站，实现DDoS攻击的效果。 防范方法：1.使用htmlspecialchars函数将特殊字符转换成HTML编码，过滤输出的变量;
2.禁止JS获取cookie，
如设置：
PHP 5.2以下支持 header("Set-Cookie: hidden=value; httpOnly");
PHP5.2以上支持 ini_set("session.cookie_httponly", 1);
三、跨网站请求伪造攻击(Cross Site Request Forgeries, CSRF)
攻击者伪造目标用户的HTTP请求，然后此请求发送到有CSRF漏洞的网站，网站执行此请求后，引发跨站请求伪造攻击。攻击者利用隐蔽的HTTP连接，让目标用户在不注意的情况下单击这个链接，由于是用户自己点击的，而他又是合法用户拥有合法权限，所以目标用户能够在网站内执行特定的HTTP链接，从而达到攻击者的目的。
它与XSS的攻击方法不同，XSS利用漏洞影响站点内的用户，攻击目标是同一站点内的用户者，而CSRF 通过伪装成受害用户发送恶意请求来影响Web系统中受害用户的利益。示例1：
银行网站A，它以GET请求来完成银行转账的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000
危险网站B，它里面有一段HTML的代码如下：
<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
首先，你登录了银行网站A，然后访问危险网站B，噢，这时你会发现你的银行账户少了1000块......
为什么会这样呢？原因是银行网站A违反了HTTP规范，使用GET请求更新资源。在访问危险网站B的之前，你已经登录了银行网站A，而B中的<img>以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代码：
<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
和示例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 οnlοad="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种最为严重，因为触发条件很简单，一个<img>就可以了，而第3种比较麻烦，需要使用JavaScript，所以使用的机会会比前面的少很多，但无论是哪种情况，只要触发了CSRF攻击，后果都有可能很严重。
理解上面的3种攻击模式，其实可以看出，CSRF攻击是源于WEB的隐式身份验证机制！WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的！
防范方法： 1、检查网页的来源 2、检查内置的隐藏变量 3、使用POST，不要使用GET，处理变量也不要直接使用$_REQUEST 4、添加验证码 5、添加表单令牌，使用存在服务器端的Session，如：1).先是令牌生成函数(gen_token())：
<?php
function gen_token() { //这里我是贪方便，实际上单使用Rand()得出的随机数作为令牌，也是不安全的。 //这个可以参考我写的Findbugs笔记中的 $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表单生成隐藏输入域的函数：
<?php
function gen_input() { gen_stoken(); echo “<input type=\”hidden\” name=\”" . FTOKEN_NAME . “\” 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>
四、Session固定攻击(Session Fixation)
攻击者预先设定session id，让合法用户使用这个session id来访问被攻击的应用程序，一旦用户的会话ID被成功固定，攻击者就可以通过此session id来冒充用户访问应用程序。
例如: 1.攻击者访问网站http:///www.bank.com，获取他自己的session id，如：SID=123； 2.攻击者给目标用户发送链接，并带上自己的session id，如：http:///www.bank.com/?SID=123； 3.目标用户点击了http:///www.bank.com/?SID=123，像往常一样，输入自己的用户名、密码登录到网站； 4.由于服务器的session id不改变，现在攻击者点击http:///www.bank.com/?SID=123，他就拥有了目标用户的身份，可以为所欲为了。 防范方法： 1.定期更改session idsession_regenerate_id(TRUE);//删除旧的session文件，每次都会产生一个新的session id。默认false，保留旧的session
2.更改session的名称
session的默认名称是PHPSESSID，此变量会保存在cookie中，如果攻击者不抓包分析，就不能猜到这个名称，阻挡部分攻击session_name("mysessionid"); 3.关闭透明化session id
透明化session id指当浏览器中的http请求没有使用cookie来制定session id时，sessioin id使用链接来传递int_set("session.use_trans_sid", 0); 4.只从cookie检查session id
int_set("session.use_cookies", 1);//表示使用cookies存放session idint_set("session.use_only_cookies", 1);//表示只使用cookies存放session id 5.使用URL传递隐藏参数
$sid = md5(uniqid(rand()), TRUE));$_SESSION["sid"] = $sid;//攻击者虽然能获取session数据，但是无法得知$sid的值，只要检查sid的值，就可以确认当前页面是否是web程序自己调用的
五、Session劫持攻击(Session Hijacking)
攻击者利用各种手段来获取目标用户的session id。一旦获取到session id，那么攻击者可以利用目标用户的身份来登录网站，获取目标用户的操作权限。
攻击者获取目标用户session id的方法: 1.暴力破解:尝试各种session id，直到破解为止; 2.计算:如果session id使用非随机的方式产生，那么就有可能计算出来; 3.窃取:使用网络截获，xss攻击等方法获得 防范方法： 1.定期更改session id 2.更改session的名称 3.关闭透明化session id 4.设置HttpOnly。通过设置Cookie的HttpOnly为true，可以防止客户端脚本访问这个Cookie，从而有效的防止XSS攻击。
六、文件上传漏洞攻击(File Upload Attack)
攻击者利用程序缺陷绕过系统对文件的验证与处理策略将恶意代码上传到服务器并获得执行服务器端命令的能力。
常用的攻击手段有： 上传Web脚本代码，Web容器解释执行上传的恶意脚本； 上传Flash跨域策略文件crossdomain.xml，修改访问权限(其他策略文件利用方式类似)； 上传病毒、木马文件，诱骗用户和管理员下载执行； 上传包含脚本的图片，某些浏览器的低级版本会执行该脚本，用于钓鱼和欺诈。 总的来说，利用的上传文件要么具备可执行能力(恶意代码)，要么具备影响服务器行为的能力(配置文件)。 防范方法： 1.文件上传的目录设置为不可执行； 2.判断文件类型，设置白名单。对于图片的处理，可以使用压缩函数或者resize函数，在处理图片的同时破坏图片中可能包含的HTML代码； 3.使用随机数改写文件名和文件路径：一个是上传后无法访问；再来就是像shell、.php 、.rar和crossdomain.xml这种文件，都将因为重命名而无法攻击； 4.单独设置文件服务器的域名：由于浏览器同源策略的关系，一系列客户端攻击将失效，比如上传crossdomain.xml、上传包含Javascript的XSS利用等问题将得到解决。