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