Improving Security Through Dynamic Resource Obfuscation
One of the most basic attacks against data-driven sites generated dynamically through scripting languages like PHP and ASP is to use the weaknesses of the language against the developer.
Attacks against sites that make use of scripting languages often attempt to exploit system level calls that can lead to all sorts of nastiness with very little work on the part of the attacker.
One of the ways to guard against this is to write secure code, of course, but we all know that we can only code against known attacks. The unknown is something we just can't always anticipate and that sometimes leaves us open to newly discovered hacks.
Resource obfuscation is an underused, overlooked capability on servers and application delivery platforms that can seriously improve the security of your web applications and decrease the chances of an accidental or automate breach of security. Resource obfuscation can be an added protection against attacks. By hiding or obfuscating the actual file/script being invoked you can prevent a lot of automated exploitation of vulnerabilities in the most popular scripting languages used to build dynamic web sites today.
Resource Obfuscation
Resource obfuscation, called "service virtualization" in the XML world, is really nothing more than rewriting the URI. In many cases you can simply "map" an external URI to an internal URI. For example, "/externalURI.php" will always map to "/internalURI.php".
If your solution is flexible enough, you could set up a map that can translate exceedingly obfuscated URIs such as "xyz123abc.php" into "internalURI.php". If you are really concerned about security and you have a truly dynamic application delivery platform with a feature like iRules you could even dynamically generate the external URIs, creating a per-session map, and replacing all the URIs in the payload with the session-constrained URIs. This is some serious work, but it would certainly keep the bad guys always guessing because the external URIs would never be the same because they would be uniquely generated on a per request basis.
In general, resource obfuscation is a simple, flexible addition to your security toolkit that is easy to implement and adds an additional layer of security around your web applications.
To make your web application even more secure try these additional simple security measures:
1. Make sure the internal URI isn't easily deduced from query parameters or the functionality of the script. For example, if you're calling a PHP script to delete a record, don't make the internal URI "deleteRecord.php", and don't include the name of the file in hidden parameters.
2. Use a WAF (Web Application Firewall) or your chosen solution for rewriting URIs to block external access to internal URIs if possible. This prevents exploitation of scripting level vulnerabilities in the event that an attack deduces the names of your internal scripts and applications.
3. Give your scripts and applications extensions (if applicable) that do not easily (and loudly) proclaim the language and platform on which your site is running. Consider changing PHP and ASP to .abc or .xyz, either on the server itself or using your chosen URI rewrite solution. It won't stop serious attackers, but it might confuse the heck out of automated bots and script kiddies, which can reduce the likelihood of someone discovering some overlooked vulnerability.
Imbibing: Coffee
