Owasp Top 10 – 2017 Vulnerabilities

A1: Injection Attacks:

Description:

Injection flaws occur when attackers try to inject some malformed data or input (such as SQL queries etc.) via input parameters or data fields to the application/database.

A successful injection exploits attack can read sensitive data and can also modify the database and execute administration operations on the database.

These flaws are often found in SQL, LDAP, Xpath, or NoSQL queries, OS commands, XML Parsers, SMTP Headers, program arguments, expression languages, and ORM queries, etc.

Prevention Techniques:

The preferred option is to use a safe API, which avoids the use of the interpreter entirely or provides a parameterized interface or migrate to use Object Relational Mapping Tools (ORMs).

Note: Even when parameterized, stored procedures can still introduce SQL injection if PL/SQL or T-SQL concatenates queries and data, or executes hostile data with EXECUTE IMMEDIATE or exec().

1. Using prepared statements (with parameterized queries) or stored procedures.
2.  Input validation and Character escape to be implemented before passing it to interpreter.
3. Input validation such as Whitelist of user supplied inputs, but it is not a complete defense. OWASP ESAPI has an extensible library of whitelist input parameter routines.
4. Minimize database privileges to reduce impact of flaw.
5. Web Application Firewalls can also be used to filter out malicious data.
6. Database errors should not reveal critical information such as database structures or configuration details and should use customized general error messages.
7. Do not run application code/services with database admin/high privileged accounts.
8. Keep the database patched and harden the database configuration and OS by disabling unnecessary services and functionality.

A2: Broken Authentication:

Description: 

Here attacker uses flaws in authentication and session management functions (ex: exposed accounts, passwords and session ids, etc.) to impersonate/pretend as original users.

The prevalence of broken authentication is widespread due to the design and implementation of most identity and access controls.

These flaws could be in areas such as logout, password management, and timeouts, remember me, secret questions, account updates, etc.  So an attacker can use any of the flaws to attack an application. Attackers have to gain access to only a few accounts, or just one admin account to compromise the system and breach confidential data.

Below are the basic vulnerable areas:

1. Two-factor authentication
2. Weak-password checks, such as testing new or changed passwords against a list of the top 10000 worst passwords.
3. User credentials are not protected when stored using hashing or encryption.
4. Credentials can be guessed or overwritten through weak account management functions (e.g.:  Account creation, change password, recover password, weak session ids, predictable credentials like admin etc).
5. Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes.
6. Session IDs are exposed in URLs (ex: URL rewriting).
7. Session ids are vulnerable to session fixation attacks.
8. Session IDs don’t timeout, or user session or authentication tokens, particularly single sign-on tokens are not invalidated properly during timeout.
9. Session IDs are not rotated after successful login.
10. Passwords, session ids and other credentials sent over unencrypted channels.

Prevention Techniques:

1. Strong Password policy should be in place.
2. All Passwords should be stored in Hashed or encrypted form to protect from exposure. Hashed form is preferred as it is not reversible.
3. Account Lockout policy should be enabled and also CAPTCHA can be used for multiple login attempts.
4. Secure and Http Only cookies – Set the secure flag on a cookie so that the browser will prevent the transmission of a cookie over an unencrypted channel.
5. Using the HttpOnly flag helps mitigate the risk of client side script accessing the protected cookie (if the browser supports it).
6. Protecting Credentials in Transit – The only effective technique is to encrypt the entire login transactions using SSL.
7. Session ID Protection -– Ideally, a user’s entire session should be protected via SSL. If this is done, then the session ID (e.g., session cookie) cannot be grabbed off the network, which is the biggest risk of exposure for a session ID.

If SSL is not viable for performance or other reasons then session IDs themselves must be protected in other ways. First, they should never be included in the URL as they can be cached by the browser, sent in the referrer header, or accidentally forwarded to a ‘friend’. Session IDs should be long, complicated, random numbers that cannot be easily guessed. Session IDs can also be changed frequently during a session to reduce how long a session ID is valid. Session IDs must be changed when switching to SSL, authenticating, or other major transitions.

