3 ms·
> Surely (obviously not) at this point in time there has to be some out-of-the-box browser-engine (webkit/blink/gecko) input sanitation for widgets like "input"
by chmod775 5y ago
> Surely (obviously not) at this point in time there has to be some out-of-the-box browser-engine (webkit/blink/gecko) input sanitation for widgets like "input", "textarea", etc?
Client side sanitation of input fields won't save you in this case.
In fact it will never save you.
Here's a "non-technical" example of why it wouldn't help, without even having to go into the details of making manual HTTP requests: Even if you have a browser that tries to sanitize input fields so it doesn't send anything to the server that causes the server to do bad things, an attacker could just use a different browser, or a modified browser, to send whatever the hell they wanted anyways.
Client side input sanitation is not security. It's just for UX.
- chrisjc 5y agoWhile what you're saying is true and what I said is not what is actually happening, I don't think you understood what I was trying to describe. And even though that's the case, I may still be wrong. I understand that client-side validation is only a cosmetic, first-round attempt at sanitation. My understanding (which is wrong) was that the malicious script was being injected into the html input where it was finally rendered and at the same time invoked. I was suggesting that the contents of an input (the value) should never be rendered (and as a result, activated) as any other contents outside of an input is rendered. Even if content within an input is never rendered, it makes little difference since the attack is able to inject the script in other places outside of an input anyways. So as others pointed out, nothing to do with inputs.