Application Security: Moving from SDLC to Secure SDLC

Recently I had an opportunity to attend Royal Holloway ISG Alumni Reunion Conference 2010 and present there for the first time at such a large scale. It was an amazing experience for me and the presentation was very well received and appreciated. I not only received comments on the contents of the presentation, but on my presentation style as well, which was quite encouraging.

The presentation is now online and can be accessed from here.

Six Steps to Achieve Software Security Assurance

Currently I am preparing for a CSSLP certification. Those of you who are not aware of what CSSLP stands for, may follow this link to know more on the ISC2 web site. CSSLP CBK is nothing but an introduction to secure software development practices through a six  phase secure software development process. I am sure these secure software development phases would be very familiar to anyone involved in software development. 

If we look at a software development process, this involves the following phases: Requirements, Design, Implementation, Testing, Acceptance testing and Deployment/Operations/Maintenance. Whichever software development methodology we adopt, a software development project has to go through these six phases. A secure software development process is nothing but applying security best practices at each one of these software development phases to achieve software security assurance. 

The six steps to achieve software security assurnace is nothing but the following six secure software development phases:

1. Secure Software Requirements: This phase involves capturing software security requirements along with functional requirements. It is also very important to capture corporate security policy and any applicable compliance requirements along with application specific security requirements. Effective security controls can only be built if the software security requirements are identified at this stage. These security requirements should be used to develop security test cases.

2. Secure Software Design and Architecture: Secure software design will involve identification of attack surface and risks to the application through a threat modeling exercise. Once a threat model is created, secure design and architecture principles should be applied to reduce the attack surface and to mitigate any risks that are identified during threat modeling exercise. Since it is not possible or cost effective to reduce the risk level to absolute zero, effective control identification and implementation would be the key to mitigate risks based on corporate security policy. Design flaws are most difficult to identify and expensive to mitigate after the software is released. Therefore every effort should be made to get it right at this stage.

3. Secure Software Implementation: Secure software implementation is nothing but applying secure coding practices to software development. This can be best achieved by identifying and documenting any technology specific weaknesses and through developer training. Static code analysis should also be conducted at this stage to identify security flaws within the source code.

4. Secure Software Testing: Security testing must be conducted along with functional and integration testing. Security unit test cases must be developed based on software security requirements. This would also involve development and execution of abuse cases from the perspective of an attacker.

5. Secure Software Acceptance: Secure software acceptance testing would not only involve adherence to function requirements, but to security requirements as well. Acceptance should only be granted if the software meets all the security requirements that are identified during requirements phase. This may be verified by conducting dynamic security analysis or a penetration testing exercise.

6. Secure Deployment/Operation/Maintenance: Secure configuration practices should be followed to harden the platform. Regular security reviews should be conducted to ensure ongoing security of the application and platform during operation. Also continuous monitoring is essential to provide an early warning sign to any attack attempts.

Only following these secure software development practices would provide complete assurance about the security posture of your application.

Web Application Security: Broken Authentication and Session Management

This is the third post in a series of ten based on OWASP Top 10 - 2010. Links to other posts in the series can be found here.

Authentication and session management are part of almost every business critical and eCommerce application. But the security issues concerning these mechanisms are almost always misunderstood. Every application is different and both these mechanisms are custom built by system designers. Since building these mechanisms correctly is hard, almost every application implemneting these mechanisms have one or more design related flaws. These flaws if compromised would provide an attacker with access to a single user account or complete control over the application via a compromised admin account.

The attacks to web applications concerning authentication and session management may come in several forms and from attackers having different levels of access to the system. This may include anonymous users (users having access to public web pages), legitimate users (users having limited authenticated access to the system) and the insiders (privileged users such as system administrators).

The authentication related attacks may include attacks on user registration process, user authentication process, password management functions such as attacks on insecure transmission and storage of  user passwords,  password change and password reset functions; while session management related attacks may include attacking weak session token creation and management processes such as unencrypted and easy to guess session tokens or tokens being transmitted in clear text or revealed within client side code.

