安全威胁分类的英文缩写是STRIDE, 代表了六种安全威胁，分别为Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Services, and Elevation of Privileges.

Spoofing 就是伪装，比如我用别人的ID发言就是Identity Spoofing, 我想到用变化IP的办法就是IP Spoofing.

Tampering 就是篡改，比如我用别人ID发言的手段就是篡改了合法包，而他们的server端没有相应的检查措施。

Repudiation 就是拒绝承认，比如我进行了这些攻击，他们并不知道是我做的，也没有证据是我做的，我就可以不承认。

Information Disclosure 就是信息的泄漏，比如他们的那串数字图片就没有任何保护，图片上的信息轻易的就被别人得到了。

Denial of Services 就是拒绝服务，比如我的自动发帖使得正常用户无法使用就是这种攻击。

Elevation of Privileges 就是权限的提升，比如我尝试用管理员的权限去做事情，就是属于这种。 ———————————————— 版权声明：本文为CSDN博主「星辰流炎」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/tryheart/article/details/106842085

涉及第三方恶意网站 如果服务端没有合适的防御措施的话，用户即使访问熟悉的可信网站也有受攻击的危险。 欺骗用户浏览器，让其以用户的名义运行操作。

防御方法 检查Referer字段 用户网站浏览器的Referer字段，但浏览器可能有安全漏洞，也存在攻击者攻击某些浏览器，篡改其Referer字段的可能。

添加校验token 当客户端通过窗体提交请求时，这个伪随机数也一并提交上去以供校验。正常的访问时，客户端浏览器能够正确得到并传回这个伪随机数，而通过CSRF传来的欺骗性攻击中，攻击者无从事先得知这个伪随机数的值，服务端就会因为校验token的值为空或者错误

以下内容参考：https://segmentfault.com/a/1190000040776689

CSRF的有效防御方案： 检测HTTP请求头：reference/origin 设置合理的session超时时间 使用验证码 尽量使用POST接口，限制GET接口

XSS攻击通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序

攻击类型： （1）持久型跨站：最直接的危害类型，跨站代码存储在服务器（数据库）。 （2）非持久型跨站：反射型跨站脚本漏洞，最普遍的类型。用户访问服务器-跨站链接-返回跨站代码。 （3）DOM跨站（DOM XSS）：DOM（document object model文档对象模型），客户端脚本处理逻辑导致的安全问题。 基于DOM的XSS漏洞是指受害者端的网页脚本在修改本地页面DOM环境时未进行合理的处置，而使得攻击脚本被执行。在整个攻击过程中，服务器响应的页面并没有发生变化，引起客户端脚本执行结果差异的原因是对本地DOM的恶意篡改利用。

防御手段： 1）基于特征防御 2）基于代码修改防御 优化Web应用开发来减少漏洞

①查询用户向服务器上提交的信息：URL和附带的HTTP头、POST数据，过滤不是规定格式、长度的内容。 ②实现Session标记（标识一次会话的唯一标记）、CAPTCHA系统（验证码）或者HTTP引用头检查，以防功能被第三方网站所执行。 ③确认接收的内容被妥善的规范化，仅包含最小的、安全的Tag，去掉任何对远程内容的引用，使用HTTP only的cookie。

Cookie 是浏览器中用作存储介质的小块数据，并随每个请求发送到服务器。它们有助于会话管理、用户个性化和跟踪。 HttpOnly是Cookie中一个属性，用于防止客户端脚本通过document.cookie属性访问Cookie，有助于保护Cookie不被跨站脚本攻击窃取或篡改

访问控制通常用于系统管理员控制用户对服务器、目录、文件等网络资源的访问。 指防止对任何资源进行未授权的访问

MAC：强访问控制，常用于多级军事安全系统，对专用或简单系统较有效，但对通用或大型系统并不太有效。 常用的分为4级：绝密级（Top Secret）、秘密级（Secret）、机密级（Confidential）和无级别级（Unclas sified），其中T>S>C>U。所有系统中的主体（用户，进程）和客体（文件，数据）都分配安全标签，以标识安全等级。

用来保护系统确定的对象，对此对象用户不能进行更改。也就是说，系统独立于用户行为强制执行访问控制，用户不能改变他们的安全级别或对象的安全属性

上读(NRU) , 主体不可读安全级别高于它的数据 下写(NWD) , 主体不可写安全级别低于它的数据

参考：https://blog.csdn.net/Connie1451/article/details/98495968

联合身份模式： 实现可以使用联合身份的身份验证机制。 将用户身份验证与应用程序代码分离，并将身份验证委托给受信任的标识提供者。 这可以简化开发，并允许用户使用更广泛的标识提供者 (IdP) 进行身份验证，同时最小化管理开销。 它还允许明确地将身份验证与授权分离。

信任的标识提供者包括公司目录、本地联合服务、由业务伙伴提供的其他安全令牌服务 (STS)，或可以对拥有 Microsoft、Google、Yahoo! 或 Facebook帐户的用户进行身份验证的社交标识提供者。

通过身份验证工具，可基于身份验证令牌中的角色声明配置访问控制。 这通常称为基于角色的访问控制 (RBAC)，并且它允许对功能和资源的访问进行较具体级别的控制。

何时使用： 企业中的单一登录 与多个合作伙伴的联合身份。 SaaS 应用程序中的联合身份。 参考： https://learn.microsoft.com/zh-cn/azure/architecture/patterns/federated-identity