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" <iop...@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 >
_______________________________________________ New York PHP User Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/show-participation
