Am 01.10.2008 um 08:57 schrieb Ashley:
On Sep 30, 2008, at 11:13 PM, Aristotle Pagaltzis wrote:
* Ashley <[EMAIL PROTECTED]> [2008-09-30 19:30]:
If scripting is involved that makes it a XSS attack instead,
though. No?
No.
Yeah, that was unclear. I was talking about our own sites
and Cat apps, not the web at large. It was in that context
which I suggested script based attacks were by definition
going to be XSS. Malicious ActionScript is still script.
But I hadn't read the POST exploits as described in the
white paper so I was wrong.
Might be pretty simple in Cat stuff. The crux of the POST
issue seems that the target site's cookies are still safe
from the attacking site's POST. So, off the top of my
head, untested, please modify, correct, refine, put
in wiki, etc.
Form template:
<form action="[% c.request.uri() %]" method="post">
[% USE Digest.SHA1 -%]
<input type="hidden" value="csrf_check" value="[% c.sessionid |
sha1_hex %]" />
</form>
Controller form validation:
use Digest::SHA1 qw(sha1_hex);
some_error_or_other() unless
$c->user_exists
and
$c->request->body_params->{csrf_check} eq sha1_hex($c->sessionid);
I think this gives you a good protection. But if you have a
XSS problem with your website the attacker could receive the
session cookie via XSS (see the facebook example above).
After that he can set up his form using the checksum.
The best way is to include a random string which has to be stored
somewhere for comparison on the server side.
moritz
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
