Tip

Eight must-fix flaws prior to an application pen test

    Requires Free Membership to View

 When providing application penetration testing services to a wide range of public- and private-sector clients, I frequently come across several common, easily exploitable vulnerabilities that can be easily addressed.

Here are some of the most common application pen test security issues discovered and how to remediate them.

  1. Trusting client-side validation: JavaScript, pull-down menus, hidden form fields and other client-side filters may improve a website's usability, but they are trivial for attackers to bypass, and hence they do not provide any security. Don't rely on security checks at the client side, because clients are beyond your control. Attackers often use their own thick clients or GUI clients to target the application. Every user input should be considered untrustworthy and its length, range, format and type should be validated on the server side.

     

  2. Blacklisting for input validation: Some applications employ a simple blacklist for input validation, both blocking and removing user-supplied data that appears on that list. However, sometimes the implemented routines do not filter out the whole set of potential attack characters. Furthermore, data can be encoded in UTF, Hex or Unicode, among other formats, to bypass these kinds of filters. It is far more secure to use a whitelist of allowable input than a blacklist of unacceptable input.

     

  3. Improper error handling: A key aspect of keeping an application secure is the ability to handle and react appropriately to user or application errors. Errors resulting from normal user operation are inevitable. However, it's difficult to predict every possible way a malicious user could interact with an application. Attackers can cause unexpected error behaviour, from which they can gather information or exploit the application. Verbose error reporting that includes sensitive system or application information -- like the exact nature of the error or the software version your systems are running -- will assist malicious attackers in their quest to understand the application infrastructure's underpinnings and exploit its flaws. Logging private data, such as passwords, should be avoided, as an attacker could then gain such information by accessing the logs. Handling unexpected errors by presenting the user with a uninformative error message is the best approach.

     

  4. Forgotten/change password functionality: Often these mechanisms introduce more problems and unveil useful information an attacker can exploit, such as user enumeration, a functionality that could be used to discover valid user IDs. The forgotten password functionality sometimes involves presenting the user with a secondary challenge question, which is easier for an attacker to guess than the actual user password. Password-reset questions regarding information like a mother's maiden name, memorable dates, favourite colours or pet names should be avoided because the answers may be publically known or easily discoverable by social engineering attacks or open source intelligence gathering.

     

  5. Unencrypted communications/authentication: Sometimes applications use authentication mechanisms that are unencrypted and allow clear text credentials to be passed over the network. Communication channels should always be encrypted to secure authentication tokens and credentials. Also, use HTTPS with forms to prevent sniffing of sensitive information and to ensure you do in fact send the data to the intended server. There are many tools available in the public domain that make capturing and decoding network traffic fairly easy to achieve, given the ability to tap the data stream. There are also specialist tools, such as Firesheep , a Firefox plug-in that made headlines last year as a tool to hack social network credentials, that have been specifically developed to intercept and decode authentication tokens and cookies.

     

  6. Lack of auditing and logging: Applications are frequently deployed without any auditing or logging. This gives a tremendous advantage to an attacker, who can then perform attacks without being identified or detected. As a minimum, activity, such as failed attempted logins, should be logged.

     

  7. Not reusing good security API or already tested code: Software developers often spend considerable time developing their own implementations of security functions even though secure, tested code already exists. Such new code generally contains more vulnerabilities, and, if a pen test reveals a significant number of coding issues, could force a code redevelopment from the ground up. The OWASP Enterprise Security API (ESAPI) project provides interfaces and implementations of important security functions, including input validation and output encoding, which, in addition to aiding security, can also save significant time and effort in development stages. ESAPI is currently implemented in Java, .NET and PHP versions. If you do need to develop your own security functionality, best practice is to define reusable input validation code for all software you create and ensure it is carefully developed and rigorously tested.

     

  8. Not following Microsoft best practice development guides: Microsoft has released guides and recommendations for helping developers to design, build and configure secure ASP.NET Web applications. These guides, methodologies and tools are available for free from the MSDN website. When followed, they can provide assurance that the applications are hardened against, and can be resilient from, an attack. Though there is no guarantee that an attack will be unsuccessful, following these best practices certainly mitigates the potential risk.

In order to save time and resources in the application pen testing process, tackle these issues before hiring a professional pen tester. Addressing these vulnerabilities can also further ensure the security of your systems and potentially thwart a large number of common and very damaging attacks.

About the author:
Neil O'Connor is a principal consultant at Activity Information Management Ltd. in Farnborough.
 

Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in January 2011

 

COMMENTS powered by Disqus  //  Commenting policy

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.