StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<h1>XSS</h1> <p>JSF is designed to have builtin XSS prevention. You can safely redisplay <strong>all</strong> user-controlled input (request headers (including cookies!), request parameters (also the ones which are saved in DB!) and request bodies (uploaded text files, etc)) using any JSF component.</p> <pre><code><h:outputText value="#{user.name}" /> <h:outputText value="#{user.name}" escape="true" /> <h:inputText value="#{user.name}" /> etc... </code></pre> <p>Note that when you're using JSF 2.0 on Facelets, then you can use EL in template text like so:</p> <pre><code><p>Welcome, #{user.name}</p> </code></pre> <p>This will also implicitly be escaped. You don't necessarily need <code><h:outputText></code> here.</p> <p><strong>Only</strong> when you're explicitly <em>unescaping</em> user-controlled input using <code>escape="false"</code>:</p> <pre><code><h:outputText value="#{user.name}" escape="false" /> </code></pre> <p>then you've a potential XSS attack hole!</p> <p>If you'd like to redisplay user-controlled input as HTML wherein you would like to allow only a specific subset of HTML tags like <code><b></code>, <code><i></code>, <code><u></code>, etc, then you need to sanitize the input by a whitelist. The HTML parser <a href="http://jsoup.org" rel="nofollow noreferrer">Jsoup</a> is very <a href="http://jsoup.org/cookbook/cleaning-html/whitelist-sanitizer" rel="nofollow noreferrer">helpful</a> in this.</p> <h3><code>itemLabelEscaped</code> bug in Mojarra < 2.2.6</h3> <p>Older Mojarra versions <em>before</em> 2.2.6 had the bug wherein <code><f:selectItems itemLabel></code> incorrectly renders the label unescaped when provided a <code>List<T></code> via <code><f:selectItems var></code> instead of <code>List<SelectItem></code> or <code>SelectItem[]</code> as value (<a href="https://github.com/javaserverfaces/mojarra/issues/3147" rel="nofollow noreferrer">issue 3143</a>). In other words, if you're redisplaying user-controlled data as item labels via a <code>List<T></code>, then you've a potential XSS hole. If upgrading to at least Mojarra 2.2.6 is not an option, then you need to explicitly set <code>itemLabelEscaped</code> attribute to <code>true</code> to prevent that.</p> <pre><code><f:selectItems value="#{bean.entities}" var="entity" itemValue="#{entity}" itemLabel="#{entity.someUserControlledProperty}" itemLabelEscaped="true" /> </code></pre> <hr> <h1>CSRF</h1> <p>JSF 2.x has already builtin CSRF prevention in flavor of <code>javax.faces.ViewState</code> hidden field in the form when using server side state saving. In JSF 1.x this value was namely pretty weak and too easy predictable (it was actually never intended as CSRF prevention). In JSF 2.0 this has been improved by using a long and strong autogenerated value instead of a rather predictable sequence value and thus making it a robust CSRF prevention. </p> <p>In JSF 2.2 this is even be further improved by making it a required part of the JSF specification, along with a configurable AES key to encrypt the client side state, in case client side state saving is enabled. See also <a href="https://github.com/javaee/javaserverfaces-spec/issues/869" rel="nofollow noreferrer">JSF spec issue 869</a> and <a href="https://stackoverflow.com/questions/30373089/reusing-viewstate-value-in-other-session-csrf/">Reusing ViewState value in other session (CSRF)</a>. New in JSF 2.2 is CSRF protection on GET requests by <a href="https://stackoverflow.com/questions/26969415/should-protected-views-be-used-for-jsf-2-2-csrf-protection"><code><protected-views></code></a>.</p> <p>Only when you're using stateless views as in <code><f:view transient="true"></code>, or there's somewhere a XSS attack hole in the application, then you've a potential CSRF attack hole.</p> <hr> <h1>SQL injection</h1> <p>This is not JSF's responsibility. How to prevent this depends on the persistence API you're using (raw JDBC, modern JPA or good ol' Hibernate), but all boils down that you should <strong>never</strong> concatenate user-controlled input into SQL strings like so</p> <pre><code>String sql = "SELECT * FROM user WHERE username = '" + username + "' AND password = md5(" + password + ")"; String jpql = "SELECT u FROM User u WHERE u.username = '" + username + "' AND u.password = md5('" + password + "')"; </code></pre> <p>Imagine what would happen if the enduser chooses the following name:</p> <p> <pre><code>x'; DROP TABLE user; -- </code></pre> <p>You should <strong>always</strong> use parameterized queries where applicable.</p> <pre><code>String sql = "SELECT * FROM user WHERE username = ? AND password = md5(?)"; String jpql = "SELECT u FROM User u WHERE u.username = ?1 AND u.password = md5(?2)"; </code></pre> <p>In plain JDBC you need to use <a href="http://download.oracle.com/javase/6/docs/api/java/sql/PreparedStatement.html" rel="nofollow noreferrer"><code>PreparedStatement</code></a> to fill the parameter values and in JPA (and Hibernate), the <a href="http://download.oracle.com/javaee/6/api/javax/persistence/Query.html#setParameter%28int,%20java.lang.Object%29" rel="nofollow noreferrer"><code>Query</code></a> object offers setters for this as well.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload