Demystifying OWASP TOP 10!

OWASP Top 10 is a standard awareness document for developers community which they can use to make their code more secure. It represents a broad consensus about the most critical security risks to web applications and also helps Pen testers to assess web apps vulnerabilities against these flaws.

Please do note that OWASP TOP 10 vulnerabilities are not listed based on severity but its based on frequency of them to happen.

1.       Injection: Injection attacks are one of the commonly found web app security risk in today’s rich data driven web apps. We all know that web apps are mainly using database connectivity in the backend to process user queries/request. This helps web apps to store user credentials (to give user access to resources) and other useful stuffs. In this case any malicious user or an attacker can pass some untrusted data to trick/manipulate the interpreter or actual database into revealing/dumping some sensitive files which shouldn’t be accessible to any normal end user. Injection attacks are possible with SQL, NoSQL and LDAP etc. Injection attack can exist whenever user-supplied data is not validated, filtered, or sanitized by the application.

 

Always remember, Code = Data = Commands.

Prevention/Identifying tips?

·       Use the concept of server-side validation (every cmnds or db queries need to be verified at server side).

·       Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.

·       Use safe API calls which can avoid concept of interpreter completely (prevent parameterized interface).

·       Don’t use stored procedure calls (this can be still susceptible for Injection).

#Attack Scenario:

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

2.       Broken Authentication: We know that web apps have several users who generally hold some kind of access to different resources. To identify and grant access to all of them each time successfully whenever they log in using their credentials, we use some authentication management solution. Also, we implement concept of session id to identify each user access uniquely. So, to do all sort of these things we apply some logic, id, or, parameter. However, often these things get implemented incorrectly which can allow attackers to compromise keys, session id, access tokens or other usable authentication mechanism. Moreover, attackers always look for credential stuffing (using different valid combinations of usernames and passwords). They can perform or make use of brute force, dictionary attacks or stolen credential re-use attacks or default password combinations/well-known passwords.

 

Prevention/Identifying tips?

·       Make use of 2FA (2 Factor authentication) or MFA (Multifactor authentication – using some other factor of proving their identity).

·       Don’t use ineffective password reset mechanism. Use strong password reset rules, policies, set of identification.

·       Use proper session id to identify each user uniquely and do session management.

·       Make sure session id shouldn’t be exposed in URL (Should be validated at server-side).

·       LIMIT failed login attempts. Use account lockout policies.

·       Enforce password complexity rules.

·       Log all successful or unsuccessful login attempts.

·       Use session manager which can keep track of all session whenever establishing, maintaining or terminating.

 

 

3.       Sensitive data exposure: As we know web apps are storing tons of sensitive data (including but not limited to health records, credentials, personal data, and credit cards information) and these data needs to be stored in a secure manner so that it doesn’t get expose to anyone who is unauthorize to see it. To make these sensitive data exposures secure we use encryption while data is at-rest or in transit. We also need to ensure that key generation, management and the actual algorithm or protocols in use is handled properly and strong enough to protect our data. However, the main challenge comes when we want to know what to protect? To know this, we use a concept of data classification; where we classify data which is getting processed, stored or transmitted by web app (Whether it is confidential, restricted or Public). By doing this we get to know about the sensitivity of the information and what level of protection is required to secure it. Okay, so, we talked about the scenario enough already. Let’s move to the part of Prevention/Identifying tips.

 

Prevention/Identifying tips?

·       Make sure all data is encrypted (stored, transmitted or processed).

·       Apply controls as per the data classification.

·       Don’t hold sensitive data unnecessary make sure to store or keep it only per business needs

·       Use data pseudonymization, masking, or, minimize the actual data that needs to be retained

·       Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key management

·       Disable caching for responses which can store sensitive data

·       Use salting along with the passwords

·       Use hashing to ensure data integrity

·       Always remember data that is not retained cannot be stolen.

 

4.       External XML entities: To know this security risk first and foremost we need to know what is an XML? So, answer here would be: XML is a language or a way used to define or describe data (It can be into human or machine-readable format). XML generally helps in encoding and structuring data into a format which can be easily understood by web apps with different architectures. Let’s move to the original content here which is security risk in XML entities. XML language/document often use or refer to some external entities which are inherently vulnerable and also leaves a web app open to some type of attacks/risks. So, what are these external entities? This is actually an XML processor allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. It can be identified via SAST (Static application security testing) tools which will look for dependencies and configuration running in backend to communicate. Okay, enough talking about security risk what can be the actual risk that can be exploited? So, XML external entities flaw can affect application and data including but not limited to extracting data (data scraping), executing a remote request from the server, scanning internal systems, performing a denial-of-service attack, as well as executing other type of attacks.