• Browser Caching – Authentication and session data should never be submitted as part of a GET request, but POST request should always be used instead. Authentication pages should be marked with all varieties of the no cache tag to prevent someone from using the back button in a user’s browser to backup to the login page and resubmit the previously typed in credentials.
• Re-Authentication process for some critical communications.
• Session tokens should be expired on server and destroyed when a browser is closed.
• Strong effort should also be make to prevent XSS vulnerability which can be used to    steal session ids.
• OWASP strongly recommends to meet all the authentication and session management requirements mentioned in  OWASP’s Application Security Verification Standard (ASVS) areas V2 (Authentication) and V3 (Session Management).

A3: Sensitive Data Exposure

Description:

This vulnerability occurs when an application fails to protect its sensitive information from revealing to illegitimate users and attackers. The attacker’s approach could be man-in-the-middle attacks, stealing clear text data from the servers, etc. One of the main reasons for this flow is not encrypting sensitive data.

Attackers will try to steal encryption keys rather than attacking crypto itself. When crypto is employed, weak key generation and management, and weak algorithm, protocol, and cipher usage are common, particularly for weak password hashing storage techniques.

Typically sensitive information includes Personally Identifiable Information (PII), Credit card information, credentials, etc.

Prevention Techniques:

1. Classify the data and apply controls as per the classification.
2. Make sure to encrypt the sensitive data at rest and in transit.
3. 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).
4. Ensure passwords are stored with algorithm specially used for password protection such as Argon2, BCRYPT, PBKDF2, SCRYPT.
5. Disable auto complete on forms and disable caching for pages that contain sensitive data.
6. 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.
7. Credentials information should not be used in configuration file or properties file. If possible encrypt this information and avoid Password in configuration file.   
8. Classify the data as per the privacy laws, regulatory requirements, or business needs.

A4: XML External Entities (XXE)

Description:

This attack occurs when XML data is parsed by applications. The main attack vector when testing an application for XXE vulnerability will be any feature within the application that takes input in XML format.  

XML is a vastly used data format found in everything from web services (XML-RPC, SOAP, REST…) to documents (XML, HTML, DOCX) and image files (SVG, EXIF data…) use XML, So where there is XML, there is an XML parser.

So attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, server-side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts.

So basically if the XML data is malicious and it is parsed by the application without validation allows executing then XXE occurs.

SAST tools can discover this issue by inspecting dependencies and configuration. These flaws can be used to extract data, execute a remote request from the server, scan internal systems, perform a denial-of-service attack, as well as execute other attacks.

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.

Prevention Techniques:

1. Developers should be aware of this attack and perform validations when data is accepted.
2. Patch or upgrade all XML processors and libraries. Use dependence checkers. Update SOAP to SOAP 1.2 or higher.
3. Implement server-side input validation, sanitization to prevent hostile data within XML documents, headers, or nodes.
4. The safest way to prevent XXE is always to disable DTDs (External Entities) completely.

Disabling DTDs also makes the parser secure against denial of services (DOS) attacks such as Billion Laughs. If it is not possible to disable DTDs completely, then external entities and external doctypes must be disabled in a way that’s specific to each parser.

Reference: https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet

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.

A5: Broken Access Control:

Description:

Applications frequently use the actual name or key of an object (ex: file, directory, database record, or key as URL or form parameter) when generating web pages. Here applications don’t always verify whether the user is authorized to access the target object. This leads to Access control vulnerabilities.

Applications don’t verify the function level access rights before making that functionality accessible to the user. Basically, applications fail to enforce sufficient authorization to certain actions. This leads to Access control vulnerabilities.

So access control checks are to be implemented properly. These Checks are performed after authentication and govern what ‘authorized’ users are allowed to do.

Sometimes, these access controls are not difficult to discover and exploit. Once these controls are exploited, In addition to viewing unauthorized content, an attacker might be able to change or delete content, perform unauthorized functions, or even take over site administration.

All known web servers, application servers, and web application environments are vulnerable to at least some of these issues.

Prevention Techniques:

1. Default should be access deny all, requiring explicit grants to specific roles for access to every function.
2. Implement access control mechanisms throughout the application.
3. Disable directory listing if they are not necessary or set access control request to deny all requests and ensure file metadata (e.g. .git) and backup files are not present within web roots.
4. Monitor and log access control failures and alert administrators.
5. Allow access to the user on basis of its privileged matrix.
6. Do not allow the user to directly call any object from the database.
7. Restrict user to download contents that he is authorized for.
8. Use Access control lists and role-based authentication mechanisms and minimize CORS usage.
9. For more sensitive functionalities like accessing administrative pages, add additional access restriction with IP address to enforce only users from certain network are permitted to access the resources, irrespective of their login status.

