In this topic we will discuss the OSI model layers and try to illustrate different types of attacks and how to mitigate and defend our network against these attacks. But first we need to clarify some terminologies:

• Vulnerability: is a weakness that can be exploited. It might be an unpatched applications or operating systems, an unrestricted wireless access point, an open port on a firewall.
• Threat: is that someone, will identify a specific vulnerability related to a specific service.
• Exploit: is taking advantage of a vulnerability trying to perform an unauthorized action.
• Impact: is the result of a successful attack, like the loss, or exposure of data.
• Countermeasure: is a Security Control (aka Safeguard) that can mitigate or eliminate a Vulnerability. A countermeasure could be patching of operating systems, software configuration, or deploying security appliances like firewalls, IPSs, or WAFs.

We will follow a top-down approach, start with layer 7 all the way down to layer 1, enough talking and let’s jump in.

Application Layer Security:

99% of the Application layer Attacks are related to the programming code, one of the most important aspects to take in consideration while programming an application is Security, unfortunately not much programmers out there know how to program a secure application, which result in flows in the application that could be exploited by an attacker.

I choose four of the most famous attacks to illustrate Web Application Security:

1-Cross-Site Scripting (XSS):

Threat: One of the most common attacks, in which the Attacker exploits a vulnerability in the Web Application that allows him to inject a malicious code (a script written in the same language as the client-side) that will be executed on the client side. Gibberish? okay let me illustrate by an example- Let’s say we have a Forums site, an Attacker can publish a post that contains a JavaScript malicious code – he can do that because the Web Application does not validate user entries-, and when a Victim tries to view the post later his browser will render the page and execute the JavaScript malicious code.

There are three types of XSS attacks:

1. Stored XSS (aka Persistent XSS): which we just explained above.
2. Reflective XSS (aka Nonpersistent XSS): in which an attacker sends a URL link to the Victim (by mail for example), and when the Victim opens the link the injected code travels from the Attacker’s website to the vulnerable web server and reflect (hence Reflective) back to the Victim browser which will execute the code as it came from a trusted web server.
3. DOM based XSS (aka type-0 XSS): Document Object Model (DOM) is the standard structure layout to represent HTML and XML documents in the browser. In such attacks the document components such as form fields and cookies can be referenced through JavaScript. The attacker uses the DOM environment to modify the original client-side JavaScript. This causes the victim’s browser to execute the resulting abusive JavaScript code. A major difference between this type and its predecessors that it occurs on the client side that’s why sometime it’s referred to as Local Cross-Site Scripting.

Impact: A successful XSS attack might result in stolen cookies, hijacked sessions, malware execution, or bypassed access control.

Countermeasures: The Web Application must be revised by professional programmers before deploying it to ensure data Input Validation is done appropriately.

2-SQL Injection:    

Threat: SQL Injection is a vulnerability that allows an attacker to insert a database SQL query which will be executed by the Web Application interpreter causing an exposure to the back-end database server. In general, SQL Injection attack will exploit a web application that lacks proper Input Validation allowing the Attacker to read, change, or delete the data. For Example- a forum with a password reset feature has a field for e-mail input, what really happens is that the application takes the e-mail address, creates a SQL query, send it to the back-end database server to retrieve your password and e-mail it back to the user. A typical Vulnerability would be that the application is not properly validating the user input in the field, which gives the attacker an opportunity to run any SQL query.

Impact: A successful SQL Injection attack will result in loss, corruption, or exposure of data.

Countermeasures: An application programmer should make sure that only proper inputs are inserted in the fields.

3-Cross-Site Request Forgery (CSRF):

Threat: This type of attacks forces the Victim’s browser already logged into a vulnerable website to send requests and use functionalities in a way that seems legitimate to the website itself. Gibberish gain? Here is an example- I logged into my bank -which uses the vulnerable web application- vulnbank.com and started to make some transactions, buying a space shuttle, paying my travel expenses to Kenya Jungles, or even giving money for charity, and I’m so very happy. Anyways while I’m logged in –must be logged in- I thought of buying some red Onion because we ran out of red Onions, so I search Google for the Onion company and I found maliciousonions.com. Not knowing that the bad guys responsible for this site are targeting happy guys using vulnbanck.com, I click on the Red Onions picture, a code like this “http://vulnbank.com/trans.do?acct=maliciousonions&amount=100000” is uploaded to my browser that will send a request to vulnbank.com –notice that I’m still logged in- to transfer 1,000,000 $ from my loaded account to their poor account.

