原理：
SQL 注入就是指 web 应用程序对用户输入的数据合法性没有过滤或者是判断，前端传入的参数是攻击者能够控制，而且参数带入数据库的查询，将不受信任的数据作为命令或查询的一部分发送到解析器时，会产生诸如SQL注入、NoSQL注入、OS注入和LDAP注入的注入缺陷。攻击者的恶意数据可以诱使解析器在没有适当授权的情况下执行非预期命令或访问数据，经过构造恶意的 sql 语句来实现对数据库的任意操作。注入--脆弱点
应用程序存在如下情况时，是脆弱的且易受攻击：用户提供的数据没有经过应用程序的验证、过滤或净化
动态查询语句或非参数化的调用，在没有上下文感知转义的情况下，被用于解释器。在ORM搜索参数中使用了恶意数据，这样搜索就获得包含敏感或未授权的数据恶意数据直接被使用或连接，诸如SQL语句或命令在动态查询语句、命令或存储过程中包含结构和恶意数据
​
比如：
一、报错注入
二、基于布尔的盲注
三、延时注入
四、宽字节注入
​
注入--防护策略
防止注入漏洞需要将数据与命令语句、查询语句分隔开来。
最佳选择是使用安全的API，完全避免使用解释器，或提供参数化界面的接口，或迁移到ORM或实体框架。
使用正确的或“白名单”的具有恰当规范化的输入验证方法同样会有助于防止注入攻击，但这不是一个完整的防御，因为许多应用程序在输入中需要特殊字符，例如文本区域或移动应用程序的API。
对于任何剩余的动态查询，可以使用该解释器的特定转义语法转义特殊字符。OWASP的JavaEncoder和类似的库提供了这样的转义例程。
在查询中使用LIMIT和其他SQL控件，以防止在SQL注入时大量地泄露记录

2.失效的身份认证和会话管理

原理:
在开发web应用程序时，开发人员每每只关注Web应用程序所需的功能，因此经常会创建自定义的认证和会话方案。可是要正确的实现这些方案倒是很难的。结果就在退出、密码管理、超时、密码找回、账户更新等方面存在漏洞。通过错误使用应用程序的身份认证和会话管理功能，攻击者能够破译密码、密钥或会话令牌，或者利用其它开发缺陷来暂时性或永久性冒充其他用户的身份。​失效的身份认证--脆弱点
应用程序存在如下情况时，那么可能存在身份验证的脆弱性：
允许凭证填充，这使得攻击者获得有效用户名和密码的列表
允许暴力破解或其他自动攻击
允许默认的、弱的或众所周知的密码，例如“Password1”或“admin/admin
使用弱的或失效的验证凭证，忘记密码程序，例如“基于知识的答案
使用明文、加密或弱散列密码（参见：敏感数据泄露）
缺少或失效的多因素身份验证
暴露URL中的会话ID（例如URL重写）
在成功登录后不会更新会话ID。
不正确地使会话ID失效。当用户不活跃的时候，用户会话或认证令牌（特别是单点登录（SSO）令牌）没有正确注销或失效失效的身份认证--防护策略
在可能的情况下，实现多因素身份验证，以防止自动、凭证填充、暴力破解和被盗凭据再利用攻击不要使用发送或部署默认的凭证，特别是管理员用户执行弱密码检查，例如测试新或变更的密码，以纠正“排名前10000个弱密码将密码长度、复杂性和循环策略与NIST-800-63B的指导方针（记住秘密）或其他现代的基于证据的密码策略相一致确认注册、凭据恢复和API路径，通过对所有输出结果使用相同的消息，用以抵御账户枚举攻击限制或逐渐延退失败的登录尝试。记录所有失败信息并在凭据填充、暴力破解或其他攻击被检测时提醒管理员。使用服务器端安全的内置会话管理器，在登录后生成高度复杂的新随机会话ID。会话ID不能在URL中，可以安全地存储和当登出、闲置、绝对超时后使其失效

3.跨站脚本攻击 XSS

