一、XSS
首先说下最常见的 XSS 漏洞，XSS (Cross Site Script)，跨站脚本攻击，因为缩写和 CSS (Cascading Style Sheets) 重叠，所以只能叫 XSS。
XSS 的原理是恶意攻击者往 Web 页面里插入恶意可执行网页脚本代码，当用户浏览该页之时，嵌入其中 Web 里面的脚本代码会被执行，从而可以达到攻击者盗取用户信息或其他侵犯用户安全隐私的目的。XSS 的攻击方式千变万化，但还是可以大致细分为几种类型。
1、非持久型 XSS
非持久型 XSS 漏洞，也叫反射型 XSS 漏洞，一般是通过给别人发送带有恶意脚本代码参数的 URL，当 URL 地址被打开时，特有的恶意代码参数被 HTML 解析、执行。一个例子，比如你的 Web 页面中包含有以下代码：
<select>
<script>
document.write(''
+ '<option value=1>'
+ location.href.substring(location.href.indexOf('default=') + 8)
+ '</option>'
);
document.write('<option value=2>English</option>');
</script>
</select>
攻击者可以直接通过 URL (类似：https://xx.com/xx?default=<script>alert(document.cookie)</script>) 注入可执行的脚本代码。
非持久型 XSS 漏洞攻击有以下几点特征：（1）即时性，不经过服务器存储，直接通过 HTTP 的 GET 和 POST 请求就能完成一次攻击，拿到用户隐私数据；（2）攻击者需要诱骗点击；（3）反馈率低，所以较难发现和响应修复；（4）盗取用户敏感保密信息。
为了防止出现非持久型 XSS 漏洞，需要确保这么几件事情：
（1）Web 页面渲染的所有内容或者渲染的数据都必须来自于服务端。
（2）尽量不要从 URL，document.referrer，document.forms 等这种 DOM API 中获取数据直接渲染。
（3）尽量不要使用 eval/new Function()/document.write()/document.writeln()/window.setInterval()/window.setTimeout()/innerHTML/document.creteElement() 等可执行字符串的方法
（4）如果做不到以上几点，也必须对涉及 DOM 渲染的方法传入的字符串参数做 escape 转义。
（5）前端渲染的时候对任何的字段都需要做 escape 转义编码。
2、持久型 XSS
持久型 XSS 漏洞，也被称为存储型 XSS 漏洞，一般存在于 Form 表单提交等交互功能，如发帖留言，提交文本信息等，黑客利用的 XSS 漏洞，将内容经正常功能提交进入数据库持久保存，当前端页面获得后端从数据库中读出的注入代码时，恰好将其渲染执行。主要注入页面方式和非持久型 XSS 漏洞类似，只不过持久型的数据不是来源于 URL，refferer，forms 等，而是来源于后端从数据库中读出来的数据。持久型 XSS 攻击不需要诱骗点击，黑客只需要在提交表单的地方完成注入即可，但是这种 XSS 攻击的成本相对还是很高。
攻击成功需要同时满足以下几个条件：（1）POST 请求提交表单后端没做转义直接入库。（2）后端从数据库中取出数据没做转义直接输出给前端。（3）前端拿到后端数据没做转义直接渲染成 DOM。
为了防止持久型 XSS 漏洞，需要前后端共同努力：
（1）后端在入库前应该选择不相信任何前端数据，将所有的字段统一进行转义处理。
（2）后端在输出给前端数据统一进行转义处理。
（3）前端在渲染页面 DOM 的时候应该选择不相信任何后端数据，任何字段都需要做转义处理。
XSS原理：Xss(cross-site scripting)攻击指的是攻击者往Web页面里插入恶意html标签或者javascript代码。比如：攻击者在论坛中放一个看似安全的链接，骗取用户点击后，窃取cookie中的用户私密信息（非持久型）；或者攻击者在论坛中加一个恶意表单，当用户提交表单的时候，却把信息传送到攻击者的服务器中（持久型），而不是用户原本以为的信任站点。
XSS防范方法：首先代码里对用户输入的地方和变量都需要仔细检查长度和对”<”,”>”,”;”,”’”等字符做过滤；其次任何内容写到页面之前都必须加以encode，避免不小心把html tag 弄出来。这一个层面做好，至少可以堵住超过一半的XSS 攻击。
CSRF（Cross-Site Request Forgery），中文名称：跨站请求伪造攻击
那么 CSRF 到底能够干嘛呢？你可以这样简单的理解：攻击者可以盗用你的登陆信息，以你的身份模拟发送各种请求。攻击者只要借助少许的社会工程学的诡计，例如通过 QQ 等聊天软件发送的链接(有些还伪装成短域名，用户无法分辨)，攻击者就能迫使 Web 应用的用户去执行攻击者预设的操作。例如，当用户登录网络银行去查看其存款余额，在他没有退出时，就点击了一个 QQ 好友发来的链接，那么该用户银行帐户中的资金就有可能被转移到攻击者指定的帐户中。
所以遇到 CSRF 攻击时，将对终端用户的数据和操作指令构成严重的威胁。当受攻击的终端用户具有管理员帐户的时候，CSRF 攻击将危及整个 Web 应用程序。
1、CSRF 原理
下图大概描述了 CSRF 攻击的原理，可以理解为有一个小偷在你配钥匙的地方得到了你家的钥匙，然后拿着要是去你家想偷什么偷什么。
CSRF 攻击必须要有三个条件：
（1）用户已经登录了站点 A，并在本地记录了 cookie
（2）在用户没有登出站点 A 的情况下（也就是 cookie 生效的情况下），访问了恶意攻击者提供的引诱危险站点 B (B 站点要求访问站点A)；
（3）站点 A 没有做任何 CSRF 防御
你也许会问：「如果我不满足以上三个条件中的任意一个，就不会受到 CSRF 的攻击」。其实可以这么说的，但你不能保证以下情况不会发生：你不能保证你登录了一个网站后，不再打开一个 tab 页面并访问另外的网站，特别现在浏览器都是支持多 tab 的。你不能保证你关闭浏览器了后，你本地的 cookie 立刻过期，你上次的会话已经结束。上图中所谓的攻击网站 B，可能是一个存在其他漏洞的可信任的经常被人访问的网站。
示例：银行网站A，它以GET请求来完成银行转账的操作，如：http://www.mybank.com/Transfe…
危险网站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，结果银行网站服务器收到请求后，认为这是一个更新资源操作(转账操作)，所以就立刻进行转账操作……
其实可以看出，CSRF攻击是源于WEB的隐式身份验证机制，WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的!
2、预防 CSRF
CSRF 的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的 CSRF 防御也都在服务端进行。服务端的预防 CSRF 攻击的方式方法有多种，但思路上都是差不多的，主要从以下两个方面入手：
（1）正确使用 GET，POST 请求和 cookie
（2）在非 GET 请求中增加 token
一般而言，普通的 Web 应用都是以 GET、POST 请求为主，还有一种请求是 cookie 方式。我们一般都是按照如下规则设计应用的请求：
（1）GET 请求常用在查看，列举，展示等不需要改变资源属性的时候（数据库 query 查询的时候）
（2）POST 请求常用在 From 表单提交，改变一个资源的属性或者做其他一些事情的时候（数据库有 insert、update、delete 的时候）
当正确的使用了 GET 和 POST 请求之后，剩下的就是在非 GET 方式的请求中增加随机数，这个大概有三种方式来进行：（1）为每个用户生成一个唯一的 cookie token，所有表单都包含同一个伪随机值，这种方案最简单，因为攻击者不能获得第三方的 cookie(理论上)，所以表单中的数据也就构造失败，但是由于用户的 cookie 很容易由于网站的 XSS 漏洞而被盗取，所以这个方案必须要在没有 XSS 的情况下才安全。（2）每个 POST 请求使用验证码，这个方案算是比较完美的，但是需要用户多次输入验证码，用户体验比较差，所以不适合在业务中大量运用。（3）渲染表单的时候，为每一个表单包含一个 csrfToken，提交表单的时候，带上 csrfToken，然后在后端做 csrfToken 验证。
CSRF 的防御可以根据应用场景的不同自行选择。CSRF 的防御工作确实会在正常业务逻辑的基础上带来很多额外的开发量，但是这种工作量是值得的，毕竟用户隐私以及财产安全是产品最基础的根本。
三、SQL 注入
SQL 注入漏洞（SQL Injection）是 Web 开发中最常见的一种安全漏洞。可以用它来从数据库获取敏感信息，或者利用数据库的特性执行添加用户，导出文件等一系列恶意操作，甚至有可能获取数据库乃至系统用户最高权限。
而造成 SQL 注入的原因是因为程序没有有效的转义过滤用户的输入，使攻击者成功的向服务器提交恶意的 SQL 查询代码，程序在接收后错误的将攻击者的输入作为查询语句的一部分执行，导致原始的查询逻辑被改变，额外的执行了攻击者精心构造的恶意代码。
很多 Web 开发者没有意识到 SQL 查询是可以被篡改的，从而把 SQL 查询当作可信任的命令。殊不知，SQL 查询是可以绕开访问控制，从而绕过身份验证和权限检查的。更有甚者，有可能通过 SQL 查询去运行主机系统级的命令。
sql注入原理：就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令
防范方法：总的来说有以下几点：1、永远不要信任用户的输入，要对用户的输入进行校验，可以通过正则表达式，或限制长度，对单引号和双"-"进行转换等；2、永远不要使用动态拼装SQL，可以使用参数化的SQL或者直接使用存储过程进行数据查询存取；3、永远不要使用管理员权限的数据库连接，为每个应用使用单独的权限有限的数据库连接；4、不要把机密信息明文存放，请加密或者hash掉密码和敏感的信息。