John Paul Mueller - Security for Web Developers: Using JavaScript, HTML, and CSS

Developing a Security Plan

Defining the Application Environment

Data is the most important resource that any business owns. Its 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 youits data. Therefore, this book is about data security, which encompasses a broad range of other topics, but its important to get right to the point of what youre really looking to protect when you read about these other topics.

Unfortunately, data isnt 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 isnt 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 introductory chapter talks about the application environment.

However, before you go any further, its important to decide precisely how applications and data interact because the rest of the chapter isnt 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

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 dont 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 doesnt know your application. A SQL injection attack is only useful if your application uses SQL in some wayperhaps it doesnt.

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, dont rely on just one listuse 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:

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.

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 isnt even part of an attack, but it might as well be. A recent article (see http://www.infoworld.com/article/2925839/netneutrality/code-injection-new-low-isps.html) discusses how Internet Service Providers (ISPs) are injecting JavaScript code into the data stream in order to overlay ads on top of a page. In order to determine what sort of ad to provide, the ISP also monitors the traffic.

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 isnt. In most cases, you dont 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 doesnt end up serving viruses or worse along with seemingly benign data.

Few experts remind you to check your output data. However, you dont 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.

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 isnt 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. Dont rely on file extension exclusion alonehackers often make one file look like another type in order to bypass server security.

Hard Coded Authentication: Developers often place authentication information in application initialization files for testing purposes. Its 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 cant 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 cant discover them accidentally.

Hidden or Restricted File/Directory Discovery: When your application allows input of special characters such as the forward slash (/) or backslash (\), its 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.

Missing or Incorrect Authentication: Its important to know whom youre dealing with, especially when working with sensitive data. Many web applications rely on common accounts for some tasks, which means its impossible to know who has accessed the account. Avoid using guest accounts for any purpose and assign each user a specific account to use.

Missing or Incorrect Authorization: Even if you know the person youre dealing with, its important to provide only the level of authorization needed to perform a given task. In addition, the authorization should reflect the users 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.