As the year progresses, there are more and more reports of companies having their web servers hacked. This can make anyone paranoid about the potential of getting hacked themselves. Taking the time to evaluate the security of the servers you manage and always keeping security in the forethought when writing code can eliminate the majority of issues that may compromise your system.
Often, in larger companies, it can be easy to lose track of who is responsible for each part of the security that is needed. The assumption may be that the network guys are taking care of the network security, the administrators are taking care of the servers and the dependency software versions, and the developers and QA are taking care of the software security. While it’s good to assign these roles to specialized groups in larger companies, it’s never a bad idea to have overlap or oversight. We should be all concerned about the systems we work with and the potential for exploitation. The different roles may have different ways of overlapping in what they are looking for. So, with that being said, here are some tips, from a developer’s perspective, of security as a priority.
Trusting the Data
The data that is being brought in from users should never be trusted at face value. The majority of client data falls into two areas:
- Valid data the client meant to input.
- Invalid data the client either mistyped or doesn’t fit the requirements of the field.
In both of these cases, there is nothing malicious intended. However, the data should be vetted to make sure that passwords match a standard or other validation that may be required. While this may be the majority of data that passes from a client, there will be people with ill-intent. Making sure THEIR data doesn’t get executed or stored is the goal.
It makes sense that you would want to prevent malicious content from being executed immediately, but storing this data may also have consequences later. For example, if later another developer trusts the data coming from within the system but doesn’t verify that it was malicious content that was stored. Most languages provide their own ways to filter input data and these should be used anytime data is handled. Some of the most exploited issues exist because data is not vetted properly, allowing malicious users to cross-site script or inject and execute SQL statements on the server.
Server Transparency
From a black box perspective, server transparency mostly comes down to the URLs being used to access pages on your server. Ideally, a redirect layer should be in place before any request for a page is made to your web server process. If a malicious user is accessing your site and they see a URL that clearly indicates the file hierarchy of your server, it can be just another clue on brute forcing to find a URL that gets them access to something they should not have access to. By having a redirect layer, you can obfuscate the hierarchy of your server into something less meaningful to the user. Take for example the following URL and what it’s potential URL could be.
Instead of: https://www.domain.com/user/admin/manage.php
Use: https://www.domain.com/user-profile/
The path to access any other files that may be in the ‘user’ or ‘user/admin’ directories is not obvious to the malicious user. To be clear, however, security through obfuscation is not real security. The best you can hope for from obfuscation is to keep away those looking for a quick hack. A determined hacker will simply jump through more hoops. If those pages you do not want a user to access are on a live server and can be accessed by you, they can be accessed by that user as well.
Ideally, any pages you would not want a regular user to have access to would not be on the same server as pages users are accessing files on. For smaller companies and sites, it may not be within the budget to have multiple servers for this purpose. In these cases, here’s a good list to run through for files like these:
- File permissions are limited to only what is needed.
- The extensions on these files are ones that will process server-side code through your web server.
- Server-side code in these files to verify the identity of those accessing them.
Avoid naming any file with extensions that do not get filtered through your web server if they contain any data that can help a malicious user. If you’re running any software that needed installing, such as WordPress, phpBB, phpMyAdmin, etc., remember to remove any install files or documentation that came with these.
0day Vulnerable
A 0day is any open vulnerability that does not yet have a known fix. For any company that runs externally developed software, a 0day can be an Achilles’ heel. The best thing you can do is keep a list of all the software your server runs on and keep those as up-to-date as possible. Regularly visit their sites or repositories and make sure you’re as updated as you can afford to be for your applications. Going through any change logs for patches will also give you a good idea if your system is vulnerable. Keeping up on the patches will not protect a system from a 0day, but it will eliminate already fixed issues from causing your system downtime or costly attacks.
Your System Is 100% Secure
… to your knowledge. Approaching security from the standpoint that there are issues you just haven’t yet found is the best and most realistic approach. I have only covered a few things that you, as a developer, can do to protect your server. With constantly changing technology, there will always be new issues coming up. Keeping on top of your patches and always being thoughtful of the code you write is your best way to prevent becoming the victim of a malicious user’s ill-intentions.