Securing MyFaces Applications Against the OWASP Top Ten

David Chandler learnjsf.com (blog) [email protected]

JSF is a Great Framework

Tool-friendly MVC Component-orientation makes reuse easy But.

Is it safe?

Framework Security Continuum

More secure

Framework makes it impossible for developers to write insecure code Developers must do all the right stuff, but you can use code scanning tools and limited inspection to find holes Possible, but developers must do all the right stuff Not possible to create a secure app (framework is flawed)

Less secure

Security Analysis Goals

Address framework / implementation vulnerabilities Lock front door and back door Inspect application code for vulnerabilities
Ideally, centralize validation and use other JSF extensions to minimize inspection points Use automated scanning tools to verify
Application code uses only safe components / extensions Application code does not access the external context directly (HttpSession) or use Lifecycle in unsafe ways

Whats OWASP?
Open Web Application Security Project OWASP tools, documents, forums, and local chapters are free and open to anyone interested in improving application security OWASP Top Ten is a minimum standard for web application security Designed to help developers and adminstrators keep Web apps secure

What is JavaServer Faces (JSF)?

What is JSF?
Spec, not an implementation (JSR 127) Many vendor implementations and two free
Suns reference implementation (RI) Apache myFaces

Where does it fit in the frameworks universe?

MVC, component-based framework servlet Builds on Struts controller, form bean concepts Builds on Tapestry components

Whats in a Typical JSF App

View templates (JSP or Facelets) Managed bean for each view registered in faces-config.xml Navigation rules in faces-config.xml

Major JSF Concepts

Components Renderers Managed beans Converters / Validators Controller (navigation model) Event handling Request lifecycle

JSF Components
Separate business logic from presentation Every view is composed of a component hierarchy Components can be added to view programmatically or via template (JSP by default, Facelets for superior performance and ease of development) Standard components divided into two groups:
Faces Core <f:view>, <f:loadBundle> HTML wrappers <h:dataTable>, <h:selectMany>, etc.

Component = class + [renderer] + tag handler (JSP)

JSF Renderers
Component renderer encodes (generates the HTML) for the component Renderer also decodes (sets component values from URL query string and form vars) Renderers are grouped into render kits
Default render kit is HTML Provide device independence w/o changing the templating language or components themselves

JSF Managed Beans

Link view to the model (like controller)
Provide event handler methods which in turn call appropriate model code (save, new) Provide helper methods (getAvailableSelectItems) Hold references to one or more domain objects

Managed by the framework in Application, Session, Request, or no scope Can inject references to related beans for nested flows

JSF Value Binding

Component values bind to model beans For each request, the framework
Converts each input value (String) into the underlying Java type (MoneyAmount) On output, converts underlying Java type to String

You register converters for custom types All security validation therefore handled centrally and automatically by model type

JSF Value Binding Example

view.xhtml

In logger object

JSF Value Binding Example

view.xhtml

Managed beans are registered in faces-config.xml

JSF Converters / Validators

Converters are bi-directional
Input converter: getAsObject() Output converter: getAsString()

Validators work with Objects, not just Strings JSF supplies standard converters for date / time, numbers, etc. You write custom converters for rich types or special behavior

JSF Converters / Validators

JSF Converter Example

Converter is registered in faces-config.xml, so all ValuedTypesafeEnum properties of any bean will use this converter

Validators also registered in faces-config.xml, but not by class

JSF Controller
Stateful or stateless navigation model Framework selects next view based on
Previous view Outcome of the event handler Event itself (regardless of outcome) Any combination of the above

Possibilities
Universal error view (triggered by error outcome) Wildcard matching permitted in outcomes, view IDs

JSF Event Handling

<h:commandButton action=#{ReportCtrl.save}>
Generates an event when pressed save() is a method on a managed bean

JSF calls ReportController.save() Can also define action listeners associated with other components in the form
Example: AccountSearch on any page without having to tell JSF navigation controller about each instance

Custom ActionListenerImpl runs before invoking method

JSF Request Lifecycle

Restore View Retrieve component tree from client or session Decode components (populate w/ String values) May skip to render phase or abort request

Apply Request Values

Request

Process Validations

Convert Strings to Objects Validate Objects

Update Model

Call setters on managed beans

Invoke Application Render Response

Invoke bean method(s) Compute navigation Respons e

Call bean getters to populate components

JSF Extension Points

Custom components Phase listeners (before, after any phase) Custom converters / validators Custom renderers Custion ActionListenerImpl to handle event Decorate or replace view handler, navigation handler, state manager, etc.

JSF Configuration
faces-config.xml Contains navigation rules as well as any customizations / extensions Can be split among directories and subdirectories as well as jars
Set javax.faces.application.CONFIG_FILES in web.xml Or put META-INF/faces-config.xml in jars so can bundle required configuration with code

OWASP Top Ten

A1 Unvalidated Input A2 Broken Access
Control A3 Broken Authentication and Session Mgmt A4 Cross Site Scripting A5 Buffer Overflow

A6 Injection Flaws A7 Improper Error

Handling A8 Insecure Storage A9 Application Denial of Service A10 Insecure Configuration Mgmt

 A1 Unvalidated Input
Parameter tampering (hidden & list boxes) Required fields Length, data type, allowed values Forced browsing Buffer overflows (see A5)

A1 Unvalidated Input JSF Validation Process

Validation is part of the request lifecycle When validation fails
Throw ConverterException or ValidationException Add message to the message queue
Message is associated with offending component Use <h:messages/> or <h:message for=component_id/> Dont forget one of these in your view!

Skip directly to render response phase

JSF Request Lifecycle

Retrieve component tree Restore from client or session View Apply Request Decode components Values (populate w/ String values) May skip to render phase or abort request

Process Validations Request

Convert Strings to Objects Validate Objects Update Model Call setters on managed beans

Invoke bean method(s) Compute navigation

Respons e

Invoke Application
Render Response

Call bean getters to populate components

A1 Unvalidated Input JSF Validation Process

Thing of beauty!
Model values never updated with invalid data User remains on current view No action methods called Messages tagged with component ID

Unless
immediate=true for some component If so, managed bean can access raw component values through component tree (dont!) JSF will NEVER update model unless validation passes

A1 Unvalidated Input Parameter Tampering

Hidden fields Multiple choices (radio, check box, select) Required fields

A1 Unvalidated Input Parameter Tampering (Hidden Fields)

Did you say hidden fields? YUCK! Of course, they can be tampered with! Must rely on validation as with any other field

A1 Unvalidated Input Parameter Tampering (Select Options)

List boxes, radio buttons, check boxes
<h:selectOneRadio value=#{bean.choice}> <f:selectItems value=#{bean.allChoices}> </h:selectOneRadio> JSF selectOne and selectMany components validate selected items against available choices
Component calls selectItems getter again and compares selected String with available Strings See java.faces.component.UISelectOne/Many

A1 Unvalidated Input Parameter Tampering (Reqd Fields)

Required fields <h:inputText value=#{bean.prop} required=true or EL /> If required field is empty (, not null), JSF will fail validation as usual
Can change default msg in properties file Or for really custom behavior, write custom converter or validator (note: validator doesnt get called for empty fields)

A1 Unvalidated Input Validating Length, Format, Data Type

Built-in validators for length & range
<f:validateLength/>, <f:validateDoubleRange/>, <f:validateLongRange/> maxLength DOESNT affect validation

Built-in converters
For all wrapper types (Boolean, Byte, etc.) <f:convertDateTime/>, <f:convertNumber/>

See Tomahawk for e-mail, regex, credit card

A1 Unvalidated Input Custom Validators

Simple interface
public void validate() throws ValidatorException

Can invoke one of three ways

setValidator() in custom component As validator tag (Facelets auto-wiring ) like builtins <my:customValidator /> <h:inputText validator=id | #{bean.validator}>

A1 Unvalidated Input Custom Converters

Simple interface
getAsObject() getAsString()

Invoke one of four ways

By type of model property bound to component setConverter() in custom component As converter tag (Facelets auto-wiring ) like built-ins <my:customConverter /> <h:inputText converter=id | #{bean.converter}>

A1 Unvalidated Input Rich Type (Model Centric) Converter

