When the "javascript hijacking" problem was discussed back in April, I
added a mechanism to prevent private information from being fetched from
a json action without an additional authenticationToken, which should
protect against another site slurping non-public information from mine
just by virtue of a user being logged into both sites simultaneously
with a single browser.
http://jroller.com/TedHusted/entry/fortify
http://www.schneier.com/blog/archives/2007/04/javascript_hija_1.html
But it's not just information that is vulnerable from this type of attack:
Cross Site Request Forgery
http://www.owasp.org/index.php/Top_10_2007-A5
Illustrates that any *action* that a user can take through your app is
just as forge-able. OWASP suggests that in order to protect from this
form of attack "insert custom random tokens into every form and URL".
This solution is ugly, and it results in much uglier links, but should
be able to be set only for requests for logged in users, and only those
that perform data-altering actions, or return extra information based on
user credentials. (Unfortunately this includes most pages on modern
sites, but at least it doesn't make urls uglier for non-logged in users
(i.e.: search engines)...)
I'd suggest that the token doesn't need to be random, and one simple way
to have this differ from user to user and also change over time is to
use a hash of the user's last successful login timestamp. Since all my
actions extend a base class I can add the field and logic there and
check validity in each data-modifying action method, but this still
seems cumbersome and error prone.
It occurred to me that this might be something the framework could help
with, although I've not completely thought through the design, so I
figured I'd throw out some ideas here and see if anything sticks:
When the action is the result of an s:form, we could add a (boolean)
attribute of the tag that causes in the .ftl to add in this extra hidden
field.
When the action is the result of an s:url, we could add a (boolean)
attribute of the tag that adds the appropriate parameter to the
generated url.
We could then add an interceptor that checks this extra authentication
token and prevents the action from executing/logs the user out/something
else should the parameter be missing/incorrect.
Opinions?
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
