The Open Source Web Application Consortium releases its list of Top 10 web vulnerabilities which is popularly known as ‘OWASP Top 10 threats. Threats like SQL injection and Cross Site Scripting (XSS) battle for positioning as the worst of the worst, cementing themselves as perennial champions of the web vulnerability world. No doubt OWASP Top 10 threats are too dangerous to be taken lightly, but as per our findings, many of those can be avoided if proper security postures are implemented and proper strategic initiatives are taken.

A1 – Injection

Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data. But it’s extremely easy to defend against them as well. Following are the steps enterprises can follow, to keep SQL injections out of their web applications:

  1. Make white box testing and secure code review an integral part of the development cycle. Automated along with periodic manual checks should be part of the operations process after deployment to keep up with new vulnerabilities and the automated scanning can help perform basic security sanity checks. It is very common to have injection issues introduced even with minor code changes as such changes may not be subjected to a fully-fledged security review process in the development cycle.
  2. In situations where fixing the code of detected vulnerabilities is difficult a WAF can be used for virtual patching after deployment.

A2 – Broken Authentication and Session Management

Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.

We can use a WAF  to validate sessions. A WAF does this by setting a collection of variables which store the session id and related information when it is created and sent to the client from the server. Every time the client sends a subsequent request, the WAF intercepts it and checks to see if a valid session id has been sent. Validity will depend on various factors including a time period. For instance, sessions are not allowed to go beyond a certain time period.

There are also session fixation rules that a WAF implements. Session fixation happens when a client sends a cookie even when the cookie is not set by the server. This happens when a hacker steals a cookie/session id of another user and uses it to impersonate him.

Finally, WAF’s help implement sticky sessions — verifying that parameters such as User-Agent and IP address, which are meant to be constant/unchanged in a particular session stay unchanged.

A3 – Cross-Site Scripting

XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface websites, or redirect the user to malicious sites.

WAFs  block keywords that lead to XSS. A hacker trying to XSS a site inputs javascript or other similar scripts. By blocking these scripts, one prevents hackers from pushing such malicious scripts into browsers.

A4 – Insecure Object Reference

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

Preventing these kind of vulnerability is pretty simple with WAF.

One can prevent “Insecure Direct Object References” vulnerability by implementing and maintaining proper session collection with the help of WAF.  WAF not only considers user mapping but also checks session and cookies to grant user access.

A5 – Security Misconfiguration

Security Misconfiguration attacks exploit configuration weaknesses found in web applications. Many applications come with necessary developer features that are dangerously unsafe if not deactivated during live production, such as debug and QA features. These features may provide means for a hacker to bypass authentication methods and gain access to sensitive information.

A process for keeping abreast of and deploying all new software updates and patches in a timely manner to each deployed environment.

Consider running scans and doing audits periodically to help detect future misconfigurations or missing patches. Also consider virtually patching where applicable in WAF (hiding error messages) while the issue is fixed in your application which is sitting behind WAF on, perhaps with elevated privileges.

A6 – Sensitive Data Exposure

IT systems usually save in a database user’s personal information such as passwords, credit card numbers, house address’, telephone number, id number etc. When the system is not protected effectively from unauthorized access there is a high probability that a hacker might exploit that vulnerability and steal that information. That vulnerability is ‘Sensitive Data Exposure’.

Consider investing on DLP solutions or for Web Applications a WAF with custom rules (mask credit card numbers, SIN numbers) with targeted policies to prevent sensitive data exposure to clients

A7 – Missing Function Level Access Control

Applications do not always protect application functions properly. Sometimes, function level protection is managed via configuration, and the system is misconfigured. Such flaws allow attackers to access unauthorized functionality.

These kind of vulnerability can be patched in following two manner with the help of WAF:

1) Create proper session implementation which will verify request/response on the basics of session and respective cookie.

2) Whitelisting: Whitelist IP of admin/privileged user. If organization has public IP 1.1.1.1 and all privileged users are using their account via accessing public IP “1.1.1.1″ then one can create WAF policy which will only allow privileged user to login via IP “1.1.1.1″ and not via any other public IP.

A8 – Cross-Site Request Forgery

Cross Site Request Forgery (also known as XSRF, CSRF, and Cross Site Reference Forgery) works by exploiting the trust that a site has for the user.

CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing.

To block CSRF vulnerability via WAF, one has to inject CSRF token into every input fields.

This process is dynamic. When WAF sees some input fields are coming from web-server, it’ll inject one random token number into the html code. For each and every transaction this token will be unique and will be verified at WAF level. It’s good measure to check non-domain HTTP_REFERERs to prevent CSRF.

A9 – Using Components with Known Vulnerabilities

The use of 3rd party frameworks and libraries in application development has become a very common practice but unfortunately most of the time, proper security policies aren’t implemented to mitigate the risks associated with the practice.

Deployment of WAF is the good technique  to centralize the action from the Vulnerability management program in protecting from platform and third party specific of vulnerabilities. Make sure your WAF is managed and backed by a team who offers a strong MSS and custom rule set to include relevant platform specific protection rules in the rule set based on the same detected.

A10 – Unvalidated Redirects and Forwards

Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.
The practice of unvalidated redirects and forwards, also often referred to as an “open redirect”, appears fairly benign on the surface. However, it can readily be employed in conjunction with a combination of social engineering and other malicious activity such as a fraudulent website designed to elicit personal information or serve malware.

But by using WAF one can prevent this attack. We can create custom policies in WAF to check “fetch” variable input. For example after scrutinizing the detailed visitors’ inputs one can implement a custom rule “Only allow ‘www.legitimate.com’ to be passed in ‘fetch’ parameter”. Right implementation of ‘Behavioral profiling’ in WAF can prevent these kind of vulnerabilities.

Beyond Compliance

Although OWASP Top 10 Vulnerability List will be good place to lay the security foundation in 2015 for any organization, it is in no way the end. As the threats grow in number and severity, there will be a dire need to partner with an advanced security vendor and understand the risks.

John Pironti, president of IP Architects, explains that compliance should be a start point. He says that it’s just a baseline security posture and organizations will need to look beyond that and develop a security trend on their own. Cyber security, especially in times when applications are widely used and attacked, should be an ongoing process built around the concept of detecting, protecting and monitoring threats.

Founder & Chief Marketing Officer, Indusface

Venky has played multiple roles within Indusface for the past 6 years. Prior to this, as the CTO @indusface, Venky built the product/service offering and technology team from scratch, and grew it from ideation to getting initial customers with a proven/validated business model poised for scale. Before joining Indusface, Venky had 10+ years of experience in security industry and had held various mgmt/leadership roles in Product Development, Professional Services and Sales @Entrust.