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.
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:
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
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.
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.
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.
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.
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.
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.
While implementing security controls is always important, often they can be ineffective or insufficient—leaving your firm’s data vulnerable. Down the road, you’ll need to go back and fix these vulnerable areas. Fixing the vulnerabilities caused by the ineffective security controls later in the development life cycle takes a lot more time for developers to fix than to just get it right the first time.
Get into the habit of implementing proper security controls throughout the software development life cycle (SDLC). This not only enables you to build security into your firm’s software, applications, and network, it also saves your team(s) a whole lot of headaches in the future.
Remember, just because you implement a security control doesn’t mean it’s guaranteed to work as you intended.