文档章节

Web客户端安全性最佳实践

杭城小刘
 杭城小刘
发布于 2015/08/16 22:28
字数 2364
阅读 106
收藏 13

HTTP?想都别想


当然,我并不想让你通过FTP或者普通的TCP协议来传输你的数据。我的意思是,如果你想让你的用户安全地访问你的网站,你应该使用SSL(HTTPS)来加密你的数据传输。不仅要加密登陆节点或者关键信息,而是要加密所有的数据。否则当用户通过公用网络访问你的应用时,他看见的内容说不定已经被别人“黑”掉了。这就叫中间人攻击。


如果你使用SSL,所有的数据在发送之前就会被加密,即使攻击者在网络中截获了数据包,他也没有办法查看或者篡改其中的内容。对于提升应用的安全性,这是目前为止最重要的一步。


严格传输安全性标记(Strict-Transport-Security)


如果你只想通过SSL来传输你的数据,那么这个HTTP头属性会让你觉得非常好用。如果服务器端在响应头中使用了这个标记(你也可以在页面中使用<meta>标签,不过这样的话就会存在一个未被加密的请求),那么所有从客户端到服务器端的数据都会被加密。使用方式如下:


Strict-Transport-Security: max-age=3600; includeSubDomains


其中的includeSubDomains属性是可选的,你可以使用它来加密当前域的子域,所有对子域的访问也会被HTTPS加密。而其中的max-age属性可以设置在多长的时间范围内(以秒为单位)需要用SSL对页面数据传输进行加密。不过可惜的是,目前只有Firefox、Chrome和Opera浏览器支持这个标记。


Secure和HttpOnly属性


还有一种方法可以有效增强HTTP和HTTPS访问的安全性,那就是使用Secure和HttpOnly这两个cookie属性。前者能确保cookie的内容只通过SSL连接进行传输;而后者可能听起来正好相反。如果你觉得这两者互相矛盾,没啥用处,那就错了。其实HttpOnly属性的真正作用是限制只能通过HTTP协议访问cookie,而不能通过本地脚本访问,从而避免了被别人轻易窃取,比如JavaScript中的document.cookie. (感谢personball指正,已修正)


通过Content-Security-Policy(CSP)标记来减少跨站脚本攻击(XSS)的危害


如果你觉得依靠XSS过滤器能够防范所有可能的XSS攻击,不妨先看一看这篇文章,再好好思考一下。当然,为整个Web应用都配置上完备的防范措施也会存在一些问题,比如,可能拖累整个网站的性能。不过我还有一招。


这招叫做Content-Security-Policy标记。它能让你指定网站上所有脚本和图片等资源的源站点。此外,它还能阻止所有内联(inline)的脚本和样式。即使有人在页面评论或者回帖中嵌入了脚本标签,这些脚本代码也不会被执行。CSP标记一般写在HTTP头中(也可以写在HTML的<meta>标签中),写法如下:


Content-Security-Policy: policy


其中的policy字段代表一系列CSP属性,下面列举一些常用的属性:


  • script-src – 设置可以接受的JavaScript代码的源站点

  • style-src – 设置可以接受的CSS样式代码的源站点

  • connect-src – 定义浏览器可以通过XHR、WebSocket或者EventSource访问哪些站点

  • font-src – 设置可以接受的字体文件的源站点

  • frame-src – 定义浏览器可以通过iframe访问哪些站点

  • img-src – 设置可以接受的图片的源站点

  • media-src – 设置可以接受的音频和视频文件的源站点

  • object-src – 设置可以接受的Flash和其它插件的源站点


如果没有设置上述属性,那么浏览器默认会接受来自任何源站点的脚本和数据。不过浏览器的默认属性也能通过default-src属性来设置。其它的属性如果没有设置的话,就会默认采用这个属性中设置的值。此外,还有一个叫做sandbox的属性,它可以让浏览器以iframe的形式加载页面。下面是一个CSP头的例子:


