NYCPHP Meetup

[Felix Shnir]

One way of handling xss detection in your case would be to check if your
form/page is being framed. Something like window.top != window would tell
you that. Based on this, you could notify the server to invalidate one time
token generated for this page if the page is in a frame.
On Jun 24, 2014 12:09 AM, "Michael B Allen" <ioplex at gmail.com> wrote:

> Hey,
>
> I've always used hash tokens in forms to sanity check POST requests.
> Meaning a random hash is generated on the server which is both stored
> in the session and emitted in a hidden field in the form so that when
> the form is submitted the server can remove it from the session and
> check it against the hash sumbitted with the form. If the client
> doesn't submit the one-time-token, there is no action taken.
>
> Just from Googling around it seems that this is fairly common, if not
> standard practice (Windows calls them "AntiForgeryToken"s). I found
> one claim that this actually thwarts CSRF and XSS although it seems to
> me that an attacker could use an async request to get a valid token
> before it submits the CSRF request. So I'm wondering if there is a
> better way.
>
> Specifically, my question is, is there anything about the legitimate
> request that would be reproducably different from the attacker's
> request (even though it was from the same browser instance - just not
> a page generated by the legit site) that could then be factored into
> the hash on the server?
>
> So does anyone have a clever technique they want to share (perhaps
> privately)?
>
> Mike
>
> --
> Michael B Allen
> http://www.ioplex.com/
> _______________________________________________
> New York PHP User Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> http://www.nyphp.org/show-participation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20140625/ba3201a8/attachment.html>