Version 1.0 of Defending Web Application, a presentation to developers on how to improve web application security.

1. Defending Web Applications

2. Introduction
• Who am I?
– Security assessor for ITSO-SPA
– Worked for TSB beginning March, 1999
• Technical support of national web applications
• Security testing
– Moved to ITSO October, 2012
– Am NOT a developer
• Wrote the TSB portal and first instances of defect
tracking used by the Judiciary

3. Overview
Guidance for security controls
• Specifying baseline requirements
– “Lock a user account for 30 minutes after 10 invalid
authentication attempts in a 30 minute period”
• Specifying “best practices”
– Store passwords as a salted hash
• Specifying security principles
– Never trust any input that comes from the client

4. Overview
• Authentication
– Login Page
– Passwords
– Password Storage
– Password Reset
• Session Management
– Session Management
– Session Token
– Cookies
• Specific Attacks
– Clickjacking
– Cross Site Request Forgery
(CSRF)
– SQL Injection (SQLi)
– Cross-site Scripting (XSS)
• Configuration
– SSL
– HTTP Response Headers
– Miscellaneous

5. Who are our threats?
• Nation-states
• Political activists
• Motivated criminals – organized crime
• Attackers with no motive against the organization
• Script kiddies
• Automated attacks – worms, virus, Trojan horse
• Disgruntled staff
• End users

6. How do we defend against these
varied threats?

7. Some basic principles
• Do not “roll your own”
– Do not create your own encryption algorithms
– Do use Web development frameworks when possible
– Do use a secure random number generator
• java.security.SecureRandom
• System.Security.Cryptography.RNGCryptoServiceProvider
• Never trust any input that comes from the client
• Never store secrets in plain text
• Don’t be helpful
• Employ a mechanism to detect important events
• Assume a potential attacker knows
• Assume eventual compromise

8. AUTHENTICATION
Defending Web Applications

9. Login Page
• System Use notification
• Only load login page over HTTPS
• Submit over HTTPS
• Do not echo password when entered
• Do not retain password in cache
• Provide consistent, standard error messages
to prevent username enumeration

10. System Use notification

11. Load and submit login page over SSL

12. Do not echo or retain passwords

13. Login error messages
For example
• Invalid account, invalid password
– “Invalid username/password”
• Valid account, invalid password
– “Password is incorrect”

14. Passwords
• Complexity Requirements
– At least eight characters long
– No more than three repeated characters
– At least four alphabetic characters
– At least one number
– Changed every 180 days

15. Passwords
• Brute Force Protections
– Enforce a limit of 10 consecutive invalid access
attempts by a user during a 30-minute time period
– Automatically lock the account minimum of 1
hour when the maximum number of unsuccessful
attempts is exceeded

16. These considerations should be addressed
anywhere in the application the user is asked to
authenticate

17. Passwords
• Do not transmit the password in plain text
– The URL
– Logs
– Error messages
• Do not store in plain text
– Database
– Client-side
– Email

18. Password Storage
• Do store the password as a salted hash
• Do use a random number generator to create the salt
• Do use a salt that is the same size as the hash output
function
• Do use a secure hash, such as SHA256
• Do always hash on the server
• Do not use a salt more than once
• Do use a standard library, such as PBKDF2 or bcrypt,
for Key Stretching

19. Password Storage – bcrypt
public class BcryptHashingExample
{
public static void main(String[] args) throws
NoSuchAlgorithmException
{
String originalPassword = "password";
String generatedSecuredPasswordHash =
BCrypt.hashpw(originalPassword, BCrypt.gensalt(12));
System.out.println(generatedSecuredPasswordHash);
boolean matched = BCrypt.checkpw(originalPassword,
generatedSecuredPasswordHash);
System.out.println(matched);
}
}
Output:
$2a$12$WXItscQ/FDbLKU4mO58jxu3Tx/mueaS8En3M6QOVZIZLaGdWrS.pK
true

