浅谈前端安全

更新日期: 2019-11-24阅读: 1.9k标签: 安全

前端安全的范围

将Web安全问题按照发生的区域来分类,发生在浏览器、Web页面中的安全问题就是前端安全问题。


同源策略

同源:URL由协议、域名、端口和路径组成,如果两个URL的协议、域名和端口相同,则表示他们同源。

URL是否同源原因

http://test.test.com/dir2/other.html

http://test.test.com/dir/test.html

https://test.test.com/test.html

协议不同

http://test.test.com:8080/test.html

端口不同

http://test123.test.com/test.html

域名不同

浏览器的同源策略,限制了来自不同源的document或脚本,对当前document读取或设置某些属性。从一个域上加载的脚本不允许访问另外一个域的文档属性。

如果没有同源限制存在,浏览器中的cookie等其他数据可以任意读取,不同域下dom可以任意操作,ajax可以任意请求。如果浏览了恶意网站那么就会泄漏这些隐私数据

在浏览器中,<script>、<img>、<iframe>、<link>等标签都可以加载跨域资源,而不受同源限制。

这些带src属性的标签每次加载时,实际上是由浏览器发起了一次GET请求。不同于XMLHttpRequest的是,通过src属性加载的资源,浏览器限制了JavaScript的权限,使其不能读、写返回的内容。


跨站脚本攻击(XSS)

XSS,即Cross Site Script(跨站脚本攻击);为了和层叠样式表(Cascading Style Sheet)做出区分,在安全领域叫做 XSS。

XSS 攻击是指攻击者在网站上注入恶意的客户端代码,利用恶意脚本对客户端网页进行篡改,从而在用户浏览网页时,对用户浏览器进行控制或者获取用户隐私数据的一种攻击方式。有很多种方式进行 XSS 攻击,但它们的共同点为:将一些隐私数据像cookie、session发送给攻击者,将受害者重定向到一个由攻击者控制的网站,在受害者的机器上进行一些恶意操作。

攻击方式

反射型XSS

恶意代码并没有保存在目标网站,通过引诱用户点击一个链接到目标网站的恶意链接来实施攻击。

攻击流程:

  1. A给B发送一个恶意构造的URL
  2. B点击URL后跳转到具有漏洞的HTML页面
  3. HTML页面在B浏览器中执行JavaScript,可以执行B所具有权限下的命令
存储型XSS

恶意代码被保存到目标网站的服务器中,这种攻击具有较强的稳定性和持久性,比较常见场景是在博客,论坛、OA、CRM等社交网站上。

攻击流程:

  1. 攻击者提交一条包含XSS代码的留言或其他数据到数据库
  2. 当目标用户查询时,XSS的内容会从服务器解析之后加载出来
  3. 浏览器将恶意代码当作正常脚本解析执行,可以执行浏览器所具有权限下的命令
DOM Based XSS

基于DOM的XSS攻击是指通过恶意脚本修改页面的DOM结构,是纯粹发生在客户端的攻击。DOM型XSS攻击中,取出和执行恶意代码由浏览器端完成,属于前端JavaScript自身的安全漏洞。

攻击流程:

  1. A给B发送一个恶意构造的URL
  2. B点击URL后HTML页面获取攻击性的代码,如通过location.hash获取的参数等
  3. 攻击性代码当作HTML代码写入页面
  4. HTML页面在B浏览器中执行JavaScript,可以执行B所具有权限下的命令

