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'
Content-Security-Policy-Report-Only
:收集报告,但没有限制请求
(2)使用meta标签
限制表单:
<meta http-equiv="Content-Security-Policy" content="form-action 'self';">
csrf
csrf: 主要借助于浏览器的一些认证机制,很多网站都是基于cookie和session id 等等来存储的
什么是 CSRF 攻击?
CSRF 是跨站点请求伪造 (Cross—Site Request Forgery),跟 XSS 攻击一样,存在巨大的危害性。
CSRF攻击原理及过程如下:
-
用户C打开浏览器,访问受信任网站A,输入用户名和密码请求登录网站A;
-
在用户信息通过验证后,网站A产生Cookie信息并返回给浏览器,此时用户登录网站A成功,可以正常发送请求到网站A;
-
用户未退出网站A之前,在同一浏览器中,打开一个TAB页访问网站B;
-
网站B接收到用户请求后,返回一些攻击性代码,并发出一个请求要求访问第三方站点A;
-
浏览器在接收到这些攻击性代码后,根据网站B的请求,在用户不知情的情况下携带Cookie信息,向网站A发出请求。网站A并不知道该请求其实是由B发起的,所以会根据用户C的Cookie信息以C的权限处理该请求,导致来自网站B的恶意代码被执行。
CSRF 攻击防护
目前防御 CSRF 攻击主要有三种策略:验证 HTTP Referer 字段;在请求地址中添加 token 并验证;在 HTTP 头中自定义属性并验证。
- 尽量使用 POST,限制 GET
- 浏览器 Cookie 策略
- 加验证码
- Referer Check(Referer Check 在 Web 最常见的应用就是 “防止图片盗链”。)
- 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),可能点击一下就钱就被转走了,然后浏览器紧跟着也出了一些策略
注:
各个浏览器有个属性设为默认值(以前是null),get请求还是会带cookie,但post就不会带了
注:
原来的采集用户的喜好(推荐商品)就是通过这种多网站的第三方的cookie来做的,禁了就做不了了
注:
csrf的cookie问题可以通过cookie的samesite属性来解决