Tuesday, 13 July 2010
Application Security: Moving from SDLC to Secure SDLC
Labels: Best Practice, Presentations, SDLC, Webappsec
Tuesday, 22 June 2010
Six Steps to Achieve Software Security Assurance
The six steps to achieve software security assurnace is nothing but the following six secure software development phases:
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.
Labels: Best Practice, How To, SDLC
Saturday, 12 June 2010
Web Application Security: Broken Authentication and Session Management
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 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.
Thursday, 3 June 2010
OWASP O2 Platform: Automating Application Security Knowledge and Workflows
- 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
- 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
Labels: Code Review, Commentary, OWASP, Tools
Monday, 31 May 2010
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.
Labels: Cheat Sheets, How To, Pentesting, Webappsec
Tuesday, 25 May 2010
Implementing Encryption Correctly
- Microsoft IIS: http://support.microsoft.com/kb/245030/en-us
- Apache: http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html
Labels: Best Practice, Cryptography, Defences, Webappsec
Thursday, 13 May 2010
Web Application Security: Cross-Site Scripting (XSS)
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.
Labels: Attacks, Best Practice, Code Review, Defences, OWASP, Pentesting, Webappsec
Saturday, 1 May 2010
Implementing Strong Password Policies
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.
- Upper case letters (A through Z)
- Lower case letters (a through z)
- Numbers (0 through 9)
- Non-alphanumeric characters (e.g. !"£$%^&*@#?+ etc.)
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.
Labels: Best Practice, Passwords
Saturday, 24 April 2010
Web Application Security: Injection Flaws
Most of the injection flaws can be prevented by following these best practices:
- 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.
- All input should be validated whenever a trust boundary is crossed within the application.
- Always follow a white listing approach over a black listing approach. This is much safer way to prevent against unknown attacks.
- 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.
- 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.
Labels: Attacks, Best Practice, Defences, OWASP, Webappsec
Monday, 19 April 2010
OWASP Top 10 - 2010: Ten Most Critical Web Application Security Risks
Labels: Announcements, Commentary, Industry Updates, OWASP, Webappsec