阅读 7535

程序员必须要了解的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:

关注下面的标签,发现更多相似文章
评论