Owasp-top10 in 2021

A01：2021- Invalid access control Broken Access Control

common CWE( Weakness enumeration )

1. CWE-200: Exposure of Sensitive Information to an Unauthorized
   Actor（ Disclose sensitive information to unauthorized participants ）
2. CWE-201: Exposure of Sensitive Information Through
   Sent Data（ Disclose sensitive information by sending data ）
3. CWE-352: Cross-Site Request Forgery （ Cross-site request forgery ）

Risk statement

Access control enforces policies , Make it impossible for users to operate beyond their expected permissions . Failure of access control usually leads to unauthorized information disclosure 、 Modify or destroy all data 、 Or perform business functions outside the user's authority . Common access control vulnerabilities include ：

1. Violate the principle of least privilege or the principle of tacit rejection , That is, access should only be granted to specific capabilities 、 Role or user , But in fact, anyone can access .
2. By modifying the URL（ Parameter tampering or forced browsing ）、 Internal application status or HTML page , Or use modification API Requested attack tools to bypass access control checks .
3. By providing a unique identifier （ Unsafe direct object reference ） Allow viewing or editing other people's accounts .
4. API No, right POST、PUT and DELETE Enforce access control .
5. Privilege Promotion . Pretend to be a user without logging in or act as an administrator when logging in as a user .
6. Metadata operations , For example, by playback or tampering JSON Web token (JWT) To access the control token , Or manipulate cookie Or hide fields to elevate permissions , Or abuse JWT invalid .
7. CORS Misconfigured to allow unauthorized or untrusted API visit .
8. An authenticated page that can only be viewed as an unauthenticated user or a privileged page that can be accessed as a standard user .

Preventive measures

Access control is only on the trusted server-side code or no server API Effective in , In this way, the attacker cannot modify the access control check or metadata .

1. In addition to public resources , The default is “ Access denied ”.
2. Use a one-time access control mechanism , And reuse them throughout the application , This includes minimizing cross source resource sharing (CORS) Use .
3. Establish an access control model to enforce ownership records , Instead of simply accepting user created 、 Read 、 Any records updated or deleted .
4. Special business application access restriction requirements should be enforced by the domain model .
5. Ban Web Server directory list , And ensure that the file metadata （ for example ： .git） And backup files do not exist in Web In the root directory of .
6. Log the failed access control , And alert the administrator when appropriate （ for example ： Repeated fault ）.
7. Yes API And the access of the controller , To minimize the harm caused by automated attack tools .
8. When the user logs off , The state session identifier on the server should be invalid . Stateless JWT The token should be short , So that the attacker's attack
   Minimize hit window . For longer JWT, It is strongly recommended to follow OAuth Standard to revoke access .

A02：2021- Encryption mechanism failure （ Sensitive data leakage ）Cryptographic Failures

common CVE( Weakness enumeration )

1. CWE-259: Use of Hard-coded Password （ Use hard coded passwords ）
2. CWE-327: Broken or Risky Crypto Algorithm（ Corrupted or risky encryption algorithms ）
3. CWE-331 Insufficient Entropy （ Entropy deficiency ）

Risk statement

First, make sure that ： What are the protection requirements for the data in transmission and stored data . for example , password 、 Credit card number 、 Medical records 、 Personal information and trade secrets need additional protection , Especially when these data belong to the privacy protection law （ Such as ： The European Union GDPR) Or regulations （ Such as ： Financial data protection standards PCI DSS) Scope of application . For these data , To be sure ：

