Most Common Mobile Application Attacks
Most Common Mobile Application Attacks
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 the Internet of Things platforms such as Wink that allow users to dim their house lights right from their mobile phones.
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.
Educating and informing developers
about the application, vulnerabilities are 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 on 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 also 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 also used in conjunction with social engineering. It also allows attackers to trick users into performing actions without their knowledge. In the video below, Brennan Brazeau demonstrates how an attacker can steal
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 also 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. then 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 then 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 also 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.