Content-Security-Policy: default-src: 'self'; script-src: https:

//apis.google.com;


在这个例子中,浏览器只会加载源自这个Web应用所在站点的资源(默认源设置为self),以及通过Google API服务器获取的脚本。CSP有很多种灵活的用法,如果使用得当,可以有效提升Web应用的安全性。


CSP的缺点


当你使用CSP的时候,有一点千万要记住:默认情况下,所有的内联JavaScript脚本都不会被执行。例如:


内联的事件监听器:比如


<body onload="main();">


所有的javascript URL:比如


<a href="javascript:doTheClick()">


之所以这样,是因为浏览器无法区分你的内联脚本和黑客注入的脚本。你需要通过JavaScript的addEventListener或者一些框架中类似的函数来重写上述脚本。某种程度上来看,这也不算一件坏事,它逼你不得不分离逻辑层的代码和展现层的代码,而你本来就应该这么做。此外,CSP默认还会阻止所有eval()风格的代码的执行,包括setInterval/setTimeout中的字符串和类似于new Function(‘return false’)之类的代码。


CSP的可用性


大部分时下流行的浏览器都支持CSP。Firefox、Chrome和Opera(包括手持设备上的)使用标准的CSP头。Safari(包括iOS中的)和安卓上的Chrome使用X-WebKit-CSP头。IE10(仅支持sandbox属性)使用X-Content-Security-Policy头。所以,由于IE的支持(部分支持也是支持),你不仅可以着手使用CSP(除非你用的是Google Chrome Frame之类的东西),而且还能在各种实际的浏览器中运行,有效地改善Web应用的安全性。


使用跨域资源共享(Cross Origin Resource Sharing)来代替JSONP


目前由于浏览器同源策略的限制,JSONP常被用于从其它服务器上获取数据。通常的办法是在脚本中写一个回调函数,然后把回调函数的名字写在请求的URL中,像下面这样:


function parseData(data) {

...

}


<script src="http://someserver.com/data?format=jsonp&callback=parseData"></script>


但是这样做会有很大的安全隐患。如果你请求数据的服务器被黑了,那么黑客就能在返回的数据中植入恶意代码,进而窃取用户的隐私信息。因为在浏览器看来,通过这种方法获取的脚本代码和正常的页面代码没什么区别。


正确的做法是使用跨域资源共享。它允许资源提供方在响应头中加入一个特殊的标记,使你能通过XHR来获取、解析并验证数据。这样就能避免恶意代码在你的应用中执行。


这个方法需要在响应头中加入的标记如下:


Access-Control-Allow-Origin: allowed origins


这里可以列举一些可以接受的数据源,以逗号隔开,使用通配符*来接受所有的数据源。


CORS可用性


目前所有主流的浏览器都支持,除了Opera Mini。


当然,更重要的是数据提供方能支持跨域资源共享,不过这就不是开发者能说了算的了。


在iframe中使用sandbox属性


如果你使用iframe加载外部网站的内容,也别忘了它的安全问题。你可以通过iframe的sandbox属性来增强iframe使用的安全性。通过设置sandbox属性,可以使得iframe无法随意跳转页面,无法执行外部脚本,无法锁定鼠标,无法弹出新窗口,无法提交表单,等等。此外页面上若干个iframe中加载的所有内容还必须来自唯一的源,也就不能使用localStorage等有悖于同源策略的东西。当然,如果有需要的话,你也可以通过显式的设置来放宽限制,可以设置的属性如下:


  • allow-same-origin –iframe只要各自符合同源规范即可

  • allow-scripts –iframe中可以执行JavaScript脚本

  • allow-forms –iframe中可以提交表单

  • allow-pointer-lock –iframe中可以锁定鼠标

  • allow-popups – iframe中可以弹出新窗口

  • allow-top-navigation – iframe中可以完成页面跳转


可用性


目前iframe的sandbox属性受各种主流浏览器支持,除了Opera Mini以外。


结束语


主要内容就是这些了。得益于HTML5的发展,我们可以在Web上实现越来越丰富的功能。但是我们也不能掉以轻心,因为网络中攻击和威胁无处不在,在敲第一行代码之前就要好好想一想安全性方面的问题。


本文转载自:http://blog.jobbole.com/54782/

共有 人打赏支持
杭城小刘
粉丝 14
博文 109
码字总数 54955
作品 0
杭州
iOS工程师
私信 提问
【PPT分享】如何保证智能客户端应用的安全性.ppt

本PPT 从下面几个方面介绍了智能客户端应用开发的安全性 满足安全性的需求 深入: 安全性的设计选择 保护数据库的安全 保护代码中的安全项 加密离线的数据 控制对本地资源的访问 控制对 Web ...

红薯
2010/09/08
237
0
前后端分离,最佳实践

文章目录 1.前后端分离是什么 2.为什么需要前后端分离 3.前后端分离,最佳实践 3.1.简单分离模式 3.2.服务端渲染模式 3.2.1.方式一,JSP渲染 3.2.2.方式二,静态页渲染 3.3.Node.js渲染模式 ...

郭恩洲_OSC博客
2016/11/21
30
0
最新的 OWASP Top 10 ,查“缺”补“漏”必备神器

2017 年,Equifax 宣布黑客窃取了其 1.45 亿条客户记录。黑客利用了 Equifax 的 Web 应用程序托管平台的一个已知安全漏洞。2015 年,英国电信公司 TalkTalk 有 157000 条客户记录遭窃,一群十...

IBMdW
01/23
0
0
Windows 通讯基础库--WCF

Windows Communication Foundation(WCF)是由微软开发的一系列支持数据通信的应用程序框架,可以翻译为Windows 通讯开发平台。WCF 整合了原有的windows通讯的 .net Remoting,WebService,Soc...

红薯
2015/05/21
1K
0
PHP 代码评审的 10 个提示

本文只代表排名前10的地区,当你接到一个关于PHP项目代码审核的任务,第二天,一个PHP高级开发者问我从哪里考虑审核PHP web 应用相关的任务.大家集体讨论,并提出列表.有趣的是,除了少数,大部分也...

oschina
2014/09/10
5.4K
6

没有更多内容

加载失败,请刷新页面

加载更多

Eureka Server启用 https服务指北

文章共 591字,阅读大约需要 2分钟 ! 概 述 在我的前文《Eureka Server 开启Spring Security Basic认证》中已经给 Eureka Server 开启了最基本的鉴权措施,本文则让 HTTPS加持于 Eureka Ser...

CodeSheep
26分钟前
3
0
OSChina 周二乱弹 —— 其实我在地板也睡不着

Osc乱弹歌单(2018)请戳(这里) 【今日歌曲】 @witt-z :分享歌词: 阴天 在不开灯的房间,当所有思绪都一点一点沉淀。 分享莫文蔚的单曲《阴天》: 《阴天》- 莫文蔚 手机党少年们想听歌,...

小小编辑
48分钟前
151
5
微服务分布式事务实现

https://www.processon.com/view/link/5b2144d7e4b001a14d3d2d30

WALK_MAN
今天
3
0
《大漠烟尘》读书笔记及读后感文章3700字

《大漠烟尘》读书笔记及读后感文章3700字: 在这个浮躁的社会里,你有多久没有好好读完一本书了? 我们总觉得自己和别人不一样,所以当看到别人身上的问题时,很少有“反求诸己”,反思自己。...

原创小博客
今天
4
0
大数据教程(9.5)用MR实现sql中的jion逻辑

上一篇博客讲解了使用jar -jar的方式来运行提交MR程序,以及通过修改YarnRunner的源码来实现MR的windows开发环境提交到集群的方式。本篇博主将分享sql中常见的join操作。 一、需求 订单数据表...

em_aaron
今天
3
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部