https://blog.csdn.net/Dax1_/article/details/124045191
2.xss ：XSS 是代码注入问题
1.xss实际场景。
简单来说，任何可以输入的地方都有可能引起XSS攻击，包括URL
在 标签属性中，恶意内容包含引号，从而突破属性值的限制，注入其他属性或者标签
在标签的 href、src 等属性中，包含 javascript: (伪协议)等可执行代码。
在HTML内嵌的文本中，恶意内容以script标签形成注入
在 内联的JavaScript中，拼接的数据突破了原本的限制（字符串，变量，方法名）等
在 style 属性和标签中，包含类似 background-image:url("javascript:..."); 的代码（新版本浏览器已经可以防范）。
在 style 属性和标签中，包含类似 expression(...) 的 CSS 表达式代码（新版本浏览器已经可以防范）。
在 onload、onerror、onclick 等事件中，注入不受控制代码
1.xss
存储型XSS
存储型 XSS(又被称为持久性XSS)攻击常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。
XSS具有更高的隐蔽性，所以危害更大，因为它不需要用户手动触发。
反射型XSS
反射型XSS的攻击步骤 反射型 XSS 跟存储型 XSS 的区别是：存储型 XSS 的恶意代码存在数据库里，反射型 XSS 的恶意代码存在 URL 里。
反射型 XSS (也被称为非持久性XSS)漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。
由于需要用户主动打开恶意的 URL 才能生效，攻击者往往会结合多种手段诱导用户点击。
POST 的内容也可以触发反射型 XSS，只不过其触发条件比较苛刻（需要构造表单提交页面，并引导用户点击），所以非常少见。
DOM型XSS
DOM型XSS的攻击步骤:
DOM 型 XSS 跟前两种 XSS 的区别：DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。
触发XSS靠的是浏览器端的DOM解析，所以防范DOM型XSS完全就是前端的责任,必须注意!!!。
2.xss原理
Cross-Site Scripting(跨站 脚本)，
跨站：在目标网站上。脚本：注入恶意脚本 ，使之在用户的浏览器上运行。获取： Cookie、SessionID用户的敏感信息
3.xss解决方案。
防御XSS攻击的方法
httpOnly：在cookie中设置HttpOnly属性后，js脚本将无法读取到cookie信息
输入过滤：一般是用于对于输入格式的检查，例如：邮箱，电话号码，用户名，密码……等，按照规定的格式输入。不仅仅是前端负责，后端也要做相同的过滤检查。因为攻击者完全可以绕过正常的输入流程，直接利用相关接口向服务器发送设置。
转义HTML：如果拼接 HTML 是必要的，就需要对于引号，尖括号，斜杠进行转义,但这还不是很完善.想对 HTML 模板各处插入点进行充分的转义,就需要采用合适的转义库
1.crsf
1.crsf实际场景 ：CSRF 是 HTTP 问题。发送 HTTP 请求时候自动带上 cookie
从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：
1.登录受信任网站A，并在本地生成Cookie。
2.在不登出A的情况下，访问危险网站B。
攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。
攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。
整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”。
跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪。
2.crsf原理
什么是CSRF
Cross-site request forgery(跨站请求伪造)，是一种挟持用户在当前已登陆的Web应用程序上执行非本意的操作的攻击方法。如:攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。
3.crsf的解决方案。
防御CSRF的方法
验证码；强制用户必须与应用进行交互，才能完成最终请求。此种方式能很好的遏制 csrf，但是用户体验比较差。
Referer check；请求来源限制，此种方法成本最低，但是并不能保证 100% 有效，因为服务器并不是什么时候都能取到 Referer，而且低版本的浏览器存在伪造 Referer 的风险。
token；token 验证的 CSRF 防御机制是公认最合适的方案。(具体可以查看本系列前端鉴权中对token有详细描述)若网站同时存在 XSS 漏洞的时候，这个方法也是空谈。
3.同源安全策略
1.为什么需要同源策略。
2.同源策略是什么。
4.http header设置。
Request
Accept 指定客户端能够接收的内容类型 Accept：text/plain,text/html
Accept-Charset 浏览器可以接收的字符编码集 Accept-Charset：iso-8859-5
Accept-Encoding 指定浏览器可以支持的web服务器返回内容压缩编码类型 Accept-Encoding：compress,gzip
Accept-Language 浏览器可以接收的语言 Accept-Language：en，zh
Accept-Ranges 可以请求网页实体的一个或者多个子范围字段 Accept-Ranges；bytes
Authorization http授权的授权证书 Authorization：Basic QWxhZGRpbjpvcGVuIHNIc2FtZQ==
Cache-Length 指定的内容长度 Cache-Length：348
Content-Type 请求的与实体对应的MIME信息 Content-Type：application/x-www-from-urlencoded
Date 请求发送的日期和时间 Date：Tue，15 Now 2010 08:12:31 GMT
Expect 请求的特定的服务器行为 Expect：100-continue
From 发出请求的用户的Email From：user@email.com
Host 指定请求的服务器的域名和端口号 Host：www.zcmhi.com
if-Match 只有请求内容与实体相匹配才有效 if-Match："737060cd8c284d8af7ad3082f209592d"
If-Modified-Since 如果请求的部门在指定时间之后被修改则请求成功，未被修改则返回304代码 If-Modified-Since：Sat，29 Oct 2010 19:43:31 GMT
If-None-Match 如果内容未改变返回304，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变
If-Range 如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体，参数也为Etag If-Range："737060cd8c2848af7ad3082f2c"
If-Unmodified-Since 只在实体在指定时间之后未被修改才请求成功 If-Unmodified-Since：Basic QWxhZGRpbjpvcGVuIhNIc2FtZQ==
1.Content-SecurityPolicy
2.X-Frame-Options
- X-Content-type-option
4.Strict-Transport-Security
5.a标签里面
href 规定链接的目标 URL。
rel 规定当前文档与目标 URL 之间的关系。仅在 href 属性存在时使用。
target 规定在何处打开目标 URL。仅在 href 属性存在时使用。
download(#)() 指定下载链接
media(#) 规定目标 URL 的媒介类型。默认值：all。仅在 href 属性存在时使用
name，rev，shape 不再会使用了。
https://baijiahao.baidu.com/s?id=1743943456883696325&wfr=spider&for=pc
https://www.vpsss.net/26608.html
1、no opener 属性
2、no referrer 属性
3、no follow 属性
4、noopener noreferrer nofollow 属性
6.iframe标签。
小明说，iframe是能耗最高的一个元素，尽量减少使用。
小蓝说，iframe的安全性太差，尽量减少使用。
name ： 规定 的名称。
width： 规定 的宽度。
height ：规定 的高度。
src ：规定在 中显示的文档的 URL。
frameborder ： 规定是否显示 周围的边框。 (0为无边框，1位有边框)。
align ： 规定如何根据周围的元素来对齐 。 (left,right,top,middle,bottom)。
scrolling ： 规定是否在 中显示滚动条。 (yes,no,auto)
referrerpolicy
表示在获取 iframe 资源时如何发送 referrer 首部：
no-referrer: 不发送 Referer 首部。
no-referrer-when-downgrade (default): 向不受 TLS (HTTPS) 保护的 origin 发送请求时，不发送 Referer 首部。
origin: referrer 首部中仅包含来源页面的源。换言之，仅包含来源页面的 scheme, host, 以及 port (en-US)。
origin-when-cross-origin: 发起跨域请求时，仅在 referrer 中包含来源页面的源。发起同源请求时，仍然会在 referrer 中包含来源页面在服务器上的路径信息。
same-origin: 对于 same origin（同源）请求，发送 referrer 首部，否则不发送。
strict-origin: 仅当被请求页面和来源页面具有相同的协议安全等级时才发送 referrer 首部（比如从采用 HTTPS 协议的页面请求另一个采用 HTTPS 协议的页面）。如果被请求页面的协议安全等级较低，则不会发送 referrer 首部（比如从采用 HTTPS 协议的页面请求采用 HTTP 协议的页面）。
strict-origin-when-cross-origin: 当发起同源请求时，在 referrer 首部中包含完整的 URL。当被请求页面与来源页面不同源但是有相同协议安全等级时（比如 HTTPS→HTTPS），在 referrer 首部中仅包含来源页面的源。当被请求页面的协议安全等级较低时（比如 HTTPS→HTTP），不发送 referrer 首部。
unsafe-url: 始终在 referrer 首部中包含源以及路径（但不包括 fragment，密码，或用户名）。这个值是不安全的, 因为这样做会暴露受 TLS 保护的资源的源和路径信息。