The new OWASP Top 10 document has documented some useful checks to make to check if you are vulnerable. OWASP Testing Guide and OWASP ASVS Standard provide some useful checks to see if you are vulnerable. Recently I have also created an authentication cheat sheet  to identify authentication related issues within web applications. Furthermore, OWASP Developent Guide can act as a very useful resource for  implementing  authentication and session management correctly. 

One thing to remember here is that both authentication and session management are design  related issues. Therefore security concern need to be thought through in the design phase itself. Otherwise it will be too late and very expensive to implement or rectify these issues later in the SDLC.

OWASP O2 Platform: Automating Application Security Knowledge and Workflows

Recently I attended one day OWASP training on OWASP Projects and Resources you can use Today in London. It was a perfect opportunity for me to learn about some of the OWASP projects and tools which I had only heard about but not used before. One such tool was OWASP O2 Platform. This tool is an open platform for automating application security knowledge and workflows and has been developed by Dinis Cruz of OWASP. As Dinis states "O2 is designed to Automate Security Consultants Knowledge and Workflows and to Allow non-security experts to access and consume Security Knowledge".

The tool not only helps to improve the efficiency of security professionals to unearth vulnerabilities within the code, but also creates a workflow in a linear fashion that helps the developers to pinpoint the areas of the code to fix.  The following are some of the problems that O2 has solutions for:

• Advanced findings filtering (for example query 50M to 500Mb assessment files)
• Visualizing traces
• Mass rule creation & management
• “Rules Driven Scans”
• Creating ALL Traces
• Joining and Manipulating Traces
• Scripting questions and workflows (on top of rich objects like CirData, Findings or Rules)
• Gain visibility into Frameworks
• Understand and exploit Spring MVC apps
• Integrate complex workflows with SDLs
• Do Virtual Patching
• Quickly Write PoCs and exploits using O2’s .NET’s power Debugger
• Create “Run-time traces”
• Write Unit Tests for PoCs
• Find (via instrumenting and automating the security consultant’s brain) all sorts of application security issues (like to ones in the OWASP Top 10)
• Start venturing into Source-Code-Fixing for vulnerabilities found
• Start venturing into auto-writing WAF rules for vulnerabilities found

The tool has been divided in modules and supports multiple technologies. The list has been provided below. But the support for a new technology, tool or framework can be easily added via numerous reusable O2 APIs.