防范手段

  • 输入检查

    在源头控制,把用户输入的一些不合法的东西都过滤或者编码掉,从而保证安全性。如移除用户提交的的DOM属性如onerror,移除用户上传的节点,<iframe>,<script>,<a>节点等。

    一般业务中是对客户端和服务端中同时进行输入检查。

  • 输出检查

    利用转义库对 HTML 模板各处节点进行充分的转义。

  • 使用HttpOnly

    通过设置HttpOnly,浏览器可以禁止页面的JavaScript访问带有HttpOnly属性的Cookie。它的目的并非是为了对抗XSS,而是对抗XSS之后的Cookie劫持攻击。

    Cookie的使用过程:

    1. 浏览器向服务器发起请求,此时没有Cookie
    2. 服务器返回Set-Cookie头,向浏览器写入Cookie
    3. 在Cookie到期之前,浏览器访问该域下的所有页面,都将发送该Cookie

    HttpOnly是在Set-Cookie的时候进行标记的

    Set-Cookie: <name>=<value>[; <Max-Age>=<age>]
    [; expires=<date>][; domain=<domain_name>]
    [; path=<some_path>][; secure][; HttpOnly]

  • 输入内容长度限制

    对输入的内容限定合理长度,可以增加XSS攻击的难度

  • 避免拼接HTML或者使用内联事件

    前端使用拼接HTML或者内联事件的情况比较危险,建议替换为createElement、setAttribute及addEventListener的实现方法,或者采用成熟的框架进行渲染,如vue/react

  • 开启CSP网页安全政策(Content Security Policy)

    一种由开发者定义的安全性政策申明,通过CSP所约束的责任指定可信的内容来源,(内容可以是指脚本、图片、style 等远程资源)。

    CSP 的实质就是白名单制度,开发者明确告诉客户端,哪些外部资源可以加载和执行,等同于提供白名单。

    开启方式:

    • 通过HTTP头信息的Content-Security-Policy字段
    • 在网页中设置<meta>标签
<meta http-equiv\="Content-Security-Policy" content\="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:"\>


跨站点请求伪造(CSRF)

跨站请求伪造攻击,原理就是攻击者构造出一个后端请求地址,诱导用户点击或者通过某些途径自动发起请求。利用受害者在被攻击网站已经获取的注册凭证,绕过后台的用户验证,冒充用户执行某些操作。

攻击流程

  1. 被攻击者登录A站点,并保留了登陆凭证
  2. 攻击者诱使被攻击者访问B站点
  3. B站点向A站点发起请求,浏览器会默认携带A站点的Cookie
  4. A站点接收请求后会对其进行验证,而且会误认为是被攻击者发起的请求,同时以被攻击者的身份执行相应的操作

攻击方式

  • GET类型

    一般是利用<img>标签等发起

    <img src="http://test.com/test?test=test">

    在被攻击者访问页面时,浏览器会自动向src指向的地址发出请求

  • POST类型

    通常是构造一个自动提交的表单在页面上,模拟用户完成了一次POST操作

  • 链接类型

    通常是需要诱骗用户点击才会触发

攻击特点

  • 攻击一般发生在第三方站点,被攻击站点无法防止攻击发生
  • 攻击手段为冒充受害者提交操作,而非直接窃取数据
  • 攻击过程中攻击者并不能获取到用户的登陆凭证,而只是冒充

防范手段

  • 验证码

    通过增加网站A的验证手段,例如增加图形验证码或短信验证码等等,只有通过验证的请求才算合法。但是这种方案拥有两个局限性,一个是增加开发成本,另外一个是降低用户体验。

  • 验证Referer

    根据 HTTP 协议,在 HTTP 头中有一个字段叫Referer,它记录了该 HTTP 请求的来源地址。通过验证Referer,可以检查请求是否来自合法的"源"。

  • 验证Token

    服务端随机生成token,保存在服务端session中,同时保存到客户端中,客户端发送请求时,把token带到HTTP请求头或参数中,服务端接收到请求,验证请求中的token与session中的是否一致。如果请求中没有 token 或者 token 内容不正确,则认为可能是 CSRF 攻击而拒绝该请求。


点击劫持

在一个Web页面下隐藏了一个透明的iframe(opacity:0),用外层假页面诱导用户点击,实际上是在隐藏的frame上触发了点击事件进行一些用户不知情的操作。

