Sergiu Dumitriu wrote: > On 03/10/2010 07:44 PM, Caleb James DeLisle wrote: >> Take a look at the "sammy is my hero" worm, myspace sent a hash to the user >> like the one you propose, >> the worm made the required get request to get the hash, then made the post >> along with the hash. >> What prevents javascript from opening the page with the hash in an iframe >> and then reading in the iframe >> to get the hash, then creating a form with the required data and posting it >> to the save action? >> >> If we were to combine a requirement for post requests with checking of the >> referrer header, then we >> would block links, forms and javascript based attacks leaving only an attack >> through older versions >> of flash which support referrer forgery and at this point the difficulty of >> the attack becomes such that >> we need to consider a wider array of attack vectors. > > Sammy also required that XSS is enabled. > > Protecting from attacks originating in the wiki is kind of impossible at > the moment, since JS can be inserted anywhere, and there's no (nice) way > to prevent attacks from JS inside the application. As long as JS can be > inserted, an attacker can do all the steps that the client would do to > perform an action. > > The secret token works as a prevention mechanism when the attack comes > from another site because the browser security model prevents the attack > code to read the form.
I just did a few tests on iframes and I was wrong, they do have good same origin policy. Caleb > >> Caleb >> >> >> Alex Busenius wrote: >>> Unfortunately, using POST requests instead of GET requests is not >>> enough. It will not prevent attacks that use forms and/or JavaScript to >>> generate POST requests. >>> >>> Alex >>> >>> >>> On 03/09/2010 02:48 PM, Caleb James DeLisle wrote: >>>> I had thought about proposing this myself but decided against it because >>>> it seems >>>> to me like a workaround for problems which can be solved in other ways. >>>> >>>> Suppose we were to add a check to the actions which alter data which made >>>> sure the request method >>>> was 'post' and made it configurable in one of the configuration files? We >>>> would have >>>> to look over the default skins for incorrect links and leave the >>>> configuration >>>> option off by default for backward compatibility at least until the next >>>> major version >>>> but we could provide wiki operators the ability to prevent CSRF. >>>> >>>> Caleb >>>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
