3 ms·
What proof do you have that #6 is not persistent XSS? If it is, that's a potentially brutal vuln (as persistent XSS often is), even if you need the users pass
by blazespin 7y ago
What proof do you have that #6 is not persistent XSS? If it is, that's a potentially brutal vuln (as persistent XSS often is), even if you need the users password to exploit it.
And persistent XSS is definitely not out of scope according to PayPal's guidelines. https://hackerone.com/paypal https://hackerone.com/paypal
Why are you saying #6 --- are duplicates of other people's issues. ? It must have been marked as dupe of N/A. They would haved gained rep if it was a dupe of someone elses report. They lost rep, so it was most likely marked as dupe of an N/A.
As I mention below, the big problem is the OP didn't include POCs. It's easy to claim "oh this is can be exploited so easily" but without a POC, it's not always clear and perhaps he missed some detail that made his assumptions incorrect.
Anyways, I do have to say hackerone looks pretty cool. This is the first I've seen it and they seem like they are working very hard (we all should be working hard) to make this work for everyone. They are likely just victim's of their success.
- tptacek 7y agoI agree that real stored XSS is a serious issue. Here, they're using a MITM to get the XSS payload injected, and Paypal has closed it saying it's not "externally exploitable". It sure looks like self-XSS to me. I agree: a POC would clear this up. All I'll say beyond that is that if they had doc'd a real stored XSS bug in Paypal, my assumption would be that they'd get a bounty for that. That they did not get a bounty for it suggests that it was invalid. Paypal does not have any incentive to stiff researchers on valid submissions; they have in fact the opposite incentive.