Nowadays, application development is moving more and more onto the Web. The Web hosts entire productivity suites such as Google Docs, calculators, email, storage, maps, weather and news — everything we need in our daily lives. Our mobile phones are useless without the Internet since nearly all mobile applications connect to the cloud, storing our pictures, usernames and passwords and private information. Even our home devices are now connecting to the Web, with Internet of Things platforms such as Wink that allow users to dim their house lights right from their mobile phone.

Application Attacks

The application layer is the hardest to defend. The vulnerabilities encountered here often rely on complex user input scenarios that are hard to define with an intrusion detection signature. This layer is also the most accessible and the most exposed to the outside world. For the application to function, it must be accessible over Port 80 (HTTP) or Port 443 (HTTPS).

In the diagram below, the Web application is completely exposed to the outside world in spite of network defenses such as firewalls and intrusion prevention systems:

In 2014, SQL injections, a type of application attack, were responsible for 8.1 percent of all data breaches. That makes it the third most used type of attack, behind malware and distributed denial-of-service attacks. You will also find on the list other common application attacks such as security misconfiguration, using components with known vulnerabilities and cross-site scripting. Attackers were able to manipulate application input and obtain confidential data without being detected by network defense systems.

Most vulnerabilities found in the proprietary code of Web applications are unknown to security defense systems; these are called zero-day vulnerabilities. This is because these vulnerabilities are specific to each application and have never been known before. A skilled attacker can easily find these vulnerabilities and exploit the issue without being detected.

The best defense against these attacks is to develop secure applications. Developers must be aware of how application attacks work and build software defenses right into their applications.

Read the white paper: Five Steps to Achieve Risk-Based Application Security Management

Educating and informing developers about application vulnerabilities is the goal of the Open Web Application Security Project (OWASP). The organization has put together a list of the 10 most common application attacks. This list is renewed every three years, with the latest refresh in 2013.

The IBM Security Ethical Hacking Team shares this goal. With this in mind, we put together a video series that demonstrates attacks from each category from OWASP’s list. Each video includes information on how to prevent these attacks and how to use automated tools to test whether attacks are possible. These videos were initially intended for internal use but have now recently been made publicly available.

So, without further ado, let’s start the countdown!

10. Unvalidated Redirects and Forwards

This category of vulnerabilities is used in phishing attacks in which the victim is tricked into navigating to a malicious site. Attackers can manipulate the URLs of a trusted site to redirect to an unwanted location. Watch Jonathan Fitz-Gerald demonstrate this attack below:

9. Using Components With Known Vulnerabilities

This category is about using unpatched third-party components. Attackers can easily exploit old third-party components because their vulnerabilities have been publicized, and tools and proof of concepts often allow cybercriminals to take advantage of these flaws with ease. Any script kiddie can conduct an exploit. In this video, you will see exploits of the famous Heartbleed and Shellshock vulnerabilities:

8. Cross-Site Request Forgery

This type of attack is used in conjunction with social engineering. It allows attackers to trick users into performing actions without their knowledge. In the video below, Brennan Brazeau demonstrates how an attacker can steal money from a victim’s banking account by leveraging social media — and pictures of cats:

7. Missing Function Level Access Control

This category covers situations in which higher-privilege functionality is hidden from a lower-privilege or unauthenticated user rather than being enforced through access controls. Here, John Zuccato demonstrates an attack in which a lower-privilege user gains access to the administration interface or a Web application:

6. Sensitive Data Exposure

This category deals with a lack of data encryption in transport and at rest. If your Web applications do not properly protect sensitive data, such as credit cards or authentication credentials, attackers can steal or modify the data to conduct credit card fraud, identity theft or other crimes.

5. Security Misconfiguration

Moving into the top five, we’re exploring another extremely dangerous category of flaws that deals with the incorrect misconfiguration of the server or of the application itself.

4. Insecure Direct Object References

In this video Fitz-Gerald takes us through a demo of another vicious attack: path traversal. This type of insecure direct object reference allows attackers to obtain data from the server by manipulating file names. You’ll see how Fitz-Gerald patiently downloads file by file until the gets the whole database.

3. Cross-Site Scripting

Cross-site scripting is a type of vulnerability that lets attackers insert Javascript in the pages of a trusted site. By doing so, they can completely alter the contents of the site to do their bidding — for example, they could send the user’s credentials to some evil server. Warren Moynihan shows us how that can be achieved below:

2. Broken Authentication and Session Management

Brazeau discusses several types of programming flaws that allow attackers to bypass the authentication methods that are used by an application:

1. Injection

As the all-time favorite category of application attacks, injections let attackers modify a back-end statement of command through unsanitized user input. Moynihan takes us through several examples of SQL injections, and he ends up making the application spit out the entire user table, including passwords.

Read the white paper: Five Steps to Achieve Risk-Based Application Security Management