《前端安全精讲》

栏目: 编程工具 · 发布时间: 4年前

内容简介:web前端安全虽然在平时的开发中涉及的不是很多,但也是前端综合技能领域重要的一环。无论是对于提升产品整体的安全性可靠性,还是作为技术人员自身能力的提升,了解基本常见的前端安全问题,都是非常有必要的。本文旨在对前端安全涉及的内容做一个梳理。其实作为讲解安全的文章,有一个痛点,那就是很难用文章的形式把这个具体的发生实现过程展示清楚,这可能需要大量的代码以及辅助的贴图,这样反而会让人看的迷糊。所以本文只会以文字形式讲解安全问题,以供大家对这个领域知识的梳理和回顾。XSS攻击的重点其实不在“跨站”这个字面上,重点是

web前端安全虽然在平时的开发中涉及的不是很多,但也是前端综合技能领域重要的一环。无论是对于提升产品整体的安全性可靠性,还是作为技术人员自身能力的提升,了解基本常见的前端安全问题,都是非常有必要的。

本文旨在对前端安全涉及的内容做一个梳理。其实作为讲解安全的文章,有一个痛点,那就是很难用文章的形式把这个具体的发生实现过程展示清楚,这可能需要大量的代码以及辅助的贴图,这样反而会让人看的迷糊。所以本文只会以文字形式讲解安全问题,以供大家对这个领域知识的梳理和回顾。

一、XSS(Cross-Site-Scripting)跨站脚本攻击

1.1 XSS攻击原理

XSS攻击的重点其实不在“跨站”这个字面上,重点是“脚本”。之所以这么说,是因为XSS攻击是发生在目标用户的浏览器层面的一种攻击,当用户浏览器渲染整个HTML文档的过程中出现了不被预期的脚本时,XSS就会发生。

其实XSS攻击攻击的原理还可以说的更加简单明了,就是用户访问的页面中,被植入了不安全的脚本。而这些脚本,具有各种危害用户的能力。至于这些脚本是如何被植入的,那形式就多种多样了。举几个例子。

1.很多网站内部的JavaScript代码,会读取浏览器地址中携带的信息,并作为内容在页面中展示。假如有这样一个URL地址

http://www.demo.com?xss=<script>alert(document.cookie)</script>
复制代码

这段地址中的query值xss如果被读取并且执行,就具备了在页面中执行程序的能力。这只是一个简单的alert,如果通过src的方式引入第三方JS文件,那么攻击者可做的事情就更多了。

2.比较常见的是一些带有用户留言功能的网站。比如攻击者A在留言中写入了一段攻击代码,这段代被发送到服务器,并且没有经过转义过滤,。当用户B访问网页的时候,获取了这段代码并直接执行了,这就产生了XSS攻击。

总之,XSS的攻击者的目的就是想尽一切办法将他的脚本内容在目标网站中目标用户的浏览器上解析执行。

1.2 XSS攻击类型

XSS攻击根据类型可以分为:

1.反射型XSS(非持久型XSS)。XSS代码出现在URL中,攻击者需要将带有攻击脚本的URL发送给目标用户。用户点击访问后,在本地的浏览器解析执行了攻击代码。

2.存储型XSS(持久型XSS)。存储型的XSS代码,会被存储在服务器端。当用户访问网页的时候,从服务器拿到攻击代码并执行。

3.DOM XSS。它和其它两个类型的差别在于DOM XSS的XSS代码并不需要服务器解析响应的参与,触发XSS考的就是浏览器的DOM解析。

1.3 XSS攻击防御

说完了XSS的原理和类型,就得了解一下相关的解决防御方案。

对于反射型XSS,需要注意的地方有:

1.web页面渲染的内容必须从服务的获取,用户的输入必须经过处理才能展示。 2.不要从URL等这些途径获取数据直接展示到页面中。 3.对于用户输入,或者是动态获取的数据,需要经过转义才能执行展示。

对于存储型XSS,需要注意的地方有:

1.后端将数据存入数据库之前,先进行转义。

2.后端输出给前端的数据,需要进行统一转义处理。

3.前端获取后端的数据后,对数据进行转义处理。

二、CSRF(Cross-Site-Request-Forgery)跨站请求伪造

2.1 CSRF的原理和实现

CSRF的攻击有两个关键点:

1.跨站点的请求。

2.请求是伪造的。

我们知道,不同域的Ajax请求时不合法的,同源策略禁止了跨域的数据传输。那么不同站点的CSRF攻击是如何产生的呢?

这里有一个很重要的知识点就是,客户端HTML标签发出的跨域GET请求被认为是合法的,不在同源策略的限制中。

1.恶意网站B上有一个带有CSRF攻击代码的页面,其中的代码可能是这样

<img src="http://www.a.com/blog/del?id=5">
复制代码

2.攻击者诱使登录了正规A网站的用户,访问了他的B网站上的CSRF页面。

3.由于用户登录了A网站,所以访问这个页面请求了携带在img标签中的地址。并且在这个访问中,http中请求信息几乎是一模一样的。

通过这样的方式,攻击者不但绕开了同源策略的限制,还伪造了请求的身份信息。

2.2CSRF的防御

虽然CSRF的攻击能够伪造用户的信息,但是这样的请求毕竟是从第三方网站发起的,它并不会经过正规网站本身。所以对于CSRF的防御大概有 1.通过设置sameSite-Strict属性,禁止第三方网站携带cookie。 2.在正规网站的页面提交内容,可以设置验证码,或者是token。 3.虽然第三方网站的跨站请求信息几乎和正规网站是一样的,但是还是有所不同。这个不同就是请求信息中的Referer字段,这个字段描述了请求的来源。可以通过这个字段禁止第三方网站的请求。

三、界面操作劫持攻击

界面操作劫持攻击是一种基于视觉欺骗的web会话攻击,它通过在页面可见控件上覆盖一个不可见的框(iframe),使得用户误以为自己在操作可见框,从而在用户不知情的情况下篡改数据、窃取信息等。

界面劫持攻击大概有三类:

1.点击劫持。

2.拖放劫持。

3.触屏劫持。

界面操作劫持的防御主要在于禁止网站被嵌入到iframe中,可以通过JavaScript代码实现。也可以通过X-FRAME-OPTIONS属性的设置,禁止页面被嵌入到iframe中。

四、Cookie安全问题

cookie是一种前端数据存储方式,后端通过HTTP响应头设置cookie。很多攻击的实现,都是通过获取用户的cookie信息,从而伪造身份造成攻击。所以保证cookie的安全,是前端安全的重要一环。

cookie的安全可以从以下几个方面着手。

1.通过加签名的方式,防止cookie被篡改。

2.通过对cookie内容的加密,防止被盗用。

3.设置响应头中的http-only字段,方式客户端的JavaScript代码读取cookie。

4.设置secure字段,只允许在https下使用cookie。

5.通过same-site保证cookie安全(浏览器兼容性较差)。

关于前端安全的问题,各式各样的变形还有很多。攻击往往也不是单一的方式,而是多种多样的攻击手段的组合。为了保证前端页面的安全性和可靠性,需要前后端的通力合作。


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Implementing Responsive Design

Implementing Responsive Design

Tim Kadlec / New Riders / 2012-7-31 / GBP 27.99

New devices and platforms emerge daily. Browsers iterate at a remarkable pace. Faced with this volatile landscape we can either struggle for control or we can embrace the inherent flexibility of the w......一起来看看 《Implementing Responsive Design》 这本书的介绍吧!

随机密码生成器
随机密码生成器

多种字符组合密码

UNIX 时间戳转换
UNIX 时间戳转换

UNIX 时间戳转换