Security+: Application Attacks (SY0-401) [DECOMMISSIONED ARTICLE]

NOTE: This article reflects an older version of the Security+ Exam – please see the current Security+ Certification page for the most up-to-date information.

---

Introduction

Gone are the days when hackers would target operating systems in their bids to find their way into a system; now most of the attacks are made on applications running on a victim system. These types of attacks are particularly dangerous because the hacker is able to target the application layer, which is normally laden with sensitive resources. Some of the most notorious application attacks are cross side scripting attacks, SQL injections, buffer overflow attacks and remote code execution etc. All of these (among others) attacks will be discussed in this article, and their importance with respect to the CompTIA’s security+ certification exam will also be shed light on. For the importance of the need to be aware of the potential threats posed by hackers, read this article about five recent attacks on hospitals.

Cross-Side Scripting

In cross-side scripting attacks, a hacker manages to inject and run unwanted harmful scripts on the server side of a vulnerable website. These attacks normally take place when the hacker sends malevolent code to either a different user or to the server side of the web application by executing a script on the browser.

Technically speaking, there are two ways for this attack to occur. The first one is when some data is sent to a web application through an unreliable third party in the form of a web request; the second way to perform this attack is by including the data in the dynamic content that’s to be received by a naïve user who isn’t going to bother validating it.

The two types of XSS attacks are:

1. Stored XSS attack:

As the name indicates, in such an attack the infected script finds a permanent abode on the victim server/database. This script can be concealed within any visitor log, comment field, or even a message forum. The victim falls prey when they request the stored information from the database and the malicious script is executed.

Reflected XSS attack:

In such an attack, the script that is injected reflects off the web server in a search result, an error message, or any other response that is part of some data that is to be sent as a request to the server. These attacks involve tricking the user into clicking on an infected link through email or through browsing a website. Once clicked, the injected script makes its way to the server side of the vulnerable application and gets reflected back to the user. Because of the fact that it got reflected back from a server which the browser deems “trusted,” the malicious code is allowed to run.

How to Minimize/Remove

1. Never allow the addition of untrusted data/code to your HTML document except for some allowed areas.
2. Escape HTML before you insert untrusted and unverified data in to the element content of the HTML file.
3. Validate and escape all the CSS code before the insertion of untrusted data in to the style sheet.
4. Ensure HTML markup sanitization with a library.

SQL Injections

Injections encompass attacks that can be done by inserting or, as the name states, “injecting” an SQL query from the client side’s input data. When successful, these attacks allow the hacker to read private data from the database or even make modifications by using the insert, update, or delete commands. Moreover, veterans of the trade can even go the mile and shut the whole DBMS down or make the host OS do things in extreme scenarios.

There are a variety of known injection attacks but some of the most common ones are:

• Command injections:

A command injection attack takes place when an attacker manages to change the web page content that is to be dynamically calculated and displayed. This can be achieved by inserting code (mostly HTML) into a client-side input field that doesn’t pass the rudimentary security tests that it should.

A simple example in this regard could be the addition of an SQL query in place of an input value in a field. Now instead of retrieving information pertaining to a normal user input, what happens is that the query runs on the server side and returns the result set for the hacker to exploit.

• Numeric parameter attack:

An injection attack performed due to a numeric parameter vulnerability is very common because of it’s easy to do. Let’s find out more about it by going through an example.

Say there’s a website that displays information regarding different players. The normal URL to display information about a player could be something like:

http://www.victim.com/viewPlayer.php?id=1

When this URL is accessed, this query gets executed on the server side:

SELECT id, name, description FROM players WHERE id=1

This looks pretty straight forward, but what if the attacker adds a different constraint on the where clause? Because the query is being built without sanitizing input, this can be done:

http://www.victim.com/viewPlayers.php?id=1 OR 1=1

The generated query:

SELECT id, name, description FROM players WHERE id=1 OR 1=1

This will lead to displaying information about all the players in the database despite the fact that the user was only authorized to view the information for one.

Broken Authentication and Session Management

Authentication and session management involves giving users specific levels of access to data and managing sessions. Even though the importance of authentication can never be understated, faulty credential management can cause perfectly authenticated sessions to fail. This the reason why most of the account details management and update functions (forgotten password, changed password change, and updated profile) need to be followed immediately by re-authentication in order to ensure that the session id is valid.

These types of attacks normally occur when the server side fails to manage the sessions astutely. For example, a user might have logged out from the website but, because his session was not destroyed at logout, a hacker was able to send in a faulty “change password” request. Here, if there is no re-authentication mechanism used by the developers, the hacker can change the password and proceed with exploiting the vulnerability.

Another easy way to perform the attack is by rewriting a very revealing URL to a website. Take this example:

http://hello.com/sale/saleitems?sessionid=26854454dsa1&dest=Marco