A6: Security Misconfiguration

Description:

This vulnerability arises when the security settings of the webserver or application are not configured properly and left with default and insecure values. Misconfiguration can occur at the application level to network-level etc. such as webserver, network devices, servers, databases, frameworks, and virtual machines.

Firewalls, for example, are frequently misconfigured by their users. Policies might have been implemented improperly, effectively leaving the network permanently exposed.

Automated scanners can be useful in detecting misconfigurations. This flaw can give attackers access to data or the functionality of the system.

Prevention Techniques:

1. Development, QA and production environments should be configured identically with different credentials.
2. A process should be set up to review all the permissions.
3. An automated process to verify the effectiveness of the configurations and settings in all environments would be much better.
4. Sending security directives to clients, e.g. Security Headers.
5. Need to keep all software up-to-date and patches in a timely manner including all code libraries.
6. Disable administrator interfaces.
7. Running scans and audits periodically.
8. Don’t give any information about stack in error messages.
9. Delete unused pages and user accounts.
10. Change default usernames and passwords and use strong and unique passwords for every account.
11. White list WebPages.  Serve pages that are allowed and disallow any pages other than *.html, *.jsp, *.js, *.css etc. Whitelist are better than blacklist.
12. Make sure that no unnecessary features are enabled or installed (ex: ports, services, pages, accounts, privileges). Disable directory listing if they are not necessary or set access control request to deny all requests.  

A7: Cross-Site Scripting

Description:

XSS is one of the most prevalent issues in the OWASP Top 10 and is found in around two-thirds of all applications.

XSS attack occurs when an attacker injects a malicious code or client-side scripts into the vulnerable application and this code or script will be executed. Here, an attacker doesn’t attack the application but the users of the application.

The impact of the attack varies a lot such as from session hijacking, disclosure of the sensitive data, CSRF attacks, and more. If the victim has admin rights, it can lead to code execution on the server.

XSS is categorized into three types: Reflected Cross-Site Scripting, Stored Cross-Site Scripting, and DOM Based Cross-Site Scripting.

Reflected Cross-Site Scripting:

This is one of the most common types of XSS. This attack occurs when a malicious script is sent to the application through the Request and the same script is reflected back to the browser and executed at the victim machine.

Using phishing emails and social engineering techniques, the attacker tricks the user to perform his intended action such as clicking on the link and it will end up executing the script to send the request and the same will be reflected and executed at the victim browser.

Stored Cross-Site Scripting:

Stored XSS is a more dangerous type in XSS. This attack occurs when a malicious script is injected and stored in the application. So whenever users navigate to the page (ex: Comments section, forum, etc.) in which script is stored, this script will be executed.

DOM Based Cross-Site Scripting:

This is a bit advanced type of cross-site scripting.  This attack occurs as a result of modifying the DOM environment of the user’s browser used by the client-side script so that this code runs in an unexpected manner.

This Vulnerability can lead to stealing a user’s session, credentials, keylogging.

Prevention Techniques:

XSS attacks are possible mainly because the server is not escaping special characters in the output.

Use frameworks and libraries which escape XSS by design and identify the limitations of such libraries and handle the use cases.

Do apply 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’.

There are 4 broad strategies for defeating XSS:

1. Character Escaping
2. Output encoding
3. Whitelisting good input
4. Blacklisting bad input

Character Escaping:
To prevent any malicious HTML from rendering. Escaping these characters involves turning them into their entity equivalents < and >, which will not be interpreted as HTML tags by a browser.

Output Encoding:
The purpose of output encoding (as it relates to Cross-Site Scripting) is to convert untrusted input into a safe form where the input is displayed as data to the user without executing as code in the browser.

Whitelisting:
Create a whitelist of characters required by the application. Once this whitelist is ready, the application should disallow all requests containing any character apart from those in the whitelist.

Blacklisting:

The application should not accept any script, special character or HTML in fields whenever not required. It should escape special characters that may prove to be harmful. Some of the main characters used in scripts that must be escaped are as follows:

