Martin Nystrom, Cisco Systems
Goal: Learn why and how to build Java web apps secured from the most common security hacks.
95% of web apps have vulnerabilities. Cross-site scripting, SQL injection, parameter tampering, cookie poisoning, database server, web server, buffer overflow.
Web attack: Discover: Examine the environment - identify open ports, discover types & versions of running apps via banner grabbing, file extensions, etc. Generate and examine errors - submit ridiculous input to provoke errors (fuzzing), database errors and stack traces are very helpful. Find info left behind - source code, comments, hidden fields.
Target login mechanism, input fields, session management, infrastructure.
Demo: Use nmap to banner grab a web site. nikto.pl throws http requests at site to see what might be vulnerable. Both tools have options to run "low and slow"
Security principles of web architecture:
- Separate services (web, app, db on separate hosts)
- Limit privileges of application user - file system (chroot or limit privs to read-only), database system (limit privs on tables, schemas, etc.), privileges of running user (xxtomcat, apache, kobayashi, etc.).
- Hide secrets (dataabase account passwords, encryption keys, etc.)
- Use standard, vetted components and libraries, and keep them patched.
- Log, and watch logs for unusual activity
- Load test and tune accordingly (think about DDoS)
- Don't trust input from user
- Review for logic holes
- Leverage vetted resources - infrastructure, components
- Only give information needed
- Build/test to withstand load - expected load, potential DoS attack
(List based on OWASP top 10 web security vuls - except buffer overflows, which aren't typically relevant to Java)
Unvalidated input: Attacker can easily change any part of the HTTP request before submitting. Input must be validated on the server. Countermeasures include code reviews (check variable against list of allowed values, not vice-versa), don't acccept unnecessary input, store in session or trusted back-end store, sanitize input with regex.
Broken access control: Inconsistently applied file system or url controls. Examples: path traversal, logic flaws, client-side caching. Countermeasures: use non-programmatic controls, access control via central container, code reviews.
Broken account and session management: Weak user authentication - password only, easliy guessable usernames, poorly implemented single-sign-on (example: storing userid in plaintext in a cookie) Weak resource authentication - how are database passwords stored? could it be disclosed via browser? Using ip to authenticate? Countermeasures - use vetted components, use strong passwords...
Cross-site scripting: inject code into web page that is then displayed to user in the browser, reflect malicious code to end-user
can hide malicious code with unicode. Vulnerable anywhere user-supplied data is redisplayed without input validation or output encoding. 2 types of attacks: stored and reflected. Impact - can steal cookies, especially vulnerable on apps with form-based authentication. Countermeasures - input validation: whitelisting (recommended), blacklisting (sub-optimal); output encoding (e.g., htmlEncode), truncate input fields to reasonable length.
Injection flaws include command injection and SQL injection. Typical dangers include runtime.exec() calls. Countermeasures - use PreparedStatements in SQL, avoid runtime.exec() calls (use libraries instead), run with limited privileges, filter and validate input.
Demo using WebGoat for SQL injection.
Improper error handling. Examples: stack traces, db dumps. Helps attacker know how to target the app. Often left behind during debugging. Inconsistencies can be revealing. Gives insight into source code. Good messages give user enough info without giving too much to attacker. Countermeasures: code review. Limit error message content. Modify default error pages (404s, etc.) Log details to log files, not to screen.
Insecure storage. Sensitive data must be protected. Poorly implemented crypto abounds. Encoding is not encrypting. Countermeasures- store only what you must. Store a (cryptographically strong) hash instead of the full value if possible. Use only vetted, public crypto (i.e., don't roll-your-own).
Denial of service. Examples that may provoke DoS:Heavy object allocation / reclamationl overuse of logging, unhandled exceptions, unresolved dependencies on other systems (web services, databases). May impact other apps, hosts, databases, or network itself. Countermeasures - load testing, code review.
Insecure configuration management. Tension between "work out of the box" and "use only what you need". Development != web masters. Countermeasures - create and use hardening guides, turn off all unused services, setup and audit roles, permissions, and accounts, use logging and alerts.
Demo of brutus password guessing tool.