程序员必需要了解的web安全

本文是读书总结，出自《白帽子讲web安全》 ----吴翰清 有兴趣的同窗能够去阅读。

1.简述

互联网原本是安全的，自从有了研究安全的人以后，互联网就变得不安全了。

1.1什么是安全？

字典的解释是指没有受到威胁、没有危险、危害、损失。

1.2什么状况下会产生安全问题？

相似咱们在机场，火车站里面，乘客开始上车以前，都会有一个必要的程序：安全检查。若是没有安全检查咱们就会产生咱们所谓的安全问题。在安全检查中咱们会检查乘客身上是否携带了打火机，可燃液体等危险物品。

从上面咱们看出为何咱们会有安全检查呢？归根结底仍是信任问题。由于咱们的信任关系被破坏，从而产生了安全问题。

1.3怎么进行有效的安全评估？

一个安全评估过程，能够简单地划分为4个阶段：资产等级划分，威胁分析，风险分析，确认解决方案。

资产等级划分：明确咱们目标是什么，要保护什么。互联网安全的核心问题，实际上是数据安全问题。用户的数据也就是咱们须要保护的。

威胁分析：找到全部可能形成危害的来源，通常采用头脑风暴列举全部的状况。

风险分析：预估形成的损失大小。

确认解决安全方案：安全评估的产出物，就是确认安全解决方案。解决方案必定要有针对性，这种针对性是由资产等级划分，威胁分析，风险分析，确认解决方案。

2.浏览器安全

近年来随着互联网的发展，人们发现浏览器才是互联网最大的入口，绝大多数用户使用互联网的工具是浏览器。所以浏览器市场的竞争也日趋白热化。浏览器安全在这种激烈竞争的环境中被愈来愈多的人所重视。

2.1同源策略

浏览器的安全都是以同源为基础，它是浏览器最核心也最基本的安全功能，若是缺乏了同源策略，则浏览器的正常功能可能都会受到影响。

浏览器的同源策略，限制了来自不一样源的“document”或脚本，对当前"document"读取或设置某些属性。

这一策略很重要，试想一下若是没有同源策略，可能a.com的一段JS脚本，在b.com不曾加载此脚本时，也能够随意涂改b.com的页面。为了避免让浏览器的页面行为发生混乱，浏览器提出了“Origin”这一律念，来自不一样Origin的对象没法互相干扰。

影响“源”的因素有：host,子域名，端口，协议。

2.2恶意网址拦截

恶意网址拦截的工做原理很简单，通常都是浏览器周期性地从服务器端获取一份最新的恶意网址黑名单，若是用户上网时访问的网址存在于此黑名单中，浏览器就会弹出一个警告页面。

3.跨站脚本攻击

跨站脚本攻击(XSS)是客户端脚本安全中的头号大敌。

XSS：跨站脚本攻击，英文名称是Cross Site Script，原本缩写是CSS，为了和层叠样式的CSS有所区别，因此在安全领域叫“XSS”。

3.1XSS攻击

XSS攻击，一般指黑客经过“HTML注入”篡改可网页，插入了恶意的脚本，从而在用户浏览网页时，控制用户浏览器的一种攻击。举个例子：某个黑客发表了一篇文章其中包含了恶意的JS代码，全部访问这篇文章的人都会执行这段JS代码，这样就完成XSS攻击。

3.2反射型XSS

反射型XSS只是简单地把用户输入的数据反射给浏览器。也就是说，黑客每每须要引诱用户点击一个而已链接，才能攻击成功

3.3存储型XSS

存储型会把用户输入的数据“存储”在服务器端。这种XSS具备很强的稳定性。黑客把恶意的脚本保存到用户的服务器端，因此这种攻击就是存储型，理论上来讲，它存在的时间是比较长的。

3.4 XSS的防护

XSS的防护是复杂的。

3.4.1 HttpOnly

HttpOnly最先是由微软提出，并在IE6中实现的，至今已经逐渐成为了一个标准。浏览器将禁止页面的JS访问带有HttpOnly属性的Cookie。

其实严格地说，HttpOnly并不是为了对抗XSS——HttpOnly解决的是XSS后的Cookie劫持攻击。HttpOnly如今已经基本支持各类浏览器，可是HttpOnly只是有助于缓解XSS攻击，但仍然须要其余可以解决XSS漏洞的方案。

3.4.2 输入检查

在XSS的防护上，输入检查通常是检查用户输入的数据中是否包含一些特殊字符，如<,>等等。若是发现这些字符，则将字符过滤或者编码。这种输入检查的方式，能够叫“XSS Filter”。互联网上于不少开源的“XSS Filter”的实现。

XSS Filter在用户提交数据时获取变量，并进行XSS检查；但此时用户数据并无结合渲染页面的HTML代码，所以XSS Filter对语境的理解并不完整。甚至有可能用户输入1<3，直接会把<符号给过滤掉，因此一个好的XSSFilter是比较重要的。

3.4.3输出检查

通常来讲，除了富文本的书除外，在变量输出到HTML页面时，可使用编码火转移的方式来防护XSS攻击。和输入检查差很少。

4.CSRF

4.1什么是CSRF

CSRF：跨站点请求伪造，他是一种常见的Web攻击。

举个例子：咱们有个博客系统当用户登录博客后，只须要请求这个URL，就可以把编号为"1"的博客给删除了。

blog.com/manage/dele…

这个url同时还存在CSRF漏洞，首先攻击者在本身域构造一个页面：

www.a.com/csrf.html

其内容为：

<img src="blog.com/manage/dele…"/>

使用了一个标签，其地址指向了删除博客文章的连接。

攻击者诱使目标用户，也就是博客主访问这个页面：

访问以后博客就会被删除。

4.2CSRF防护

CSRF的攻击主要是在用户不知情的状况下，背着用户偷偷发了请求。

4.2.1验证码

验证码被认为是是CSRF攻击最简洁而有效的防护方法。

由于CSRF攻击的过程当中，每每是在用户不知情的状况下构造了网络请求。验证码其实就是强制用户必须和咱们当前应用交互才能完成请求。

4.2.2referer Check

根据检查当前请求的来源Referer来判断是不是CSRF攻击。判断当前的re

4.2.3anti csrf token

csrf为何可以攻击成功，本质缘由是重要操做的参数均可以被攻击者猜想到，须要新加一个参数token。Token被用户端放在Cookie中，同源页面每次发请求都在请求头或者参数中加入Cookie中读取的Token来完成验证。CSRF只能经过浏览器本身带上Cookie，不能操做Cookie来获取到Token并加到http请求的参数中。由于Token加密后经过Cookie储存，只有同源页面能够读取，把Token做为重要的验证参数，CSRF没法获取Token放在参数中，也没法仿造出正确的token，就被防止掉了。

5.最后

本文是读书总结，出自《白帽子讲web安全》 ----吴翰清 有兴趣的同窗能够去阅读。

想要获取更多信息请关注个人公众号吧

最后这篇文章被我收录于JGrowing，一个全面，优秀，由社区一块儿共建的Java学习路线，若是您想参与开源项目的维护，能够一块儿共建，github地址为:github.com/javagrowing… 麻烦给个小星星哟。

若是你们以为这篇文章对你有帮助，或者想提早获取后续章节文章，或者你有什么疑问想提供1v1免费vip服务，均可以关注个人公众号，你的关注和转发是对我最大的支持，O(∩_∩)O: