Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation OWASP IISF Secure development (for a secure planet) Eoin Keary OWASP Board member Senior Manager, Ernst & Young

OWASP IISF 2010 ME Leader within OWASP since 2002 OWASP Global Board member OWASP Testing Guide OWASP Code Review Guide OWASP Irish chapter founder A&P Senior Manager: Ernst & Young Application Developer & Application Security: 12 Years

OWASP IISF 2010 OWASP – What’s it all about 3 OWASP is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security visible so that people and organizations can make informed decisions about application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license. The OWASP Foundation is a 501c3 not-for-profit charitable organization that ensures the ongoing availability and support for our work.

OWASP IISF OWASP Supporters

OWASP IISF 2010 The ISSUE…  More and More application level issues……  Sept/Oct 2008 – SQL Injection $9,000,000 in 24 Hours (RBS)  Business Logic Exploited in US Army Servers – May, 2009  HSBC and Barclays sites were both hit by major XSS vulnerabilities - June 2009  The Telegraph site was exposed by a severe SQL injection vulnerability - June “In the last five years, approximately 500 million records containing personal identifying information of United States residents stored in government and corporate databases was either lost or stolen.” - “

OWASP IISF 2010 Things are not improving  Eg: XSS was discovered circa 1996  Initially is was a curiosity  Evolved to an exploit  Further evolution to a worm  MySPACE- SAMMY WORM 2005, first self propagating xss worm  Wide scale problem, 13 years later!  Toolkits: Mpack, LuckySploit, ISR-Evilgrade etc  Attacking the client: Phisihing, Malware Upload  Ironically easy to fix and detect but 60%-70% of sites are vulnerable.. 6

OWASP IISF 2010 What’s in your application?  Application Code is like sausages: 7 SausageCode “Taste nice”Apps Look Nice FillingFulfil requirement We don’t want to know what's in them, or how they are made!!!! Same with code!!!!! Currently software QA (Unit, System, Integration, UAT) tests what software can do, not what we can make it do!!!! Negative Testing is still not commonplace within the SDLC but ironically easy to do!

OWASP IISF 2010 Where is your Application Perimeter?  Border Router?  WAF/Firewall?  Public facing – Authentication Page  Software food chain?  Lets look at this for a sec:  Where does your code come from? Who wrote it? How do I know its secure / developed in a secure manner? 8