• Ounce Labs Scanner: (FULL Support): scanning, CIR consumption, rules creation, open & save findings format. Languages: .NET, Java, C/C++, ASP Classic, VB 6.0
• IBM AppScan Developer Edition: open findings format. Language: Java
• Microsoft CAT.NET scanner: scanning, open findings format. Language: .NET (C#, VB.net, Iron Phyton, etc...)
• FindBugs scanner: open findings format. Language: Java
• OWASP CodeCrawler: open findings format. Language: .NET
• Fortify (very early stages) : open findings format (FVDL). Language: .NET, Java, C/C ++, etc.
• .NET - create CIR, create call flow traces, create run-time traces
• Java - create CIR, create call flow traces
• Spring MVC ‘Annotation Based Controllers’ - Model controllers behavior, drive BlackBox tests

Web Application Authentication Cheat Sheet

I have just created a new document "Web Application Authentication Cheat Sheet" which is available to download from Scribd. This is my first go at creating this document. Any comments are welcome that would help me to improve the document further.

Implementing Encryption Correctly

Secure transmission of sensitive information over the Internet requires an encrypted connection. However, most of the time, system designers will get the encryption wrong and inadvertently expose their systems to risks.

Most of the time whilst conducting pentests, I come across applications that are required to implement an encrypted connection to prevent sensitive information from being intercepted. There are two things that need to be kept in mind whilst implementing a secure SSL connection to encrypt traffic. One, which SSL protocols are to be used; and the other, which ciphers need to be supported.

The main SSL protocols that are supported to encrypt traffic are SSL2, SSL3 and TLS1. However, the SSL2 protocol suffers from several cryptographic weaknesses and has been deprecated for several years. I have found this protocol to be supported by many applications. It  makes these applications vulnerable to man-in-the-middle and other cryptographic attacks. The other thing to remember is to choose strong encryption ciphers. Encryption ciphers using key lengths of 128 bit or higher are considered strong and should only be supported.

Vendors normally provide guidelines on how to implement strong encryption for their products. I have provided links for both Microsoft-IIS and Apache web servers which are the most commonly used web servers:

• Microsoft IIS: http://support.microsoft.com/kb/245030/en-us
• Apache: http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html

Disclaimer: The guidance above has been provided as an information only. Please seek professional advice before undertaking any changes to your system based on the guidance provided in this post. I take absolutely no responsibility for any damages caused to your system as a result of your actions based on the guidance provided in this post.

Web Application Security: Cross-Site Scripting (XSS)

This is the second post in a series of ten based on OWASP Top 10 - 2010. Links to other posts in the series can be found here.

Although XSS is the most prevalent security flaw within web applications, it was down to number two position in the latest OWASP Top 10 - 2010 document from its number one position in OWASP Top 10 - 2007. This was because the potential risk paused by injection flaws is considered to be higher than the potential risk paused by XSS flaws.

XSS flaws occur within web applications when a user supplied input is sent back to the browser without proper validation and escaping of data. The XSS flaws within an application may be used to hijack authenticated user session tokens giving an attacker complete control of a victim's account, defacing web sites, executing malicious content on compromised users' machines etc. The three common types of XSS flaws are Stored (also called persistent), Reflected (also called non-persistent) and DOM based XSS. Out of these three attack techniques, stored XSS is most dangerous and easy to carry as the malicious code can be stored within the vulnerable web site and this code will be executed in every user's web browser who visits the compromised web page.

Sometimes developers may underestimate the risks paused by XSS flaws and may think of it as a poor attack technique used by script kiddies to cause annoyance to other users, but an advanced XSS attack may be quite damaging and may require a good understanding of scripting language. A recent hack on Apache infrastructure was conducted by exploiting an XSS flaw, providing attackers complete control of the attacked server.

What are the best ways to prevent XSS flaws?
XSS flaws can be prevented by having proper input validation controls in place. The best way to achieve this is to follow a white list approach rather than a black list approach for reasons described here. Some times it may not be possible to limit or sanitise special characters (or at least some of these) as these may be genuinely required by the application. To overcome this situation, output encoding techniques may be utilised where special characters are URL encoded so that these can be treated as data rather than active content within the web browsers.

How to look for XSS flaws?
The best ways to discover XSS flaws is to use both code review and penetration testing techniques. It may not be possible to identify all the instances of XSS by following just one of these techniques. This can be explained with one simple example: if during a pentest, the tester has access to a normal user account. If one of the user input fields has been found to be vulnerable to XSS and the contents of this field are stored in the database providing access to the data only within the administrative portion of the web site. If the tester does not have access to the admin area of the web site, it will be difficult to verify this vulnerability during a pentest, but the same vulnerability can be discovered by a code review exercise with the tester having access to the code for the whole web site.

Other noteworthy thing to discover XSS flaws is utilising manual testing techniques as compared to automated techniques. Automated tools may not always be capable of identifying all the possible instances of XSS flaws. One simple example where automated tools fail is getting HTTP 200 and HTTP 301 response codes back. In the first case where HTTP 200 response code is returned, it may be a false positive because the web site returns a custom error message while the tool may assume that the attack has succeeded. In the second case where HTTP 301 response code is returned, tool would miss a potential vulnerability altogether as it has not received an intended response back and thus makes it a false negative, while the same vulnerability can be confirmed with manual testing techniques.

Implementing Strong Password Policies

There are so many articles and posts on the web about choosing strong passwords; therefore I did not want to add another post to that list. The main audience for this post are the web application designers and developers. 

I very frequently come across web applications that implement poor password policies and allow end users to choose weak passwords. Bruce Schneier in one of his articles mentions how various password cracking tools crack commonly used weak passwords, and an another article documents the approximate amount of time required to crack passwords of various degrees. Implementing proper password policies in your application would not rely on end users to choose strong passwords whilst visiting your web site and thus help prevent password based brute force attacks.

There are few guidelines which may be considered to implement strong password policies within web applications:

1. Password Complexity

A strong password should contain characters from at least three of the following four categories (although implementing all four would be even better):

• Upper case letters (A through Z)
• Lower case letters (a through z)
• Numbers (0 through 9)
• Non-alphanumeric characters (e.g. !"£$%^&*@#?+ etc.)

2. Password Uniqueness

A strong password should enforce uniqueness of characters. This would mean avoiding character repetition, number and character sequences, full or part of the password same as the user name or common dictionary words.

3. Password Length

Password length is directly proportion to the amount of time required to crack the password. Although the optimum length to thwart most password cracking attempts is considered to be more than 14 characters, but implementing a policy that requires minimum eight characters along with above requirements would still be sufficient to thwart most of the attacks.

4. Password Aging and Expiry

Password aging and expiry may be considered for high profile web sites. But this requirement needs to be considered very carefully. If implemented poorly, this may prove to be counter productive; e.g. asking users to change passwords very frequently may prompt them to choose weak passwords (e.g. Password1 - a password meeting first three complexity requirements, but still considered a weak password), or to write their password somewhere.

If considered carefully, strong password implementation policies would prevent users from choosing weak passwords and help prevent compromise of user accounts through brute force attacks.

Web Application Security: Injection Flaws

OWASP has recently released the latest version of OWASP Top 10 - 2010 presenting the ten most critical web application security risks. In this and future posts, I will discuss about these most critical web application security risks and the measures to prevent them.

This is the first post in the series of ten, discussing Injection flaws. Links to other posts can be found here.

Injection flaws have topped the OWASP Top 10 list, meaning that this is still a wide spread problem within web applications and presents the highest level of risk to the organisations. Injection flaws occur when a user input is processed by the application on the server without validating client side input data. This input can originate from any source interacting with the application including a human user or a system or process. The different types of injection flaws that may exist include SQL injection, LDAP injection, XPATH injection, OS command injection or buffer overflows. The complete list of injection flaws can be found on the OWASP website.

Injection flaws affect all three elements of the CIA triangle by leaking, modifying or deleting potentially sensitive information from the target system and therefore pose the highest level of threat to the system. 

Most of the injection flaws can be prevented by following these best practices:

1. All client side input should be considered malicious and should be checked on the server for length, type, format and range. Client side validation may be utilised to enhance user experience, but it cannot be trusted to provide any security.
2. All input should be validated whenever a trust boundary is crossed within the application.
3. Always follow a white listing approach over a black listing approach. This is much safer way to prevent against unknown attacks. 
4. Where special characters need to be accepted, these should be properly escaped before processing. Also parametrised queries should be utilised to prevent mixing of data with executable code.
5. Always develop and use centralised data validation modules. It is best to use time tested standard validation modules or libraries, if possible. One such example of a standard data validation library is the OWASP ESAPI project.

PS: I have used the term prevent and not mitigate in this post as the best way to mitigate these risks is to prevent the existence of injection flaws within your application, which can be achieved by following the above best practices.

OWASP Top 10 - 2010: Ten Most Critical Web Application Security Risks

The final version of OWASP Top 10 - 2010, listing the latest ten most critical web application vulnerabilities has been released today on 19th April 2010. The OWASP Top 10 was first released in 2003 with minor updates in 2004 and 2007, and this is 2010 release. The goal of the Top 10 project is to raise awareness about application security by identifying some of the most critical risks facing organisations. Although the usefulness of Top 10 is highly debated by some of the industry experts, but it can still act as a good first step towards developing an effective application security program within an organisation as discussed in one of my previous posts.

Not a lot has changed in terms of new additions to this year's Top 10 list, but a notable change is that the vulnerabilities in this release have been ranked based on the risk presented to the organisations as oppose to the frequency with which these vulnerabilities appear within web applications. Also, one of the main goals of this document is to change the focus from finding vulnerabilities to shifting the culture towards integrating security into the software development life cycle.

Below are the latest Top 10 application security risks as listed in the document:

A1. Injection

A2. Cross-Site Scripting (XSS)

A3. Broken Authentication and Session Management

A4. Insecure Direct Object Reference

A5. Cross-Site Request Forgery (CSRF)

A6. Security Misconfiguration (New)

A7. Insecure Cryptographic Storage

A8. Failure to Restrict URL Access

A9. Insufficient Transport Layer Protection

A10. Unvalidated Redirects and Forwards (New)

The complete document can be downloaded from here.