In the previous article i went through how to fortify and identify potential common threats for an application with Threat modelling framework.
In this article i will walk you through how you can use OCI WAF to mitigate the web application threats .
First, i would like to recap the typical web application vulnerabilities that are defined in the Open Web Application Security Project (OWASP) Top 10 list ( i will consider both 2013 and 2017 realeases)
- A1 Injection
- A2 Broken Authentication and Session Management
- A3 Cross-Site Scripting (XSS)
- A4 Broken Access Control (NEW)
- A5 Security Misconfiguration
- A6 Sensitive Data Exposure
- A7 Insufficient Attack Protection (NEW)
- A8 Cross-Site Request Forgery (CSRF)
- A9 Using Components with Known Vulnerabilities
- A10 Underprotected APIs (NEW)
A1 – Injection
Injection flaws occur when an application sends untrusted data to an interpreter. Often, the interpreter has its own domain-specific language.
The most popular injection flaws are SQL injection flaws. These occur when input isn’t properly sanitized , and the values are inserted in SQL statements directly. If the values themselves contain SQL syntax statements, the database query engine executes those as such. This triggers actions that weren’t originally intended, with potentially dangerous consequences.
A2 – Broken Authentication and Session
Generally Speaking attackers rely on vulnerabilities in the way client-server communication is implemented. Or they target how session or authorization tokens are generated, stored, transferred, reused, timed-out, or invalidated by your application to obtain tsese credentials. After they obtain credentials, attackers impersonate legitimate users and make requests to your web applications using those tokens.
For example, if an attacker obtains the API Keys or a token that authorizes communication between your web client and the RESTful API, they can impersonate that user until the token expires by launching HTTP requests with the illicitly obtained authorization token.
A3 – Cross-Site Scripting (XSS)
ross-site scripting (XSS) flaws occur when web applications include user- provided data in webpages that is sent to the browser without proper sanitization. If the data isn’t properly validated , an attacker can use those vectors to embed scripts, inline frames, or other objects into the rendered page (reflection). These in turn can be used for a variety of malicious purposes, in order to install system malware. The impact of the attack is magnified if that user data persists server side in a data store and then delivered to a large set of other users.
Consider the example of a common, but popular, blog that accepts user comments. If user comments aren’t correctly sanitized, a malicious user can embed a malicious script in the comments, such as:
A4 – Broken Access Control
This category of application flaws, new in the proposed 2017 Top 10, covers lack of or improper enforcement of restrictions on what authenticated users are allowed to do. It consolidates the following categories from the 2013 Top 10: A4 – Insecure Direct Object References and A7 – Missing Function Level Access Controls.
Application flaws in this category allow internal web application objects to be manipulated without the requestor’s access permissions being properly validated. Depending on the specific workload, this can lead to exposure of unauthorized data, manipulation of internal web application state, path traversal, and file inclusion.
Your applications should properly check and restrict access to individual modules, components, or functions in accordance with the authorization and authentication scheme used by the application. Flaws in function-level access controls occur most commonly in applications where access controls weren’t initially designed into the system, but were added later.
These flaws also occur in applications that take a perimeter security approach to access validation. In these cases, access level can be validated once at the request initialization level. However, checks aren’t done further in the execution cycle as various subroutines are invoked. This creates an implicit trust that the caller code can invoke other modules, components, or functions on behalf of the authorized user—which might not always hold true.
If your web application exposes different components to different users based on access level or subscription level, then you should have authorization checks performed anytime those functions are invoked.
Consider the following examples of flawed implementations for illustration:
- A web application that allows authenticated users to edit their profile generates a link to the profile editor page upon successful authentication:https://example.com/edit/profile?user_id=3324
- The profile editor page, however, doesn’t specifically check that the parameter matches the current user. This allows any user who’s logged in to find information about any other user by simply iterating over the pool of user IDs. This exposes unauthorized information:
A5 – Security Misconfiguration
Misconfiguration of server parameters, especially ones that have a security impact, can happen at any level of your application stack. This can apply to the operating system, middleware, platform services, web server software, application code, or database layers of your application.
A examples of security misconfigurations are:
- Leaving default directory listings enabled on production web servers. This allows malicious users to browse for files that are hosted by the web server.
A6 – Sensitive Data Exposure
Sensitive data exposure application flaws are typically harder to mitigate using web application firewalls. These flaws commonly involve encryption processes that have been deficiently implemented. Some examples are the lack of encryption on transported or stored sensitive data, or using vulnerable legacy encryption ciphers, where malicious parties can intercept and decode your data.
Less commonly, there can be flaws in application or protocol implementations, or client browsers, which can also lead to the exposure of sensitive data. Exploits that ultimately lead to sensitive data exposure can span multiple OWASP categories. A security misconfiguration that allows for the use of weak cryptographic algorithms leads to encryption downgrades and, ultimately, to an attacker being able to capture the data stream to decode sensitive data.
A7 – Insufficient Attack Protection
This category has been proposed for the new 2017 Top 10, and it reflects the reality that attack patterns can change quickly. Malicious actors are able to adapt their toolsets quickly to exploit new vulnerabilities and launch large-scale automated attacks to detect vulnerable systems. This category focuses strongly on your ability to react in a timely manner to new attack vectors and abnormal request patterns, or to application flaws that are discovered.
A broad range of attack vectors fall into this category, with many overlapping other categories. To better understand them, ask yourself the following questions:
- Are you able to detect and recognize when your application is targeted with unusual request patterns or high volume? Do you have systems in place that can do that detection in an automated fashion? Are these systems capable of reacting to and blocking such unwanted traffic?
- Are you able to detect when a malicious actor launches a directed, targeted attack against your application, trying to find and exploit flaws in your application? Is this capability automated, so that you can react in near-real time?
- How fast can you deploy a patch to a discovered application flaw or vulnerability in your application stack and mitigate attacks against it? Do you have mechanisms in place to detect the effectiveness of the patch after deployment?
A8 – Cross-Site Request Forgery (CSRF)
Because browsers send credentials like session cookies automatically, attackers can create malicious web pages which generate forged requests that are indistinguishable from legitimate ones.
Detection of CSRF flaws is fairly easy via penetration testing or code analysis.
A9 – Using Components with Known Vulnerabilities
Currently, most web applications are highly composed. They use frameworks and libraries from a variety of sources, commercial or open source. One challenge is keeping up to date with the most recent versions of these components. This is further exacerbated when underlying libraries and frameworks use other components themselves. Using components with known vulnerabilities is one of the most prevalent attack vectors. They can help open up the attack surface of your web application to some of the other attack vectors discussed in this document. Mitigating vulnerabilities in such components is challenging because not all of them are reported and tracked by central clearinghouses such as Common Vulnerabilities and Exposures (CVE).
A10 – Underprotected APIs
Another new category proposed for the 2017 Top 10, Underprotected APIs, focuses on the target of potential attacks, rather than the specific application flaw patterns that can be exploited. This category recognizes the prevalence and anticipated future growth of APIs. Currently, entire applications are published that don’t have a user-facing UI. Instead, they’re available as APIs that other application publishers can use to build loosely coupled applications. Many applications can have both user UIs and APIs, whether those APIs are intended to be consumed by third parties or not.
Old Top 2013 A10 – Unvalidated Redirects and Forwards
Most websites and web applications contain mechanisms to redirect or forward users to other pages—internal or partner sites. If these mechanisms don’t validate the redirect or forward requests, it’s possible for malicious parties to use your legitimate domain to direct users to unwanted destinations. These links use your legitimate and reputable domain to trick users.
Consider the following example:
You run a video sharing site and operate a URL shortener mechanism to enable users to share videos over text messages on mobile devices. You use a script to create the URLs:
Users receive a URL like below, and it takes them to the correct content page:
If your link generator script doesn’t validate the acceptable input domains for the target page, a malicious user can generate a link to an unwanted site:
They can then package it and send it to users as it would originate from your site:
The OCI WAF is an enterprise-grade, cloud-based, globally deployed security solution designed to protect business-critical web applications from malicious cyberattacks.
The OCI WAF provides a suite of security services that uses a layered approach to protect web applications against cyberattacks. This release includes over 250 predefined OWASP rules, application-specific rules, and compliance rules.
Administrators can add their own access controls based on geolocation, whitelisted and blacklisted IPs, and HTTP URL and header characteristics.
Onboarding your applications to OCI WAF will protect against Layer 7 denial-of-service (DDoS) attacks.
How it works
The OCI WAF acts as a reverse proxy that will inspect all traffic flows or requests prior to these arriving at the origin web application. It will also inspect any request going from the web application server to the end user. This is very powerful and will allow you to control data leakage from your applications servers as well as protecting your servers from outside threats.
OCI WAF Integration
The OCI WAF is tightly integrated into the OCI console along with the many other applications and services offered by OCI, providing ease of use for your OCI setup and control. Here are a few examples: OCI Tagging can be applied to WAF policies for cost tracking. OCI Identity and Access Policy can be used to control access to WAF management, and WAF changes are recorded in the OCI Audit service.