OWASP IISF 2010 Software food chain 9 Application Code COTS (Commercial off the shelf Outsourced development Sub- Contractors Bespoke outsourced development Bespoke Internal development Third Party API’s Third Party Components & Systems Degrees of trust You may not let some of the people who have developed your code into your offices!! “More”“Less”

OWASP IISF 2010 How do we (attempt) to fix this problem?  Secure Software development  Application Security Testing (Manual, Automated)  Code review (Automated, Manual) 10 CHALLENGES FACING HUMANITY Make solar energy affordable Provide energy from fusion Develop carbon sequestration Manage the nitrogen cycle Provide access to clean water Reverse engineer the brain Prevent nuclear terror Secure cyberspace Enhance virtual reality Improve urban infrastructure Advance health informatics Engineer better medicines Advance personalised learning Explore natural frontiers

OWASP IISF 2010 Solutions 11

OWASP IISF Philosophy of Secure Development  Security = F (Quality)  Write code "properly"!!  Adhere to business requirements and no more!!  "Is it a business requirement that I can access other users data”  Negative use case/testing  Lets forget XSS, SQLI CSRF for a minute.  There are easier ways to commit fraud than this:  Breaking business Logic  Breaking authorisation logic  Breaking arithmetic logic  They require less technical skill but can be very powerful and automated tools do not detect such issues. Design Goals: “Security at source” “Self-defending/aware applications” Fulfill business requirements and nothing more, nothing less.

OWASP IISF Philosophy of Secure Development  Security Touch-Points (Design, Development, Test, Deployment)  Catch issues before they go live – Runtime & Static Analysis  Overall Improvement in quality: Stability, Reliability, Security Probably the cheapest solution in the long term: Lower TCO & risk of compromise, overall better quality

OWASP IISF 2010 Software security tollgates in the SDLC Requirements and use cases DesignTest plans Code Test results Field feedback Security requirements Risk analysis Risk-based security tests Static analysis (tools) Penetration testing Design Review Iterative approach Manual Code Review What do we need to test, And how? Code review tools

OWASP IISF Application Security Verification Techniques – Check out the OWASP ASVS Find Vulnerabilities Using the Running Application (Outside-In) Find Vulnerabilities Using the Source Code (Inside-Out) Automated Application Vulnerability Scanning Automated Static Code Analysis Manual Application Penetration Testing Manual Security Code Review

OWASP IISF °/Greybox Testing – Pros & Cons 16

OWASP IISF 2010 Runtime Testing  Automated ( “Wide but not Deep” )  Good:  Detecting technical vulnerabilities: –XSS, SSI, SQLI, Buffer Overflows  Produce good coverage in a limited time (if lucky!)  Cost effectiveness  Bad:  Does not detect business logic issues very well  False sense of security  False Positives & (worse) False Negatives  Can Fail with complex flows or rich client apps (Web 2.0, Legacy)  Non Standard environments, Can be fooled.  Business impact identification. 17  Manual ( “Deep but less wide” )  Good:  Detecting technical vulnerabilities: –XSS, SSI, SQLI, Buffer Overflows……  Contextual aspects, critical business focus  Detecting business logic issues  More Accurate  Allows for creativity to identify non standard variants (E.g. “Persisted XSS”)  Bad:  Time limited coverage, variant coverage (attack vectors)  Tester skill dependant ( think about OWASP ASVS )  Can be expensive

OWASP IISF 2010 Lets look at Code review 18

OWASP IISF 2010 Code Review (Static Analysis)  Automated  Good:  Generally good (no crawling setbacks)  High accuracy in identifying code violations (not necessarily security violations)  Fast and more cost effective  Bad:  Logical Vulnerabilities  Runtime binding/relationships not apparent  Issues are signature based, may not detect many variants  External compensating controls not apparent.  High rate of false positives  Problematic when not all code available 19  Manual  Good:  Generally good with technical vulnerabilities  Somewhat limited but better with logical vulnerabilities  Potentially excellent if performed properly, –Can detect Denial of Service, Privacy & Audit issues –Can detect potential backdoors, root-kits & malware  Bad:  Slow and relatively expensive. (Critical apps only?!)  Poorly written code (think sausage) can be difficult to review

OWASP IISF 2010 Code review  Authorisation logic  Insecure code: No authorisation code = No code [to review]  No code = tool has no issue to report  No issue to report = secure code!! [clean report]  Horizontal Authorisation (User Authorisation) –A user can not view, manipulate or deny access another user’s [of the same role] data.  Vertical Authorisation ( Role Authorisation) –A user can not perform any action outside their role. 20  Business Logic:  Transactions: –Any transactional function which does not require re-authentication is potentially vulnerable to CSRF –Requires a workflow decision: Tools don’t understand business workflow  Mathematical controls: –Negative values –Limits –Conversion rates  Data Transfer –Funds transfer: source and destination accounts (Logic) –Data size Key weakness with Automated Code review

OWASP IISF  Password Complexity:  Unless complexity logic is hard coded; –RegEx stored in configuration file –Runtime binding to file: static analysis tools wont see this Code review Key weakness with Automated Code review

OWASP IISF Tools – At Best 45%! (SAMATE-2009)  MITRE (US Gov research foundation) found that all application security tool vendors’ claims put together cover only 45% of the known vulnerability types (695)  They found very little overlap between tools, so to get 45% you need them all (assuming their claims are true)

OWASP IISF 2010 Solution: No single answer  Both Runtime testing and Static Analysis have their strengths and weaknesses. – we probably need to use both (360 Analysis)  Simple authorisation and business logic verification is often overlooked.  Most effective approach is to attempt to build secure code during the SDLC. Third-party verification services; “How do I measure my return on investment?”………OWASP ASVS!! 23

OWASP IISF 2010 Challenges…  There is a huge range in coverage and rigor available in the application security verification market!  “We did a security assessment” ;  Consumers have no way to tell the difference between:  Someone running a grep tool, and  Someone doing painstaking code review and manual testing!  Security FUD, Snake Oil, Skill of Assessor. 24 There are differences in coverage and rigor between types of tools, between tools and manual techniques, and between types of manual techniques!

OWASP IISF Philosophy of ASVS  It is intended as a standard for how to verify the security of web applications  It should be application- independent  It should be development life- cycle independent  It should define requirements that can be applied across web applications without special interpretation Any such standard also needs to be commercially-viable and therefore not overly burdensome! Design Goals: The standard should define increasing levels of application security verification The difference in coverage and level of rigor between levels should be relatively linear The standard should define functional verification requirements that take a white- list (i.e., positive) approach The standard should also be verification tool and technique independent!

OWASP IISF What Questions Does ASVS Answer?  What security features should be built into the required set of security controls?  What are reasonable increases in coverage and level of rigor when verifying the security of a web application?  How can I compare verification efforts?  How much trust can be placed in a web application? ASVS can answer these questions for applications ranging from minimum risk applications, to critical infrastructure applications. A Success Story: Application Security Verification Standards are specifications produced by OWASP in cooperation with secure applications developers and verifiers worldwide for the purpose of accelerating the deployment of secure web applications. First published in 2008 as a result of an OWASP Summer of Code grant and meetings with a small group of early adopters, the ASVS documents have become widely referenced and implemented.

OWASP IISF What are ASVS Verification Levels?

OWASP IISF Level 1  Automated verification of a web application treated as groups of components within single monolithic entity

OWASP IISF Level 2  Manual verification of a web application organized into a high-level architecture.

OWASP IISF Level 3  Level 2 + Threat modeling information to verify design (Secure Architecture)

OWASP IISF Level 4  Internal verification of a web application by searching for malicious code (not malware) and examining how security controls work.

OWASP IISF 2010 Verification Requirements Various levels have different technical verification requirements. This is due to the additional effort and rigor of level 4 compared to level 1 and all in- between. Verification requirements are prescriptive such that fulfilling them helps to achieve a level of verification. V1. Security Architecture V2. Authentication V3. Session Management V4. Access Control V5. Input Validation V6. Output Encoding/Escaping V7. Cryptography V8. Error Handling and Logging V9. Data Protection V10. Communication Security V11. HTTP Security V12. Security Configuration V13. Malicious Code Search V14. Internal Security Verification Requirement Level 1A Level 1B Level 2A Level 2B Level 3 Level 4 V1.1 Verify that all application components (either individual or groups of source files, libraries, and/or executables) that are present in the application are identified. V1.1 Verify that all components that are not part of the application but that the application relies on to operate are identified. V1.1 Verify that a high-level architecture for the application has been defined. [1] [1] V1.1 Verify that all application components are defined in terms of the business functions and/or security functions they provide. V1.1 Verify that all components that are not part of the application but that the application relies on to operate are defined in terms of the business functions and/or security functions they provide. V1.1 Verify that threat modeling information has been provided. Example Security Architecture Documentation Requirements

OWASP IISF 2010 How do I get started using ASVS?  Buyer and seller: agree how technical security controls will be verified by specifying a level from 1 to 4  Perform an initial verification of the application 33 Using ASVS requires planning and in that respect is just like any other testing exercise! This is where ASVS can be used Educate and Collect Perform Initial Verification This is where the Contract Annex can be used to specify an ASVS level Here is where you find out if your application has vulnerabilities such as Cross-Site Scripting(XSS),SQL injection,CSRF,etc. The OWASP ASVS, OWASP Contract Annex, and OWASP ESAPI can be used to support your Software Development Life Cycle (SDLC).

OWASP IISF Integrating ASVS into your SDLC (Outsourcing not required)

Questions Questions