1. Whether plaintext transmission is used during data transmission ？ This is related to the transmission protocol , Such as ：HTTP、SMTP、 after TLS upgrade （ Such as STARTTLS ） Of FTP. External network traffic is harmful . All internal communications need to be verified , Such as , Load balancing 、Web Traffic between servers or back-end systems .
2. Whether by default or in old code , Are you still using any old or fragile encryption algorithms or transport protocols ？
3. Whether to use the default encryption key 、 Generate or reuse fragile encryption keys , Or whether there is a lack of appropriate key management or key management ？ Whether the encryption key has been submitted to the source code repository ？
4. Whether forced encryption is not performed , for example , Is there a lack of safety related HTTP（ browser ） Instruction or header ？
5. Are the received server certificates and trust chains properly verified ？
6. Whether the initialization vector ignores , Whether the reused or generated password operation mode is not secure enough ？ Whether unsafe operation mode is being used , For example, the operating mode that the European Central Bank is using ？ Whether to use encryption when authentication encryption is more appropriate ？
7. In the absence of cryptographic base key derivation functions , Whether to use password as encryption key ？
8. Whether randomness is used for encryption purposes that are not intended to meet encryption requirements ？ Even if you choose the right function , Whether it needs to be sown by developers , If you don't need to , Whether developers use lack of enough entropy / Unpredictable seeds cover the built-in powerful seeding function ？
9. Whether to use obsolete hash functions , for example MD5 or SHA1, Or use an unencrypted hash function when the hash function needs encryption ？
10. Are deprecated encryption population methods being used , for example PCKS number 1 v1.5？
11. Whether the encrypted error message or side channel information can be used , For example, use the form of filling Oracle attack ？

Preventive measures

 Handle the application 、 Classification of stored or transmitted data , And according to the privacy law 、 Regulatory requirements or business needs determine which data is sensitive .
 For sensitive data that does not need to be stored , Should be removed as soon as possible , Or by PCI DSS Tokenize or intercept . Unsaved data cannot be stolen .
 Ensure that all sensitive data stored is encrypted .
 Make sure you use the latest 、 Powerful standard algorithm 、 Protocol and key ; And key management is in place .
 Ensure that the data during transmission is encrypted , Such as using security protocols （ For example, it has forward confidentiality (FS) Cryptographically TLS、 Password priority of the server
And safety parameters ）. Ensure that data encryption is enforced , If you use HTTP Strictly secure transport protocol (HSTS) Such as instruction .
 Disable caching of responses containing sensitive data .
 Implement the required security controls according to the data classification application .
 Do not use FTP and SMTP And other traditional protocols to transmit sensitive data .
 Use with working factor （ Delay factor ） Strong adaptive and salt hash function for storing passwords , for example Argon2、scrypt、bcrypt or PBKDF2.
 The initialization vector suitable for the operation mode must be selected . For most modes , have access to CSPRNG（ Password security pseudo-random number generator ）.
For patterns that require random numbers , Then initialize the vector (IV) No need to use CSPRNG. In all cases , For a fixed key , Never use twice IV.
 Always use authenticated encryption , Not just encryption .
 The key should be randomly generated in an encrypted manner and stored in memory as a byte array . If you use a password , Then it must be converted into a key through the appropriate cryptographic base key derivation function .
 Make sure to use cryptographic randomness where appropriate , And not seeded in a predictable way or with low entropy . Most modern API There is no need for developers to CSPRNG Seed for security .
 Avoid using obsolete encryption functions and padding schemes , for example MD5、SHA1、PKCS number 1 v1.5.
 Verify the validity of each security configuration item separately .

A03：2021- Inject Injection

common CWE( Weakness enumeration )

1. CWE-79： Cross-siteScripting（ Cross-site scripting ）
2. CWE-89：SQL Injection（SQL Inject ）
3. CWE-73：External Control of File Name or Path（ External control of file name or path ）

Risk statement

In the following cases , Applications are vulnerable ：

1. The application does not validate 、 Filter or clean the data provided by users .
2. Dynamic queries or nonparametric calls without context aware escape are used directly in the interpreter .
3. Malicious data is mapped in object relation （ORM） Search parameters are used to extract additional sensitive records .
4. Malicious data is directly used or connected .SQL Or the command contains dynamic queries 、 Structures and malicious data in commands or stored procedures .

Preventive measures

Preventing injection requires separating data from commands and queries ：

1. The recommended option is to use safe API, This avoids using the interpreter entirely 、 Provide parameterized interfaces or migrate to object relational mapping tools （ORM）. Be careful ： Even parameterization , If PL/SQL or T-SQL Connect queries to data , Or use EXECUTE IMMEDIATE or exec（） Execute malicious data , Stored procedures can still be introduced SQL Inject .
2. Use affirmations （positive） or “ White list ” Server side input validation . This is not a perfect defense , Because many applications
   The program requires special characters , For example, a text area in a mobile application or API.
