Web开发安全|青训营笔记这是我参加[第五届青训营]伴学笔记创作活动的第10天本堂课程重要内容了解从「攻击者」的角色

这是我参加[第五届青训营]伴学笔记创作活动的第10天

本堂课程重要内容

了解从「攻击者」的角色的安全问题的危害和技术
了解从「防御者」的角色的安全问题的解决方案

Cross-Site Scripting(XSS)跨站脚本攻击

漏洞简述： 在输入框中插入恶意脚本在用户浏览网站时不知情进行攻击可能导致隐私泄露或作为挖矿的机子 漏洞之"洞" 形成XSS攻击，攻击者主要利用开发者盲目信任用户提交和直接将用户提交的字符串转化为dom
漏洞特点 通常难以从UI上感知(暗地执行脚本);窃取用户信息(如cookie/token);绘制UI(eg.获奖弹窗),诱骗用户点击/填写表单
漏洞分类

Stored XSS存储型-恶意脚本存储在数据库中，只要访问页面后需要读取数据就相当于被攻击了，该类攻击危害最大，对全部用户可见
Reflected XSS反射型-不涉及数据，从URL的参数后面跟的值上攻击
DOM-based XSS基于dom-不需要服务器参与，恶意攻击发起和执行全在浏览器完成
Mutation-based XSS-利用浏览器渲染DOM 的特性（不同浏览器有自己独特渲染机制）。按照不同浏览器进行区别攻击

这两种XSS类型的区别：完成注入脚本的地方不同

解决方案
1.现成工具

前端-主流框架（vue，react等）都默认防御，google-closure-library
服务端(Node)-DOMPurify

2.业务需求涉及使用以下场景所对应的解决方案

string->dom:在使用DOMParser时需要先转译string
上传svg，需要先做图片扫描
blob动态生成script，不要做自定义跳转行为
允许用户自定义样式

Same-origin Policy同源策略

协议

域名

端口

Contetnt Security Policy(CSP) 哪些源(域名)被认为是安全的,来自安全源的脚本可以执行,否则直接抛错,此外对eval标签+inlinescript内联说No，直接报错

Cross-site request forgery(CSRF)跨站伪造请求

漏洞简述： 在用户不知情的前提下利用用户权限(cookie),构造指定HTTP请求,窃取或修改用户敏感信息 get-a,img,表单

通过Origin+Referrer判断请求来源是否合法外，还有通过token判断，从合法页面来判断是否请求合法，然后服务器标记例子：iframe攻击-解决：X-Frame-Options：DENY/SAMEORIGIN CSRF anti-pattern反公式
SameSite Cookie策略：避免用户信息被携带，限制cookie域名与当前页面域名是否匹配
特殊情况：依赖cookie的第三方服务-设置Set-Cookie:SameSite=None; Secure;