web安全及防护
本文将对web方面的安全问题以及相应的防护方法进行一个简单的介绍。
SQL注入（SQL Injection）
原理：就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说就是用户可以利用恶意的SQL语句提交之后，到后台数据库执行，得到一个存在安全漏洞的网站上的数据库，而不是按照设计者的意图去执行SQL语句。
SQL注入的攻击力到底有多强：轻的话会暴露数据库中的数据，严重的话会对数据库中的数据进行恶意的增删改查。
为什么会发生SQL注入？主要还是程序没有很好地去过滤掉用户输入的数据，导致数据可以非法输入。
根据相关技术原理，SQL注入可以分为平台层注入和代码层注入。前者由不安全的数据库配置或数据库平台的漏洞所致；后者主要是由于程序员对输入未进行细致地过滤，从而执行了非法的数据查询。
关于防护总的来说有以下几点：
1.永远不要信任用户的输入，要对用户的输入进行校验，可以通过正则表达式，或限制长度，对单引号和双"-"进行转换等。
2.永远不要使用动态拼装SQL，可以使用参数化的SQL或者直接使用存储过程进行数据查询存取。
3.永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接。
4.不要把机密信息明文存放，请加密或者hash掉密码和敏感的信息。
可以参考：SQL注入系列的文章
XSS(Cross-site scripting 跨站脚本分析)
XSS攻击指的是攻击者往Web页面里插入恶意 html标签或者javascript代码。比如：攻击者在论坛中放一个看似安全的链接，骗取用户点击后，窃取cookie中的用户私密信息；或者攻击者在论坛中加一个恶意表单，当用户提交表单的时候，却把信息传送到攻击者的服务器中，而不是用户原本以为的信任站点。
分类：
1、反射型跨站脚本(Reflected Cross-site Scripting)。主要是将恶意脚本附加到URL地址的参数中，原理如下：发现存在反射XSS的URL——根据输出点的环境构造XSS代码——进行编码等迷惑手法——发送给受害人——受害打开后，执行XSS代码——完成攻击(获取cookies、url、浏览器信息、IP等)。反射型XSS的特点是只在用户单击时触发，且只执行一次，故也称作非持久型跨站。
http://www.test.com/search.php?key="><script>alert("XSS")</script> http://www.test.com/view.shtml?query=%3Cscript%3Ealert%281%29%3C/script%3E http://www.test.com/logout.asp?out=1&url=javascript:alert(document.cookie)
2、持久型跨站脚本(Persistent Cross-site Scripting)。攻击者事先将恶意Javascript代码上传或储存到漏洞服务器上，只要受害者浏览包含此恶意代码的页面就会中招。一般出现在留言、评论等交互处。
3、DOM XSS。前面两种XSS一般出现在服务器端代码中，而DOM-Based XSS是基于DOM文档对象模型，受客户端浏览器代码的影响。这一漏洞的前提是，一个网页以不安全的方式使用document.location、document.URL、document.referrer等对象获取数据。
举个例子，有如下HTML代码：
<html> <head> <title>Welcome!</title> </head> <body> <p>Hi</p> <script> var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length)); </script> </body> </html>
通常，这个欢迎网页的请求是这样的：
http://www.test.com/welcome.html?name=lihua
然而，如果这个请求是这样的：
http://www.test.com/welcome.html?name=<script>alert(document.cookie)</script>
这就导致了XSS，弹出了cookie。
XSS防范方法
首先代码里对用户输入的地方和变量都需要仔细检查长度和对”<”,”>”,”;”,”’”等字符做过滤；其次任何内容写到页面之前都必须加以encode，避免不小心把html tag 弄出来。这一个层面做好，至少可以堵住超过一半的XSS 攻击。
首先，避免直接在cookie 中泄露用户隐私，例如email、密码等等。
其次，通过使cookie 和系统ip 绑定来降低cookie 泄露后的危险。这样攻击者得到的cookie 没有实际价值，不可能拿来重放。
如果网站不需要再浏览器端对cookie 进行操作，可以在Set-Cookie 末尾加上HttpOnly 来防止javascript 代码直接获取cookie 。
尽量采用POST 而非GET 提交表单
CSRF（Cross-site request forgery 跨站请求伪造）
也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF， 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。就是冒充用户发起请求（在用户不知情的情况下）,完成一些违背用户意愿的请求（如恶意发帖，删帖，改密码，发邮件等）。
关于CSRF与XSS的区别：
CSRF 的全称是“跨站请求伪造”，而 XSS 的全称是“跨站脚本”。看起来有点相似，它们都是属于跨站攻击——不攻击服务器端而攻击正常访问网站的用户，它们的攻击类型是不同维度上的分类。CSRF 顾名思义，是伪造请求，冒充用户在站内的正常操作。我们知道，绝大多数网站是通过 cookie 等方式辨识用户身份（包括使用服务器端 Session 的网站，因为 Session ID 也是大多保存在 cookie 里面的），再予以授权的。所以要伪造用户的正常操作，最好的方法是通过 XSS 或链接欺骗等途径，让用户在本机（即拥有身份 cookie 的浏览器端）发起用户所不知道的请求。
通常来说CSRF是由XSS实现的，所以CSRF时常也被称为XSRF[用XSS的方式实现伪造请求]（但实现的方式绝不止一种，还可以直接通过命令行模式（命令行敲命令来发起请求）直接伪造请求[只要通过合法验证即可]）。 XSS更偏向于代码实现（即写一段拥有跨站请求功能的JavaScript脚本注入到一条帖子里，然后有用户访问了这个帖子，这就算是中了XSS攻击了），CSRF更偏向于一个攻击结果，只要发起了冒牌请求那么就算是CSRF了。
在知乎上看到一句比较形象的对比：如何用简洁生动的语言理清XSS和CSRF的区别？
xss：我（作为公司内部人员）因为内部监管不严混进领导层和领导喝酒打牌
csrf：我（伪装成公司领导）混进领导层里喝酒打牌
XSS是获取信息，不需要提前知道其他用户页面的代码和数据包。CSRF是代替用户完成指定的动作，需要知道其他用户页面的代码和数据包。
要完成一次CSRF攻击，受害者必须依次完成两个步骤：
登录受信任网站A，并在本地生成Cookie。
在不登出A的情况下，访问危险网站B。
CSRF的防御
服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数。
主要可以从三个层面进行，即服务端的防御、用户端的防御和安全设备的防御。服务器端防御CSRF攻击主要有三种策略：验证HTTP Referer字段，在请求地址中添加token并验证，在HTTP头中自定义属性并验证。
参考：
