4 ineffective security controls that leave you with a false sense of security

Secure coding practices are a trending topic in a variety of industries these days. And for good reason. With online attacks and data breaches at an all-time high, firms are scrambling to secure their applications. However, there are certain practices that give a false sense of security by introducing weak security controls. Are you sure that your application security controls are effective?

Let’s visualize it.

It’s not unusual for firms to add security controls that work like this red gate.

It’s often easier to bypass security controls than you’d like to think. That being the case, let’s take a look at four things that developers do that, at first glance, seem to secure code, but in reality these practices only make attackers have to go just a little out of their way to get what they’re after.

Improper input validation

Processing untrusted data without first validating the contents can lead to a variety of security issues including: cross-site scripting, SQL injection, XML injection, and link injection. Your first instinct may be to implement blacklisting to look for characters known to be used in writing queries and script, such as brackets and quotes. However, blacklisting typically fails for one very important reason:

                                                                          Attackers are creative.

There are plenty of ways to write malicious payloads that don’t use those special characters you’re filtering out. For instance, you may think that you’ve prevented cross-site scripting by rejecting all input with the word “javascript” in it, but what happens when an attacker sends a VB script payload? How about loading an event handler?

How to fix the problem: Don’t exclusively use blacklisting as your injection prevention. If you need to prevent special characters from coming through, use whitelisting wherever possible. Unfortunately, even whitelisting isn’t a sure fix. Defense in depth, such as the use of output encoding to prevent cross-site scripting and parameterized queries to prevent SQL injection attacks provide robust protection

Frame-busting code

Many developers are now learning that attackers can steal credentials and other information through iframes. As such, these developers are placing frame-busting code at the top of their pages. And—you guessed it—there are ways to bypass this. Iframes that force browsers into restricted, or sandbox, mode prevent frame-busting code from running. Other attacks, like double-framing, reframe the site once the frame-busting code has broken the page out of the first frame.

How to fix the problem: Use a combination of frame-busting code and X-Frame-Options. This prevents your application from being placed in any type of iframes for all but the most legacy and obscure browsers. Modern popular browsers support the X-Frame-Options header.

File upload validation

Unless there is some strange need for a user to upload an executable file, most uses of file uploads are for documents. Validating the file type and file size are important security controls, lest an attacker uploads something that is going to do harm. The easiest option is to have client-side code check the file extension. However, once that’s done, the file is sent. The traffic can be easily intercepted before it gets to the server with proxy software. From there, the contents of the file upload can be changed to be malicious, rendering your validation useless.

How to fix the problem: Always check the file type and file size server-side. Additionally, check the magic number of the file. The extension can be spoofed, renaming a .exe to a .doc, for example. In addition to these controls, limit the file size and rate at which files can be uploaded. Lastly, implement virus scanning software to check those files. As with input validation, the best defense is a multi-layered approach to validation.

Improper authorization controls

So you’ve got some admin functionality in your application and want normal users to stay out of it. The most obvious solution may be to hide all the links to the admin functionality. Unfortunately this is not adequate. Hidden buttons do very little to a determined attacker. Guessing the URL of admin pages through fuzzing or modifying the source code of the page to unhide buttons are two ways attackers can bypass this security control.

How to fix the problem: Always check for authorization on any pages that aren’t open to all users. It’s easy to forget that once you’ve authenticated the user and authorized them to use the application, you may also need to authorize them to see certain data or use certain functionality.