Application Security & Verification Requirements David Jones July 2014 This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. Contains content Copyright © 2008 – 2013 The OWASP Foundation. Application security for custom development projects is a challenge. Working with customers to determine security requirements and balancing competing demands on a project’s budget is made more difficult when there is lack of rigorous experience amongst developers with implementing secure solutions. Graded levels of security verification requirements provide a potential way to work with customers while providing the development team with a clear and directed approach to implementation and verification of the security of a system. Application Security & Verification Requirements 1. Security Headlines 2. Verification Requirements Using ASVS 3. Common Web Security Risks 4. Next Steps Application Security & Verification Requirements 1. Security Headlines 2. Verification Requirements Using ASVS 3. Common Web Security Risks 4. Next Steps How well are internet technology firms doing? Adobe Breach Impacted At Least 38 Million Users …The recent data breach at Adobe that exposed user account information and prompted a flurry of password reset emails impacted at least 38 million users, the company now says. It also appears that the already massive source code leak at Adobe is broadening to include the company’s Photoshop family of graphical design products… Skype users warned of serious security problem accounts can be hijacked with ease …The Next Web describes how it managed to reproduce the attack, accessing the Skype accounts of staff by just knowing their email address, and then changing the passwords of their "victims" to lock them out… Microsoft rushes out fix after hackers reset passwords to hack Hotmail accounts …News of the critical bug spread rapidly across underground hacking forums, and Whitec0de reported earlier this week that hackers were offering to break into any Hotmail account for as little as $20… Cisco warns of big remote management hole in tiny routers …In simple English, that means a crook could connect to your router via HTTPS and, without entering a username or password, take it over… OpenSSL Heartbleed …Heartbleed sees first arrest in wake of Canada Revenue Agency breach… Apple HTTPS “goto fail” …When you update, be sure to follow the advice below about avoiding insecure networks. The Software Update app uses the buggy Security library!… NSA grabbing Cisco shipments en route to be loaded up with physical spyware before they reach the end user What about non-technology companies? • Man pleads guilty to bank fraud, 48-hour global operation netted $14 million • Code Spaces shuts down following DDoS extortion, deletion of sensitive data • Small businesses running cloud-based POS software hit with unique 'POSCLOUD' malware • Home Depot staffers arrested, stole employee info and opened fraudulent credit cards • Lowe's employee info accessible online for about 10 months • Computers stolen, health data compromised for 168K in L.A. • Web crawlers tap data, put about 146K Indiana Univ. students at risk • Phishing scam lures three Calif. physicians, patient data compromised • Virginia county school data accidentally posted online It seems anyone can fail… • Even the best funded and capable internet companies can fail with security. • Smaller companies also struggle and they can also experience targeted attacks. • Threats can come from staff as well as from external/network sources. • Some of these failures could have been detected with a reasonably thorough development and release process. Application Security & Verification Requirements 1. Security Headlines 2. Verification Requirements Using ASVS 3. Common Web Security Risks 4. Next Steps The primary aim of the OWASP Application Security Verification Standard (ASVS) is to normalize the range in the coverage and level of rigour available in the market when it comes to performing web application security verification. The ASVS standard provides a basis for testing application technical security controls, as well as any technical security controls in the environment, that are relied on to protect against vulnerabilities such as Cross-Site Scripting (XSS) and SQL injection. This standard can be used to establish a level of confidence in the security of Web applications. 1 The standard defines over one hundred security verification requirements. An example security requirement from the Session management area: ! V2.2 Verify that sessions are invalidated when the user logs out.! The rationale for the verifications are not included in the standard, however, they are all based on common threats and security approaches, which can be found in other online resources. The requirements can be manually tested, and in some cases automatically verified through static analysis, penetration testing or functional tests. V1. Authentication V8. Communication Security V2. Session Management V9. HTTP Security V3. Access Control V10. Malicious Controls V4. Input Validation V11. Business Logic V5. Cryptography (at Rest) V12. Files and Resources V6. Error Handling and Logging V13. Mobile V7. Data Protection Different threats have different motivations, and some industries have unique information and technology assets as well as regulatory compliance requirements. Although some unique criteria and some differences in threats exist for each industry, a common theme throughout all industry segments is that opportunistic attackers will look for any vulnerable applications reachable through the Internet, which is why ASVS Level 1 is recommended for all Internet-accessible applications regardless of industry. How could this be used? • Collaborating with the customer early in the engagement to identify which of the three requirement levels best matches the risks and expectations of the solution. • Consideration of the identified security requirements during the formative technical design and architecture. • More rigorous security verification during story DAT and acceptance testing. • And a way to deepen the knowledge of practical security skills throughout the course of the project. Application Security & Verification Requirements 1. Security Headlines 2. Verification Requirements Using ASVS 3. Common Web Security Risks 4. Next Steps The ASVS Verification Requirements opens the door to identifying a security level of an application with the customer and a way to confirm it was reached. How can this be implemented in code when the development staff have a mix of experience implementing secure solutions? The OWASP Top 10 for 2013 is based on data that spans over 500,000 vulnerabilities across hundreds of organizations and thousands of applications. The Top 10 items are selected and prioritized according to this prevalence data, in combination with consensus estimates of exploitability, detectability, and impact estimates. The primary aim of the OWASP Top 10 is to educate developers, designers, architects, managers, and organizations about the consequences of the most important web application security weaknesses. The Top 10 provides basic techniques to protect against these high risk problem areas – and also provides guidance on where to go from here. The Top 10 critical web security risks are represented at the Application Security Verification Standard (ASVS) Level 2 Standard. SQL Injection using JPA String empId= req.getParameter(“empId"); q = entityManager.createQuery(“select e from Employee e WHERE ” + “e.id = '” + empId + “‘”); Expected URL: /api/employees?empId=123 Injection Example: /api/employees?empId=123’ or ‘a’=‘a The SQL query will return details for all employees rather than a single employee. Named Parameters is one way to protect against SQL Injection With JPA or Hibernate you should use Named Parameters. Named parameters are parameters in a query that are prefixed with a colon (:). Named parameters in a query are bound to an argument by the javax.persistence.Query.setParameter(String name, Object value) method. For example: q = entityManager.createQuery(“select e from Employee e WHERE ” + “e.id = ':id'”); q.setParameter(“id”, empId); This sets the id to the empId in the SQL command and any dangerous characters should be automatically escaped by the JDBC driver. ! https://blogs.oracle.com/carolmcdonald/entry/owasp_top_10_number_2 Application Security & Verification Requirements 1. Security Headlines 2. Verification Requirements Using ASVS 3. Common Web Security Risks 4. Next Steps How could you apply verification requirements on your current project? • Identify which of the three verification levels (Opportunistic, Standard, or Advanced) best match the needs of your current project. Use the industry segment descriptions to guide you. The standard PDF includes some additional segments. • Which verification requirements in Level One (Opportunistic) apply to your current development story? • Test each of the verification requirements of Level One (Opportunistic) against your current system. For each failed requirement consider whether they should be added to your project’s backlog of work. • Can you explain the rationale for the inclusion of the Level One and Level Two verification requirements? Use the Top 10 list and other online resources to help you. • Can you automate the verification of any of the requirements that seem significant to your project? Consider also using static analysis tools, for example those that come with Sonar as well as third party tools. Application Security & Verification Requirements 1. Security Headlines 2. Verification Requirements Using ASVS 3. Common Web Security Risks 4. Next Steps ! Questions? Appendix - Resources A. Resources • • OWASP Application Security Verification Standard Project • https://www.owasp.org/index.php/ Category:OWASP_Application_Security_Verification_Standard_Project • ASVS 2.0 beta used by presentation • Creative Commons Attribution ShareAlike 3.0 OWASP Top Ten 2013 • https://www.owasp.org/index.php/Top10#OWASP_Top_10_for_2013 • Creative Commons Attribution ShareAlike 3.0 Appendix - A9 Components with Vulnerabilities B. Components with vulnerabilities • 88% of code in today’s applications come from libraries and frameworks • 31 most popular Java frameworks/libs – 26% had known vulnerabilities Dependency-Checker Tool • Dependency-check scans directories and files and if it contains an Analyzer that can scan a particular file type then information from the file is collected. This information is then used to identify the Common Platform Enumeration (CPE). If a CPE is identified a listing of associated Common Vulnerability and Exposure (CVE) entries are listed in a report • Analyzes Java & .Net libraries • Triggered by CLI, Ant Task, Maven Plugin, and Jenkins plugin ! https://github.com/jeremylong/DependencyCheck