3. For any residual dynamic queries , Use the interpreter's specific escape syntax to escape special characters . Be careful ：SQL structure （ As shown in the table
   name 、 Name, etc ） Can't escape , Therefore, the structure name provided by the user is dangerous . This is a common problem in report writing software .
4. Use in query LIMIT And others SQL Control , In order to prevent in SQL In the case of injection, a large number of disclosure records .

A04：2021- Unsafe design Insecure Design

2021 A new category in the 2008 Edition , Focus on the risks associated with design and architectural defects , Call for more use of threat modeling 、
Security design patterns and reference architectures .

common CWE( Weakness enumeration )

1. CWE-209：Generation of Error Message Containing Sensitive Information（ Generate an error message containing sensitive information ）
2. CWE-256：Unprotected Storage of Credentials（ Unprotected storage of credentials ）
3. CWE-256：Unprotected Storage of Credentials（ Unprotected storage of credentials ）
4. CWE-522：Insufficiently Protected Credentials（ Insufficient voucher protection ）

Risk statement

Unsafe design is a broad category , Represent different weaknesses , Expressed as “ Missing or invalid control design ”. Unsafe design
Not all other pre - 10 Sources of risk categories . There are differences between unsafe designs and unsafe implementations . We distinguish between design defects and implementation defects for a reason , They have different root causes and remedies . Security design may still have implementation flaws , Which could lead to exploitable vulnerabilities . An unsafe design cannot be fixed by a perfect implementation , Because by definition , The required security controls have never been created to protect against specific attacks . One of the factors leading to unsafe design is the lack of inherent business risk analysis in the developed software or system , Therefore, it is impossible to determine what level of security design is required .

1. Demand and resource management
   Collect the business requirements of the application and negotiate with the business , Including the confidentiality of all data assets and expected business logic 、 integrity 、 Protection requirements for availability and authenticity . Consider how open your application is , And whether tenant isolation is required （ In addition to access control ）. Prepare technical requirements , Functional and non functional requirements . Plan and negotiate all designs 、 build 、 Budget for testing and operation , Including safety activities .
2. Safety design
   Safety design is a culture and method , It constantly evaluates threats , And ensure that the code has been robust design and testing , To prevent known attack methods . Threat modeling should be integrated into the elaboration session （ Or similar activities ） in ; View changes in data flow and access control or other security controls . In user story development , Determine the correct process and fault status , Ensure that the responsible party and the affected party fully understand and agree with these states . Analyze the assumptions and conditions of the expected and fault flows , Make sure it is still accurate and desirable . Determine how to verify the assumptions and implementation conditions required for correct behavior . Make sure the results are recorded in the user story . Learn from your mistakes , And provide positive incentives for improvement . Security design is neither an add-on , Nor is it a tool that can be added to the software .
3. Security development lifecycle
   Secure software requires a secure development lifecycle 、 Some form of security design pattern 、AppSec Planning method 、 Secure component library 、 Tools and threat modeling . During the whole project and software maintenance process , Contact your security expert at the beginning of the software project . Consider using
   OWASP Software Assurance maturity model （SAMM） To help build your security software development efforts .

Preventive measures

1. Establish and use a secure development lifecycle with application security professionals , To help evaluate and design security and privacy related controls .
2. Build and use a library of safe design patterns , Or use AppSec Existing elements in the plan .
3. Critical authentication 、 Access control 、 Business logic and key flows are modeled using threats .
4. Integrate security language and security controls into user stories .
5. At every layer of the application （ From front end to back end ） Integration rationality check .
6. Write unit and integration tests , To verify that all critical flows can resist the threat model . Compile the right use cases and misuse cases for each layer of the application .
7. Depending on exposure and protection needs , Layer the system layer and network layer .
8. Strictly isolate tenants in all tiers by design .
9. Limit the resource consumption of users or services .

A05：2021- Security configuration error Security Misconfiguration

common CWE( Weakness enumeration )

1. CWE-16 Configuration（ To configure ）
2. CWE-611 Improper Restriction of XML External Entity Reference（XML Improper restrictions on external entity references ）

