网站安全整理总结

网站安全

iframe

iframe简介：

运行：iFrame通常与主页在同一线程/进程中运行

iframe的基本属性：

src iframe页面地址，有同域跨域之分

height iframe高度

width iframe宽度

name iframe命名，可通过window.frames[xxx]被调用

scrolling iframe滚动模式

sandbox html5新特性，用于限制iframe的功能

获取iframe的window对象和document对象：

let iwindow = iframe.contentWindow; // 获取iframe的window对象
let idoc = iframe.contentDocument; // 获取iframe的document对象
let iframe = document.getElementById('demo')|| window.frames['demo']//获取iframe对象dom元素的两种方法;

使用iframe操控父级内容：

我们通过window.self，window.parent，window.top这三个属性分别获取自身window对象，父级window对象，顶级window对象

同域/跨域

iframe的实现会存在资源的跨域获取问题 还有同源策略的限制

iframe实现跨域通讯：

document.domain配置相同值,浏览器解析成同域就可以通讯

iframe其他用途

1.使用iframe做异步请求，不用在原页面上进行阻塞操作，还有一些获取数据的过程

2.独立区块运行第三方内容 3.sandbox沙箱 4.历史记录管理

iframe安全优化：

防嵌套页面操作

iframe引用问题：需判断引用对象是否同源，自定义校验规则等来防止我们被嵌套

if (top.location.host != window.location.host) {
　　top.location.href = window.location.href;
}

在http头中加入 X-FRAME-OPTIONS 属性，在请求服务端的时候作用，此属性控制页面是否可被嵌入 iframe 中DENY：不能被所有网站嵌套或加载；SAMEORIGIN：只能被同域网站嵌套或加载；ALLOW-FROM URL：可以被指定网站嵌套或加载。

沙箱引入三方iframe：sandbox属性配置

sandbox是html5的新属性，主要是提高iframe安全系数。iframe因安全问题而臭名昭著，这主要是因为iframe常被用于嵌入到第三方中，然后执行某些恶意操作。
现在有一场景：我的网站需要 iframe 引用某网站，但是不想被该网站操作DOM、不想加载某些js（广告、弹框等）、当前窗口被强行跳转链接等，我们可以设置 sandbox 属性。如使用多项用空格分隔。

• allow-same-origin：允许被视为同源，即可操作父级DOM或cookie等
• allow-top-navigation：允许当前iframe的引用网页通过url跳转链接或加载
• allow-forms：允许表单提交
• allow-scripts：允许执行脚本文件
• allow-popups：允许浏览器打开新窗口进行跳转
• “”：设置为空时上面所有允许全部禁止

opener

通过a标签跳转和window编程式api跳转的opener可以访问来源页面的window对象，
对a标签的处理行为是：协议规定，字符解析指控
对window的处理行为：窗口行为，对象属性调节

clickJacking（点击劫持）

一般会利用透明 iframe 覆盖原网页诱导用户进行某些操作达成目的。

CSRF/XSRF(跨站请求伪造)：窃取cookie等浏览器存储

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-h1MakTop-1654847951525)(C:\Users\86189\Pictures\笔记图\image-20220531141728894.png)]

概念：

Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证(cookies 等)，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

CSRF攻击类型：

GET

通过get的参数携带＋一些获取信息脚本操作实现伪造信息。

POST

类似访问后直接获取希望获取数据进行表单提交。

链接：

上述攻击本质都是通过一些能发送报文的标签或者元素以及页面跳转携带信息等的方法进行伪造受害者

CSFR特性：

攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。

攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。

整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”。

跨站请求可以用各种方式：图片 URL、超链接、CORS、Form 提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪。

CSFR防御措施

1.身份校验，就是服务器可通过 request headers 里 origin 和 referer 两个字段确定请求的来源域（但是不同的第三方可能有不同的漏洞）如暴露了refer头的修改，导致来源域可以被修改而产生攻击。
2.请求地址中添加token并且验证（这个token值是因为是一些原生的操作不能被规范添加所以必须携带在url中）
3.将token放置进入自定义属性中，通过xhr等报文定义属性进行发送token
（后端的校验问题 token的拆解）
4.添加验证码等防止构造报文请求的攻击方式，增大复杂度。

5.增加cookie验证,因为CSRF攻击时不能直接获取到用户Cookie的,通过请求时候，取出Cookie，并添加到URL的参数中。进行交流

6.samesite属性：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fdtYM1oh-1654847951528)(C:\Users\86189\Pictures\笔记图\image-20220531144157829.png)]