<> ( ) ‘ ” / \  * ; : = { } `(backtick) % + ^ ! – \x00-\x20 (x is a hexadecimal notation – it includes Space, Tab, Carriage Return, and Linefeed.)

A8: Insecure Deserialization:

Description:

This vulnerability occurs when an attackers crafts a malicious code in serialized object or request and sent to the application and this will code will be executed when it is Deserialized.

It is better to understand serialization and deserialization before proceeding with this vulnerability.

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage or to send as part of communications. Deserialization is the reverse of that process — taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.

Many high-level programming languages offer a native capability for serializing objects which offer more features than JSON or XML, including a custom serialization process. However, the features of these native deserialization mechanisms can be repurposed for malicious effects when operating on untrusted data.

These flaws can lead to remote execution attacks, denial of service, etc.

Prevention Techniques:

There are no lots of exploits available to attack insecure deserialization vulnerability, however; it does not make this issue less dangerous.

1. First thing is to not trust user input and perform input validation even it is in the form of serialized object.
2. Use integrity checks on the data such as digital signatures for serialized objects to prevent data tampering.
3. Enforcing strict type constraints during deserialization before object creation as the code typically expects a definable set of classes.
4. Run the deserialization in low privileged environments.
5. Log deserialization exceptions and failures, such as where the incoming type is not the expected type, or the deserialization throws exceptions.
6. Monitor the deserialization activity when it happens continuously by a particular user.
7. Please go through the below link for techniques for prevent this attack:

Reference: https://www.owasp.org/index.php/Deserialization Cheat_Sheet

A9: Using Components with Known Vulnerabilities:

Description:

Developers use components within applications such as frameworks, libraries, and other software modules. These components might have some known and existing vulnerabilities. Some of the largest breaches have relied on exploiting know vulnerabilities. Organizations can give priority to this issue based on the assets and classification of data.

This vulnerability can be in any components such as OS, web/application server, database, applications, APIs and all components, runtime environments, and libraries. Automated scanners will be useful in identifying this flaw.

Applications will be at risk 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.

Struts 2 remote code execution vulnerability that enables execution of arbitrary code on the server is an example of “Using components with known vulnerabilities.”

Prevention Techniques:

1. Be up-to-date with all the components used in application and there should be patch management policy in place.
2. Identify all components and version and monitor security of these components.
3. Stay up-to-date with vulnerability news and scan the application regularly.
4. Remove unused dependencies, unnecessary features, components, files, and documentation.
5. Download the components only from authentic sources and secure links.
6. 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.
7. Remove unused dependencies, unnecessary features, components, files, and documentation.
8. 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

Info on Virtual Patch:

Ref: https://www.owasp.org/index.php/Virtual_Patching_Best_Practices#What_is_a_Virtual_Patch.3F

A10: Insufficient Logging & Monitoring

Description:

Insufficient Logging & Monitoring vulnerability means that critical security events are not logged and current happenings and logged events are not monitored or no proper monitoring system is in place. The lack of these functionalities will make an attack harder to detect and identify the incidents. OWASP has included this vulnerability in its top 10 list based on the in industry survey and its effects.

These features play a vital role in audit trials when an attack happens. Vulnerabilities and breaches take lots of time and effort to find and can to some millions of dollars for organizations due to insufficient logging and monitoring.

This vulnerability can occur in the below scenarios:

• System/application events, such as logins, failed logins, and high-value transactions are not logged.
• Warnings and errors doesn’t generate sufficient logs to alert.
• Application and API logs not monitored for suspicious activity.
• Applications are not intelligent enough to identify and alert the administrator when attack happens.
• Logs are stored locally and not backed up. Attackers will try to delete the logs to hide their activities.
• Lack of skilled security analysts to analyze the logs.

Prevention Techniques:

1. Make sure that 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 stored for later Forensic Analysis.
2. Make sure that logs are generated in a format that can be easily read by centralized log management solutions.
3. High-valued transactions are logged, monitored and should have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar.
4. Establish a 24/7 team of skilled security analyst to monitor the suspicious events and respond in timely fashion.
5. Implement incident response team and prepare a recovery plan.
6. There are a number of open source and commercial intrusion detection tools and frameworks that can help you automate the monitoring of your system.