Joachim Van der Auwera
ASVS
in a business application
Who am I
Disclaimer
ASVS v2
Application Security Verification Standard
The primary aim of the OWASP Application Security Verification
Standard (ASVS) is to normalize the range in the coverage and level
of rigor available in the market when it comes to performing web
application security verification.
OWASP
Why ?
Who knows OWASP?
OWASP -> Open Web Application Security Project Improve
security of software Make software security visible -> informed
decisions about true software security risks
ASVS -> practical reference to think about security
Questions -> raise hand personal opinion - discuss
Four levels
Cursory : optional, some kind of verification, custom
requirements
Opportunitic Requirements can be verified using minimal-to-low
effort Protection against simple attacks or easy-to-exploit
vulnerabilities
Standard Includes OWASP Top 10 and business logic sensitive
applications, b2b applicatons
Advanced Include more difficult to exploit vulnerabilities
Protect against determined attackers - also check design, reqs + -
security stuff (cross cutting) -> centralized implementation -
all validation should use whitelist approach - input validation
only second line of defense, parameterization and output encoding
is first Critical app, life and safety, substantial damage,
sensitive assets
Scope + The code for the application or release needs to comply
with req Frameworks/libraries/services verification is optional (+)
certification when checking those Not all reqs applicable as no
code available -
Level for each verification
13 security areas
Various requirements for each area, each indicates with the
levels at which the requirement needs to be met
190 requirements, of which 54 at level 1
Verify
[ver-uh-fahy]1. to prove the truth of, as by evidence or
testimony; confirm; substantiate: Events verified his prediction.2.
to ascertain the truth or correctness of, as by examination,
research, or comparison: to verify a spelling.3. to act as ultimate
proof or evidence of; serve to confirm.4. Law. to prove or confirm
(an allegation). to state to be true, especially in legal use,
formally or upon oath.
All requirements use Verify... wording.
Automated testing is not enough.Trusting your developers is not
enough.Trusting the libraries / frameworks / tooling is not
enough
Authentication
Verify all pages/resources require authentication except
specific
Verify that all authentication decisions are logged
Verify all account password are salted account specific and use
bcrypt, scrypt or PBKDF2 before storing
Credentials and identity information should not traverse
un/weakly encrypted links
No clear text password sent to user
Username enumeration not possible in login/reset/forgot
account
No default passwords (e.g. admin/password)
1
2
3
1
2
2
1
1
1
1
Authentication continued
Verify password entry fields allow or encourage the use of
passphrases, and do not prevent long passphrases or highly complex
passwords being entered, and provide a sufficient minimum strength
to protect against the use of commonly chosen passwords.
Forget password should not lock account
No shared knowledge questions/answers (secret questions)
Allow configuration to disallow x previous passwords
Require two-factor authentication as per risk profile
1
2
3
2
2
2
2
3
Session Management
Verify that sessions timeout after a certain period of
inactivity
Session timeout after (config) maximum time regardless of
activity
Session id never disclosed other than in cookie headers. No URL
rewriting of session cookies.
Verify session id is changed upon re-authentication
Session tokens should be sufficiently long and random to prevent
guessing attacks
Cookie path should be restrictive, domain not set (unless for
business requirement like SSO)
HttpOnly should be set on cookie, Secure set when using
https
No duplicate concurrent users originating from different
machines
1
2
3
1
2
1
2
2
2
1
2
Acces Control
Users can only access functions or services for which they
possess specific authorization
Verify directory browsing disabled unless deliberately
desired
All access controls are enforced on the server side
User, data, policy information used by access controls cannot be
manipulated unless specifically authorized
Log all access control decisions (success and failure)
Require use of strong CSRF tokens
Aggregate access control protection e.g. throttle requests to
prevent the entire database from being scraped by an individual
user.
1
2
3
1
1
1
2
2
1
2
RESTEasy interceptor
@Component@Provider@ServerInterceptorpublic class
SecurityPreProcessInterceptor implements ContainerRequestFilter
{
@Override public void filter( ContainerRequestContext
requestContext) throws IOException { // .... }
}
Require access annotation
if (requestContext instanceof PostMatchContainerRequestContext)
{ PostMatchContainerRequestContext pmcrc = (PostMatch...)
requestContext; Annotation[] annotations =
pmcrc.getResourceMethod().getMethodAnnotations(); if
(!contains(annotations, PermitAll.class)) { if
(contains(annotations, RolesAllowed.class)) { RolesAllowed ra =
get(annotations, RolesAllowed.class);
checkUserHasRole(requestContext, ra.value()); } else { throw new
AuthException("Missing security + constraints on endpoint. " +
pmcrc.getResourceMethod().getMethod()); } }}
Malicious Input Handling
Verify all input validation or encoding done server side
Log all input validation failures
No SQL, LDAP, OS command injection
All untrusted data output as HTML should be escaped
Verify defenses against HTTP parameter pollution attacks
1
2
3
1
3
1
1
2
Cryptography at Rest
All cryptographic functions to protect secrets done server
side
Cryptographic modules validated agains FIPS 140-2 or an
equivalent standard
Verify there is a policy for managing cryptographic keys. Verify
that policy is properly enforced.
1
2
3
2
3
2
Error Handling and Logging
No sensitive data in error messages or stack traces (including
session id or sensitive information)
Verify that all authentication decisions are logged
Each log event should include timestamp, severity, indication if
security relevant (in mixed logs), identity, request IP address,
success/failure, description
Do not log sensitive data that can help an attacker. Presence
and length may be logged.
Log before executing a transaction, if logging fails the
application fails safely. Important for integrity and
non-repudiation.
1
2
3
1
2
2
3
2
Data Protection
Disabled client-side caching and autocomplete for sensitive
fields
Sensitive data in HTTP body (not request parameters)
Ensure proper caching of sensitive data
Minimize number of parameters sent to untrusted systems e.g.
hidden fields, cookies, ajax variables, header values
Alert and detect abnormal number of requests eg for screen
scraping
1
2
3
1
1
2
3
3
Communications Security
Valid SSL certificates, path from root CA and validity
Failed TLS communications should not fallback to HTTP
1
2
3
1
3
HTTP Security
Every HTTP response should include a safe character set (e.g.
UTF-8)
No detailed version information in HTTP headers
1
2
3
1
2
Malicious Controls
All checks are level 3Verify no malicious code in code developed
or modified
Integrity of interpreted code, libraries, executables,
configuration files verified using checksums or hashes
Sensitive data rapidly sanitized from memory when no longer
needed
1
2
3
3
3
3
Business Logic
No spoofing of high value transactions
No tampering with high value business logic parameters like
price
Verify defensive measures against repudiation attacks such as
verifiable and protected transaction logs, or real-time monitoring
of activities and trransactions for anomalies
Detection and governor controls to protect against brute force
or denial of service attacks
Business limits and enforces them in trusted location, e.g. max
$10/day for new SIM users, or limit patient access to max #
patients you can treat in a day, or max 100 new users a day in a
forum, or not allowing posts before a users account has been
verified
1
2
3
2
2
2
2
2
Files and Resources
Verify the application does not execute uploaded data from
untrusted sources
1
2
3
2
Mobile
Verify that unique device ID (UDID) is not used as security
controle
Don't store sensitive data on shared resources (eg shared
folder)
No sensitive data in SQLite database on device
No hard-coded secret keys or passwords in executable
Verify permissions requested and resources authorized
(AndriodManifest.xml, iOS entitlements)
Obfuscate binary
No sensitive data logged (crash log, system log or
filesystem)
Use certificate pinning to prevent proxying of app data
Sensitive data should be cryptographically secured when
stored
Overwrite sensitive data in memory (mitigate damage from memory
analysis attack)
1
2
3
1
1
1
2
2
3
2
3
3
3
Authentication verification
Null checks
Domain lookup
Type conversion
Still boilerplate !
Gender gender;if (StringUtils. isEmpty(to.getGender)) { Gender =
null;} else { Gender = Gender.valueOf(
to.getGender());}res.setGender(gender);
Think about security in your application
https://www.owasp.org/
@joachimvda
@eliwan_be
@joachimvda
@eliwan_be
@joachimvda
#DV13jTransfo
@joachimvda
#DV13jTransfo
Demo
@joachimvda
#DV13jTransfo