If this link is shared with somebody by the user and if the session management is not done flawlessly on the server side, by making changes to the session id above, the hacker can potentially view data that is not meant for them.

How to Minimize/Remove:

1. Improve the session management mechanism. This will involve:
2. Ensuring short idle and absolute timeouts.
3. If a privileged state is to be stored, making sure that the device is trusted.
4. Destruction of sessions after logout.
5. Rotation of important session identifiers.
6. Never allowing session rewriting.
7. Logging all the session failures.
8. Never logging session identifiers.
9. Make sure that there are no XSS flaws in the system. These flaws can lead to stealing of session identifiers.

Cross-Site Request Forgery

A cross-site request forgery (CSRF) attack occurs when a user is forced to do some unwanted and undesired actions on a website on which they would ideally be authenticated at the time. These types of attacks are concerned with state-altering requests and don’t really cause any theft of data, as the attacker can’t see the response that might be received for the sent faulty request.

This attack requires social engineering techniques to lure users into following the steps that the attacker wants them to. If the user is naïve enough (doesn’t possess enough technical knowledge), the attacker can send all sorts of state-altering requests. This can include transferring of funds, changing of important details, and such. Also, a CSRF attack can cause the whole web application to function like the attacker wants if the compromised user is an administrator.

In order to understand this attack properly, let’s consider an example.

Suppose that a bank uses an online form for all its user transactions. The following URL shows how the website uses GET requests to transfer funds and related things:

GET http://banking.com/transfer.execute?acct=amar&amount=1000 HTTP/1.1

Here is when the social engineering trick comes in to play. Consider the following URL:

http://banking.com/transfer.execute?acct=dan&amount=10050

This URL can be conceived by the hacker “Dan” in this case by logging in to their own account and seeing how the bank’s application handles transfer requests and then he can replace the account name with his own. Then all he has to do is to trick “Amar” (the user) in to clicking on this link when logged in to his account. This is normally achieved by one of the following ways:

1. Sending an unrequested email with HTML content.
2. Implanting the URL in to a web page that is expected to be visited by the user while they are also doing banking.

The best (or probably the worst) part about this is that this malicious code can be made to look very harmless as well.

<img src="http://banking.com/transfer.execute?acct=dan&amount=10050" width="1 height="10" border="10">

The image tag as mentioned above, if included in the email, wouldn’t apparently be anything harmful for “Amar” but, once he clicks it while being logged on, the bank will receive the request and proceed with it.

How to Minimize/Remove

The most widely used and most effective method to prevent CSRF is by appending random large challenge tokens at the end of each request and somehow associating it with the user session. These tokens will be unique per session at the least but, if you then make a unique per request, they can become even more useful. This will remove the possibility of CSRF because the developer would now be certain that the request has actually been submitted by nobody other than the user. It’s to be noted that there should be token matching and maintenance mechanisms at the back end of the application that are always readily available in order for this procedure to work without flaws.

Buffer Overflow Attacks

As the name indicates, buffer overflow attacks occur when memory fragments of a process (which should have not been altered in the first place) are overwritten by a hacker. An example is overwriting values of important registers like the instruction pointer (IP) or the base pointer (BP); as a result, the operating system starts reporting segmentation faults and exceptions, out of nowhere. Buffer overflow attacks can occur as a result of stack overflow or heap overflow.

An example of buffer flow can be explained via the following code:

#include <stdio.h>

int main(int argc, char **argv)

{

char buffer[16]; // buffer for 16 characters

scanf(buffer); // read from stdio stream

printf("%snn", buffer); // print out stored data

return 0;

}

Even though the above code looks okay and will compile without any errors), it has a serious problem. The character buffer has a size of 16 characters and there is no check present in the code to ensure that buffer overflow doesn’t occur. So, if the user were to enter a string that had more than 16 characters, it would result in the gcc compiler throwing a segmentation fault and the application crashing. This problem can be replicated at a higher level, leading to enterprise system crashes.

How to avoid/minimize:

1. Perform manual or automated code auditing to spot any potential cases.
2. Use non-executable stacks if possible.
3. Use safe functions (like strncat instead of strcat ).
4. Ensure that your application and all the servers are fully patched and updated. Don’t ignore or overlook any bug reports.
5. Use the readily available buffer overflow scanners periodically to ensure that there remain no vulnerabilities in the code.

Final Word

Not enough can be said about the importance of application attacks in the realm of information security. The article briefly walked the readers through some of the most common (yet most dangerous) application attacks that arise due to vulnerabilities in the system. Knowledge of these attacks is of pivotal importance for aspirants of the security+ exam, among many other topics. To ace the preparation astutely and to reduce the need of consulting various resources to get information, consider InfoSec Institute's security+ training for comptia to help you clinch the security+ certification.