[
https://issues.apache.org/jira/browse/MYFACES-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500849#comment-13500849
]
Leonardo Uribe commented on MYFACES-3652:
-----------------------------------------
Any view key algorithm must comply with the following requeriments:
- The generated key must be unique per session.
- It should provide basic protection against cross-site request forgery attacks.
- It should not be possible to use the key for one view in other view.
Right now there are two possible strategies:
A. counter + viewId hashcode + encryption + mac
- The counter ensures uniqueness
- encryption + mac provides protection against CSRF, because you need
infeasible amounts of computation to generate a mac and break encryption.
- the viewId hashcode protects against use one valid key for one view in other
view.
B. counter + viewId hashcode + random sequence
- The counter ensures uniqueness
- the random sequence protects against CSRF, because you cannot predict easily
the next random number.
- the viewId hashcode protects against use one valid key for one view in other
view, the controversial part is if the random sequence do already that too
(because in theory only a SecureRandom generates a sequence that cannot be
predicted).
SecureRandom is expensive, but in tomcat the use use of a
ConcurrentLinkedQueue<SecureRandom>() improves performance vastly. I wouldn't
worry about use SecureRandom.
In few words, option A is well known and secure, but the encryption step impose
an small overhead over each request. This is overcome making the key as small
as possible. Option B has the advantage that theorically it does not require
encryption, but I still has doubts about that, because if you can predict the
next random number, the application will be vulnerable against CSRF attacks.
I like the idea of use
Option C. counter + fast random sequence + encryption + mac
by default, but I don't know if the solution using SecureRandom without
encryption + mac is faster or not.
In this algorithm, my priority is ensure the 3 previous requeriments, and then
minimize the key size and at last ensure a small performance overhead.
Which one is better? I still don't have a clue. Unfortunately, there is not
much time for me to check this now, but maybe later.
> Define default view key algorithm
> ---------------------------------
>
> Key: MYFACES-3652
> URL: https://issues.apache.org/jira/browse/MYFACES-3652
> Project: MyFaces Core
> Issue Type: Sub-task
> Components: JSR-344
> Affects Versions: 2.2.0, 2.1.9
> Reporter: Mark Struberg
> Assignee: Mark Struberg
>
> Currently we have a few different viewkey generator implementations. Those
> got added only in 2.1.9. Before that the only had a TicketCounter in each
> Session.
> The original implementation also had no viewId in the key.
> If you think about it, then it makes no sense at all to add the viewId.
> Despite it's an int hashCode we have 2 problems which completely trashes the
> purpose:
> a.) hashCode is not guaranteed to be unique
> b.) the hashCode is always the same for the same view.
> Think about an application with only one xhtml page. In that case the viewId
> would add no additional info.
> With 4 pages you would only reduce the collision rate to over 25%. Since the
> application will most times mainly hit by a few entry points like index.html
> you gain barely anything from adding this information.
> IF we have had problems with any collisions, then we shall add an XorShift
> random generator instead of the viewId. Leo, I didn't an issue report for
> such a problem. Do you have any tip for me where I can find that?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
