服务端漏洞
第三方组件漏洞
以java为例，用第三方库的时候可以用dependency-check-maven检查项目依赖是否存在漏洞。
注入漏洞
-
SQL注入
SQL语句静态模板和动态数据部分没有严格区分， 如果数据中加了某些关键字（union select, drop之类），就可能被执行。
- 所以永远不要相信用户的输入，一定要检查。我体感一般是在前端框架就把许多不合规则的输入拦截了
- 事实上，无论出于安全还是用户体验，能做成选项的就不要让用户手动输入
- 后端做的是使用ORM框架将template和数据拆分开，避免使用Raw方法与DB交互
- 但ORM中也有些危险函数，比如Mybatis-plus的inSql（支持sql的直接拼接）
- 类似地，GORM的Order()如果直接承接用户输入就可能产生注入
- 所以永远不要相信用户的输入，一定要检查。我体感一般是在前端框架就把许多不合规则的输入拦截了
-
命令注入
代码中遇到要调用某个命令的情况，通常涉及到命令的拼接。如果没做好安全过滤，就会有命令注入风险。
- 比如对linux来说，在输入后加个pipe，就可以把返回结果“偷”给pipe后的命令，并执行
总之，对动态值尽可能设置白名单（选项就是一种白名单）；如果不行，要尝试校验数据类型，过滤黑名单中的特殊字符/转义。
越权漏洞
- 未授权
- 水平越权（e.g. 某权限者A执行了另一同级权限者B的权限范围的操作）
- 垂直越权（e.g. 某权限者A执行了不同级权限者B的权限范围的操作）
- 通常只会发生在一个账号里（？）
前面说到用户的不法输入往往在前端框架被拦住，但是假若不做权限校验，攻击者可以开通另外的测试管理员账户抓包获取接口（？），或者reverse-engineer前端代码获取接口，从而绕过前端直接访问后端接口。因此，后端必须做好权限的校验拦截。
SSRF服务端请求伪造攻击
这种攻击成立的原因是后端server有内网的权限。攻击者以后端server为跳板，让后端service向内网地址发出恶意请求，以获取敏感信息，或执行恶意操作。
通常通过改变后端service访问的地址来完成。防护方式是，对url的host开启白名单，或解析判定url的ip是否指向内网。
文件上传
经典例子是上传了一段可执行的脚本文件，比如php文件，然后服务器的web容器解析执行了脚本，导致脚本内代码执行。
要完成这个攻击，要满足以下几个条件:
- 上传的文件能够被Web容器解释执行。所以文件上传后所在的目录要是Web容器所覆盖到的路径
- 用户能够从Web上访问这个文件。如果文件上传了，但用户无法通过Web访问，或者无法得到Web容器解释这个脚本，那么也不能称之为漏洞
- 用户上传的文件若被安全检查、格式化、图片压缩等功能改变了内容，则也可能导致攻击不成功
也有一种神奇的操作是“借你的CDN来用”：找到公开的上传点（视频发布/文章发布/客服反馈等），上传（符合文件类型的）文件，然后获取到文件的url，用于自己的内容传播。
防护：
- 限制文件类型
- 站库分离：应用部署位置和上传文件分离，采用TOS/OSS进行文件存储。这样一来，存文件的地方不会执行文件里的内容，防止恶意的执行
- 防止图床：对图片url进行时间、访问身份限制
客户端漏洞
开放重定向
攻击者构造恶意重定向链接。解决方案是用白名单。
XSS跨站脚本攻击
往目标web页面里提交恶意script代码（比如通过input）。当用户访问页面时，这段嵌入的代码被执行，以此窃取用户信息/以用户身份执行操作。
防护：
- 输入过滤
- 输出过滤：字符输出到DOM时，对危险字符进行html encode；用框架时避免使用危险指令（v-html等）
- 对富文本场景严格限制tag和attribute（采用白名单/黑名单）
- 配置Content-Security-Policy进行限制
CSRF跨站请求伪造
某网站在网页源代码中嵌入js代码，通过js代码给我们的服务器发送请求。由于发送请求时，浏览器会自动把cookie发送给对应的服务器，我们的服务器就不知道这个请求是由别的网站伪造的。
防护：核心是判断请求的来源
- 首次访问时给客户端派发CSRF token，客户端访问时，cookie和body里都要带这个token
- 配置SameSite cookies，禁止某些场景发送第三方cookie
- referer-based validation，校验referer是否合法
clickjacking点击劫持
点击劫持与CSRF的不同之处在于，点击劫持需要用户执行某种操作，比如点击按钮，而CSRF则是在用户不知情或者没有输入的情况下伪造整个请求。
诱导点击的方式如，在钓鱼页面iframe（这个是html原生element）原始页面，并覆盖一层诱导性文字。
防护：不让非预期网站iframe我的站点
- X-Frame-Options: DENY/SAMEORIGIN，或配置CSP的frame-ancestors
其它可能出漏洞的地方
CORS配置：错配allow list
- 要正确设置跨域白名单。代码层由middleware统一处理，网关层nginx反代理统一拦截处理
websocket：Cross-Site WebSocket Hijacking，即在使用cookie作为认证方式时，如果websocket服务端未校验好请求来源，可能导致会话被监听
- cookie鉴权要限制请求的origin；或者直接换token鉴权（需要多经过HTTPserver， auth center）
Ref & 引申阅读：
