web安全（xss及csrf）

xss

xss ： 把一些数据直接拿来用，比如url，input中输入了一些东西，请求的资源等等一些用户能自定义的一些东西

比如：在input中输入一些标签（script标签），没进行过滤或转义（转义是把它们转成实体字符）

实体字符：
< 小于符号的实体字符,在页面中替换成<。

https://blog.csdn.net/weixin_49007365/article/details/118583523

html Sanitizer API(最新 消毒api)

10月18号， W3C中网络平台孵化器小组（Web Platform Incubator Community Group）公布了HTML Sanitizer API的规范草案。这份草案用来解决浏览器如何解决XSS攻击问题。

Web网络安全中最大的一类安全威胁是XSS跨站点脚本攻击，如何解决这类漏洞和攻击是开发、运维和安全工程师比较头疼的问题。目前由谷歌、Mozilla和Cure53联手提供Sanitzer API即将完成最后的开发

https://blog.csdn.net/powertoolsteam/article/details/121650718

注：csp也可以防xss

CSP

CSP指的是内容安全策略。

CSP以白名单的机制对网站加载或执行的资源起作用。在网页中，这样的策略通过HTTP头信息或者meta元素定义
CSP虽然提供了强大的安全保护，但是他也造成了如下问题：Eval及相关函数被禁用、内嵌的JavaScript代码将不会执行、只能通过白名单来加载远程脚本。

（1）使用HTTP的 Content-Security-Policy头部

在服务器端使用 HTTP的 Content-Security-Policy头部来指定你的策略

只能从同域下加载 :

Content-Security-Policy: default-src 'self'
1

Content-Security-Policy-Report-Only ：收集报告，但没有限制请求

（2）使用meta标签

限制表单：

1

https://www.jianshu.com/p/74ea9f0860d2

csrf

csrf： 主要借助于浏览器的一些认证机制，很多网站都是基于cookie和session id 等等来存储的

什么是 CSRF 攻击？

CSRF 是跨站点请求伪造 (Cross—Site Request Forgery)，跟 XSS 攻击一样，存在巨大的危害性。
CSRF攻击原理及过程如下：

1. 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；

2. 在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；

3. 用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；

4. 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；

5. 浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

CSRF 攻击防护

目前防御 CSRF 攻击主要有三种策略：验证 HTTP Referer 字段；在请求地址中添加 token 并验证；在 HTTP 头中自定义属性并验证。

1. 尽量使用 POST，限制 GET
2. 浏览器 Cookie 策略
3. 加验证码
4. Referer Check（Referer Check 在 Web 最常见的应用就是 “防止图片盗链”。）
5. Anti CSRF Token（现在业界对 CSRF 的防御，一致的做法是使用一个 Token（Anti CSRF Token）。
   
   注：
   CSRF 的 Token 仅仅用于对抗 CSRF 攻击。当网站同时存在 XSS 漏洞时候，那这个方案也是空谈。
   所以 XSS 带来的问题，应该使用 XSS 的防御方案予以解决。

Cookie

PS：Cookie 分为两种

Session Cookie（在浏览器关闭后，就会失效，保存到内存里），

Third-party Cookie（即只有到了 Exprie 时间后才会失效的 Cookie，这种 Cookie 会保存到本地）。

PS：另外如果网站返回 HTTP 头包含 P3P Header，那么将允许浏览器发送第三方 Cookie。

h5页面登陆问题

因为http是无状态的，在下一次用户登录时不可能让用户再登录一次，所以必须要记住用户的身份。

所以服务端会在请求返回的时候给一个set Cookie走一下这个cookie，下一次浏览器再发请求时，浏览器会把这个cookie带上，服务端就知道我是谁了

如果这是一个转账的东西（比如一个简单的get），可能点击一下就钱就被转走了，然后浏览器紧跟着也出了一些策略

https://www.wangan.com/wenda/3482

https://blog.csdn.net/u013934914/article/details/50428869

注：
各个浏览器有个属性设为默认值（以前是null），get请求还是会带cookie，但post就不会带了

注：
原来的采集用户的喜好（推荐商品）就是通过这种多网站的第三方的cookie来做的，禁了就做不了了

注：
csrf的cookie问题可以通过cookie的samesite属性来解决