XSS是跨站脚本攻击，原理是攻击者向有XSS漏洞的网站中输入恶意的HTML代码。当应用程序的新网页中包含不受信任的、未经怡当验证或转义的数据时，或者使用可以创建HTML或JavaScript的浏览器API更新现有的网页时，就会出现XSS缺陷。XSS让攻击者能够在受害者的浏览器中执行脚本，并动持用户会话、破坏网站或将用户重定向到恶意站点。当其它用户浏览该网站时，这段HTML代码会自动执行，从而达到攻击的目的。跨站脚本（XSS）--脆弱性
典型的XSS攻击可导致盗取session、账户、绕过MFA、DIV替换、对用户浏览器的攻击（例如：恶意软件下载、键盘记录）以及其他用户侧的攻击。
存在三种XSS类型，通常针对用户的浏览器：反射式XSS：应用程序或API包括未经验证和未经转义的用户输入，作为HTML输出的一部分。一个成功的攻击可以让攻击者在受害者的浏览器中执行任意的HTML和JavaScript。通常，用户将需要与指向攻击者控制页面的某些恶意链接进行交互，例如恶意漏洞网站，广告或类似内容。
存储式XSS：你的应用或者API将未净化的用户输入存储下来了，并在后期在其他用户或者管理员的页面展示出来。存储型XSS一般被认为是高危或严重的风险。
基于DOM的XSS：会动态的将攻击者可控的内容加入页面的Javascript框架、单页面程序或API存在这种类型的漏洞。理想的来说，你应该避免将攻击者可控的数据发送给不安全的JavaScriptAPI。

什么是 HttpOnly?
若是您在 cookie 中设置了 HttpOnly 属性，那么经过 js 脚本将没法读取到cookie 信息，这样能有效的防止 XSS 攻击。
​
跨站脚本（XSS）--防护策略
防止XSS需要将不可信数据与动态的浏览器内容区分开。使用设计上就会自动编码来解决XSS问题的框架，如：Ruby3.0或ReactJs。为了避免反射式或存储式的XSS漏洞，要根据HTML输出的上下文（包括：主体、属性、Javascript、csS或URL）对所有不可信的HTTP请求数据进行恰当的转义。在客户端修改浏览器文档时，为了避免DOMXSS攻击，最好的选择是实施上下文敏感数据编码。如果这种情况不能避免，可以采用类似上下文敏感的转义技术应用于浏览器API。使用内容安全策略（CSP）是对抗XSS的深度防御策略。如果不存在可以通过本地文件放置恶意代码的其他漏洞（例如：路径遍历覆盖和允许在网络中传输的易受攻击的库），则该策略是有效的。

4.直接引用不安全的对象

定义：
不安全的直接对象引用（IDOR）容许攻击者绕过网站的身份验证机制，并经过修改指向对象连接中的参数值来直接访问目标对象资源，这类资源能够是属于其余用户的数据库条目以及服务器系统中的隐私文件等等。
​
出现的缘由：
Web应用每每在生成Web页面时会用它的真实名字，且并不会对全部的目标对象访问时来检查用户权限，因此这就形成了不安全的对象直接引用的漏洞。
服务器上的具体文件名、路径或数据库关键字等内部资源被暴露在URL或网页中，攻击者能够尝试直接访问其余资源。
​
防护措施：
1.使用基于用户或会话的间接对象访问，这样可防止攻击者直接攻击未受权资源
2.访问检查：对任何来自不受信源所使用的全部对象进行访问控制检查
3.避免在url或网页中直接引用内部文件名或数据库关键字
4.验证用户输入和url请求，拒绝包含./ …/的请求 

5.安全配置错误

