devbox
weixin_40725706
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

浅谈前端安全

作者：weixin_40725706 | 2024-05-13 10:21:46

赞

踩

前端安全

1 什么是前端安全？

所有发生在浏览器、单页面应用、Web页面当中的安全问题都算是算是“前端安全问题”。或者就是说所有需要前端开发人员去修复的问题都属于前端安全问题。

2 前端目前存在哪些安全问题

2.1 xss（Cross Site Scripting）跨站脚本攻击

原理

xss说白了就是攻击者想尽一切的方法，将可执行的代码注入到我们的页面中，让页面进行一些非法的操作（浏览器错误的将攻击者输入的数据当做JavaScript脚本给执行了）。
xss从攻击的时间上可以分为持久型（存储型）攻击和非持久型（反射型）攻击。

持久型

持久型的就是指攻击者通过我们的页面，将具有攻击性的代码通过服务器保存到了数据库中，导致其他的用户在浏览当前页面时，受到了攻击。最常见的就是具有评论功能的页面。

非持久型

非持久型相比于持久型攻击危害就小的多了，一般通过修改 URL 参数的方式加入攻击代码，诱导用户访问链接从而进行攻击。

场景

1.页面中所有的input框
2.window.location（href、hash等）
3.window.name
4.document.referrer // 保存着链接到当前页面的那个页面的URL。
5.document.cookie
6.localstorage
7.XMLHttpRequest返回的数据

危害
  • 网络钓鱼,包括盗取各类用户账号;
  • 窃取用户cookies资料,从而获取用户隐私信息,或利用用户身份进一步对网站执行操作;
  • 劫持用户(浏览器)会话,从而执行任意操作,例如进行非法转账、强制发表日志、发送电子邮件等;
  • 强制弹出广告页面、刷流量等;
  • 网页挂马;进行恶意操作,例如任意篡改页面信息、删除文章等 进行大量的客户端攻击,如DDoS攻击;
  • 获取客户端信息,例如用户的浏览历史、真实IP、开放端口等;
  • 控制受害者机器向其他网站发起攻击;
  • 结合其他漏洞,如CSRF漏洞,实施进一步作恶;
  • 提升用户权限,包括进一步渗透网站;
  • 传播跨站脚本，蠕虫等;
防御

防御的方式总的来说就是两方面。一方面是验证所有输入数据，有效检测攻击；另一方就是对所有输出数据进行适当的编码，以防止任何已成功注入的脚本在浏览器端运行。

转义字符

一般会转（&、<、>、"、’、/）这6个字符。
比如说将

<script></script>

  • 1

标签存储为

&lt;script&gt&lt;/script&gt

  • 1

这样浏览器就不会将这段代码当做js来执行了。

CSP（内容安全策略）

CSP通过指定有效域——即浏览器认可的可执行脚本的有效来源——使服务器管理者有能力减少或消除XSS攻击所依赖的载体。一个CSP兼容的浏览器将会仅执行从白名单 域获取到的脚本文件，忽略所有的其他脚本
(包括内联脚本和HTML的事件处理属性)。
当然除了可以指定域之外，还可以指定加载脚本的协议，比如只允许访问https的脚本

Content-Security-Policy主要有以下几大分类

  1. default-src ‘self’ 所有的资源必须是同源的
  2. default-src ‘self’; img-src ; media-src media1.com media2.com; script-src userscripts.example.com
    图片可以从任何地方加载(注意 "    " 通配符)。
    多媒体文件仅允许从 media1.com 和 media2.com 加载(不允许从这些站点的子域名)。
    可运行脚本仅允许来自于userscripts.example.com。
  3. connect-src https； 只允许http是的请求
    等等等还有好多，还没有整体出来
<meta http-equiv="Content-Security-Policy" content="script-src 'self'">

  • 1

正常的http请求
在这里插入图片描述
加了安全策略之后，
在这里插入图片描述
网络请求的安全策略
在这里插入图片描述

框架

在这里插入图片描述

2.2 CSRF(Cross Site Request Forgery)跨站请求伪造

原理

CSRF(Cross Site Request Forgery)，即跨站请求伪造，是一种常见的Web攻击。CSRF攻击过程的受害者用户登录网站A，输入个人信息，在本地保存服务器生成的cookie。然后在A网站点击由攻击者构建一条恶意链接跳转到B网站，然后B网站携带着的用户cookie信息去访问B网站。让A网站造成是用户自己访问的假相，从而来进行一些列的操作，常见的就是转账。
在这里插入图片描述

场景

网站使用Cookie验证用户
用户没有登出网站
网站没有做任何CSRF的防御

危害

通过基于受信任的输入form和对特定行为无需授权的已认证的用户来执行某些行为的web应用。已经通过被保存在用户浏览器中的cookie进行认证的用户将在完全无知的情况下发送HTTP请求到那个信任他的站点，进而进行用户不愿做的行为。

防御

大致要遵循以下几点规则：

  1. Get 请求不对数据进行修改
  2. 不让第三方网站访问到用户 Cookie
  3. 阻止第三方网站请求接口
  4. 请求时附带验证信息，比如验证码或者Token
SameSite

Cookie 的SameSite属性用来限制第三方 Cookie，从而减少安全风险。

验证 Referer

验证一下发起请求的页面是不是我们的系统

Token

发送一个带有过期时间的token

跨域资源共享（CORS）

