As Web applications become the regular locus of online business, so too are they becoming the frequent targets of attackers. Unfortunately, many Web applications are fraught with vulnerabilities, a fair number of which result from an insufficient focus on security during the development process.

While the scope of the fundamental security flaws in some applications often requires a re-architecture, there are several secondary measures infosec teams can implement to safeguard flawed applications. This tip covers a few of the steps that information security professionals can take to lock down their Web apps.

Using VPNs
For starters, as a best practice, certain functionality should only be accessible via a VPN. All admin functionality, for instance, should be remapped onto internal IPs, which can then only be accessed by certain IPs over a VPN. Example functions include content management systems (CMS), server status scripts (server-status), and info scripts or SQL admin programs. Recently, HBGary Federal was attacked partly because the company allowed its CMS to be exposed to public IPs accessible from the Internet.

It is also prudent to restrict Web services access only to internal IPs, unless you intend to give other companies access to them, in which case, those companies should also be provided with credentials for service access.

Correcting coding errors
Programmers frequently rely too much on frameworks (like the .NET validate-request feature) to defend against dangerous inputs, or use application firewalls based on signatures that work by blacklisting the various attack vectors published by hackers in cross-site scripting (XSS) or SQL injection cheat sheets. This approach is flawed, as custom attacks can -- and often do -- bypass the protection afforded by .NET and simple blacklists. The best approach for addressing such security vulnerabilities in Web applications is to correctly validate the input when the software is written, or update the code after the app has been deployed with the help of a programmer or pen tester. Similarly, it is common for programmers to only filter hyphens on input passed to SQL queries, and, as such, numeric inputs are commonly found vulnerable to SQL injection, as hyphens are not needed in order to escape into SQL commands having numeric inputs.

Another commonly neglected coding area is user authentication; existing usernames/email addresses are often enumerated on registration or through forgotten password mechanisms, which can allow valid logins to be brute-forced. The more popular the target website is, and the more users supported, the easier it becomes to enumerate accounts by brute force. .One fix for this, however, would be implementing captchas.

Coding errors have also become more prevalent in file upload and download functionality in applications that, for instance, enable people to upload pictures. Common coding errors might allow shell code to be uploaded to attack the server, or malicious files uploaded for other users which, when viewed, can be used to attack other user's machines. As such, it's necessary to have regular network pen tests to discover and eradicate any such vulnerabilities.

Authentication and access control
Perhaps the greatest area of concern is that passwords are often shared between websites, with a single set of credentials (email address and password) used to access eBay, PayPal and corporate email, for instance. Let's say a social network website with hundreds of thousands of users is hacked, and immediately after the shell code is run, all the usernames, emails and passwords are remotely accessed by the attacker. It's common for an attacker to immediately attempt to use stolen credentials to access victims' accounts on other websites to obtain payment card data or financial account access, or to sell the credentials to other parties interested in perpetrating fraud. To defend against this, it's common for banks and other organisations to implement additional authentication methods, using IP address checks, tokens, pinpads and other similar devices, as usernames and passwords alone are no longer considered secure.

Giving unnecessary rights to users is another area of concern, whether they be rights to a SQL server database or the service account that the application or Web server runs on. This allows SQL tables to be dropped, commands run on SQL servers or the Web server to run a wide range of programs, some of which might have privilege escalation vulnerabilities. While performing a recent pen test, I obtained a shell within an application server. Even though I was unable to escalate my privileges, the account had the ability to download and compile programs like port-scanners, which allowed me to demonstrate that the machine could be used to stage further attacks into the network. Thus, making sure that users -- and programs that run as users -- have the minimum amount of rights necessary to do their jobs, and no more, is of utmost importance.

Cleaning up error pages
It is still common for default error pages to be left in place; this might, for instance, allow the SQL database structure to be easily enumerated. More seriously is that such errors are likely to be captured by Google or other search engine crawls, which hacker groups can then use to discover servers potentially vulnerable for attack. When I hear of a high-profile website compromise, the first thing I do is inspect the Google cache for reported errors and, in approximately 80% of the cases, the Google cache contains a number of errors stored from the website.

It's possible for an organisation's developers to detect such pages by downing the SQL server to produce a SQL timeout error page within the development environment. And then, to prevent such pages from causing harm by exposing information, make the program redirect to the homepage instead of displaying such errors.

Other regular causes for concern include the following:

• Default accounts with usernames such as 'admin,' 'administrator,' 'anonymous' or 'test'.Such accounts are rarely removed or renamed, which makes things easier for attackers, as only the password needs to be brute-forced.
• Broken access control mechanisms, which allow users to read or modify other user's documents. These can be achieved by knowing the document ID, or, if the document name is predictable, guessing other document names. And, in the same manner, gaining access to admin programs by brute-forcing program names, within directories found to exist, like /admin/.
• Cross-site request forgery flaws, which can be used to take over users accounts within websites. Once an attacker takes over an account, he or she can then message other users from the account, or perform other actions, like forwarding messages to the compromised user's mailing list and/or changing their passwords.

Conclusion
Because of the expansion of social networking sites and the broader use of application and Web servers security controls, attacks have had to become more sophisticated. Where, in the past, it was common to find SQL injection and buffer overflow type attacks, it has become more common now to find account enumeration, cross-site request forgery, cross-site scripting or file upload/download attacks. As such, locking down Web applications in whatever way possible is of the utmost importance.

A great first step would be addressing shared passwords between websites by requiring strong, frequently changed passwords, according to policies outlined above. It does not matter how secure a website is if the credentials used to access it have been reused from another poorly programmed or compromised site.

About the author:
Richard Brain is an expert in pen-testing and penetration automation with nearly three decades of computing experience.

The following article appears on Search Security. Please click here to read it in its original source.