<converter-for-class>StringAN</> public static class UserCode extends StringAN {
Public UserCode (String value) throws InvalidStringException { super(value, 14); // length }

} In your model class, define & use type UserCode Now all components bound to property of type UserCode are automatically converted / validated StringAN does validation in constructor so an invalid instance can never be created

A1 Unvalidated Input JSF Validation Summary

Strengths
All validations declarative Associated with view, not action (so cant be overlooked in case of multiple actions) Model never updated unless all validations pass Converter-for-class eliminates need for explicit validator on every widget

A1 Unvalidated Input JSF Validation Summary

Weaknesses
No way to confirm that you didnt miss a validator or two

Unless
You use only custom converters / validators that add the id of each validated component to a Request variable And use a phase listener after validation to walk the component tree and find unvalidated UIInputs

A1 Unvalidated Input JSF Validation Extra

How can I validate related fields together?
Can always do in bean action method, but lose benefits of request lifecycle Put a custom tag after last form field <my:formValidator validator=#{bean.method} />

How can I determine requiredness based on metadata?

Use a converter tag that reads the metadata

A1 Unvalidated Input Forced Browsing

JSF prevents forced actions
Example
Simulate clicking a button not on view Like http://server/someAction.do?...

Every JSF URL contains the previous view ID JSF restores component tree from prior request Only processes events for components in the saved view But can still force an action on another view How do we solve it? View / mappings?

A1 Unvalidated Input Forced Browsing

JSF Can Be Extended to Prevent All Forced Browsing and Session Riding
Form action is obtained from the ViewHandler Decorate ViewHandlerImpl to override getActionURL() and append a hash of the URL Write custom phase listener to
Generate new token in Session for each request Compare hash in the URL with expected token

All <h:commandLink>s and <h:commandButton>s are now protected (w/ no mappings required!)

 A2 Broken Access Control

Insecure IDs Forced Browsing Past Access Control Checks Path Traversal File Permissions Client Side Caching

A2 Broken Access Control Forced Browsing Past Access Control

Safe approaches to user authentication
Use built-in features of servlet container or portal Servlet filter Extend MyFacesGenericPortlet with auth hooks Portlet filtersee MyFaces JIRA 434 Phase listener before RESTORE_VIEW
ExternalContext.getUserPrincipal() ExternalContext.isUserInRole() Both servlet impl and portlet impl define these methods

A2 Broken Access Control Forced Browsing Past Access Control

Safe ways to control access to views
(easy) Use rendered attribute with bean permission getters for fine-grained control <h:panelGroup rendered=#{bean.hasPermX}/> Use above with forced browsing preventer
Only have to check view perms when you display a link

Mapping approaches
Phase listener that maps view IDs to user perms And/or custom component <my:authChecker reqPerm=view_accounts />

A2 Broken Access Control Forced Browsing Past Access Control

Safe ways to control access to actions
(easy) Check perms in each bean action method Use rendered attribute with bean permission getters when displaying links
<h:commandLink rendered=#{bean.hasEditPerm} /> JSF automatically prevents forcing the action, even without forced browsing preventer

Centralized approach
Decorate ActionListenerImpl to intercept events Conceivable to annotate bean methods with reqd perm

A2 Broken Access Control Client Side Caching

Concern: browser caching, shared terminals Use phase listener to write no-cache headers

 A3 Broken Authentication and Session Management

Not JSF-specific
Password policy, storage Roll-your-own session management (dont!) Protect login via SSL

Login page should always POST, not GET

JSF forms are always POSTed

 A4 Cross Site Scripting

Two types of attacks
Stored (ex: malicious input stored in DB) Reflected (ex: malicious e-mail submits a request with cookie-stealing Javascript in text field)
Reflected attacks are initiated externally (as via e-mail) Forced browsing / session riding preventer stops these since request doesnt contain a valid hash Just make sure you dont put an unchecked HTTP header or cookie in the error message

Two approaches: input & output filtering

A4 Cross Site Scripting Approach 1: Input Filtering

Filter all input with Converters, Validators
Positive enforcement (allowed characters only) stronger than negative enforcement (remove bad chars) JSF numeric converters protect numeric properties Dont forget HTTP headers & cookies are input, too

Rich type converters greatly help with text input (i.e., UserCode = alphanumeric, maxlen 14)
Then you only need to worry about value bindings to free form String model properties

A4 Cross Site Scripting Approach 2: Output Filtering

MyFaces does this mostly for you
<h:outputText> and <h:outputFormat> values are escaped unless you explicitly turn off with escape=false <h:outputLink> URIs beginning with javascript: are escaped All other HTML components (<h:> tags) are safely rendered Tag attributes are escaped for all components Escaped chars are < > & (not sufficient w/in JS)

A4 Cross Site Scripting XSS Code Review

What to look for in view templates
<h:outputText/Format escape=false /> <h:outputLink value=#{bean.non_js_prop} /> Any output components between <script> tags

What to look for elsewhere

Rich type constructors and/or getAsString() for rich type converters Custom components and renderers

 A5 Buffer Overflows
Not an issue in Java per se Might be an issue for 3rd party systems (DB) Always validate input for length
Numeric types are safe (Integer, Long, etc.) Prefer rich types to Strings Use <f:maxLength> for String properties Keeping max lengths short also helps with XSS

 A6 Injection Flaws
Ex: SQL injection SELECT * FROM users where ID = URL.ID Suppose URL.ID = 34; DROP TABLE users Most effective protection is nearest the calls to external system
Use O/R mapping Parameterize all queries

Nevertheless, JSF can be of some help

A6 Injection Flaws Common Problem: IDs in URLs

JSF <h:dataTable> uses indexed rows

Dont use <f:param> with real IDs Use ListDataModel and getRowData(). JSF will do the mapping and get the Object for you What if an item is added to the list? Extend DataModel w/ hash + encryption?

A6 Injection Flaws Common Problem: IDs in OPTIONs

Values of select options, radio buttons, check boxes often use real IDs Several ways to avoid this
Populate <f:selectItems> with Integer values that index into an array stored in your managed bean
Could write SelectItemsHelper, but creates dependency

Create a custom converter w/ hash + encryption

<my:indexConverter> Wrap default components with one that sets converter Or use phase listener to set converters (maybe?)

A6 Injection Flaws Common Problem: IDs in OPTIONs

Or rich type converter Converter getAsString() can tell whether the component is a UISelectMany/One Thus, you can write a rich type converter that does indexing / hash + encryption for Selects but does escape(value.toString()) for everything else If youre willing for all domain rich types to implement a simple interface, you can write one Converter for the interface Index converter prevents information leakage, too

A6 Injection Flaws Summary

Not an issue with JSF But JSF can help Once again, converters are the key

 A7 Improper Error Handling

Not a JSF issue per se Use standard servlet techniques
<error-page> in web.xml, etc.

Try not to
Show the user a stack trace Reveal names of internal machines, etc.

A7 Improper Error Handling Facelets Has Beautiful Error Messages

Beautiful, but more than the customer needs to know
<context-param> <param-name>

facelets.DEVELOPMENT </param-name> <param-value> false </param-value> </context-param>

 A8 Insecure Storage
Not a Web tier problem
Use hashes instead of encryption Dont write your own encryption algorithm!

Except for one thing in web.xml (see A10)

A9 Application Denial of Service

All Web apps are vulnerable to some degree
Forced browsing listener will minimize damage by rejecting bogus requests early

No known magic bullets for JSF like ping L 65510 Load test Load test Load test

 A10 Insecure Config Mgmt

Primarily concerned with
Server OS, software, misconfigurations Improper file & directory permissions, etc. Unnecessary services

What about JSF configuration?

State saving method View handler (JSP or Facelets)

A10 Insecure Configuration Mgmt Beware Client State Saving

Server- (default) or client-side state saving Out of the box, client-side state saving is Base64 encoded only (no encryption!)
Allows hacker to alter component tree(!) Replace converters & validators Change EL expressions that populate fields, select boxes Change EL in command link to call different event handler, remove action listener

A10 Insecure Configuration Mgmt Enable Client State-Saving Encryption

If client saving, provide encryption key in <init-param> org.apache.myfaces.secret Default algorithm is DES See myfaces-shared-impl StateUtils class to change
Org.apache.myfaces.algorithm Org.apache.myfaces.algorithm.parameters Org.apache.myfaces.secret.cache

A10 Insecure Configuration Mgmt Lock Down .xhtml with Facelets

Lock down .xhtml extension if using Facelets
Rejecting servlet Or <security-constraint> in web.xml See Facelets doc for details

Putting It All Together

Use only rich types in model beans Rich type converter(s) should
Provide positive input validation Index values for select components (radio, check, menu) Escape all other output

Use listener to check for unvalidated components Use forced browsing / session riding preventer Dump JSP for Facelets

Resources
www.owasp.org facelets.dev.java.net

learnjsf.com (blog, code samples, etc.)