OWASP TOP 10
1.SQL注入
将不受信任的数据作为命令或查询的一部分发送到解析器时，会产生诸如SQL注入、OS注入和LDAP注入的注入缺陷。攻击者的恶意数据可以诱使解析器在没有适当授权的情况下执行非预期命令或访问数据。
危害
注入可以导致数据丢失或被破坏，缺乏可审计性或拒绝服务。注入漏洞有时甚至可导致完全接管主机
sql注入类型
1. 数字型
2. 字符型
3. 搜索型
4. 堆叠注入
5. 联合注入
6. 报错注入
7. 宽字节注入
8. 布尔盲注
9. 时间盲注
常用函数
if(condition,A,B) : 若condition返回真则执行A，假则执行B
substr(str,A,B) : 字符串截取函数，截取str字符串从A位置开始，截取B个字符
left(str,A) : 类似字符串截取函数，返回str字符串从左往右数的A个字符
count(A) : 计算A的数目，常用与查询数据表、数据列、数据内容的条数
len(A) : 计算A的长度，常用于返回数据库名、数据表名、数据列名的长度
ascii(A) : 返回A的ascii码，当逐字猜解限制单引号的输入时，可以通过查询ascii码来绕过
updatexml(1,concat('~',SQL语句,'~'),1)
extractvalue(1,concat('~',(SQL语句)))
防御
1.对用户输入的内容进行转义（PHP中addslashes()、mysql_real_escape()函数）。
2.限制关键字的输入（PHP中preg_replace()函数正则替换关键字），限制输入的长度 。
3.使用SQL语句预处理，对SQL语句首先进行预编译，然后进行参数绑定，最后传入参数。
4.使用白名单规范化验证输入
5.数据类型进行严格定义，数据长度进行严格规定。比如查询数据库某条记录的id，定义它为整型，如果用户传来的数据不满足条件，要对数据进行过滤。数据长度也应该做严格限制，可以防止较长的SQL注入语句。
2. 失效的身份验证和会话管理
通常，通过错误使用应用程序的身份认证和会话管理功能，攻击者能够破译密码、密钥或会话令牌，或者利用其它开发中的缺陷来冒充其他用户的身份（暂时或永久）。
防御
使用多因素身份验证
执行弱密码检查，使用更复杂的密码
生成随机且高度复杂的会话ID，超时即失效
限制失败的登录次数，防止暴力破解
3. 敏感数据泄露
许多Web应用程序和API都无法正确保护敏感数据，例如：财务数据、医疗保健数据和PII。攻击者可以窃取或修改这些未加密的数据，以进行信用卡诈骗、身份盗窃或其他犯罪。因此，我们需要对敏感数据加密，这些数据包括：传输过程中的数据、被存储的数据以及浏览器交互数据。
防御
对系统处理、存储或传输的数据分类，并根据分类进行访问控制。（权限控制）
熟悉与敏感数据保护相关的法律和条例，并根据每项法规要求保护敏感数据。
对于没必要存放的、重要的敏感数据，应当尽快清除，或者通过PCI DSS标记或拦截。未存储的数据不能被窃取。
确保存储的所有敏感数据被加密。(加密敏感数据)
确保使用了最新的、强大的标准算法或密码、参数、协议和密匙，并且密钥管理到位。
确保传输过程中的数据被加密，如：使用TLS。确保数据加密被强制执行，如：使用HTTP严格安全传输协议（HSTS）。（加密传输）
禁止缓存对包含敏感数据的响应。（禁止缓存）
确保使用密码专用算法存储密码，如：Argon2 、scrypt、bcrypt或者PBKDF2 。将工作因素（延迟因素）设置在可接受范围。
单独验证每个安全配置项的有效性。
4. XML外部实体（XXE）
许多较早的或配置不佳的XML处理器评估了XML文档中的外部实体引用。外部实体可以通过URI文件处理器、在Windows服务器上未修复的SMB文件共享、内部端口扫描、远程代码执行来实施拒绝服务攻击
危害
1. 任意文件读取
2. 执行系统命令
3. 内网扫描
4. 攻击内网网站
5. 拒绝服务攻击
防御
使用开发语言提供的禁用外部实体的方法
过滤用户提交的XML数据
使用尽可能简单的数据格式（如：JSON），避免对敏感数据进行序列化
使用防火墙（WAF）检测、监控和防止XXE攻击
5. 失效的访问控制
未对通过身份验证的用户实施恰当的访问控制。攻击者可以利用这些缺陷访问未经授权的功能或数据，例如：访问其他用户的帐户、查看敏感文件、修改其他用户的数据、更改访问权限等。
危害
1. 伪造用户身份
2. 获取管理员权限
防御
除公有资源外，默认情况下拒绝访问。
使用一次性的访问控制机制，并在整个应用程序中不断重用它们，包括最小化CORS使用。
建立访问控制模型以强制执行所有权记录，而不是接受用户创建、读取、更新或删除的任何记录。
域访问控制对每个应用程序都是唯一的，但业务限制要求应由域模型强制执行。
禁用Web服务器目录列表，并确保文件元数据（如：git）不存在于Web的根目录中。
记录失败的访问控制，并在适当时向管理员告警（如：重复故障）。
对API和控制器的访问进行速率限制，以最大限度地降低自动化攻击工具的危害。
当用户注销后，服务器上的令牌应失效。
6. 安全配置错误
安全配置错误是数据中最常见的缺陷，这部分缺陷包含：手动配置错误、临时配置（或根本不配置）、不安全的默认配置、开启S3 bucket、不当的HTTP 标头配置、包含敏感信息的错误信息、未及时修补或升级（或根本不修补和升级）系统、框架、依赖项和组件。
防御
一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、质量保证和生产环境都应该进行相同配置，并且，在每个环境中使用不同的密码。这个过程应该是自动化的，以尽量减少安装一个新安全环境的耗费。
搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功能和框架。
检查和修复安全配置项来适应最新的安全说明、更新和补丁，并将其作为更新管理过程的一部分，。在检查过程中，应特别注意云存储权限。
一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构，包括：分段、容器化和云安全组。
向客户端发送安全指令，如：安全标头。
在所有环境中能够进行正确安全配置和设置的自动化过程。
7. XSS 跨站脚本
每当应用程序的新网页中包含不受信任的、未经过恰当验证或转义的数据，或者使用可以创建JavaScript 的浏览器API 更新现有的网页时，就会出现XSS 缺陷。XSS 缺陷让攻击者能够在受害者的浏览器中执行脚本，并劫持用户会话、污损网站或将用户重定向到恶意站点。
XSS攻击类型
1. 反射型 XSS
- 需要攻击者提前构造一个恶意链接，来诱使客户点击，比如这样的一段链接：
abc.com/?params=<script>alert(/xss/)</script>
2. 存储型(持久型) XSS
- 主要将XSS代码提交存储在服务器端（数据库，内存，文件系统等），下次请求目标页面时不用再提交XSS代码。当目标用户访问该页面获取数据时，XSS代码会从服务器解析之后加载出来，返回到浏览器做正常的HTML和JS解析执行，XSS攻击就发生了。存储型 XSS 一般出现在网站留言、评论、博客日志等交互处，恶意脚本存储到客户端或者服务端的数据库中。
3. DOM XSS
- 这种类型则是利用非法输入来闭合对应的html标签。比如，有这样的一个a标签：
<a href='$var'></a>当$var的内容变为' οnclick='alert(/xss/) //这段代码就会被执行
XSS 常见攻击方法
- 绕过 XSS-Filter，利用 <> 标签注入 Html/JavaScript 代码；
- 利用 HTML 标签的属性值进行 XSS 攻击。例如：
<img src="javascript:alert('xss')"/>；（当然并不是所有的 Web 浏览器都支持 Javascript 伪协议，所以此类 XSS 攻击具有一定的局限性） - 空格、回车和 Tab。如果 XSS Filter 仅仅将敏感的输入字符列入黑名单，比如 javascript，用户可以利用空格、回车和 Tab 键来绕过过滤，例如：
<img src="javas cript:alert(/xss/);"/>； - 利用事件来执行跨站脚本。例如：
<img src="#" onerror= "alert(1)"/>，当 src 错误的视乎就会执行 onerror 事件； - 利用 CSS 跨站。例如：
body {backgrund-image: url("javascript:alert('xss')")}； - 扰乱过滤规则。例如：
<IMG SRC="javaSCript: alert(/xss/);"/>； - 利用字符编码，通过这种技巧，不仅能让 XSS 代码绕过服务端的过滤，还能更好地隐藏 Shellcode；（ JS 支持 unicode、eacapes、十六进制、十进制等编码形式）；
- 拆分跨站法，将 XSS 攻击的代码拆分开来，适用于应用程序没有过滤 XSS 关键字符（如<、>）却对输入字符长度有限制的情况下；
- DOM 型的 XSS 主要是由客户端的脚本通过 DOM 动态地输出数据到页面上，它不依赖于提交数据到服务器，而是从客户端获得DOM中的数据在本地执行。容易导致 DOM 型的 XSS 的输入源包括：Document.URL、Location(.pathname|.href|.search|.hash)、Document.referrer、Window.name、Document.cookie、localStorage/globalStorage；
防御
对输入内容的特定字符进行编码
为了避免反射式或存储式的XSS漏洞，最好的办法是根据HTML输出的上下文（包括：主体、属性、JavaScript、CSS或URL）对所有不可信的HTTP请求数据进行恰当的转义
Http Only cookie , 许多 XSS 攻击的目的就是为了获取用户的 cookie，将重要的 cookie 标记为 http only，这样的话当浏览器向服务端发起请求时就会带上 cookie 字段，但是在脚本中却不能访问 cookie，这样就避免了 XSS 攻击利用 js 的 document.cookie获取 cookie。
8. 不安全的反序列化
当应用程序接收到恶意的序列化对象时，会出现不安全的反序列缺陷。不安全的反序列化会导致远程代码执行。即使反序列化缺陷不会导致远程代码执行，也可以重播、篡改或删除系列化对象以欺骗用户、进行注入攻击和提升权限。
防御
执行完整性检查，如：任何序列化对象的数字签名，以防止恶意对象创建或数据篡改。
在创建对象之前强制执行严格的类型约束，因为代码通常被期望成一组可定义的类。绕过这种技术的方法已经被证明，所以完全依赖于它是不可取的。
如果可能，隔离运行那些在低特权环境中反序列化的代码。
记录反序列化的例外情况和失败信息，如：传入的类型不是预期的类型，或者反序列处理引发的例外情况。
限制或监视来自于容器或服务器传入和传出的反序列化网络连接。
监控反序列化，当用户持续进行反序列化时，对用户进行警告
9. 使用含有已知漏洞的组件
组件（例如：库、框架和其他软件模块）运行和应用程序相同的权限。如果使用含有已知漏洞的组件，这样的攻击可以造成严重的数据丢失或服务器接管。使用含有已知漏洞的组件的应用程序和API，可能会破坏应用程序防御、造成各种攻击并产生严重影响。
防御
移除不使用的功能、组件、依赖等
仅从官方渠道定期更新组件，并使用签名机制防止组件被篡改或伪造
10.不足的日志记录和监控
不足的日志记录和监控，以及事件响应集成的丢失或无效，使得攻击者能够进一步攻击系统、保持持续性或转向更多系统，以及篡改、提取或销毁数据。大多数缺陷研究显示，缺陷被检测出的时间超过200天，并且通常通过外部检测方检测，而不是通过内部进程或监控检测。
防御
确保所有登录、访问控制失败、输入验证失败能够被记录到日志中去，并保留足够的用户上下文信息，以识别可疑或恶意帐户，并为后期取证预留足够时间。
确保日志以一种能被集中日志管理解决方案使用的形式生成
确保高额交易有完整性控制的审计信息，以防止篡改或删除，例如审计信息保存在只能进行记录增加的数据库表中。
建立有效的监控和告警机制，使可疑活动在可接受的时间内被发现和应对。
建立或采取一个应急响应机制和恢复计划