Basically you need to put something like this on a page you control (where "xss code" is the code triggering the XSS):

    <form action="https://www.paypal.com/de/cgi-bin/searchscr?cmd=_sitewide-search" method="post">
        <input type="text" name="queryString" value="xss code" />
    </form>

Then, just as the page loads, submit that form and you're executing JS on a paypal.com page. This would work great for phishing or session hijacking.

Isn't this CSRF?

Combination of XSS and CSRF.

This seems like it's just plain XSS - it doesn't take advantage of a user's serverside session to forge an action on their behalf.

As an example, an attacker can craft a script that would run within the paypal.com domain name. The script can therefore potentially grab the user paypal session (if the user is already logged in). Otherwise, it can show any information the attacker wants, and to the user this looks like a real trustworthy paypal page. It is running on the paypal.com domain, and the browser shows it's secured and trusted. So for example, it can display the login page and asking to confirm the password, or keylog anything the user presses etc.

This link can be embedded on a different site, or sent via email, and because the link itself points to paypal.com - it is much more likely to be trusted by unsuspecting users.

> This link can be embedded on a different site, or sent via email, and because the link itself points to paypal.com - it is much more likely to be trusted by unsuspecting users.

Doesn't seem like that is the case here. The bug is in the search form, which is POST only. It wouldn't be enough to share the link to the search page, you'd need something that does the search on your behalf.

It doesn't matter that the form is POST only if it doesn't do CSRF checks. (I haven't checked.)

That is not what I am disputing. If there is a bug in paypal's search via POST only, you cannot link to paypal's search. You would need to link to a page you control that performs the POST automatically. If you send a link to the search that only takes parameters via POST, paypal will never receive the payload.

if the paypal search only accept POSTs then you're absolutely right. It won't be as easy as sharing a link. If it happens to also accept GET requests, then it would. I didn't test this.

Note that _if_ the form is already CSRF-protected, then attackers won't easily be able to POST from a different domain either, which would drastically reduce the attack surface.

I didn't test this, but I'm not sure the form is fully CSRF protected though. I tried to explain the potential exploit from this discovered vulnerability. Perhaps I should have stated more clearly that this is more a general comment, and not specific to this particular case.

I'm not sure whether you'd still have access to cookies, but it's entirely feasible to include a script which will then submit the POST request.

Although the user has to place in the payload himself to exploit this vulnerability, there are a few ways the attacker can use this. The most obvious and simplest to do is to create a form that does the search for the user, and thus fills out the form for the user, exploiting this vulnerability. You could have the form submit automatically via javascript on page load, requiring no user interaction.

Once the form has been submitted on behalf of the user, you have javascript execution in the context of paypal.com, and can do pretty much anything. Send the contents of your account to another address, shut down the account, exfiltrate past transaction data, etc.

I'm sure PayPal is using some form or CSRF protection to prevent a POST from some external site from working.

There's a CSRF token in the form, but deleting it doesn't seem to cause the search to fail.

It's a search form.

It seems quite possible that CSRF checks could have been omitted in not expecting this to be a source of woe. Just goes to show... :P

I could set up a redirect to POST data to that search form and steal his cookies/replace the page with a login form/all the fun you get running arbitrary javascript.

If you can redirect someone to that page you could redirect them to any page... But they want to go to PayPal, you send them there, and you pass along some post data to hijack their session.