Web客户端安全性最佳实践.docxVIP

得益于HTML5，Web应用中越来越多的逻辑从服务器端迁移到了客户端。因而，前端开发人员也需要更多关注安全性方面的问题。在这篇文章中，我会 告诉你如何使你的应用更加安全。我会着重描述一些你可能从未听说过的技术，而不是仅仅告诉你“别忘了对用户提交的页面数据做转义（escape）”。 HTTP？想都别想 当然，我并不想让你通过FTP或者普通的TCP协议来传输你的数据。我的意思是，如果你想让你的用户安全地访问你的网站，你应该使用 SSL（HTTPS）来加密你的数据传输。不仅要加密登陆节点或者关键信息，而是要加密所有的数据。否则当用户通过公用网络访问你的应用时，他看见的内容 说不定已经被别人“黑”掉了。这就叫中间人攻击，见下图： (译者注：此处引用的原图中笔误，中间人攻击的英文为Man-In-The-Middle Attack) 如果你使用SSL，所有的数据在发送之前就会被加密，即使攻击者在网络中截获了数据包，他也没有办法查看或者篡改其中的内容。对于提升应用的安全性，这是目前为止最重要的一步。 严格传输安全性标记（Strict-Transport-Security） 如果你只想通过SSL来传输你的数据，那么这个HTTP头属性会让你觉得非常好用。如果服务器端在响应头中使用了这个标记（你也可以在页面中使用meta标签，不过这样的话就会存在一个未被加密的请求），那么所有从客户端到服务器端的数据都会被加密。使用方式如下： 1Strict-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攻击，不妨先看一看 HYPERLINK /index.php/XSS_Filter_Evasion_Cheat_Sheet \o how many ways there are to perform these attacks 这篇文章，再好好思考一下。当然，为整个Web应用都配置上完备的防范措施也会存在一些问题，比如，可能拖累整个网站的性能。不过我还有一招。 这招叫做Content-Security-Policy标记。它能让你指定网站上所有脚本和图片等资源的源站点。此外，它还能阻止所有内联 （inline）的脚本和样式。即使有人在页面评论或者回帖中嵌入了脚本标签，这些脚本代码也不会被执行。CSP标记一般写在HTTP头中（也可以写在 HTML的meta标签中），写法如下： 1Content-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的形式加载页面。下面是一个C