定义：
安全配置错误是最常见的安全问题，这通常是由于不安全的默认配置、不完整的临时配置、开源云存储、错误的HTTP标头配置以及包含敏感信息的详细错误信息所造成的。因此，我们不仅需要对所有的操作系统、框架、库和应用程序进行安全配置，而且必须及时修补和升级它们。安全配置错误--脆弱性
应用程序存在以下情况，可能受到攻击：应用程序栈堆的任何部分都缺少适当的安全加固，或者云服务的权限配置错误。
应用程序启用或安装了不必要的功能（例如：不必要的端口、服务、网页、帐户或权限）。默认帐户的密码仍然可用且没有更改。
错误处理机制向用户披露堆栈跟踪或其他大量错误信息。
对于更新的系统，禁用或不安全地配置最新的安全功能。
应用程序服务器、应用程序框架（Struts、Spring、ASP.NET）、库文件、数据库等没有进行安全配置。
服务器不发送安全标头或指令，或者未对服务器进行安全配置。
您的应用软件已过期或易受攻击（参见：使用含有已知漏洞的组件）。​
安全配置错误--防护策略
一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。
开发、质量保证和生产环境都应该进行相同配置，并且在每个环境中使用不同的密码。
这个过程应该是自动化的，以尽量减少安装一个新安全环境的耗费。搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和示例。移除不适用的功能和框架。
检查和修复安全配置项来适应最新的安全说明、更新和补丁，并将其作为更新管理过程的一部分，（参见：使用含有已知漏洞的组件）。
在检查过程中，应特别注意云存储权限。
一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构，包括分段、容器化和云安全组。
向客户端发送安全指令，如：安全标头。
在所有环境中能够进行正确安全配置和设置的自动化过程。

6.敏感信息泄露

漏洞描述：
因为管理员或者技术人员等各类缘由致使敏感信息泄露。许多web应用程序和app都没法正确保护敏感数据，攻击者能够经过窃取或修改未加密的数据来实施犯罪行为。未加密的敏感数据容易受到破坏，所以，必须要对敏感数据加密，这些数据包括：传输过程当中的数据、存储的数据以及浏览器的交互数据。
​
敏感数据泄露--脆弱性
对于敏感数据，要确定：在数据传输过程中是否使用明文传输？这和传输协议相关，如：HTTP、SMTP和FTP。外部网络流量非常危险。验证所有的内部通信，如：负载平衡器、Web服务器或后端系统之间的通信。
当数据被长期存储时，无论存储在哪里，它们是否都被加密，包含备份数据？
无论默认条件还是源代码中，是否还在使用任何旧的或脆弱的加密算法？
是否使用默认加密密钥，生成或重复使用脆弱的加密密钥，或者缺少恰当的密钥管理或密钥回转？
是否强制加密敏感数据，例如：用户代理（如：浏览器）指令和传输协议是否被加密？
用户代理（如：应用程序、邮件客户端）是否未验证服务器端证书的有效性？

敏感数据泄露--防护策略
对系统处理、存储或传输的数据分类，并根据分类进行访问控制。熟悉与敏感数据保护相关的法律和条例，并根据每项法规要求保护敏感数据对于没必要存放的、重要的敏感数据，应当尽快清除，或者通过PCIDSS标记或拦截确保存储的所有敏感数据被加密。确保使用了最新的、强大的标准算法或密码、参数、协议和密匙，并且密钥管理到位。确保传输过程中的数据被加密（HTTPS）；确保数据加密被强制执行禁止缓存对包含敏感数据的响应确保使用密码专用算法存储密码。将工作因素（延退因素）设置在可接受范围。单独验证每个安全配置项的有效性。

7.缺乏功能级的访问控制

原理：
大多数Web应用程序的功能在UI页面显示以前,会验证功能级别的访问权限。不足的日志记录和监控，以及事件响应缺失或无效的集成，使攻击者能够进一步攻击系统、保持持续性或转向更多系统，以及算改、提取或销毁数据，比如若是请求没有被验证,攻击者可以伪造请求从而在未经适当受权时访问功能。
​
测试方法：
一、 保证合法受权用户能够访问成功
二、 限制非法未受权用户的访问
​
防护措施：
一、 设计严格的权限控制系统，对于每一个请求和URL都要进行校验和权限确认，防止非法请求被执行
二、 对于每一个功能的访问，都要有明确的角色受权，采用过滤器的方式校验每一个请求的合法性
三、 实现Web访问的IP白名单列表，禁止不可信的IP访问Web系统 

8.跨站请求伪造 CSRF

