Web站点的安全问题，在我看来是十分重要的，如果你的站点频频出现安全问题，那么如何吸引更多的用户呢？进来就来看看Web站点有哪些常见的攻击方式与对应的防范措施吧！
CSRF
CSRF(Cross-site request forgery)跨站请求伪造，也被称为 One Click Attack 或者 Session Riding。
具体指：用户当前已经认证的站点，使用户在不知情的情况下执行了攻击者伪造的请求。
那么如何防范呢？基本思路：Token验证
- 方式一：服务端强token验证
- 方式二：Double cookie submit
- 方式三：Custom Header
其他：验证码
XSS
XSS(Cross Site Scripting)跨站脚本攻击。分为两类：
- 反射型XSS：由于服务端接受到客户端不安全的输入，在客户端触发执行从而发起web攻击。
- 存储型XSS：通过提交带有恶意脚本的内容存储到服务器上，当其他人看到这些内容时发起web攻击。
如何防范XSS攻击呢？解决问题的根本就是知道哪些地方可能存在XSS攻击，对于存在XSS攻击的地方进行转码！大致如下：
- HTML BODY：常见场景就是富文本！容易造成存储型XSS，措施：encode html
- HTML Attributes：html属性是可以闭合标签的
- CSS：因为css支持javascript伪协议，eg：background:url('javascript:alert(1)')
- URL: 因为url也是支持javascript伪协议，eg：href='javascript:alert(1)'
防范XSS攻击的基本原则
- 服务端和客户端均需要转码
- 不要相信用户的输入，过滤之
- 使用http-only的cookie
- 使用web安全头
CSP
注意这不是一种攻击手段，而是防止XSS的解决方案，全称Content Security Policy。
CSP是一种由开发者定义的安全性政策性申明，通过CSP所约束的的规责指定可信的内容来源(这里的内容可以指脚本、图片、iframe、fton、style等等可能的远程的资源)。通过CSP协定，让WEB处于一个安全的运行环境中。
CSP 1.1
- 资源加载的限制
- url限制
- http与https
- report-uri
- unsafe-inline
CSP 2.0
- Content-security-policy: ‘nonce-aaaa';
有两种方式开启CSP，一种是通过HTTP 头信息的Content-Security-Policy的字段，一种是通过标签。
meta标签格式如下：
<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:">
上面代码中，CSP做了如下配置：
- 脚本：只信任当前域名
<object>标签：不信任任何URL，即不加载任何资源- 样式表：只信任
http://cdn.example.org和http://third-party.org - 框架（frame）：必须使用HTTPS协议加载
- 其他资源：没有限制
更多请移步大神教程：Content Security Policy 入门教程
越权
越权攻击主要是由于开发者考虑不全面导致的，如果开发严谨是可以避免的，具体的越权有如下两种形式：
- 水平越权
- 看到了其他人的信息
- 垂直越权
- 普通用户拿到了超级管理员的权限
ID风险
水平越权重灾区：各种管理系统 学校/图书馆/电商/论坛，大部分的水平越权都是由于ID号导致的。因此有艺术的ID设计，有利于分布式+防爬，基本ID规则如下：
- 唯一
- 尽量短
- 无规则
- 不可遍历
此外session和token一定要过期！
如何防止越权呢，基本严谨思路如下：
- 每个页面都要做好权限控制
- ID要取的有艺术
- 不要用一些危险的uri，比如/admin,/manage
- 权限要存在生命周期，记得销毁
- 上线的时候不要把debug版本带上线
- 上线的时候干掉所有的超级管理员
HTTP Splitting
全称HTTP应答拆分攻击，HTTP拆分攻击是指由于Web应用程序缺乏有效的输入验证，允许攻击者将CR和LF字符插入到应用程序响应的报头，从而将服务器的回应拆分成两个不同的HTTP消息的攻击手段。攻击者通过发送经过精心构造的HTTP请求，试图完全控制第二个响应来实现攻击。
原理：CRLF可以允许多段http response 虽然某些浏览有防范，但是可以轻松绕过。
结果：造成存储型XSS，通过提交带有恶意脚本的内容存储在服务上，当其他看到这些内容时发起Web攻击。
攻击场景：接收用户的参数并重定向，写cookie，操作header
SSRF
SSRF(Server-Side Request Forgery:服务器端请求伪造)是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下，SSRF攻击的目标是从外网无法访问的内部系统。(正是因为它是由服务端发起的，所以它能够请求到与它相连而与外网隔离的内部系统)
SSRF形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能且没有对目标地址做过滤与限制。比如从指定URL地址获取网页文本内容，加载指定地址的图片，下载等等。
那么具体什么情况下会造成SSRF攻击
- 从用户指定的url获取图片，保存后展示给用户
- 获取用户指定url的数据(文件或者html)，使用socket跟服务器建立tcp连接
- 根据用户提供的URL，抓取web站点，并且动态生成XX站
- 测速功能，根据用户提供的URL访问目标获取访问速度
如何防范SSRF攻击
- 基本思路：识别危险跳转
- 危险跳转: 内网域名、ip、xip.io
- 直接获取url对应的ip，域名则返回对应ip，然后再对ip进行判断是否为内网ip，即可防御SSRF内网探测
HPP
HPP是HTTP Parameter Pollution的缩写。这是一种注入型的漏洞，攻击者通过在HTTP请求中插入特定的参数来发起攻击。如果Web应用中存在这样的漏洞，可以被攻击者利用来进行客户端或者服务器端的攻击。
通常在一个请求中，同样名称的参数只会出现一次。但是在HTTP协议中是允许同样名称的参数出现多次的。但是针对同样名称的参数出现多次的情况，不同的服务器的处理方式会不一样。比如node中后台就表现为一个对应数组，此时就不是我们想要的！
实际上这本身并没有什么问题，但是前提是Web应用程序的开发者知道这个事情并且有正确的进行处理。否则的话那么难免会对攻击者造成可乘之机。如果对同样名称的参数出现多次的情况没有进行正确处理的话，那么可能会导致漏洞使得攻击者能够利用来发起对服务器端或客户端的攻击。
危险跳转
不安全跳转，钓鱼攻击。
- this.redirect(url)
<img src="http://xx.xxx.xx.xx/fishing/401.php?a.jpg//" />- iframe钓鱼(click jacking)
- 使用x-frame-options
措施：对每次跳转进行安全域名校验
ISP
运营商劫持
- 根本解决办法：使用HTTPS
- 歪招？上HTTPS之前，伪造html标签，''，导致运营商脚本可能就插入到注释中啦
在转HTTPS时，出现mixed content安全警告，解决办法：
- 去scheme：
http://xx/xx.jpg = > //xx/xx.jpg - optionally: img, video, prefetched
- Content-Security-Policy: block-all-mixed-content
XST
XST攻击，Cross-Site Tracing，客户端发TRACE请求至服务器，如果服务器按照标准实现了TRACE响应，则在response body会返回此次请求的完整头信息。通过这种种方式，客户端可以获取某些敏感的头字段，例如httpOnly的cookie。
解决办法：禁止trace track options 三种危险类型请求
TIMING ATTACK
中文名词计时攻击。
原理：比较两个字符串是否相等的话，直接使用==比较的话，如果值越接近，那么耗时越短。那么应该如何比较呢？
module.export = function scmp(a,b){
a = String(a);
b = String(b);
if(a.length !== b.length){
return false;
}
var result = 0;
for(var i = 0;i<a.length;i++){
result |= a.charCodeAt(i)^b.charCodeAt(i);
}
return result == 0;
}