前言
安全无小事,任意一个小的安全漏洞都会造成非常严重的后果。我们一起来看下有哪些安全漏洞和常见预防措施
CSRF
介绍和危害
CSRF跨站请求伪造，通常是用户在不知情的情况下执行了攻击者伪造的请求。可能造成的危害比如: 强制关注，强制收藏,发送垃圾信息,转账,付款,修改密码等。
如何防范
常见的思路都是使用Token来进行验证。
- 服务端强Token验证
服务端比对Token,Token 由服务端下发到客户端,每次POST请求时候都会带上CSRF token 被放在表单中一起提交。提交后,服务端校验表单中的token 和session中的token 值是否一致。不一致则为CSRF攻击 - 双cookie提交校验(Double Submit Cookie)
这种策略的安全性基于攻击脚本无法跨域读取Cookie值。如果服务端没有提供session机制。可以在用户认知完成时，同时设置一个随机token 存储在Cookie中。
当用户提交表单时,读取Cookie中的token，附加在表单或者Header中一起发送。有服务端验证Cookie和参数值是否合法。
由于需要去用Cookie的值作为Token。所以cookie需要标识为httponly,当攻击者结合XSS漏洞,子域名XSS，CRLF漏洞,畸形Cookie等Cookie值可以被注入或固定时，此种防御方法就会被绕过 - 手动校验加验证码
XSS
反射性XSS
也就是攻击相对于访问者而言是一次性的，具体表现在我们把我们的恶意脚本通过url的方式传递给了服务器，而服务器则只是不加处理的把脚本“反射”回访问者的浏览器而使访问者的浏览器执行相应的脚本。
也就是说想要触发漏洞，需要访问特定的链接才能够实现。
什么是储存型XSS
它与反射型XSS最大的不同就是服务器再接收到我们的恶意脚本时会将其做一些处理。
例如储存到数据库中，然后当我们再次访问相同页面时，将恶意脚本从数据库中取出并返回给浏览器执行。这就意味着只要访问了这个页面的访客，都有可能会执行这段恶意脚本，因此储存型XSS的危害会更大。
XSS的防范
XSS 存在的根本原因是我们队URL中的参数或者用户输入的数据没有充分的过滤。这些不合法的数据存在服务端或者数据库。这些不合法的代码又在客户端被执行了。
我们要对输入(包括URL参数)进行过滤，同时对输出进行编码。Cookie需要设置为http-only
CSP
XSS的防御需要采取很多编程的措施，非常麻烦。能不能从根本解决，浏览器自动禁止外部注入恶意的脚本?
这就是CSP的来历,CSP实质是白名单的机制，开发者明确告诉浏览器。哪些外部资源可以执行和加载。它的实现和执行完全由浏览器实现。开发者只需要提供配置。
开启方式
- 通过HTTP头部信息
Content-Security-Policy
image
- 通过网页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，即不加载任何资源
- 样式表：只信任cdn.example.org和third-party.org
- 框架（frame）：必须使用HTTPS协议加载
- 其他资源：没有限制
参考 http://www.ruanyifeng.com/blog/2016/09/csp.html
SSRF
Server-Side Request Forgery，服务器端请求伪造）通俗的来说就是我们可以伪造服务器端发起的请求，从而获取客户端所不能得到的数据。SSRF漏洞形成的原因主要是服务器端所提供的接口中包含了所要请求的内容的URL参数，并且未对客户端所传输过来的URL参数进行过滤
服务端接受客户端的URL然后服务端拿你给你的URL去请求，然后返回给客户端。
class DemoController extends app.Controller {
const response = this.curl(this.request.url);
this.ctx.body = response.body;
}
上面的代码会造成SSRF漏洞
网友评论