参考
Web安全之SQL注入攻击技巧与防范
总结 XSS 与 CSRF 两种跨站攻击
CSRF的攻击与防御
CSRF 攻击的应对之道
一、SQL注入
用Web网站中常用的会员登录系统来做一个场景实例。如果输入正确的用户名 plhwin 和密码 123456，执行的SQL语句为：SELECT uid,username FROM user WHERE username='plhwin' AND password='...' 但如果有捣蛋鬼输入的用户名为 plhwin’ AND 1=1– hack，密码随意输入，比如aaaaaa，那么拼接之后的SQL查询语句就变成了如下内容：SELECT uid,username FROM user WHERE username='plhwin' AND 1=1-- hack' AND password='...'。执行上面的SQL语句，因为1=1是永远成立的条件，这意味着黑客只需要知道别人的会员名，无需知道密码就能顺利登录到系统。
解决方式:
- 检查变量数据类型和格式
- 过滤特殊符号
- 参数化查询，使用预编译语句
二、XSS
XSS 全称“跨站脚本”，是注入攻击的一种。其特点是不对服务器端造成任何伤害，而是通过一些正常的站内交互途径，例如发布评论，提交含有 JavaScript 的内容文本。这时服务器端如果没有过滤或转义掉这些脚本，作为内容发布到了页面上，其他用户访问这个页面的时候就会运行这些脚本。
运行预期之外的脚本带来的后果有很多中，可能只是简单的恶作剧——一个关不掉的窗口：
while (true) {
alert("你关不掉我~");
}
也可以是盗号或者其他未授权的操作。每个访问到含有该评论的页面的用户都会遇到麻烦——他们不知道背后正悄悄的发起了一个请求，是他们所看不到的。而这个请求，会把包含了他们的帐号和其他隐私的信息发送到收集服务器上。
解决方式:过滤输入和转义输出。
三、CSRF
CSRF攻击原理比较简单，如图1所示。其中Web A为存在CSRF漏洞的网站，Web B为攻击者构建的恶意网站，User C为Web A网站的合法用户。
图1 CSRF攻击原理
- 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；
- 在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；
- 用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；
- 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；
- 浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。
再举个例子，一论坛网站的发贴是通过 GET 请求访问，点击发贴之后 JS 把发贴内容拼接成目标 URL 并访问： http://example.com/bbs/create_post.php?title=标题&content=内容 那么，我只需要在论坛中发一帖，包含一链接： http://example.com/bbs/create_post.php?title=我是脑残&content=哈哈 只要有用户点击了这个链接，那么他们的帐户就会在不知情的情况下发布了这一帖子。可能这只是个恶作剧，但是既然发贴的请求可以伪造，那么删帖、转帐、改密码、发邮件全都可以伪造。
如何解决这个问题，我们是否可以效仿上文应对 XSS 的做法呢？过滤用户输入， 不允许发布这种含有站内操作 URL 的链接。这么做可能会有点用，但阻挡不了 CSRF，因为攻击者可以通过 QQ 或其他网站把这个链接发布上去，为了伪装可能还使用 bit.ly 压缩一下网址，这样点击到这个链接的用户还是一样会中招。所以对待 CSRF ，我们的视角需要和对待 XSS 有所区别。CSRF 并不一定要有站内的输入，因为它并不属于注入攻击，而是请求伪造。被伪造的请求可以是任何来源，而非一定是站内。所以我们唯有一条路可行，就是过滤请求的处理者。
比较头痛的是，因为请求可以从任何一方发起，而发起请求的方式多种多样，可以通过 iframe、ajax（这个不能跨域，得先 XSS）、Flash 内部发起请求（总是个大隐患）。由于几乎没有彻底杜绝 CSRF 的方式，我们一般的做法，是以各种方式提高攻击的门槛。
首先可以提高的一个门槛，就是改良站内 API 的设计。对于发布帖子这一类创建资源的操作，应该只接受 POST 请求，而 GET 请求应该只浏览而不改变服务器端资源。当然，最理想的做法是使用REST 风格 的 API 设计，GET、POST、PUT、DELETE 四种请求方法对应资源的读取、创建、修改、删除。现在的浏览器基本不支持在表单中使用 PUT 和 DELETE 请求方法，我们可以使用 ajax 提交请求（例如通过 jquery-form 插件，我最喜欢的做法），也可以使用隐藏域指定请求方法，然后用 POST 模拟 PUT 和 DELETE （Ruby on Rails 的做法）。这么一来，不同的资源操作区分的非常清楚，我们把问题域缩小到了非 GET 类型的请求上——攻击者已经不可能通过发布链接来伪造请求了，但他们仍可以发布表单，或者在其他站点上使用我们肉眼不可见的表单，在后台用 js 操作，伪造请求。
接下来我们就可以用比较简单也比较有效的方法来防御 CSRF，这个方法就是“请求令牌”。读过《J2EE 核心模式》的同学应该对“同步令牌”应该不会陌生，“请求令牌”和“同步令牌”原理是一样的，只不过目的不同，后者是为了解决 POST 请求重复提交问题，前者是为了保证收到的请求一定来自预期的页面。实现方法非常简单，首先服务器端要以某种策略生成随机字符串，作为令牌（token），保存在 Session 里。然后在发出请求的页面，把该令牌以隐藏域一类的形式，与其他信息一并发出。在接收请求的页面，把接收到的信息中的令牌与 Session 中的令牌比较，只有一致的时候才处理请求，否则返回 HTTP 403 拒绝请求或者要求用户重新登录验证身份。
PrideChung 2013-08-23 15:41:03 +08:00
搞清楚CSRF攻击的原理就行了。session id能够标识一个用户，却无法知道该用户提交的表单是自愿主动提交的，还是被骗去点了个链接，被恶意的JS提交的，所以才需要CSRF token。
zzNucker 2013-08-25 13:51:17 +08:00
@leonwong 就算是CSRF劫持的请求也会带上网站的cookie的，所以光验证session并不能避免CSRF。 token的关键是在于你在发送请求的时候一定要保证你是读取了这个页面的。。 而不是凭空就发送请求
etata 40 天前
@binux
还是没说为什么用 token ，不用 sessionid 啊。既然唯一 id ，放在 cookies 也是放，放在 hidden 里也是放。再说 sessionid 在 cookies 禁止的时候也是放在 url 中或者表单中啊。 为什么不统一用一个呢？
binux 40 天前
@etata 唯一 id 一般是固定的， token 可以不是固定的，而是每次访问随机生成的。当然你要把 seesionid 用作 token 也不是不可以。