Risk statement

Your application may be under attack , If the application is ：

1. Any part of the application stack lacks proper security reinforcement , Or the permission configuration of the cloud service is wrong .
2. The application has enabled or installed unnecessary features （ for example ： Unnecessary ports 、 service 、 Webpage 、 Account or permissions ）.
3. The default account and password are still available and have not been changed .
4. The error handling mechanism leaks stack information or other large amount of error information to the user .
5. For upgraded systems , The latest security features are disabled or not configured .
6. Application server 、 Application framework （ Such as ：Struts、Spring、ASP.NET）、 The library files 、 The database is not accessed
   Row security configuration .
7. The server does not send security headers or instructions , Or the safety parameters are not set .
8. Your application has expired or is vulnerable （ See “A6:2021- Fragile and obsolete components ”）.
   Lack of a system 、 Repeatable application security configuration process , The system will be at high risk

Preventive measures

1. A repeatable hardening process that can be quickly and easily deployed in another locked environment . Development 、 Both quality assurance and production environments should be configured the same , And use different passwords in each environment . This process should be automated , To minimize installation
   The cost of a new security environment .
2. Build a minimization platform , The platform does not contain any unnecessary functions 、 Components 、 Documents and examples . Remove or do not install inapplicable features and frames .
3. Check and repair security configuration items to adapt to the latest security instructions 、 Updates and patches , And as part of the update management process （ See “A6:2021- Fragile and obsolete components ”）. During the inspection , Special attention should be paid to cloud storage permissions （ Such as ：S3 Barrel right
   limit ）.
4. A segmented application architecture that provides effective separation and security between components and users , Include ： piecewise 、 Containerization and cloud security groups （ACL）.
5. Send security instructions to the client , for example ： Security header .
6. An automated process that verifies the correct security configuration and settings in all environments .

A06：2021- Defective and obsolete components Vulnerable and Outdated Components

common CWE( Weakness enumeration )

1. CWE-1104 Use of Unmaintained Third-Party
   Components（ Using unmaintained third-party components ）

Risk statement

If one of the following conditions is met , Then your application is vulnerable to such attacks ：

1. If you don't know all the component version information used （ Include ： Server and client ）. This includes directly used components or indirectly dependent components .
2. If the software is vulnerable , No longer supported or obsolete . This includes ： System 、Web The server 、 Application server 、 Data base
   Management system （DBMS）、 Applications 、API And all the components 、 Running environment and library .
3. If you do not regularly do vulnerability scanning and subscribe to the security bulletin of using components .
4. If you do not timely repair or upgrade the underlying platform based on risk 、 Framework and dependency libraries . This is likely to happen ： Control according to change , Upgrade monthly or quarterly , This makes the organization vulnerable to fixed but unfixed vulnerabilities during this period of time .
5. If the software engineer doesn't have an update 、 Compatibility test for upgraded or patched components .
6. If you do not have security configuration for the component （ See “A05:2021– Security configuration error ”).

Preventive measures

1. Remove unused dependencies 、 Functions not needed 、 Components 、 Files and documents .
2. Take advantage of versions、OWASP Dependency Check、retire.js And other tools to continuously record the version information of the client and server and their dependent libraries . Continuous monitoring, such as CVE and NVD Whether to publish vulnerability information of used components , Software analysis tools can be used to automate this function . Subscribe to warning emails about using component security vulnerabilities .
3. Secure access to components only from official sources , And use the signature mechanism to reduce the risk of components being tampered with or added to malicious vulnerabilities ( See
   “A08:2021- Software and data integrity failure ”).
4. Monitor libraries and components that are no longer maintained or do not release security patches . If you can't patch , Consider deploying virtual patches to monitor 、 Detect or protect .
   Every organization should have a plan , Monitor the whole software life cycle 、 review 、 Upgrade or change configuration .

A07：2021- Identification and authentication errors （ Invalid Authentication ）Identification and Authentication Failures

common CWE( Weakness enumeration )

1. CWE-297: Improper Validation of Certificate with Host Mismatch（ Perform improper voucher confirmation with the unmatched server ）
2. CWE-287: Improper Authentication（ Improper certification ）
3. CWE-384: Session Fixation（ Session fixation attack ）