攻击流程

  1. 攻击者构造一个诱导用户点击的内容,将页面放入到<iframe>
  2. 利用z-index和opacity将<iframe>叠加到实际页面上方并透明化
  3. 受害者访问到欺骗页面后,实际看到的是诱使点击的内容,点击之后则是有害页面

攻击方式

  • 盗取用户资金
  • 获得用户敏感信息
  • 与XSS或者CSRF相配合,诱骗用户点击恶意链接

防范手段

  • 设置X-FRAME-OPTIONS

    服务器端可设置HTTP头X-Frame-Options:DENY来让浏览器主动禁止<iframe>内嵌,但是这种方式需要结合HTTPS来实现,因为HTTP不可靠,容易被窃听篡改内容


链接: https://fly63.com/article/detial/7612

Web前端安全同样不可忽视,编写前端代码时保持安全意识

随着网络的普及,黑客进行网络攻击的手段越来也多,越来越复杂。前端的HTML、JavaScript、CSS、Flash等技术变成了前端攻击者和开发者的战场,网站安全问题也开始向前端倾斜。

AJAX请求真的不安全么?谈谈Web安全与AJAX的关系。

AJAX请求真的不安全么?AJAX请求哪里不安全?怎么样让AJAX请求更安全?本文包含的内容较多,包括AJAX,CORS,XSS,CSRF等内容,要完整的看完并理解需要付出一定的时间。

第三方 CSS 并不安全

第三方内容在其沙箱区域内具有强大的能力。如果你担心恶意用户诱使你的网站加载第三方资源,可以通过 CSP 用作防护手段,其可以限制加载图片,脚本和样式的来源。

WEB应用程序安全检查列表

检查页面隐藏或丢失的内容:检查webserver元数据文件,如:robots.txt, sitemap.xml,.DS_Store, .htaccess,检查搜索功能可能的注入或攻击方式,检查不同agent代理访问网站显示内容的是否一致

利用CSS注入(无iFrames)窃取CSRF令牌

要做到无iFrame,我将使用一种类似于之前我讨论过的方法:我将创建一个弹窗,然后在设置计时器后更改弹出窗口的位置。使用这种方法,我仍然可以加载受害者的CSS,但我不再依赖于受害者是否允许iFrame。

30 分钟理解 CORB 是什么

我当前的 chrome 版本是 v68,如果是 v66 或更低版本可能提示的警告信息略有不同。印象中只对 CORS 比较熟悉,CORB 是个什么鬼?好奇心迫使我想要了解一下它到底是什么,于是暂时把手头工作放下查了一些资料并花时间汇总了一下,就有了这篇文章

谈 target=‘_blank’的安全问题

大家都喜欢target=_blank, 因为新页面打开不影响原来的页面。但是这个存在安全问题, 由target=_blank打开的页面, 可以通过window.opener访问原来的窗口。遍可以简单的将网页导航到其他网站, 这就存在很多的安全隐患了, 比如钓鱼,这种问题解决起来也很简单, 在链接中加入rel=noreferrer noopener属性就可以了

Web安全测试检查单

Web安全测试检查单。上传功能:绕过文件上传检查功能,上传文件大小和次数限制。注册功能:注册请求是否安全传输,注册时密码复杂度是否后台检验,激活链接测试

一些安全相关的HTTP header

HTTP Strict-Transport-Security,简称为HSTS。X-Frame-Options:是否允许一个页面可在<frame>、<iframe>、<object>中展现的标记。X-XSS-Protection作用:防范XSS攻击。

第三方CSS安全吗?

第三方内容在其沙箱中具有很高的影响力。 虽然图像或沙盒iframe有着非常小的沙箱,但脚本和样式的作用范围却影响你的整个页面,甚至是整个站点。如果你担心用户会欺骗你的网站去加载第三方资源,可以使用CSP(内容安全策略)保证安全

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!