大多数情况下，为了省事，都配置为*，这样就会存在很大的安全隐患。
在这里插入图片描述
普通跨域请求：
只服务端设置Access-Control-Allow-Origin即可，前端无须设置，
若要带cookie请求：
前后端都需要设置。

2.3 SQL脚本注入（SQL Injection）

原理
  • SQL注入(SQL Injection)，应用程序在向后台数据库传递SQL(Structured Query Language，结构化查询语言)时，攻击者将SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。
    1.是一种将SQL语句插入或添加到应用(用户)的输入参数中的攻击
    2.这些参数传递给后台的SQL数据库服务器加以解析并执行
危害

1.获取不属于当前用户的管理权限
2.对数据库进行增删改查

防御

1、增加黑名单或者白名单验证
白名单验证一般指，检查用户输入是否是符合预期的类型、长度、数值范围或者其他格式标准。黑名单验证是指，若在用户输入中，包含明显的恶意内容则拒绝该条用户请求。在使用白名单验证时，一般会配合黑名单验证。
2、安全检测
在项目完成的时候，始终坚持安全检测。
3、防止系统敏感信息泄露
对数据表的访问权限进行严格控制，尽量限制用户不必要的访问权限

2.4 上传漏洞

原理

指攻击者上传了一个可执行的文件到服务器并能够成功执行。
在这里插入图片描述

危害

上传漏洞与SQL注入或 XSS相比 , 其风险更大 , 如果 Web应用程序存在上传漏洞 ,攻击者上传的文件是Web脚本语言，服务器的Web容器解释并执行了用户上传的脚本，导致代码执行。如果上传的文件是Flash的策略文件crossdomain.xml，黑客用以控制Flash在该域下的行为。如果上传的文件是病毒、木马文件，黑客用以诱骗用户或者管理员下载执行。如果上传的文件是钓鱼图片或为包含了脚本的图片，在某些版本的浏览器中会被作为脚本执行，被用于钓鱼和欺诈。甚至攻击者可以直接上传一个webshell到服务器上
完全控制系统或致使系统瘫痪。

防御
客户端

javascript校验（一般只校验后缀名）

服务端校验
  1. 文件头content-type字段校验（image/gif）
  2. 文件内容头校验（GIF89a）
  3. 后缀名黑名单校验
  4. 后缀名白名单校验
  5. 自定义正则校验

2.5 控制台输入

天猫官网给出的提示

2.6 img标签的再次利用 onerror事件

原理

通过将图片地址认为的设置错误，从而引发执行onerror事件.
在这里插入图片描述

危害

系统执行攻击者的 代码，造成数据泄露

防御

可以参考CSP（内容安全策略）

2.7 点击劫持

原理

这是一种欺骗性比较强，同时也需要用户高度参与才能完成的一种攻击。
通常的攻击步骤是这样的：
　　1、攻击者构造一个诱导用户点击的内容，如Web页面小游戏
　　2、将被攻击的页面放入到iframe当中
　　3、利用z-index等CSS样式将这个iframe叠加到小游戏的垂直方向的正上方
　　4、把iframe设置为100%透明度
　　5、受害者访问这个页面，肉眼看到的是一个小游戏，如果受到诱导进行了点击的话，实际上点击到的却是iframe中的页面

危害

点击劫持的危害在于，攻击利用了受害者的用户身份，在其不知情的情况下进行一些操作。

防御
X-FRAME-OPTIONS

设置页面是否可以在标签中显示
1、DENY：不能被嵌入到任何iframe或者frame中。
2、SAMEORIGIN：页面只能被本站页面嵌入到iframe或者frame中
3、ALLOW-FROM uri：只能被嵌入到指定域名的框架中

JS 防御
<head>
   <style id="click-jack">
     html {
       display: none !important;
     }
   </style>
</head>
<body>
   <script>
     if (self == top) {
       var style = document.getElementById('click-jack');
       document.body.removeChild(style);
     } else {
       top.location = self.location;
     }
   </script>
</body>

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17

以上代码的作用就是当通过 iframe 的方式加载页面时，攻击者的网页直接不显示所有内容了。
在这里插入图片描述
微信的安全策略

2.8 本地存储数据泄露

前端应用是完全暴露在用户以及攻击者面前的，在前端存储任何敏感、机密的数据，都会面临泄露的风险，就算是在前端通过JS脚本对数据进行加密基本也无济于事。

2.9 iframe的安全属性 sandbox

原理

有时候前端页面为了显示别人的网站或者一些组件的时候，就用iframe来引入进来，比如嵌入一些广告等等。但是有些iframe安全性我们无法去评估测试，有时候会携带一些第三方的插件啊，或者嵌入了一下不安全的脚本啊，这些都是值得我们去考虑的。

防御

在iframe的标签中添加 sandbox = “”, 将开启一下所有的限制

配置效果
allow-forms允许进行提交表单
allow-scripts运行执行脚本
allow-same-origin允许同域请求,比如ajax,storage
allow-top-navigation允许iframe能够主导window.top进行页面跳转
allow-popups允许iframe中弹出新窗口,比如,window.open,target="_blank"
allow-pointer-lock在iframe中可以锁定鼠标，主要和鼠标锁定有关

2.10 不安全的第三方依赖 CDN

原理

在我们的系统中引用的一些在线的第三方库，可能会存在被别人贡献的危害，是的我们的系统中执行一些非常规的操作

2.11 登录的账号密码不能明文传输

2.12 https安全加密

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/weixin_40725706/article/detail/563141
推荐阅读