Risk statement

1. Allow automated attacks like the attacker already has a list of valid user names and passwords .
2. Allow violent or other automated attacks .
3. Allow preset 、 fragile 、 Common passwords , Like "Password1" or "admin/admin".
4. The process of replying to or forgetting a password using fragile or invalid authentication information , Such as unsafe " Knowledge related questions and answers ".
5. Use clear code 、 A password that is encrypted or uses a more fragile hash ( Reference resources A3: 2017- Sensitive data leakage ).(TODO)https://github.com/OWASP/Top10/issues/553
6. No or invalid multifactor certification .
7. On URL Leak session in (session) ID( Such as URL rewrite ).
8. No rotation session after successful login (session) ID.
9. no Yes just indeed Of notes pin Meeting word (session) ID. use Household Of Meeting word (session) or recognize Prove tokens( Lord want yes single One deng Enter into (SSO)token) Not properly logged off during logout or a period of inactivity .

Preventive measures

Where possible , Implement multi factor authentication to prevent automatic library collision attacks 、 Brute force 、 And the stolen authentication information is duplicated
Exploit the attack .

1. Do not deliver or deploy any pre-set credentials , Especially managers .
2. Implement weak password check , For example, test whether the newly set or changed password exists in the previous 10000 A list of the worst passwords .
3. Change the password length 、 Complexity and rotation policies are related to NIST 800-63b file “ The first 5.1.1 section - Remembered secrets or other modern based on
   Password policy for evidence ” Consistent content of .
4. Respond with the same message for all results , Make sure you register 、 Authentication credentials reply and API Path can resist account enumeration attacks .
5. Limit or increase the delay of failed login attempts . All failures are logged and a crash is detected 、 Notify when brute force cracking or other attacks occur
   police .
6. Use the server end 、 Secure built-in session manager , After login, a new random session with high entropy is generated ID. conversation ID It should not be
   stay URL in , Must be stored safely , And after logging out 、 idle 、 Logged out after timeout .

A08：2021- Software and data integrity failure Software and Data Integrity Failures

common CWE( Weakness enumeration )

1. CWE-829：Inclusion of Functionality from Untrusted Control Sphere（ Contains functionality from the untrusted control realm ）
2. CWE-494：Download of Code Without
   Integrity Check（ Downloading code without integrity checking ）
3. CWE-502：Deserialization of Untrusted
   Data（ Deserialization of untrusted data ）.

Risk statement

Software and data integrity failures are related to code and infrastructure that cannot prevent integrity violations . An example of this is , Applications rely on untrusted sources 、 Repositories and content distribution networks （CDN） Plug in for 、 Library or module . unsafe CI/CD Pipelines can lead to unauthorized access 、 Malicious code or system security risk . Last , Many applications now include automatic updates . among , The update package was downloaded without sufficient integrity verification , And applied to previously trusted applications . An attacker may upload his own update package , To distribute and run on all installations . Another example is , Objects or data are encoded or serialized into structures that an attacker can see and modify , Vulnerable to unsafe deserialization .

Preventive measures

1. Use a digital signature or similar mechanism to verify that the software or data is from the intended source , And not modified .
2. Ensure that libraries and dependent projects , Such as ：npm or Maven, Using trusted Repository . If your risk is high , Please consider it
   Hosting an audited 、 Internally known qualified repositories .
3. Ensure the use of software supply chain security tools （ Such as ：OWASP Dependency Check or OWASP CycloneDX） To verify that the component does not contain known vulnerabilities .
4. Ensure code and configuration changes are reviewed , To minimize the possibility of malicious code or configuration being introduced into the software pipeline .
5. Make sure your CI/CD The pipeline has proper isolation 、 Configuration and access control , To ensure code integrity during build and deployment .
6. Ensure that serialized data is detected for tampering or replay through a specific form of integrity check or digital signature , All unsigned or unencrypted serialized data will not be sent to untrusted clients .

A09：2021- Security logs and monitoring failures Security Logging and Monitoring Failures

common CWE( Weakness enumeration )

