Ok, people should read the whitepaper. Part of it describes how http
gets and using query parameters are somewhat easier to do request
forging on than posts. I have to think through the filter approach,
but the big deal is on forms. However, several app design principles
also apply - in particular, ensuring that there are no changes that
one can make, if one were forged, that don't include notification that
the change was made to the original e-mail address of the user.
The classic example is on a bank site. If i can forge a request to
change the notification e-mail, then can set my own e-mail as the new
notification source. THEN I can do all sorts of things, including ask
for a password reset and get them to my own address, and take over the
account. If, however, such underlying account changes require a phone
call, or are protected from forgery, then you dramatically limit the
danger of the forgery.
The reason I'd not enable this on every single request (especially
navigation alone) is that generating a cryptographically valid request
key and storing it puts a pretty high burden on a server with any
serious load, and having this happen on any and every click can be
quite expensive. The only caveat I'd make to that is the fact that
T5 uses some parameterization via the URL, and if those parameters are
worth forging, then having the solution implemented on clicks as well
would be critical.
Blanket solutions don't make you secure if they're knee-jerk. You
still have to do threat modelling, and incorporate it into the app
design. I'd much rather see the capability to have a secure request
key be built into ActionLink, Page, and Form, to allow one to enable
it with a flag, according to what needs protecting. T5, having the
component consume its own data is in a much better place to implement
this cleanly in a few key components than Struts or other things. But
getting nervous about XSRF (or CSRF or whatever the current acronym is
today) and applying broad strokes isn't a good model of security, in
my view.
Unfortunately, I can't provide source code for our example, as I don't
have it any more, and it was client code. I'm in the thick of other
source and other issues, so I don't really have time to implement it.
I do have a client that may need it, so if I get there before a good
general solution is adopted in T5, I'll try to write it in a way that
I can share the source with the community.
Christian.
On 6-Aug-08, at 03:13 , 9902468 wrote:
Hi,
CSRF solution could be the base for the solution to my problem,
described
here:
http://www.nabble.com/T5-double-click---multiple-windows-on-same-session-prevention-to18807447.html
Could you post the code? I think that I need only to customize it so
that it
changes the sid to every response and accepts only request with the
latest
one.
I'm also interested of the mixin(s) code. (Or the custom action
link / form
implementation if that approach was chosen.)
- 99
Martijn Brinkers (List)-2 wrote:
Also, the internal LinkFactory service has listeners that know
when an
action link is created; it might be possible to automatically add a
query parameter to every link with authentication, and then provided
filters in the ComponentEventRequestHandler pipeline to enforce the
check.
I finally had time to implement the 'Cross-site request forgery'
filter
in the way suggested by Howard and it was really simple and
straightforward (which shows me again why I think Tapestry is
extremely
well built). All action links now contain a sid (random generated for
each user) and the sid is checked using a
ComponentEventRequestFilter.
The only possible problem (which was not a problem for me though)
could
be that the action links now contain an extra parameter
(example: ?sid=enn50tk96) which wasn't there before the filter was
added. This can interfere with existing code. I was wondering
whether it
would be possible to remove the sid attribute after checking the
sid so
the rest of the application has no knowlegde of the sid?
Martijn
On Mon, 2008-07-28 at 12:27 -0700, Howard Lewis Ship wrote:
I wonder if this could be created as a Mixin?
Also, the internal LinkFactory service has listeners that know
when an
action link is created; it might be possible to automatically add a
query parameter to every link with authentication, and then provided
filters in the ComponentEventRequestHandler pipeline to enforce the
check.
On Mon, Jul 28, 2008 at 12:24 PM, Martijn Brinkers (List)
<[EMAIL PROTECTED]> wrote:
Hi Christian,
Do you have some example code of you Form extension?
Thanks,
Martijn
On Mon, 2008-07-28 at 15:18 -0400, Christian Edward Gruber wrote:
A good way would be to alter the Form object to contain (via a
hidden
variable) a field that's generated per the whitepaper linked
from that
wikipedia article. The form would then consume the post, and if
that
field is not in the expected state, generate an error state, which
could then be redirected to a security page or some such. We
solved
it this way, though without changing the T5 form object - we
used a
custom form object.
A friend of mine wrote the linked whitepaper, so if someone's
trying
to put the fix into the Tapestry framework infrastructure, then
let me
know and I'll connect you by e-mail. It's a good read anyway,
as it's
a bit of a subtle problem.
Christian.
On 28-Jul-08, at 14:50 , Martijn Brinkers (List) wrote:
Cross-site request forgeries (CSRF) is a web application
vulnerability
that is often neglected by web developers. If your application is
vulnerable to CSRF and an attacker can entice you to request some
URL
(this can be done for example with an image with the src set to
some
Tapestry action) the attacker can execute random Tapestry actions
and
post forms (like adding a adminitrator etc.) without the users
consent.
For more info on CSRF see for example:
http://en.wikipedia.org/wiki/Cross-site_request_forgery.
One way to protect against CSRF is to add a non-guessable code
(saved in
the user session) to the URLs that need to be protected against
CSRF
or
add a hidden field to a Form with this unique code. When Tapestry
recieved a request (for a page or action) and that page/action
need
protection a check is done to see if the code from the URL
matches
the
code stored in the user session. If not you know that the request
did
not generated by tapestry.
My question is what is the best way to implement this? Should I
add
the
code as a context parameter and for forms as a hidden field?
And use
a
dispatcher to check whether the page should have been protected?
Thanks,
Martijn Brinkers
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/T5%3A-How-to-protect-against-%27Cross-site-request-forgery%27--tp18697003p18845568.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
