> Successful exploitation of the vulnerability results in persistent session > hijacking (admin), account steal via persistent phishing or > persistent search module web context manipulation. > > Exactly how is the session hijacking/phishing/web content manipulation _persistent_? Just because the payload is _stored_ does not necessarily mean that is it always running.
> Proof of Concept: > ================= > The persistent vulnerability can be exploited by remote attackers with > privileged paypal user account and low required user interaction. > > [...] > > Manually reproduce ... > > 1. Go to the addressbook and switch to add a new contact to adressbook > 2. Include script code (html/js) as username to the addressbook and save > the context > 2. Now, switch to the user search (addressbook) module (other layer) & > click the user contact search to activate > 3. Include the exact name of the username (script code (html/js)) from the > addressbook and press the search button > 4. The context of the other layer from the addressbook will be executed > directly out of the results listing page of the exisiting user contacts > 5. Done! POST REQUEST: method="post" name="searchContact" > > How is THAT a "low user interaction" scenario? IIUC, victim has to manually (no mention of CSRF here) insert a XSS payload into his address book, then search for the payload exactly as inserted (is there a antiCSRF token needed for the search request) and only then is the payload executed. During this scenario user knowingly sees & uses Javascript code twice - that's hardly low interaction. Unless I'm missing something - is there a cross-account action going on where one user manipulates the address book for a second user (e.g. from the same organisation?) Best regards, Krzysztof Kotowicz
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
