List of Common Web Application Threats

You can find lists of web application threats all over the Internet. Some of the lists are quite complete and don’t necessarily have a bias, some address what the author feels are the most important threats, some lists tell you about the most commonly occurring threats, and you can find all sorts of other lists out there.

The problem with all these lists is that the author doesn’t know your application. A SQL injection attack is only useful if your application uses SQL in some way – perhaps it doesn’t.

Obviously, you need to get ideas on what to check from somewhere and these lists do make a good starting place. However, you need to consider the list content in light of your application. In addition, don’t rely on just one list – use multiple lists so that you obtain better coverage of the threats that could possibly threaten your application. With this need in mind, here is a list of the most common threats you see with web applications today:

1. Buffer Overflow

An attacker manages to send enough data in an input buffer to overflow an application or output buffer. As a result, memory outside the buffer becomes corrupted. Some forms of buffer overflow allow the attacker to perform seemingly impossible tasks because the affected memory contains executable code.

The best way to overcome this problem is to perform range and size checks on any data, input or output, that your application handles.

2. Code Injection

An entity adds code to the data stream flowing between a server and a client (such as a browser). The target often views the added code as part of the original page, but it could contain anything. Of course, the target may not even see the injected code.

It might be lurking in the background ready to cause all sorts of problems for your application. A good way to overcome this attack is to ensure you use encrypted data streams, the HTTPS protocol, and code verification (when possible). Providing a client feedback mechanism is also a good idea.

3. Cross-site Scripting (XSS)

An attacker injects JavaScript or other executable code into the output stream of your application. The recipient sees your application as the source of the infection, even when it isn’t. In most cases, you don’t want to allow users to send data directly to each other through your application without strict verification.

A moderated format for applications such as blogs is a must to ensure your application doesn’t end up serving viruses or worse along with seemingly benign data.

Types of XSS:-

Reflected XSS
Stored XSS
DOM XSS

4. File Uploads

Every file upload, even those that might seem otherwise innocuous, is suspect. If possible, disallow file uploads to your server. Of course, it isn’t always possible to provide this level of security, so you need to allow just certain types of file and then scan the file for problems.

Authenticating the file as much as is possible is always a good idea. For example, some files contain a signature at the beginning that you can use to ensure the file is legitimate. Don’t rely on file extension exclusion alone – hackers often make one file look like another type in order to bypass server security.

5. Hard Coded Authentication

Developers often place authentication information in application initialization files for testing purposes. It’s essential to remove these hard coded authentication entries and rely on a centralized data store for security information instead.

Keeping the data store in a secure location, off the server used for web applications, is essential to ensuring that hackers can’t simply view the credentials used to access the application in certain ways. If you do need initialization files for the application, make sure these files reside outside the webroot directory to ensure that hackers can’t discover them accidentally.

6. Hidden or Restricted File/Directory Discovery

When your application allows input of special characters such as the forward slash (/) or backslash (\), it’s possible for a hacker to discover hidden or restricted files and directories. These locations can contain all sorts of information that a hacker can find useful in attacking your system.

Disallowing use of special characters whenever possible is a great idea. In addition, store critical files outside the webroot directory in locations that the operating system can control directly.

7. Missing or Incorrect Authentication

It’s important to know whom you’re dealing with, especially when working with sensitive data. Many web applications rely on common accounts for some tasks, which means it’s impossible to know who has accessed the account. Avoid using guest accounts for any purpose and assign each user a specific account to use.

8. Missing or Incorrect Authorization

Even if you know the person you’re dealing with, it’s important to provide only the level of authorization needed to perform a given task. In addition, the authorization should reflect the user’s method of access. A desktop system accessing the application from the local network is likely more secure than a smartphone accessing the application from the local coffee shop.

Relying on security promotion to assist in sensitive tasks lets you maintain minimal rights the rest of the time. Anything you can do to reduce what the user is authorized to do helps maintain a secure environment.

9. Missing or Incorrect Encryption

Use encryption to transmit data of any sort between two endpoints to help keep hackers from listening in on your communication. It’s important to keep track of the latest encryption techniques and rely on the best encryption supported by the user’s environment.

For example, Triple Data Encryption Standard (3DES) isn’t secure any longer, yet some organizations continue to use it. The current Advanced Encryption Standard (AES) remains mostly secure, but you want to use the largest key possible to help make it harder to crack.

10. Parameter Manipulation

Hackers can experiment with parameters passed as part of the request header or URL. For example, when working with Google, you can change the URL and the results of your search.

Make sure you encrypt any parameters you pass between the browser and the server. In addition, use secure web page protocols, such as HTTPS, when passing parameters.

11. Remote Code Inclusion

Most web applications today rely on included libraries, frameworks, and APIs. In many cases, the include statement contains a relative path or uses a variable containing a hard coded path to make it easier to change the location of the remote code later.

When a hacker is able to gain access to the path information and change it, it’s possible to point the remote code inclusion to any code the hacker wants, giving the hacker full access to the application. The best way to avoid this particular problem is to use hard coded full paths whenever possible, even though this action makes it harder to maintain the code.

12. Session Hijacking

Every time someone logs into your web server, the server gives that user a unique session. A session hijacker jumps into the session and intercepts data transferred between the user and the server. The three common places to look for information used to hijack a session are: cookies, URL rewriting, and hidden fields. Hackers look for session information in these places.

By keeping the session information encrypted, you can reduce the risk of someone intercepting it. For example, make sure you rely on the HTTPS protocol for logins. You also want to avoid doing things like making your session IDs predictable.

13. SQL Injection

An attacker modifies a query that your application creates as the result of user or other input. In many cases, the application requests query input data, but it receives SQL elements instead.

Other forms of SQL injection attack involve the use of escape or other unexpected characters or character sequences. A good way to avoid SQL injection attacks is to avoid dynamically generated queries.

Types of SQL Injection:-

Blind Based SQL Injection
Boolean Based SQL Injection
Error Based SQL Injection
Time Based SQL Injection

14. OS Command Injection

An attacker modifies an operating system command your application uses to perform specific tasks. Your web-based application probably shouldn’t use operating system calls in the first place. However, if you absolutely must make operating system calls, make sure the application runs in a sandbox.

You may also like: