Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <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>&lt;h:outputText value="#{user.name}" /&gt; &lt;h:outputText value="#{user.name}" escape="true" /&gt; &lt;h:inputText value="#{user.name}" /&gt; 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>&lt;p&gt;Welcome, #{user.name}&lt;/p&gt; </code></pre> <p>This will also implicitly be escaped. You don't necessarily need <code>&lt;h:outputText&gt;</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>&lt;h:outputText value="#{user.name}" escape="false" /&gt; </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>&lt;b&gt;</code>, <code>&lt;i&gt;</code>, <code>&lt;u&gt;</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 &lt; 2.2.6</h3> <p>Older Mojarra versions <em>before</em> 2.2.6 had the bug wherein <code>&lt;f:selectItems itemLabel&gt;</code> incorrectly renders the label unescaped when provided a <code>List&lt;T&gt;</code> via <code>&lt;f:selectItems var&gt;</code> instead of <code>List&lt;SelectItem&gt;</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&lt;T&gt;</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>&lt;f:selectItems value="#{bean.entities}" var="entity" itemValue="#{entity}" itemLabel="#{entity.someUserControlledProperty}" itemLabelEscaped="true" /&gt; </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>&lt;protected-views&gt;</code></a>.</p> <p>Only when you're using stateless views as in <code>&lt;f:view transient="true"&gt;</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>
    singulars
    1. This table or related slice is empty.
    1. POCSRF, XSS and SQL Injection attack prevention in JSF
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USEmil Sierżęga
    1. USBalusC
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POCSRF, XSS and SQL Injection attack prevention in JSF
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI'd add that contrary to popular believe, using stored procedures does **not** automatically save you from SQL injection attacks: I've seen stored procedures create SQL statements by concatenation and **that** is *equally vulnerable* to SQL injection! It's the same way that using PreparedStatements doesn't automatically save your from SQL injection attacks, if you're using them wrong!
      singulars
      1. PO
      1. USJoachim Sauer
    2. CO@BalusC Well I cannot thank you enough for this awesome explanation..But I have some doubts. In my GUI, I use <h:outputText value="#{user.name}" escape="false" /> for displaying on the GUI..Now this is a potential XSS Attack.How do I avoid it.??. Secondly, I am stll using JSF 1.2 and so how do I handle CSRF then?.I used WebScrarab tool to intercept Http Request and modify the value and it indeed was successful.Does it mean that the application is prone to Attack.How can I avoid it. I have already handled SQL injection. Only thing to worry for me is XSS and CSRF as of now..Please help.
      singulars
      1. PO
      1. USAngelsandDemons
    3. CO@BalusC Also the explanation provided by Samuel suggest me to have a look at closure Template for sanitizing HTML input. But I have heard that closure template has serious performance issue and morever it is from Google Labs so it will be almost in Beta version hence not stable...Which one would you recommend for HTMl santizing..Jsoup or Closure..I am absolutely new to this santizing and parsing and hence I would prefer something which is easy to learn and implement.
      singulars
      1. PO
      1. USAngelsandDemons
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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