Web客户端安全性最佳实践

标签: IT技术 互联网 安全 最佳实践 浏览器 | 发表时间:2014-01-09 16:35 | 作者:njuyz
出处:http://blog.jobbole.com

得益于HTML5,Web应用中越来越多的逻辑从服务器端迁移到了客户端。因而,前端开发人员也需要更多关注安全性方面的问题。在这篇文章中,我会告诉你如何使你的应用更加安全。我会着重描述一些你可能从未听说过的技术,而不是仅仅告诉你“别忘了对用户提交的页面数据做转义(escape)”。

HTTP?想都别想

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

main-in-the-middle
(译者注:此处引用的原图中笔误,中间人攻击的英文为Man-In-The-Middle Attack)

如果你使用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访问的安全性,那就是使用 SecureHttpOnly这两个cookie属性。前者能确保cookie的内容只通过SSL连接进行传输;而后者正好相反。如果你觉得这两者互相矛盾,没啥用处,那就错了。它们告诉浏览器cookie的内容只能分别通过HTTP(S)协议进行访问,从而避免了被别人轻易窃取,比如JavaScript中的document.cookie.

通过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以外。

结束语

主要内容就是这些了。希望读者能通过这篇文章学到一些新技术,能用于今后的项目中,更好的提升Web应用的安全性。得益于HTML5的发展,我们可以在Web上实现越来越丰富的功能。但是我们也不能掉以轻心,因为网络中攻击和威胁无处不在,在敲第一行代码之前就要好好想一想安全性方面的问题。

Web客户端安全性最佳实践,首发于 博客 - 伯乐在线

相关 [web 客户端 最佳实践] 推荐:

Web客户端安全性最佳实践

- - 博客 - 伯乐在线
得益于HTML5,Web应用中越来越多的逻辑从服务器端迁移到了客户端. 因而,前端开发人员也需要更多关注安全性方面的问题. 在这篇文章中,我会告诉你如何使你的应用更加安全. 我会着重描述一些你可能从未听说过的技术,而不是仅仅告诉你“别忘了对用户提交的页面数据做转义(escape)”. 当然,我并不想让你通过FTP或者普通的TCP协议来传输你的数据.

Web前端优化最佳实践

- Jimmy - 中文热文榜|最新
还有 Jason, Bixuan, 曦, 推荐,查看全部 8 个推荐. 博评 - Sting的网经发表于2010-08-08 08:41:10. Google的前端优化最佳实践 Yahoo的前端优化最佳实践. Web前端优化最佳实践之Content篇. 尽量减少 HTTP 请求 (Make Fewer HTTP Requests).

Web 前端优化最佳实践之 Mobile(iPhone) 篇

- - 可咔酷 | 网络杂货铺
Web 前端优化最佳实践最后一部分是针对移动应用的,其实只是针对 iPhone 的,目前只有两条规则. 单个数据对象小于 25K (Keep Components under 25K). 这个似乎只是 针对 iPhone 研究的. 建议保持单个 Web 数据对象在 25 K 以下. Apple 官方信息指出可缓存到内存中的 Web 对象最大支持到 10M,但经过测试,发现也就是 25K 左右.

Web 开发指南:前端开发编码标准及最佳实践

- - 博客园_梦想天空
  本文向大家推荐来自 isobar(全球顶级数字公司)的前端开发编码标准和最佳实践. 这份文档涵盖 HTML、CSS 和 JavaScript 编码标准,可访问性,性能优化,浏览器兼容和测试和搜索引擎优化支持等众多内容,下面是全文目录:. 60款很酷的 jQuery 幻灯片演示和下载. 12个很棒的学习 jQuery 的网站推荐.

Web 应用程序中提交表单时处理 GIF 动画的最佳实践

- - 博客 - 伯乐在线
来源 developerWorks. 简介: 在 Web 应用中的提交表单时,为了很好的用户体验或防止表单重复提交,我们通常会从请求发起那一刻开始,展示出一个动态的 GIF 图标来提示用户请求正在处理. 本文将介绍在传统的提交方式下,如何巧妙地使用 Javacript 方式来解决请求发起时 IE 浏览器下动态沙漏图标不播放的问题,以及在请求完成后点击浏览器回退按钮,Firefox 浏览器依旧显示着沙漏图标的问题.

iOS客户端开发与Web前端开发

- - bang's blog
不知不觉做iOS客户端开发已经半年多了,了解到iOS客户端开发与Web前端开发的一些异同,写一下. 用户角度上看,客户端升级必须让用户手动下载整个新的安装包覆盖安装,而web的升级无需用户做任何事情. 开发角度上看,如果客户端有个小bug需要紧急修复,需要修复完后打包一个完成的安装包,给一个版本号,发布给用户升级.

Web项目如何防止客户端重复发送请求

- - SegmentFault 最新的文章
在Web项目中,有一些请求或操作会对数据产生影响(比如新增、删除、更新),针对这类请求一般都需要做一些保护,以防止用户有意或无意的重复发起这样的请求导致的数据错乱. 本文总结了一些防止客户端重复发送请求的方法. 方法一:JS监听Form的onsubmit事件. 在经典场景下,浏览器通过Form发送请求.

jQuery最佳实践

- andi - 阮一峰的网络日志
上周,我整理了《jQuery设计思想》. 那篇文章是一篇入门教程,从设计思想的角度,讲解"怎么使用jQuery". 今天的文章则是更进一步,讲解"如何用好jQuery". 我主要参考了Addy Osmani的PPT《提高jQuery性能的诀窍》(jQuery Proven Performance Tips And Tricks).

PHP最佳实践

- xiangqian - 阮一峰的网络日志
虽然名字叫《PHP最佳实践》,但是它主要谈的不是编程规则,而是PHP应用程序的合理架构. 它提供了一种逻辑和数据分离的架构模式,属于MVC模式的一种实践. 我觉得,这是很有参考价值的学习资料,类似的文章网上并不多,所以一边学习,一边就把它翻译了出来. 根据自己的理解,我总结了它的MVC模式的实现方式(详细解释见译文):.

MongoDB最佳实践

- - NoSQLFan
将 MongoDB加入到我们的服务支持列表中,是整个团队年初工作计划中的首要任务. 但我们感觉如果先添加一项对NoSQL存储的支持,而不是先升级已支持的关系型数据库,可能对用户不太好,毕竟目前的用户都使用关系型数据库. 所以我们决定将引入MongoDB这项工作放到升级MySQL和PostgreSQL之后来做.