2014-03-14T16:34:30Z

EoinKeary:

{{Template:OWASP Testing Guide v4}}

==Foreword by [https://www.owasp.org/index.php/Eoin_Keary Eoin Keary], OWASP Global Board==

The problem of insecure software is perhaps the most important technical challenge of our time. The dramatic rise of web applications enabling business, social networking etc has only compounded the requirements to establish a robust approach to writing and securing our Internet, Web Applications and Data.
At The Open Web Application Security Project (OWASP), we're trying to make the world a place where insecure software is the anomaly, not the norm. The OWASP Testing Guide has an important role to play in solving this serious issue.

It is vitally important to our approach to testing software for security issues is based on the principles of engineering and science. We need a consistent, repeatable and defined approach to testing web applications. A world without some minimal standards in terms of engineering and technology is a world in chaos.
It goes without saying that you can't build a secure application without performing security testing on it. Testing is part of a wider approach to building a secure system.

Many software development organizations do not include security testing as part of their standard software development process. Even worse is many security vendors deliver testing with varying degrees of quality and rigor.

Security testing, by itself, isn't a particularly good stand alone measure of how secure an application is, because there are an infinite number of ways that an attacker might be able to make an application break, and it simply isn't possible to test them all. We cant hack ourselves secure and we only have a limited time to test and defend where an attacker does not have such constraints.

In conjunction with other OWASP projects such as the Code review Guide, The Development Guide and tools such as OWASP ZAP, this is a great start towards building and maintaining secure applications. The [[Building Guide|Development Guide]] will show your project how to architect and build a secure application, the [[Code Review Guide]] will tell you how to verify the security of your application's source code, and this [[Testing Guide]] will show you how to verify the security of your running application. I highly recommend using these guides as part of your application security initiatives.

==Why OWASP?==

Creating a guide like this is a huge undertaking, requiring the expertise of hundreds of people around the world. There are many different ways to test for security flaws and this guide captures the consensus of the leading experts on how to perform this testing quickly, accurately, and efficiently. OWASP gives like minded security folks the ability to work together and form a leading practice approach to a security problem.

The importance of having this guide available in a completely free and open way is important for the foundations mission. It gives anyone the ability to understand the techniques used to test for common security issues.
Security should not be a black art or closed secret that only a few can practice. It should be open to all and not exclusive to security practitioners but also QA, Developers and Technical Managers.
The project to build this guide keeps this expertise in the hands of the people who need it, You, Me, Anyone that is involved in building software!!

This guide must make its way into the hands of developers and software testers. There are not nearly enough application security experts in the world to make any significant dent in the overall problem. The initial responsibility for application security must fall on the shoulders of the developers, they write the code. It shouldn't be a surprise that developers aren't producing secure code if they're not testing for it or consider the types of bugs which introduce vulnerability.

Keeping this information up to date is a critical aspect of this guide project. By adopting the wiki approach, the OWASP community can evolve and expand the information in this guide to keep pace with the fast moving application security threat landscape.

This Guide is a great testament to the passion and energy our members and project volunteers have for this subject.

It shall certainly help change the world a line of code at a time.

==Tailoring and Prioritizing==

You should adopt this guide in your organization. You may need to tailor the information to match your organization's technologies, processes, and organizational structure.

In general there are several different roles within organizations that may use this guide:

* Developers should use this guide to ensure that they are producing secure code. These tests should be a part of normal code and unit testing procedures.

* Software testers / QA should use this guide to expand the set of test cases they apply to applications. Catching these vulnerabilities early saves considerable time and effort later.

* Security specialists should use this guide in combination with other techniques as one way to verify that no security holes have been missed in an application.

* Project Managers should consider the reason this guide exists; security issues are manifested via bugs in code and design.

The most important thing to remember when performing security testing is to continuously re-prioritize. There are an infinite number of possible ways that an application could fail, and organizations always have limited testing time and resources. Be sure it is spent wisely. Try to focus on the security holes that are a real risk to your business. Try to contextualize risk in terms of the application and its use cases.

This guide is best viewed as a set of techniques that you can use to find different types of security holes. But not all the techniques are equally important. Try to avoid using the guide as a checklist, new vulnerabilities are always manifesting and no guide can be an exhaustive list of "things to test for", but rather a great place to start.

==The Role of Automated Tools==

There are a number of companies selling automated security analysis and testing tools. Remember the limitations of these tools so that you can use them for what they're good at. As Michael Howard put it at the [[OWASP_AppSec_Seattle_2006/Agenda|2006 OWASP AppSec Conference in Seattle]], "Tools do not make software secure! They help scale the process and help enforce policy."

Most importantly, these tools are generic - meaning that they are not designed for your custom code, but for applications in general. That means that while they can find some generic problems, they do not have enough knowledge of your application to allow them to detect most flaws. In my experience, the most serious security issues are the ones that are not generic, but deeply intertwined in your business logic and custom application design.

These tools can also be seductive, since they do find lots of potential issues. While running the tools doesn't take much time, each one of the potential problems takes time to investigate and verify. If the goal is to find and eliminate the most serious flaws as quickly as possible, consider whether your time is best spent with automated tools or with the techniques described in this guide.

Still, these tools are certainly part of a well-balanced application security program. Used wisely, they can support your overall processes to produce more secure code.

==Call to Action==

If you're building, designing, testing software, I strongly encourage you to get familiar with the security testing guidance in this document. It is a great road map for testing the most common issues facing applications today, but not exhaustive. If you find errors, please add a note to the discussion page or make the change yourself. You'll be helping thousands of others who use this guide.

Please consider [[Membership|joining us]] as an individual or corporate member so that we can continue to produce materials like this testing guide and all the other great projects at OWASP.

Thank you to all the past and future contributors to this guide, your work will help to make applications worldwide more secure.

--[https://www.owasp.org/index.php/Eoin_Keary Eoin Keary], OWASP Board Member, April 19, 2013

__NOTOC__

Testing Guide Foreword

2014-03-14T16:26:06Z

EoinKeary:

{{Template:OWASP Testing Guide v4}}

==Foreword by [https://www.owasp.org/index.php/Eoin_Keary Eoin Keary], OWASP Global Board==

The problem of insecure software is perhaps the most important technical challenge of our time. The dramatic rise of web applications enabling business, social networking etc has only compounded the requirements to establish a robust approach to writing and securing our Internet, Web Applications and Data.
At The Open Web Application Security Project (OWASP), we're trying to make the world a place where insecure software is the anomaly, not the norm. The OWASP Testing Guide has an important role to play in solving this serious issue.

It is vitally important to our approach to testing software for security issues is based on the principles of engineering ans science. We need a consistent, repeatable and defined approach to testing web applications. A world without some minimal standards in terms of engineering and technology is a world in chaos.
It goes without saying that you can't build a secure application without performing security testing on it. Testing is part of a wider approach to building a secure system.

Many software development organizations do not include security testing as part of their standard software development process. Even worse is many security vendors delivery testing with varying degrees of quality and rigor.

Security testing, by itself, isn't a particularly good stand alone measure of how secure an application is, because there are an infinite number of ways that an attacker might be able to make an application break, and it simply isn't possible to test them all. We cant hack ourselves secure and we only have a limited time to test and defend where an attacker does not have such constraints.

In conjunction with other OWASP projects such as the Code review Guide, The Development Guide and tools such as OWASP ZAP, this is a great start towards building and maintaining secure applications. The [[Building Guide|Development Guide]] will show your project how to architect and build a secure application, the [[Code Review Guide]] will tell you how to verify the security of your application's source code, and this [[Testing Guide]] will show you how to verify the security of your running application. I highly recommend using these guides as part of your application security initiatives.

==Why OWASP?==

Creating a guide like this is a huge undertaking, requiring the expertise of hundreds of people around the world. There are many different ways to test for security flaws and this guide captures the consensus of the leading experts on how to perform this testing quickly, accurately, and efficiently. OWASP gives like minded security folks the ability to work together and form a leading practice approach to a security problem.

The importance of having this guide available in a completely free and open way is important for the foundations mission. It gives anyone the ability to understand the techniques used to test for common security issues.
Security should not be a black art or closed secret that only a few can practice. It should be open to all and not exclusive to security practitioners but also QA, Developers and Technical Managers.
The project to build this guide keeps this expertise in the hands of the people who need it, You, Me, Anyone that is involved in building software!!

This guide must make its way into the hands of developers and software testers. There are not nearly enough application security experts in the world to make any significant dent in the overall problem. The initial responsibility for application security must fall on the shoulders of the developers, they write the code. It shouldn't be a surprise that developers aren't producing secure code if they're not testing for it or consider the types of bugs which introduce vulnerability.

Keeping this information up to date is a critical aspect of this guide project. By adopting the wiki approach, the OWASP community can evolve and expand the information in this guide to keep pace with the fast moving application security threat landscape.

This Guide is a great testament to the passion and energy our members and project volunteers have for this subject.

It shall certainly help change the world a line of code at a time.

==Tailoring and Prioritizing==

You should adopt this guide in your organization. You may need to tailor the information to match your organization's technologies, processes, and organizational structure.

In general there are several different roles within organizations that may use this guide:

* Developers should use this guide to ensure that they are producing secure code. These tests should be a part of normal code and unit testing procedures.

* Software testers / QA should use this guide to expand the set of test cases they apply to applications. Catching these vulnerabilities early saves considerable time and effort later.

* Security specialists should use this guide in combination with other techniques as one way to verify that no security holes have been missed in an application.

* Project Managers should consider the reason this guide exists; security issues are manifested via bugs in code and design.

The most important thing to remember when performing security testing is to continuously re-prioritize. There are an infinite number of possible ways that an application could fail, and organizations always have limited testing time and resources. Be sure it is spent wisely. Try to focus on the security holes that are a real risk to your business. Try to contextualize risk in terms of the application and its use cases.

This guide is best viewed as a set of techniques that you can use to find different types of security holes. But not all the techniques are equally important. Try to avoid using the guide as a checklist, new vulnerabilities are always manifesting and no guide can be an exhaustive list of "things to test for", but rather a great place to start.

==The Role of Automated Tools==

There are a number of companies selling automated security analysis and testing tools. Remember the limitations of these tools so that you can use them for what they're good at. As Michael Howard put it at the [[OWASP_AppSec_Seattle_2006/Agenda|2006 OWASP AppSec Conference in Seattle]], "Tools do not make software secure! They help scale the process and help enforce policy."

Most importantly, these tools are generic - meaning that they are not designed for your custom code, but for applications in general. That means that while they can find some generic problems, they do not have enough knowledge of your application to allow them to detect most flaws. In my experience, the most serious security issues are the ones that are not generic, but deeply intertwined in your business logic and custom application design.

These tools can also be seductive, since they do find lots of potential issues. While running the tools doesn't take much time, each one of the potential problems takes time to investigate and verify. If the goal is to find and eliminate the most serious flaws as quickly as possible, consider whether your time is best spent with automated tools or with the techniques described in this guide.

Still, these tools are certainly part of a well-balanced application security program. Used wisely, they can support your overall processes to produce more secure code.

==Call to Action==

If you're building, designing, testing software, I strongly encourage you to get familiar with the security testing guidance in this document. It is a great road map for testing the most common issues facing applications today, but not exhaustive. If you find errors, please add a note to the discussion page or make the change yourself. You'll be helping thousands of others who use this guide.

Please consider [[Membership|joining us]] as an individual or corporate member so that we can continue to produce materials like this testing guide and all the other great projects at OWASP.

Thank you to all the past and future contributors to this guide, your work will help to make applications worldwide more secure.

--[https://www.owasp.org/index.php/Eoin_Keary Eoin Keary], OWASP Board Member, April 19, 2013

__NOTOC__

File:OWASP-SF-2014.pdf

2014-02-28T13:34:08Z

EoinKeary: Training deck from Jillians. Feb 24th San Francisco.

Training deck from Jillians.
Feb 24th San Francisco.

Dublin

2014-02-24T18:18:16Z

EoinKeary:

OWASP Code Review V2 Table of Contents

2013-12-12T15:46:11Z

EoinKeary: /* 360 Review: Coupling source code review and Testing / Hybrid Reviews */

= '''OWASP Code Review Guide v2.0:''' =

==Forward==
# Author - Eoin Keary
# Previous version to be updated:[[https://www.owasp.org/index.php/Code_Review_Guide_History]]
'''[[CRV2_Forward|Content here]]'''

== Code Review Guide Introduction==
# Author - Eoin Keary
# Previous version to be updated:[[https://www.owasp.org/index.php/Code_Review_Introduction]]
'''[[CRV2_Introduction|Content here]]'''

=== What is source code review and Static Analysis ===
=== What is Code Review ===
# Author - Zyad Mghazli, Eoin Keary
# New Section
''' [[CRV2_WhatIsCodeReview|Content here]]'''

=== Manual Review - Pros and Cons ===
# Author - Zyad Mghazli, Eoin Keary,Gary David Robinson
# New Section
# Suggestion: Benchmark of different Stataic Analysis Tools Zyad Mghazli
# [[CRV2_ManualReviewProsCons|Put content here]]

=== Advantages of Code Review to Development Practices ===
# Author - Gary David Robinson
# New Section
# [[CRV2_AdvantagesToDevPractices|Put content here]]

=== Why code review ===
==== Scope and Objective of secure code review ====
# Author - Ashish Rao
# [[CRV2_WhyCodeReview|Put content here]]

=== We can't hack ourselves secure ===
# Author - Eoin Keary
# New Section
# [[CRV2_CantHackSecure|Put content here]]

=== 360 Review: Coupling source code review and Testing / Hybrid Reviews===
# Author - eoin Keary
# New Section
# [[CRV2_360Review|Put content here]]

=== Can static code analyzers do it all? ===
# Author - Ashish Rao
# New Section
# [[CRV2_CanStaticAnalyzersDoAll|Put content here]]

=Methodology=
===The code review approach===
#Author - Open
# [[CRV2_CodeReviewApproach|Put content here]]

==== Preparation and context ====
# Author - Gary David Robinson
# Previous version to be updated: [[https://www.owasp.org/index.php/Code_Review_Preparation]]
# [[CRV2_PrepContext|Put content here]]

====Application Threat Modeling====
#Author - Larry Conklin
# Previous version to be updated: [[https://www.owasp.org/OCRG1.1:Application_Threat_Modeling]]
# [[CRV2_AppThreatModeling|Put content here]]

====Understanding Code layout/Design/Architecture====
#Author - Open
# [[CRV2_CodeLayoutDesignArch|Put content here]]

===SDLC Integration===
#Author - Open
# Previous version to be updated: [[https://www.owasp.org/index.php/Security_Code_Review_in_the_SDLC]]
# [[CRV2_SDLCInt|Put content here]]

====Deployment Models====
=====Secure deployment configurations=====
#Author - Open
# [[CRV2_SecDepConfig|Put content here]]

# New Section
=====Metrics and code review=====
#Author - Open
# Previous version to be updated: [[https://www.owasp.org/index.php/Code_Review_Metrics]]
# [[CRV2_MetricsCodeRev|Put content here]]

=====Source and sink reviews=====
#Author - Open
# New Section
# [[CRV2_SourceSinkRev|Put content here]]

=====Code review Coverage=====
#Author - Open
#Previous version to be updated: [[https://www.owasp.org/index.php/Code_Review_Coverage]]
# [[CRV2_CodeRevCoverage|Put content here]]

=====Design Reviews=====
#Author - Ashish Rao
*Why to review design?
**Building security in design - secure by design principle
**Design Areas to be reviewed
**Common Design Flaws
# [[CRV2_DesignRev|Put content here]]

=====A Risk based approach to code review=====
#Author - Open
#New Section
*"Doing things right or doing the right things..."
**"Not all bugs are equal
# [[CRV2_RiskBasedApproach|Put content here]]

====Crawling code====
#Author - Open
# Previous version to be updated: [[https://www.owasp.org/index.php/Crawling_Code]]
*API of Interest:
**Java
**.NET
**PHP
**RUBY
*Frameworks:
**Spring
**.NET MVC
**Structs
**Zend
#New Section
*Searching for code in C/C++
#Author - Gary David Robinson

# [[CRV2_CrawlingCode|Put content here]]

====Code reviews and Compliance====
#Author -Open
# Previous version to be updated: [[https://www.owasp.org/index.php/Code_Reviews_and_Compliance]]
# [[CRV2_CodeRevCompliance|Put content here]]

=Reviewing by Technical Control=
===Reviewing code for Authentication controls===
#Author - Open
# [[CRV2_AuthControls|Put content here]]

====Forgot password====
#Author Abbas Naderi, Larry Conklin
# [[CRV2_ForgotPassword|Put content here]]

====Authentication====
#Author - Open
# [[CRV2_Authentication|Put content here]]

====CAPTCHA====
#Author Larry Conklin, Joan Renchie
'''[[CRV2_CAPTCHA|Content here]]'''

====Out of Band considerations====
#Author - Open
# Previous version to be updated: [[https://www.owasp.org/index.php/Codereview-Authentication]]
# [[CRV2_OutofBand|Put content here]]

===Reviewing code Authorization weakness===
#Author Eoin Keary .NET MVC added
# [[CRV2_AuthorizationWeaknesses|Put content here]]

====Checking authz upon every request====
#Author - Abbas Naderi
# [[CRV2_CheckAuthzEachRequest|Put content here]]

====Reducing the attack surface====
#Author Open
# Previous version to be updated: [[https://www.owasp.org/index.php/Codereview-Authorization]]
# [[CRV2_ReducingAttSurf|Put content here]]

====SSL/TLS Implementations====
#Author - Eoin Keary
# [[CRV2_SSL-TLS|Put content here]]

====Reviewing code for Session handling====
#Author - Abbas Naderi
# Previous version to be updated: [[https://www.owasp.org/index.php/Codereview-Session-Management]]
# [[CRV2_SessionHandling|Put content here]]

====Reviewing client side code====
#New Section
# [[CRV2_ClientSideCodeIntro|Put content here]]

=====Javascript=====
#Author - Abbas Naderi
# [[CRV2_ClientSideCodeJScript|Put content here]]

=====JSON=====
#Author - Open
# [[CRV2_ClientSideCodeJSon|Put content here]]

=====Content Security Policy=====
#Author - Open
# [[CRV2_ClientSideCodeContSecPolicy|Put content here]]

====="Jacking"/Framing=====
#Author - Eoin Keary
# [[CRV2_ClientSideCodeJackingFraming|Put content here]]

=====HTML 5?=====
#Author - Open
# [[CRV2_ClientSideCodeHTML5|Put content here]]

=====Browser Defenses policy=====
#Author - Open
# [[CRV2_ClientSideCodeBrowserDefPol|Put content here]]

=====etc...=====

====Review code for input validation====
#Author - Open
# [[CRV2_InputValIntro|Put content here]]

=====Regex Gotchas=====
#Author - Open
#New Section
# [[CRV2_InputValRegexGotchas|Put content here]]

=====ESAPI=====
#Author - Open
#New Section
# Internal Link: [[https://www.owasp.org/index.php/Codereview-Input_Validation]]
# [[CRV2_InputValESAPI|Put content here]]

====Reviewing code for contextual encoding====
[[Overall approach to content encoding and anti XSS]]
=====HTML Attribute=====
#Author - Eoin Keary
# [[CRV2_ContextEncHTMLAttribute|Put content here]]

=====HTML Entity=====
#Author - Eoin Keary
# [[CRV2_ContextEncHTMLEntity|Put content here]]

=====Javascript Parameters=====
#Author - Eoin Keary
# [[CRV2_ContextEncJscriptParams|Put content here]]

=====JQuery=====
#Author - Open
# [[CRV2_ContextEncJQuery|Put content here]]

====Reviewing file and resource handling code====
#Author - Open
# [[CRV2_FileResourceHandling|Put content here]]

====Resource Exhaustion - error handling====
#Author - Open
# [[CRV2_ResourceExhaustionErrHandling|Put content here]]

=====native calls=====
#Author Open
# [[CRV2_ResourceExhaustionNativeCalls|Put content here]]

====Reviewing Logging code - Detective Security====
#Author - Open
* Where to Log
* What to log
* What not to log
* How to log
# Internal link: [[https://www.owasp.org/index.php/Logging_Cheat_Sheet]]
# [[CRV2_LoggingCode|Put content here]]

====Reviewing Error handling and Error messages====
#Author - Gary David Robinson
# Previous version to be updated: [[https://www.owasp.org/index.php/Codereview-Error-Handling]]
# [[CRV2_ErrorHandlingMessages|Put content here]]

====Reviewing Security alerts====
#Author - Open
# [[CRV2_SecurityAlerts|Put content here]]

====Review for active defense====
#Author - Colin Watson
# [[CRV2_ActiveDefense|Put content here]]

====Reviewing Secure Storage====
#Author - Open source
# New Section
# [[CRV2_SecureStorage|Put content here]]

====Hashing & Salting - When, How and Where====
=====Encrpyption=====
======.NET======
#Author Larry Conklin, Joan Renchie
# Previous version to be updated: [[https://www.owasp.org/index.php/Codereview-Cryptographic_Controls]]
*''Can we talk about key storage as well i.e. key management for encryption techniques used in the application? - Ashish Rao''
'''[[CRV2_HashingandSaltingdotNet|Content here]]'''

=Reviewing by Vulnerability=
===Review Code for XSS===
#Author Examples added by Eoin Keary
# Previous version to be updated: [[https://www.owasp.org/index.php/Reviewing_Code_for_Cross-Site_Scripting]]
# In reviewing code for XSS - we can give more patterns on "source to sink" patterns for ASP.NET wrf to difference versions and mechanisms to display data in a page - Ashish Rao
# [[CRV2_RevCodeXSS|Put content here]]

===Persistent - The Anti pattern===
#Author
# [[CRV2_RevCodePersistentAntiPatternIntro|Put content here]]

====.NET====
#Author Johanna Curiel, Eoin Keary
# [[CRV2_RevCodePersistentAntiPatterndotNet|Put content here]]

====.Java====
#Author Johanna Curiel
# [[CRV2_RevCodePersistentAntiPatternJava|Put content here]]

====PHP====
#Author Abbas Naderi
# [[CRV2_RevCodePersistentAntiPatternPHP|Put content here]]

====Ruby====
#Author OPen
# [[CRV2_RevCodePersistentAntiPatternRuby|Put content here]]

===Reflected - The Anti pattern===
# [[CRV2_RevCodeReflectedAntiPatternIntro|Put content here]]

====.NET====
#Author Johanna Curiel
# [[CRV2_RevCodeReflectedAntiPatterndotNet|Put content here]]

====.Java====
#Author Johanna Curiel
# [[CRV2_RevCodeReflectedAntiPatternJava|Put content here]]

====PHP====
#Author Abbas Naderi
# [[CRV2_RevCodeReflectedAntiPatternPHP|Put content here]]

====Ruby====
# Author - Open
# [[CRV2_RevCodeReflectedAntiPatternIRuby|Put content here]]

===Stored - The Anti pattern===
# Author - Open
# [[CRV2_RevCodeStoredAntiPatternIntro|Put content here]]

====.NET====
#Author Johanna Curiel
# [[CRV2_RevCodeStoredAntiPatterndotNET|Put content here]]

====.Java====
#Author Johanna Curiel
# [[CRV2_RevCodeStoredAntiPatternJava|Put content here]]

====PHP====
#Author Abbas Naderi
# [[CRV2_RevCodeStoredAntiPatternPHP|Put content here]]

====Ruby====
#Author - Open
# [[CRV2_RevCodeStoredAntiPatternRuby|Put content here]]

===DOM XSS ===
#Author Larry Conklin
# [[CRV2_DOMXSS|Put content here]]

===JQuery mistakes===
#Author
# [[CRV2_JQueryMistakes|Put content here]]

===Reviewing code for SQL Injection===
#Author Open
# Previous version to be updated: [[https://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection]]
# [[CRV2_RevCodeSQLInjection|Put content here]]

====PHP====
#Author - Mennouchi Islam Azeddine
# [[CRV2_SQLInjPHP|Put content here]]

====Java====
#Author - Johanna Curiel
# [[CRV2_SQLInjJava|Put content here]]

====.NET====
#Author - Open
# [[CRV2_SQLInjdotNET|Put content here]]

====HQL====
#Author - Open
# [[CRV2_SQLInjHQL|Put content here]]

===The Anti pattern===
#Author Larry Conklin
#[[CRV2_AntiPattern| Content here]]
https://www.owasp.org/index.php/CRV2_AntiPattern
====PHP====
#Author -
# [[CRV2_AntiPatternPHP|Put content here]]

====Java====
#Author -
#=> Searching for traditional SQL,JPA,JPSQL,Criteria,...
# [[CRV2_AntiPatternJava|Put content here]]

====.NET====
#Author Open
# [[CRV2_AntiPatterndotNet|Put content here]]

====Ruby====
#Author - Open
# [[CRV2_AntiPatternRuby|Put content here]]

====Cold Fusion====
#Author - Open
# [[CRV2_AntiPatternColdFusion|Put content here]]

===Reviewing code for CSRF Issues===
#Author Abbas Naderi
# Previous version to be updated: [[https://www.owasp.org/index.php/Reviewing_Code_for_Cross-Site_Request_Forgery]]
# [[CRV2_CSRFIssues|Put content here]]

===Transactional logic / Non idempotent functions / State Changing Functions===
#Author Abbas Naderi
# [[CRV2_TransLogic|Put content here]]

===Reviewing code for poor logic /Business logic/Complex authorization===
#Author - Open
# [[CRV2_PoorLogic|Put content here]]

===Reviewing Secure Communications===
====.NET Config====
#Author Johanna Curiel, Renchie Joan
# [[CRV2_SecCommsdotNet|Put content here]]

====Spring Config====
#Author - Open
# [[CRV2_SecCommsSpringConfig|Put content here]]

====HTTP Headers====
#Author Open
# [[CRV2_SecCommsHTTPHdrs|Put content here]]

=====CSP=====
#Author Open
# [[CRV2_SecCommsHTTPHdrsCSP|Put content here]]

=====HSTS=====
#Author Open
# [[CRV2_SecCommsHTTPHSTS|Put content here]]

===Tech-Stack pitfalls===
#Author Open
# [[CRV2_TechStackPitfalls|Put content here]]

===Framework specific Issues===
====Spring====
#Author - Open
# [[CRV2_FrameworkSpecIssuesSpring|Put content here]]

====Structs====
#Author - Open
# [[CRV2_FrameworkSpecIssuesStructs|Put content here]]

====Drupal====
#Author Open
# [[CRV2_FrameworkSpecIssuesDurpal|Put content here]]

====Ruby on Rails====
#Author - Open
# [[CRV2_FrameworkSpecIssuesROR|Put content here]]

====Django====
#Author Open
# [[CRV2_FrameworkSpecIssuesDjango|Put content here]]

====.NET Security / MVC====
#Author Johanna Curiel, Eoin Keary
# [[CRV2_FrameworkSpecIssuesdotNetMVC|Put content here]]

====Security in ASP.NET applications====
#Author Johanna Curiel
# [[CRV2_FrameworkSpecIssuesASPNet|Put content here]]

=====Strongly Named Assemblies=====
#Author Johanna Curiel, Larry Conklin
# [[CRV2_FrameworkSpecIssuesASPNetStrongAssembiles|Put content here]]

======Round Tripping======
# Author - Open
# [[CRV2_FrameworkSpecIssuesASPNetRT|Put content here]]

======How to prevent Round tripping======
# Author - Open
#Author Johanna Curiel
# [[CRV2_FrameworkSpecIssuesASPNetRTPrevention|Put content here]]

=====Setting the right Configurations=====
#Author Johanna Curiel
# [[CRV2_FrameworkSpecIssuesASPNetConfigs|Put content here]]

=====Authentication Options=====
#Author Johanna Curiel
# [[CRV2_FrameworkSpecIssuesASPNetAuth|Put content here]]

=====Code Review for Managed Code - .Net 1.0 and up=====
#Author Johanna Curiel
# [[CRV2_FrameworkSpecIssuesASPNetManagedCode|Put content here]]

=====Using OWASP Top 10 as your guideline=====
#Author Johanna Curiel
# [[CRV2_FrameworkSpecIssuesASPTop10|Put content here]]

=====Code review for Unsafe Code (C#)=====
#Author Johanna Curiel
# [[CRV2_FrameworkSpecIssuesASPNetUnsafeCode|Put content here]]

====PHP Specific Issues====
#Author Open
# [[CRV2_FrameworkSpecIssuesPHP|Put content here]]

====Classic ASP====
#Author Johanna Curiel
# [[CRV2_FrameworkSpecIssuesASPClassic|Put content here]]

====C#====
#Author Open
# [[CRV2_FrameworkSpecIssuesCsharp|Put content here]]

====C/C++====
#Author Open
# [[CRV2_FrameworkSpecIssuesCplusplus|Put content here]]

====Objective C====
#Author Open
# [[CRV2_FrameworkSpecIssuesObectiveC|Put content here]]

====Java====
#Author Open
# [[CRV2_FrameworkSpecIssuesJava|Put content here]]

====Android====
#Author Open
# [[CRV2_FrameworkSpecIssuesAndroid|Put content here]]

====Coldfusion====
#Author Open
# [[CRV2_FrameworkSpecIssuesColdfusion|Put content here]]

====CodeIgniter====

# Author Open
# [[CRV2_FrameworkSpecIssuesCodeIgniter|Put content here]]

=Security code review for Agile development=
#Author Carlos Pantelides
# [[CRV2_CodeReviewAgile|Put content here]]

=Code Review Tools=
https://www.owasp.org/index.php/CRV2_CodeReviewTools

CRV2 360Review

2013-12-12T15:13:17Z

EoinKeary:

== 360 Reviews - outside-in & inside-out ==
The term 360 degree reivews some from coupling source code review and dynamic testing. 
Dynamic testing is in effect runtime penetration testing. It can also be ferered to as hybrid testing. 

As mentioned in previous sections source code review can assess an application of issues which may otherwise be difficult to assess. 
Issues such as information leakage, logging of sensitive data, privacy and other items in relation to general good-health of an application may have significant impact in terms of regulatory compliance. 
Assessing the cryptographic controls is suited well for sourec code review but testing authentication functionality is easier to deliver via dynamic testing. 
When perfroming a penetration test it is very valueable if one can map a discovered vulnerability or parameter to a class file or script in the application source code. 
such mapping assists the developer in both understanding and addressing the issue. 

'''Pen Testing Pros'''

*Requires less specialized expertise
*Easier setup
*Easier to perform
*Exercises the entire app infrastructure
*Proves vulnerabilities

'''Code Review Pros'''

*Assess all the content
*Discover all instances of certain types of flaws
*Verify controls are correct (Positive Security)
*Verify controls are used in all the required places (Positive Security)

Combining them together gives a better overall view of the security posture of the application.

CRV2 360Review

2013-12-12T15:13:00Z

EoinKeary:

== 360 Reviews - outside-in & inside-out ==
The term 360 degree reivews some from coupling source code review and dynamic testing. 
Dynamic testing is in effect runtime penetration testing. It can also be ferered to as hybrid testing. 

As mentioned in previous sections source code review can assess an application of issues which may otherwise be difficult to assess. 
Issues such as information leakage, logging of sensitive data, privacy and other items in relation to general good-health of an application may have significant impact in terms of regulatory compliance. 
Assessing the cryptographic controls is suited well for sourec code review but testing authentication functionality is easier to deliver via dynamic testing. 
When perfroming a penetration test it is very valueable if one can map a discovered vulnerability or parameter to a class file or script in the application source code. 
such mapping assists the developer in both understanding and addressing the issue. 

'''Pen Testing Pros'''

*Requires less specialized expertise
*Easier setup
*Easier to perform
*Exercises the entire app infrastructure
*Proves vulnerabilities

'''Code Review Pros'''

*Assess all the content
*Discover all instances of certain types of flaws
*Verify controls are correct (Positive Security)
*Verify controls are used in all the required places (Positive Security

Combining them together gives a better overall view of the security posture of the application.

CRV2 360Review

2013-12-12T14:42:41Z

EoinKeary:

CRV2 360Review

2013-12-12T14:42:14Z

EoinKeary: Created page with " == 360 Reviews - outsidein & inside out == The term 360 degree reivews some from coupling source code review and dynamic testing. Dynamic testing is in effect runtime pen..."

== 360 Reviews - outsidein & inside out ==
The term 360 degree reivews some from coupling source code review and dynamic testing. 
Dynamic testing is in effect runtime penetration testing. It can also be ferered to as hybrid testing. 

As mentioned in previous sections source code review can assess an application of issues which may otherwise be difficult to assess. 
Issues such as information leakage, logging of sensitive data, privacy and other items in relation to general good-health of an application may have significant impact in terms of regulatory compliance. 
Assessing the cryptographic controls is suited well for sourec code review but testing authentication functionality is easier to deliver via dynamic testing. 
When perfroming a penetration test it is very valueable if one can map a discovered vulnerability or parameter to a class file or script in the application source code. 
such mapping assists the developer in both understanding and addressing the issue.

CRV2 ManualReviewProsCons

2013-12-12T14:29:24Z

EoinKeary: /* Manual Review - Pros and Cons */

= Manual Review - Pros and Cons =

Manual review is sited when a risk based approach to the code review is required.
Risk based code review works by.

1. Identification of the trust boundaries in the code.
2. Identification of data paths and storage classes.
3. Identification of authorisation components.
4. Identification of authentication components.
5. Review of input validation and encoding methods.
6. Review of logging components.

Manual review is good for :

Data leakage detection
Resource usage/exhaustion detection
Business Logic review*
Denial of service
Deep Dive review

'''Not so good for:'''
Business Logic review*
Level of coverage

== Choosing a static analysis tool ==

Choosing a static analysis tool is a difficult task since there are a lot of choices. The comparison charts below should help you decide which tool is right for you. This list is not exhaustive.
The first thing to do is to look to for a tool that supports the programming language of your choice. You also have to decide whether you want a commercial tool or a free one. Usually the commercial tools have more features and are more reliable than the free ones. The major commercial tools are equally effective but their usability might differ. Next, there is the type of analysis you are looking for: Security or Quality, Static or Dynamic analysis. You should also check the compatibility of the tool with your programming environment.
This was the easy part to narrow the choice down to a few tools. The next step requires you to do some work since it is quite subjective. The best thing to do is to test a few tools to see if you are satisfied with different aspects such as the user experience, the reporting of vulnerabilities, the level of false positives, the customization, the customer support… The choice should not be based on the number of features, but on the features that you need and how they could be integrated in your SDLC. Also, before choosing the tool, the security expertise of the targeted users should be clearly evaluated in order to choose an appropriate tool.

=== '''Free static analysis tools''' ===

[[File:Free_static_analysis_tools.png]]
[[File:Legend_free_static_analysis_tools.png]]

=== '''Commerical static analysis tools''' ===

[[File:Commercial_static_analysis_tools.png]]
[[File:Legend Commercial static analysis tools.png]]

[[File:Owasp_Benchmark_Static_analysis_tools.pptx]]

File:MASTER-RSA2013.pdf

2013-10-29T07:44:27Z

EoinKeary: Slide from RSA Europe training class. - Amsterdam 2013

Slide from RSA Europe training class. - Amsterdam 2013

CRV2 ContextEncJscriptParams

2013-10-21T13:43:55Z

EoinKeary:

Untrusted data, if being placed inside a Javascript function/code requires validation.
Unvalidated data may break out of the data context and wind up being executed in the code context on a users browser.

'''Examples of exploitation points (sinks) which are worth reviewing for:'''

<script>var currentValue=''''UNTRUSTED DATA'''';</script>
<script>someFunction(''''UNTRUSTED DATA'''');</script>
attack: ');'''/* BAD STUFF */'''

'''Potential solutions:'''

[https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project OWASP HTML sanatiser Project] 
[https://www.owasp.org/index.php/OWASP_JSON_Sanitizer OWASP JSON Sanitizer Project]

ESAPI javascript escaping can be call in this manner:
String safe = ESAPI.encoder().encodeForJavaScript( request.getParameter( "input" ) );

'''Please note there are some JavaScript functions that can never safely use untrusted data as input - EVEN IF JAVASCRIPT ESCAPED!'''

For example:

<script>
window.setInterval('...EVEN IF YOU ESCAPE UNTRUSTED DATA YOU ARE XSSED HERE...');
</script>

'''eval()'''
var txtField = "A1";
var txtUserInput = "'test@google.ie';'''alert(1);'''";
'''eval'''( "document.forms[0]." + txtField + ".value =" + A1);

'''jquery'''
var txtAlertMsg = "Hello World: ";
var txtUserInput = "test<script>alert(1)<\/script>";
$("#message").'''html'''( txtAlertMsg +"" + txtUserInput + "");

Safe usage (use text, not html)
$("#userInput").'''text'''( "test<script>alert(1)<\/script>");<-- treat user input as text

'''Nested Contexts'''
Best to avoid such nested contexts: an element attribute calling a Javascript function etc
These contexts can really mess with your mind.

<div onclick="showError('<%=request.getParameter("errorxyz")%>')" >An error occurred ....</div>

'''Here we have a HTML attribute(onClick) and within a nested Javascript function call (showError).'''

When the browser processes this it will first HTML decode the contents of the onclick attribute.
It will pass the results to the JavaScript Interpreter.
So we have 2 contextx here...HTML and Javascript (2 browser parsers).
We need to apply “layered” encoding in the RIGHT order: 
'''1) JavaScript encode''' 
'''2) HTML Attribute Encode so it "unwinds" properly and is not vulnerable'''. 

<div onclick="showError
('<%= Encoder.encodeForHtml(Encoder.encodeForJavaScript( request.getParameter("error")%>')))"
>An error occurred ....</div>

CRV2 ContextEncJscriptParams

2013-10-21T13:43:34Z

EoinKeary:

Untrusted data, if being placed inside a Javascript function/code requires validation.
Unvalidated data may break out of the data context and wind up being executed in the code context on a users browser.

'''Examples of exploitation points (sinks) which are worth reviewing for:'''

<script>var currentValue=''''UNTRUSTED DATA'''';</script>
<script>someFunction(''''UNTRUSTED DATA'''');</script>
attack: ');'''/* BAD STUFF */'''

'''Potential solutions:'''

[https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project OWASP HTML sanatiser Project] 
[https://www.owasp.org/index.php/OWASP_JSON_Sanitizer OWASP JSON Sanitizer Project]

ESAPI javascript escaping can be call in this manner:
String safe = ESAPI.encoder().encodeForJavaScript( request.getParameter( "input" ) );

'''Please note there are some JavaScript functions that can never safely use untrusted data as input - EVEN IF JAVASCRIPT ESCAPED!'''

For example:

<script>
window.setInterval('...EVEN IF YOU ESCAPE UNTRUSTED DATA YOU ARE XSSED HERE...');
</script>

'''eval()'''
var txtField = "A1";
var txtUserInput = "'test@google.ie';'''alert(1);'''";
'''eval'''( "document.forms[0]." + txtField + ".value =" + A1);

'''jquery'''
var txtAlertMsg = "Hello World: ";
var txtUserInput = "test<script>alert(1)<\/script>";
$("#message").'''html'''( txtAlertMsg +"" + txtUserInput + "");

Safe usage (use text, not html)
$("#userInput").'''text'''( "test<script>alert(1)<\/script>");<-- treat user input as text

'''Nested Contexts'''
Best to avoid such nested contexts: an element attribute calling a Javascript function etc
These contexts can really mess with your mind.

<div onclick="showError('<%=request.getParameter("errorxyz")%>')" >An error occurred ....</div>

'''Here we have a HTML attribute(onClick) and within a nested Javascript function call (showError).'''

When the browser processes this it will first HTML decode the contents of the onclick attribute.
It will pass the results to the JavaScript Interpreter.
So we have 2 contextx here...HTML and Javascript (2 browser parsers).
We need to apply “layered” encoding in the RIGHT order:
'''1) JavaScript encode''' 
'''2) HTML Attribute Encode so it "unwinds" properly and is not vulnerable'''. 

<div onclick="showError
('<%= Encoder.encodeForHtml(Encoder.encodeForJavaScript( request.getParameter("error")%>')))"
>An error occurred ....</div>