CSRF概念：
CSRF跨站点请求伪造(Cross—Site Request Forgery)，跟XSS攻击同样，存在巨大的危害性，你能够这样来理解：攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来讲这个请求是彻底合法的，可是却完成了攻击者所指望的一个操做，攻击者可以利用外部实体窃取使用URI文件处理器的内部文件和共享文件、监听内部扫描端口、执行远程代码和实施拒绝服务攻击。以下：其中Web A为存在CSRF漏洞的网站，Web B为攻击者构建的恶意网站，User C为Web A网站的合法用户。
​
CSRF攻击攻击原理及过程以下：
1. 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登陆网站A；
2.在用户信息经过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登陆网站A成功，能够正常发送请求到网站A；
3. 用户未退出网站A以前，在同一浏览器中，打开一个TAB页访问网站B；
4. 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；
5. 浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的状况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求实际上是由B发起的，因此会根据用户C的Cookie信息以C的权限处理该请求，致使来自网站B的恶意代码被执行。
​
分类：
GET型和POST型。
​
防护手段：
一、验证 HTTP Referer 字段。根据HTTP协议，在HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址。
二、在请求地址中添加 token 并验证在HTTP请求中以参数的形式加入一个随机产生的token（随机字符串），并在服务器端创建一个拦截器来验证这个token，若是请求中没有token或者token内容不正确，则认为多是CSRF攻击而拒绝该请求。
三、二次验证在转帐等关键操做以前提供当前用户的密码或者验证码。二次验证能够有效防护CSRF 攻击。 

9.使用含有已知漏洞的组件

原理：
使用含有已知漏洞的组件（例如：库、框架和其他软件模块）拥有和应用程序相同的权限。如果应用程序中含有已知漏洞的组件被攻击者利用，可能会造成严重的数据丢失或服务器接管。同时，使用含有已知漏洞的组件的应用程序和API可能会破坏应用程序防御、造成各种攻击并产生严重影响。

含有已知漏洞的组件--脆弱性
如果满足下面的某个条件，那么应用程序就易受此类攻击：
如果不知道所有使用的组件版本信息（包括：服务端和客户端）。这包括了直接使用的组件或其依赖的组件。如果软件易受攻击，不再支持或者过时。这包括：OS、Web服务器、应用程序服务器、数据库管理系统（DBMS）、应用程序、API和所有的组件、运行环境和库。
如果你定期做漏洞扫描和订阅你使用组件的安全公告。
如果不基于风险并及时修复或升级底层平台、框架和依赖库。很可能发生这种情况：根据变更控制，每月或每季度进行升级，这使得组织在这段时间内会受到已修复但未修补的漏洞的威胁。
如果软件工程师没有对更新的、升级的或打过补丁的组件进行兼容性测试
如果你没有对组件进行安全配置。

使用含有已知漏洞的组件-防护策略应该制定一个补丁管理流程：
移除不使用的依赖、不需要的功能、组件、文件和文档。利用如versions、DependencyCheck、retirejs等工具来持续的记录客户端和服务器端以及它们的依赖库的版本信息。
持续监控如CVE和NVD等是否发布已使用组件的漏洞信息。
订阅关于使用组件安全漏洞的警告邮件。
仅从官方渠道安全的获取组件，使用签名机制降低组件被算改或恶意漏洞的风险。
监控那些不再维护或者不发布安全补丁的库和组件。
如果不能打补丁，可以考虑部署虚拟补丁来监控、检测或保护。
每个组织都应该制定相应的计划，对整个软件生命周期进行监控、评审、升级或更改配置。

10.未验证的重定向和转发

重定向：
重定向是服务端根据逻辑，发送一个状态码（一般为3xx），告诉浏览器从新去请求那个地址.因此地址栏显示的是新的URL。（重定向是在客户端完成的）
转发：
转发是在服务器内部将请求转发给另外一个资源，把那个URL的响应内容读取过来,而后把这些内容再发给浏览器.浏览器根本不知道服务器发送的内容从哪里来的,由于这个跳转过程是在服务器实现的，并非在客户端实现的因此客户端并不知道这个跳转动做，因此它的地址栏仍是原来的地址。（转发是在服务器端完成的）
​
二者的区别：
一、重定向是浏览器向服务器发送一个请求并收到响应后再次向一个新地址发出请求，转发是服务器收到请求后为了完成响应跳转到一个新的地址。
二、重定向有两次请求，不共享数据，转发是有一次请求且共享数据。
三、重定向后地址栏会发生变化，转发不会。
四、重定向的地址能够是任意地址，转发的地址只能是当前应用类的某一个地址。
​
预防措施：
一、重定向外部网站须要验证是否在白名单。
二、转发内部网站要验证是否有权限,有权限才转发。