Java zone ASVS 2015

@joachimvda@eliwan_be
Joachim Van der Auwera
ASVS
in a business application

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 ?

Four levels

Level for each verification

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.

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
@ServerInterceptor
public 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 3
• Verify 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

Think about security in your application
https://www.owasp.org/

Java zone ASVS 2015

More Related Content

What's hot (20)

Similar to Java zone ASVS 2015 (20)

More from Joachim Van der Auwera (9)

Recently uploaded (20)

Java zone ASVS 2015

Editor's Notes