20. Password Reset
• Do not send the password to the user
• Do not disable the user’s account
• Do not let the user change the password after
answering security questions
• Do email a random, single-use token
• Do not send any user account information in the
link
• Do expire the token
– After a set amount of time
– After use
– After a successful login

21. SESSION MANAGEMENT
Defending Web Applications

22. Session Management
• Do use a Web development framework
• Do implement an inactivity and absolute
timeout
• Do provide a means for the user to logout
• Do destroy the session server-side on logout
or after timeout
• Do not allow concurrent logins from different
workstations

23. Session ID
• Generated by the application
• Do renew after any privilege level change
• Do change the default name to prevent
fingerprinting
• Do have a length greater than 20 bytes (160 bits)
• Do have sufficient entropy (randomness)
• Do not store secret data in the session ID
• Do not allow in URLs, logs or error messages
• Do treat as any other client-side input

24. Cookies
• Do set
– HTTPOnly
– Secure
– Path
– Domain
– Expire
• Do not store sensitive data in cookies

25. SPECIFIC ATTACKS
Defending Web Applications

26. Clickjacking
• Set HTTP Header (X-Frames-Options)

27. CSRF
• Include an anti-CSRF token
– Unique per user and per session
– Tied to a single user session
– Large random value
– Generated by a cryptographically secure RNG

28. CSRF
• One way to implement
– Generate Token, store server side for the session
– Add token as a hidden parameter to a form
– When form is submitted, check that the submitted
token matches the token saved server-side

29. SQL Injection
• Parameterize Queries
The following is an example of Java code which is
vulnerable to SQL injection:
String query = "SELECT * FROM users WHERE userid ='"+ userid +
"'" + " AND password='" + password + "'";
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(query);

30. SQL Injection
• Parameterize Queries
Here is the same code properly parameterized:
PreparedStatement stmt =
connection.prepareStatement("SELECT * FROM users WHERE
userid=? AND password=?");
stmt.setString(1, userid);
stmt.setString(2, password);
ResultSet rs = stmt.executeQuery();

31. XSS
On submit
• Enforce input field type and lengths
• Validate fields
• Ensure option selects and radio contain only sent values
On render:
• Set correct content type
• Set safe character set (UTF-8)
• Output encode all user data according to context
• Set input constraints

32. File Upload
• Do
– Scan with Anti-Virus
– Check for expected file extension
– Check file content-type
– Check file size
– Use a new name
– Store outside of web root
– Deny access to file except through application
– Strip away extraneous content

33. CONFIGURATION
Defending Web Applications

34. SSL
• Do use secure ciphers suites
• Do force HTTPS (all points from login to
logout)
• Do use valid SSL certificates
• Do not allow mixed mode
– All CSS, images, JavaScript, etc. must be served
over SSL

35. Headers - Remediation
• Unset: Server, X-Powered-By, X-AspNet-
Version
• X-Frame-Options
• Cache-Control
• Content-Type

36. Headers - Preventative
• X-Content-Type-Options
• X-XSS-Protection
• Strict-Transport-Security
• X-Content-Security-Policy
• Character set (UTF-8)

37. Misc.
• Do not enable directory browsing
• Do not allow direct access to objects
• Do not allow verbose error messages
• Do implement sufficient auditing and logging

38. Summary

39. Questions & Answers

40. References
• http://howtodoinjava.com/2013/07/22/how-to-generate-secure-password-hash-md5-sha-pbkdf2-
bcrypt-examples/
• https://crackstation.net/hashing-security.htm
• http://arr.gr/blog/2012/02/password-hashing-revisited/
• https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
• https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet
• https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet
• https://www.owasp.org/index.php/Secure_Coding_Cheat_Sheet
• https://www.owasp.org/index.php/Authentication_Cheat_Sheet
• https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
• https://www.owasp.org/index.php/Secure_Coding_Principles
• https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Session_Management_Im
plementation
• https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet#OWASP_Top_Ten_Cheat_Sheet
• http://www.troyhunt.com/2013/05/hack-yourself-first-how-to-go-on.html#PasswordStorage
• http://www.troyhunt.com/2012/06/our-password-hashing-has-no-clothes.html