Chrome 51 开始，浏览器的 Cookie 新增加了一个 SameSite 属性限制第三方 Cookie，用来防止 CSRF 攻击和用户追踪。

SameSite 根据严格程度取值为 Strict, Lax, None。

SameSite cookies - HTTP | MDN (mozilla.org)

目前兼容性及实用性都不太好（不支持子域），暂时不用

---

CSFR漏洞挖掘：

首先就是cookie的同源策略三元组name、domain、path，它是不能实现跨域访问的，但如果使用一些不受同源影响的script，img 或者 iframe 之类的标签加载地址，然后携带窃取的用户cookie，就可以进行crsf攻击了。

1.判断接收报文是否有referer表头标示访问源和token
2.工具检测，没有身份校验标准refer和token的报文存在csfr

CSRF详解 - 掘金 (juejin.cn)

[详解WEB攻击之CSRF攻击与防护 | 更新日期：2022/5/30,DDR爱好者之家 - 无损音乐,高清电影,福利资源,技术教程,磁力下载,网盘云盘资源 (ddrfans.com)](http://www.ddrfans.com/Html/1/165714.html#:~:text=CSRF 背景与介绍 CSRF定义： 跨站请求伪造（英语：Cross-site request forgery），也被称为 one-click,attack 或者 session riding，通常缩写为 CSRF 或者 XSRF， 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。)

xss详解（跨站脚本攻击）

XSS种类：

存储型：

持久化，将恶意脚本存储在服务器中，由用户请求，在用户页面执行，容易形成蠕虫传递。

反射型：

非持久化，需要用户在xss漏洞下在登录态页面中进行恶意代码访问执行，在同源条件下可以盗取cookie等存储发送给自己服务器，做报文模拟等。

DOM型：

通过url传入参数控制触发，也需要执行xss漏洞下的输入js脚本，访问DOM存储的形式控制输入参数。

XSS攻击载荷：

1.script等不受同源策略限制的脚本引入标签，且直接可以执行，但是需要dom操作和标签解析流程，很难触发（乱引用外源js脚本）。
2.svg的onload方法也可以执行js脚本
3.img的onerror（也是执行）
4.body的onload （body为什么要有生命周期？）它还有其他生命周期也可以执行一些脚本
5.video标签-类似 6.style-类似

XSS怎么注入：

1.字符解析用户输入到script标签中，被执行
2.用户输入被作为html的注释内容，被解析执行
3.成为标签属性名（input?表单等重灾区）属性值
4.用户输入为标签名（都是解析方面的执行）
5.用户输入直接插入到css中（css中有协同执行的js代码*）
6.引入问题（置信CDN）

XSS漏洞的挖掘：

黑盒测试

尽可能找到一切用户可控并且能够输出在页面代码中的地方，比如下面这些：

• URL的每一个参数
• URL本身
• 表单
• 搜索框

常见业务场景

• 重灾区：评论区、留言区、个人信息、订单信息等
• 针对型：站内信、网页即时通讯、私信、意见反馈
• 存在风险：搜索框、当前目录、图片属性等

白盒测试(代码审计)

关于XSS的代码审计主要就是从接收参数的地方和一些关键词入手。

PHP中常见的接收参数的方式有GET、_POST、

也可以搜索类似echo这样的输出语句，跟踪输出的变量是从哪里来的，我们是否能控制，如果从数据库中取的，是否能控制存到数据库中的数据，存到数据库之前有没有进行过滤等等。

大多数程序会对接收参数封装在公共文件的函数中统一调用，我们就需要审计这些公共函数看有没有过滤，能否绕过等等。

同理审计DOM型注入可以搜索一些js操作DOM元素的关键词进行审计。

XSS的攻击过程

XSS防御措施：

XSS防御的总体思路:对用户的输入(和URL参数)进行过滤，对输出进行html编码

XSS的简单过滤和绕过（输入层）

在实现输入操作的时候可以对输入的文字进行xss校验，排除掉可能生成的xss攻击;但是攻击者也可以分析你的过滤手段进行反向绕过操作实现，所以整体上还是不太安全。(过滤的另一层在我看来就是对输出的HTML进行编码)。

还可以进行长度控制，提高代码难度，增加验证码提高模拟报文难度。

黑白名单过滤

黑名单过滤虽然可以拦截大部分的XSS攻击，但是还是存在被绕过的风险。白名单过滤虽然可以基本杜绝XSS攻击，但是真实环境中一般是不能进行如此严格的白名单过滤的。

设置会话Cookie的HTTP Only属性或者Secure属性

使得客户端的脚本不能读取该cookie信息，但是可能会被元素超长溢出攻击

只能在https协议状态下发送到服务器，防止信息传递中的信息泄漏

CSP内容安全策略详解（浏览器层）

CSP可以通过HTTP头部（Content-Security-Policy）或``元素配置页面的内容安全策略，以控制浏览器可以为该页面获取哪些资源’’，是一种以可信白名单作机制

首先是，默认配置下不允许执行内联代码（<script>块内容，内联事件，内联样式），以及禁止执行eval() , newFunction() , setTimeout([string], …) 和setInterval([string], …)//可以防止注入

使用方式：

HTTP Header 和 HTML中可以配置CSP头：

<meta http-equiv="content-security-policy" content="策略集">

"Content-Security-Policy:" 策略集

指令：

• default-src : 定义针对所有类型（js/image/css/font/ajax/iframe/多媒体等）资源的默认加载策略，如果某类型资源没有单独定义策略，就使用默认的。
• script-src : 定义针对 JavaScript 的加载策略。
• style-src : 定义针对样式的加载策略。
• img-src : 定义针对图片的加载策略。
• font-src : 定义针对字体的加载策略。
• media-src : 定义针对多媒体的加载策略，例如:音频标签<audio>和视频标签<video>。
• object-src : 定义针对插件的加载策略，例如：<object>、<embed>、<applet>。
• child-src :定义针对框架的加载策略，例如： <frame>,<iframe>。
• connect-src : 定义针对 Ajax/WebSocket 等请求的加载策略。不允许的情况下，浏览器会模拟一个状态为400的响应。
• sandbox : 定义针对 sandbox 的限制，相当于 <iframe>的sandbox属性。
• report-uri : 告诉浏览器如果请求的资源不被策略允许时，往哪个地址提交日志信息。
• form-action : 定义针对提交的 form 到特定来源的加载策略。
• referrer : 定义针对 referrer 的加载策略。
• reflected-xss : 定义针对 XSS 过滤器使用策略。

指令值：

指令值	说明
*	允许加载任何内容
‘none’	不允许加载任何内容
‘self’	允许加载相同源的内容
www.a.com	允许加载指定域名的资源
*.a.com	允许加载 a.com 任何子域名的资源
https://a.com	允许加载 a.com 的 https 资源
https：	允许加载 https 资源
data：	允许加载 data: 协议，例如：base64编码的图片
‘unsafe-inline’	允许加载 inline 资源，例如style属性、onclick、inline js、inline css等
‘unsafe-eval’	允许加载动态 js 代码，例如 eval()

参考：[Web 安全之内容安全策略（Content-Security-Policy,CSP）详解 - debug101 - 博客园 (cnblogs.com)](https://www.cnblogs.com/ldebug/p/9601878.html#:~:text=内容安全策略（Content Security,Policy，简称CSP）是一种以可信白名单作机制，来限制网站是否可以包含某些来源内容，缓解广泛的内容注入漏洞，比如 XSS。)

禁止加载外域代码，防止复杂的攻击逻辑。

禁止外域提交，网站被攻击后，用户的数据不会泄露到外域。

禁止内联脚本执行（规则较严格，目前发现 GitHub 使用）。

禁止未授权的脚本执行（新特性，Google Map 移动版在使用）。

合理使用上报可以及时发现 XSS，利于尽快修复问题。

URL加密

JavaScript中有三个可以对字符串编码的函数，分别是： escape,encodeURI,encodeURIComponent，相应3个解码函数：unescape,decodeURI,decodeURIComponent 。

escape()除了 ASCII 字母、数字和特定的符号外，对传进来的字符串全部进行转义编码，因此如果想对URL编码，最好不要使用此方法。

而encodeURI() 用于编码整个URI,因为URI中的合法字符都不会被编码转换。

encodeURIComponent方法在编码单个URIComponent（指请求参数）应当是最常用的，它可以将参数中的中文、特殊字符进行转义，而不会影响整个URL。

CDN劫持

攻击者劫持了 CDN，或者对 CDN 中的资源进行了污染，攻击者可以肆意篡改我们的前端页面，对用户实施攻击。

Subresource Integrity

(29 封私信 / 80 条消息) 应对流量劫持，前端能做哪些工作？ - 知乎 (zhihu.com)

SRI API

可以通过生成一个文件的唯一hash值，通过比对脚本或者静态资源的hash值是否一致，不一致就报错不加载

子资源完整性(SRI)是允许浏览器检查其获得的资源（例如从 CDN 获得的）是否被篡改的一项安全特性。它通过验证获取文件的哈希值是否和你提供的哈希值一样来判断资源是否被篡改。//解释

实现方式：

通过给 link 标签或者 script 标签增加 integrity 属性即可开启 SRI 功能.

integrity属性对应两部分：一部分是hash值生成算法，而部分是通过编码侯生成的实际hash值 integrity 值可以包含多个由空格分隔的哈希值，只要文件匹配其中任意一个哈希值，就可以通过校验并加载该资源。

如何使用 SRI

通过使用 webpack 的 html-webpack-plugin 和 webpack-subresource-integrity 可以生成包含 integrity 属性 script 标签。

import SriPlugin from 'webpack-subresource-integrity';

const compiler = webpack({
output: {
 crossOriginLoading: 'anonymous',
},
plugins: [
 new SriPlugin({
   hashFuncNames: ['sha256', 'sha384'],
   enabled: process.env.NODE_ENV === 'production',
 }),
],
});
复制代码

然后通过插件 script-ext-html-webpack-plugin 在 script 里注入 onerror 事件和 onsuccess 事件。onerror 事件里再次请求一次数据，比较两次数据是否一致来判断是否被 CDN 劫持。

作者：Korey
链接：https://juejin.cn/post/6844904120227201032
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

联合CSP

Content-Security-Policy: require-sri-for script;

这条指令规定了所有 JavaScript 都要有 integrity 属性，且通过验证才能被加载

中间人攻击

攻击原理

用户在访问某个网站的时候，在浏览器里却往往直接输入网站域名。浏览器便向网站发起一次 HTTP 请求，在得到一个重定向响应后，再发起一次 HTTPS 请求并得到最终的响应内容。由于在建立起 HTTPS 连接之前存在一次明文的 HTTP 请求和重定向，使得攻击者可以以中间人的方式劫持这次请求，从而进行后续的攻击，例如窃听数据，篡改请求和响应，跳转到钓鱼网站等。
作者：Korey
链接：https://juejin.cn/post/6844904120227201032

HSTS

全称：HTTP Strict-Transport-Security（严格安全传输）

服务器设置response header只能通过HTTPS访问

语法：

Strict-Transport-Security: <max-age=>[; includeSubDomains][; preload]

max-age 是必选参数，是一个以秒为单位的数值，它代表着 HSTS Header 的过期时间，通常设置为 1 年，即 31536000 秒。

includeSubDomains 是可选参数，如果包含它，则意味着当前域名及其子域名均开启 HSTS 保护。

preload 是可选参数，只有当你申请将自己的域名加入到浏览器内置列表的时候才需要使用到它//内置列表？

隐患

第一次还是需要发起一次明文HTTP请求（内置列表解决）浏览器只发HTTPS

HST配置

配置开启：resheader内开启

加入到HSTS Preload List中进行配置 （网站具备一定条件）：

1.有效证书 2.重定向响应和接收重定向后的HTTPS请求 3.子域名同使用HTTPS 4.根域名的HTTP响应头中，加入HSTS Header，包含preload参数 ，必须包含includeSubDomains参数。

参考：web漏洞 | XSS（跨站攻击脚本）详解 - 云+社区 - 腾讯云 (tencent.com)这篇很不错，上述内容大部分整合于此

前端安全汇总（持续更新） - 掘金 (juejin.cn)

【前端工程师面试宝典】学习说明_互联网校招面试真题面经汇总_牛客网 (nowcoder.com)

总结：

前端网站的安全可以从这些角度出发：

1.保护第三方不能操作自己页面的DOM和BOM

(例opener[跳转window],沙箱sandbox[二者都有],XSS防御DOM型[DOM])。

2.防止页面输出执行可疑脚本,实现内存窃取或者身份伪造：

（XSS过滤黑白名单,XSS注入的问题）

3.引入资源的可靠性校验：

（SRI资源hash码校验，CSP配置HTTP头部的校验属性）

4.服务端的身份验证,实现信息加密：

（URL添加token，双重cookie，编程式的报文配置token，reqheader中的origin域referer字段判断来源域，配置Samesite发送防止CSRF）

5.传播过程介质的可靠性保障：

（中间人攻击，HTTPS报文交流，服务端HSTS配置安全严格传输限制）

6.页面嵌套,页面伪装实现的直接盗取等：

（iframe服务器配置HTTP头防止资源嵌套引入（被引入），clickJacking点击劫持（被引入））

7.用户浏览器存储介质保护：

(cookie的同源策略规划，设置会话Cookie的HTTP Only属性和Secure属性)