Impact: An Attacker can force the Victim to perform any action or change any data the Victim is allowed to change

Countermeasures: Adding a per session authentication token –using nonce values- to the URL of each new session. A nonce value is a random value added to the user authentication password, and is valid for only one session. If the Web Application receives a request with a NULL value it drops the request, if it receives a request with a previously used value it drops the request. That way it will be impossible for an attacker to predict the correct random value unless of course he’s inspired by GOD. Additionally a human interaction could be requested before each sensitive transaction, like re-authenticating or using CAPTCHAs.

4-Denial/Distributed Denial of Services (DoS/DDoS):

Threat: A Denial of Services attack aims to exhaust a system resources in a matter that prevents it from serving other clients. A Distributed Denial of Services is a Denial of Services attack performed by multiple users, those users might be Attackers or zombies (aka Bots). A zombie is a regular user with an infected PC (by malware or worm) that allows an attacker to control that PC and send requests through it.

Two types of DoS attacks, Layer 4 (aka SYN attack) and Layer 7 DoS. We will leave Layer 4 till we discuss Transport Layer attacks. A Layer 7 attack could affect protocols like HTTP, HTTPS, FTP, etc., but our main focus here will be HTTP.

Layer 7 DoS attack is a Service exhaustion attack and is much more lethal than a traditional Layer 4 Hardware Resources exhaustion attacks for several reasons: First, It’s a legitimate TCP, UDP connection (can’t differentiate user from attacker), Second, requires much less connections (more efficient), Third, It consumes the Service Resources regardless of Hardware Resources (more effective).

HTTP GET Attack: An attacker sends queries to exhaust service resources. With HTTP GET the Attacker sends a Get request (after TCP 3-way handshake) demanding a large amount of data and the application starts serving these requests until it reaches a limit where it can’t serve other clients. Rate-limits and Timeouts are used by web servers (IIS, Apache) prevent those types of attacks, but still a DDoS attack is much harder to detect because Rate-limits and Timeouts are applied per session (user), so if an Attacker has like 1000 zombies he might be able to perform the attack without exceeding the limit.

Impact: The service becomes unavailable to legitimate users.

Countermeasures: Deploying a WAF that runs some sort of rate-shaping algorithm that watches clients and ensures that they request no more than a configurable number of objects per time period.

So as you can see the main Countermeasure is to revise the Web Application code, but we are human and human do make mistakes, so what else can be deployed as another layer of defense?

Intrusion Prevention Systems (IPS):

IPS appliances inspect each passing through packet against predefined and continuously updated signatures, IPS inspects traffic for attacks like SQL Injections, XSS, Web Servers (IIS, Apache), worms, L3-L4, and OS attacks. When an attack is detected an IPS performs certain predefined actions (for e.g. block attacker address, drop malicious packets, or produce an alert) based on a Risk Rating (RR) matrix.

The problem with IPS is that it inspects the packet against “fixed signatures” and when if it finds a  matching signature it applies the action associated with that specific signature, if it doesn’t then it will forward the packet, and then forgets all about it. The problem is that when we deal with Web Application we can’t just depend on a packet by packet inspection, we need an appliance that can monitor the whole session, understand the behavior of protocols like HTTP/HTTPS, and understand the behavior of a programming language like HTML, XML, or Java. In short words what we need is a WAF.

Web Application Firewall (WAF):

WAF is a firewall operating on the application layer. Inspects inbound and outbound web traffic to and from the web server. WAFs has a predefined customizable signatures and rules applied to the traffic. WAFs main function is to learn and predict traffic behavior, and apply rules to traffic on a per packet and per session basis. A typical WAF deployment would be as a reverse proxy, where client traffic terminate at the WAF and a new session is established between the WAF and the Web Application Server.

WAF can inspect HTTP and HTTPS (using SSL Offloading) for new unknown types of attacks (Zero Day Attacks). By watching for unusual or unexpected patterns in the traffic. For example- if a WAF detects that the application is returning much more data than it is expected to, the WAF can block it and alert someone.

Well that will be it for the Application Layer. In part two we will discuss attacks on Layers 3 and 4 (There is not really much in layers 5, and 6)

If interested, more information about Web Application Security could be found in the following links:

www.owasp.org
www.sans.org
www.webappsec.org

I hope it has been informative.

Kind Regards.