Data is the most important resource that any business owns. It’s literally possible to replace any part of a business except the data. When the data is modified, corrupted, stolen, or deleted, a business can suffer serious loss. In fact, a business that has enough go wrong with its data can simply cease to exist.
The focus of security, therefore, is not hackers, applications, networks, or anything else someone might have told you—it’s data.
Therefore, this article is about data security, which encompasses a broad range of other topics, but it’s important to get right to the point of what you’re really looking to protect when you read about these other topics.
Unfortunately, data isn’t much use sitting alone in the dark. No matter how fancy your server is, no matter how capable the database that holds the data, the data isn’t worth much until you do something with it. The need to manage data brings applications into the picture and the use of applications to manage data is why this article talks about the application environment.
However, before you go any further, it’s important to decide precisely how applications and data interact because the rest of the article isn’t very helpful without this inside.
An application performs just four operations on data, no matter how incredibly complex the application might become. You can define these operations by the CRUD acronym: Create, Read, Update and Delete.
The sections that follow discuss data, applications, and CRUD as they relate to the web environment. You discover how security affects all three aspects of web development, keeping in mind that even though data is the focus, the application performs the required CRUD tasks. Keeping your data safe means understanding the application environment and therefore the threats to the data the application manages.
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. Code injection occurs more often than you might think. In some cases, the code injection isn’t even part of an attack, but it might as well be.
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.
Few experts remind you to check your output data. However, you don’t actually know that your own application is trustworthy. A hacker could modify it to allow tainted output data. Verification checks should include output data as well as input data.
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. Operating System Command Injection: An a ttacker 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.
11. 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.
12.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.
13. Session Hijacking: Every time someone logs into your web server, the server gives that user a unique session. A session hijack er 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.
14. 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.
This may look like a lot of different threats, but if you search long enough online, you could easily triple the size of this list and not even begin to scratch the surface of the ways in which a hacker can make your life in teresting.
Don’t worry, in most cases the fixes end up being common sense and a single fix can resolve more than one problem. For example, look through the list again and you’ll find that simply using HTTPS solves a number of these problems.
