随着Web2.0、社交网络、微博等等一系列新型的互联网产品的诞生，基于Web环境的互联网应用越来越广泛，企业信息化的过程中各种应用都架设在Web平台上，Web业务的迅速发展也引起黑客们的强烈关注，接踵而至的就是Web安全威胁的凸显。
黑客利用网站操作系统的漏洞和Web服务程序的SQL注入漏洞等得到Web服务器的控制权限，轻则篡改网页内容，重则窃取重要内部数据，更为严重的则是在网页中植入恶意代码，使得网站访问者受到侵害。
如今，Web安全成为焦点，但网站的漏洞还是频频出现，在白帽子们进行网站测试时，恐怕对于SQL注入、XSS跨站、CSRF接触最多，但对于网站的开发者们来说，对这些熟知多少？本文从开发者的角度，对于XSS和CSRF进行简要概述。
PART1 XSS跨站脚本（Cross-site scripting）
XSS成因概括 ：
XSS其实就是Html的注入问题，攻击者的输入没有经过严格的控制进入了数据库，最终显示给来访的用户，导致可以在来访用户的浏览器里以浏览用户的身份 执行Html代码，数据流程如下：攻击者的Html输入—>web程序—>进入数据库—>web程序—>用户浏览器。
检测方法：
//通常有一些方式可以测试网站是否有正确处理特殊字符：
- ><script>alert(document.cookie)script>
- ='>
- ">
- %3Cscript%3Ealert('XSS')%3C/script%3E
-
XSS')">
-
XSS')"> - XSS'),1)" />（这个仅限 IE 有效）
攻击手段和目的:
攻击者使被攻击者在浏览器中执行脚本后，如果需要收集来自被攻击者的数据（如cookie或其他敏感信息），可以自行架设一个网站，让被攻击者通过JavaScript等方式把收集好的数据作为参数提交，随后以数据库等形式记录在攻击者自己的服务器上。
a. 盗用 cookie ，获取敏感信息。
b.利用植入 Flash ，通过 crossdomain 权限设置进一步获取更高权限；或者利用Java等得到类似的操作。
c.利用 iframe、frame、XMLHttpRequest或上述Flash等方式，以（被攻击）用户的身份执行一些管理动作，或执行一些一般的如发微博、加好友、发私信等操作。
d.利用可被攻击的域受到其他域信任的特点，以受信任来源的身份请求一些平时不允许的操作，如进行不当的投票活动。
e.在访问量极大的一些页面上的XSS可以攻击一些小型网站，实现DDoS攻击的效果。
漏洞的防御和利用:
避免XSS的方法之一主要是将用户所提供的内容进行过滤，许多语言都有提供对HTML的过滤：- PHP的htmlentities()或是htmlspecialchars()。
- Python的cgi.escape()。
- ASP的Server.HTMLEncode()。
- ASP.NET的Server.HtmlEncode()或功能更强的MicrosoftAnti-CrossSiteScriptingLibrary
- Java的xssprotect(OpenSourceLibrary)。
- Node.js的node-validator。
使用HTTP头指定类型:
很多时候可以使用HTTP头指定内容的类型，使得输出的内容避免被作为HTML解析。如在PHP语言中使用以下代码：- header('Content-Type: text/javascript; charset=utf-8');
即可强行指定输出内容为文本/JavaScript脚本（顺便指定了内容编码），而非可以引发攻击的HTML。
PART2 CSRF：冒充用户之手
示意图：
XSS 是实现 CSRF 的诸多途径中的一条，但绝对不是唯一的一条。一般习惯上把通过 XSS 来实现的 CSRF 称为 XSRF。
CSRF 顾名思义，是伪造请求，冒充用户在站内的正常操作。我们知道，绝大多数网站是通过 cookie 等方式辨识用户身份（包括使用服务器端 Session 的网站，因为 Session ID 也是大多保存在 cookie 里面的），再予以授权的。所以要伪造用户的正常操作，最好的方法是通过 XSS 或链接欺骗等途径，让用户在本机（即拥有身份 cookie 的浏览器端）发起用户所不知道的请求。
要完成一次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表单如下：-
- ToBankId:
- Money:
-
后台处理页面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与时俱进，它改了一下代码：
-
- function steal()
- {
- iframe = document.frames["steal"];
- iframe.document.Submit("transfer");
- }
-
-
-
-
-