1. CWE-778 Insufficient Logging（ Insufficient logging ）
2. CWE-117 Improper Output Neutralization for Logs（ Improper log output ）
3. CWE-223 Omission of Security-relevant Information（ Safety event information is not reported ）
4. CWE-532 Insertion of Sensitive Information into Log File（ Include sensitive information in the log file ）

Risk statement

If no logging and monitoring , You can't find violations . Logging occurs at any time 、 testing 、 Inadequate monitoring and proactive response :

1. Events requiring audit , for example ： Sign in 、 Failed logins and high value transactions , But not recorded .
2. Warnings and errors do not generate logs or log records are insufficient or log messages are not clear .
3. Applications and API The log of is not monitored for security suspicious activities .
4. Logs are only stored locally .
5. Appropriate alert thresholds and response escalation procedures are inadequate or ineffective .
6. Penetration testing and dynamic application security testing （DAST） Tools （ for example ：OWASP ZAP） The scan of did not trigger an alarm .
7. Applications cannot detect in real time or near real time 、 Upgrade or alert active attacks .
8. If you let users or attackers see log and alert events , You are vulnerable to information disclosure （ see “A01:2021- loss
   Effective access control ”）.

Preventive measures

Developers should consider the risks of the application , Implement some or all of the following controls ：

1. Make sure all logins 、 Both access control and server-side input validation failures can be documented in sufficient user context , To identify suspicious or malicious accounts , And leave enough time to allow for delayed forensic analysis .
2. Ensure that the logs are generated by the log management solution in a convenient format .
3. Ensure that the log data is properly encoded and encrypted , To prevent injection or attack on the log or monitoring system .
4. Ensure that high-value transactions have an audit trail of integrity controls , To prevent tampering or deletion , for example ： Only attach database tables or similar content .
5. DevSecOps The team should establish effective monitoring and alerts , In order to detect suspicious activities and react quickly .
6. Establish or adopt accident response and recovery plan , for example ： National institute of standards and technology (NIST)800-61r2 Or later .
7. There are some commercial and open source application protection frameworks , Such as ：OWASP ModSecurity Core ruleset , And open source log related software , Such as ：Elasticsearch、Logstash、Kibana（ELK）, It has custom instrument panel and alarm function .

A10：2021- Server request forgery Server-Side Request Forgery

Risk statement

once Web The application did not verify the user provided when obtaining remote resources URL, Will appear SSRF defects . It allows an attacker to force an application to send a crafted request to an unexpected destination , Even with a firewall 、VPN Or other types of network access control lists （ACL） In the case of protection .

With modern times Web Applications provide convenient functions for end users , obtain URL Become a common scene . therefore ,SSRF Security attacks are also on the rise . Besides , Due to the complexity of cloud services and Architecture ,SSRF The severity of is getting higher and higher .

Preventive measures

Developers can implement some or all of the following defenses , Defense in depth to prevent SSRF:

Network layer defense suggestions ：

1. Set multiple network segments with remote resource access functions in an isolated network , In order to reduce SSRF Influence .
2. perform “ Default refusal ” Firewall policies or network access control rules , To block all communication except necessary internal communication .
   Tips : Establish ownership and lifecycle of application based firewall rules .
3. Record all accepted and blocked network flows on the firewall ( See “A09:2021- Security logs and monitoring failures ”).

Application layer defense suggestions ：

1. Check and verify all input data provided by the client .
2. Use the white list allow list allow list execution URL Uniform resource identifier 、 Port and destination .
3. Do not send the original reply to the client .
4. Ban HTTP Redirect .
5. Be careful URL The consistency of , To avoid DNS Rebind and “ Check time , Use your time ”(TOCTOU) Competitive conditions and other attacks .
6. Do not mitigate by using blacklists, reject lists, or regular expressions SSRF. The attacker has a payload list 、 Tools and skills to bypass the reject list .

Measures requiring additional consideration :

1. Do not deploy other security related services on the front-end system （ Such as ：OpenID）. Control local traffic on these systems （ Such as ：localhost）.
2. For dedicated and manageable front-end users , Network encryption can be used on stand-alone systems （ Such as ：vpn） To meet very high security protection requirements .