All of these flaws can give an attacker opportunity to exploit these vulnerable XML processors in a way that they can send any hostile content in an XML document and look to exploit any dependencies or integrations with external entities.

 

Prevention/Identifying tips?

·       If a web app is using SAML within federated security or for SSO (Single sign on) purpose; SAML uses XML for identity assertions and can be vulnerable.

·       If a web app accepts XML directly or XML document for uploads, especially from an untrusted source or insert untrusted data into XML documents, which then parsed by an XML processor. It can leave a web app 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

·       Patch all vulnerable XML processors or libraries in use by web app.

·       Verify that XML file upload functionality has some kind of validation check.

·       Lastly use WAF to detect, monitor, and block XXE attacks.

 

#Attack Scenario:

 

Here the attacker attempts to extract data from the server:

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE foo [

<!ELEMENT foo ANY >

<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

<foo>&xxe;</foo>

 

5.       Broken access control: This security flaw is one of the most commonly seen risk in web apps. We know that web apps have different types of users and they already have some entitlements associated with them. These are generally stored in a user a/c store whichever a web app support. To maintain these user’s access in a secure way we use authentication mechanism to identify them and authorize them to have access to different resources in a web app. They can do certain tasks for which they are authorized. So, in this case, an attacker can target these user accounts to fulfil their malicious intent. Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc. They continuously look to exploit access control. Since access control enforces policy that users can’t act outside of their intended permissions.

 

 

6.       Security Misconfiguration: Security misconfiguration is the most common vulnerability on the list, and is often the result of using default configurations/credentials or displaying excessively verbose errors and backend tech services getting used in web apps. For instance, an application could show a user overly-descriptive errors which may reveal vulnerabilities in the application using different components. This can be mitigated by removing any unused features in the code and ensuring that error messages are more general rather than in descriptive format.

 

 

7.       Insecure deserialization: This threat targets the many web applications which frequently serialize and deserialize data. Serialization means taking objects from the application code and converting them into a format that can be used for another purpose, such as storing the data to disk or streaming it. Deserialization is just the opposite: converting serialized data back into objects the application can use. Serialization is sort of like packing furniture away into boxes before a move, and deserialization is like unpacking the boxes and assembling the furniture after the move. An insecure deserialization attack is like having the movers tamper with the contents of the boxes before they are unpacked.

An insecure deserialization exploit is the result of deserializing data from untrusted sources, and can result in serious consequences like DDoS attacks and remote code execution attacks. While steps can be taken to try and catch attackers, such as monitoring deserialization and implementing type checks, the only sure way to protect against insecure deserialization attacks is to prohibit the deserialization of data from untrusted sources.

 

 

8.       Cross site scripting (XSS): Cross-site scripting vulnerabilities occur when web applications allow users to add custom code into a url path or onto a website that will be seen by other users. This vulnerability can be exploited to run malicious JavaScript code on a victim’s browser. For example, an attacker could send an email to a victim that appears to be from a trusted bank, with a link to that bank’s website. This link could have some malicious JavaScript code tagged onto the end of the url. If the bank’s site is not properly protected against cross-site scripting, then that malicious code will be run in the victim’s web browser when they click on the link.

 

Mitigation strategies for cross-site scripting include escaping untrusted HTTP requests as well as validating and/or sanitizing user-generated content. Using modern web development frameworks like ReactJS and Ruby on Rails also provides some built-in cross-site scripting protection.

 

9.       Using components with known vulnerabilities: Many modern web developers use components such as libraries and frameworks in their web applications. These components are pieces of software that help developers avoid redundant work and provide needed functionality; common example include front-end frameworks like React and smaller libraries that used to add share icons or a/b testing. Some attackers look for vulnerabilities in these components which they can then use to orchestrate attacks. Some of the more popular components are used on hundreds of thousands of websites; an attacker finding a security hole in one of these components could leave hundreds of thousands of sites vulnerable to exploit.

Component developers often offer security patches and updates to plug up known vulnerabilities, but web application developers don’t always have the patched or most-recent versions of components running on their applications. To minimize the risk of running components with known vulnerabilities, developers should remove unused components from their projects, as well as ensuring that they are receiving components from a trusted source and ensuring they are up to date.

 

 

10.   Insufficient logging and monitoring: Many web applications are not taking enough steps to detect data breaches. The average discovery time for a breach is around 200 days after it has happened. This gives attackers a lot of time to cause damage before there is any response. OWASP recommends that web developers should implement logging and monitoring as well as incident response plans to ensure that they are made aware of attacks on their applications.