I just counted, I’ve used it thrice this year alone on assessments.
That’s very clever idea for pen testing.
What’s the proper way to defend against something like this?
The “short” answer is with input validation & output encoding (IV/OE). You should know the format of your data (it’s shape, length, composition, and type) as well as the context in which it will be used. Once you understand the shape of the data, and where it will be used, you can validate that user provided data (input) matches what you expect, and you can safely contextualize (encode) it for output.
That last point is far more tricky than people often realize; formats are far more complex than programers often realize (to wit, witness JSFuck), and if you mix in multiple representations, you’re in for a world of hurt. Take for example, the humble apostrophe; very often clients will get the correct escaping for say, their SQL database, and then completely miss the fact that they used the client-provided value in html: <img src='/some/user/provided/path.blah' onerror='alert(1)'>.
<img src='/some/user/provided/path.blah' onerror='alert(1)'>
So, round about back to your question: how do you defend against something like this? The simplest way is IV/OE, allowing the types/format in your program to deal with validation, and doing the input validation as early as possible, and the output encoding as late as possible. That last point is crucial; you want to reject invalid input early, and encode data only when you need to do so. Why only when you need to do so? To avoid things like double encoding, to avoid encoding for the wrong context, or to avoid modifying actually-correct data (O'Brien causing an error in multiple locations… oops).
I hope that answers your question.
Well this is…something.
Nice find arc.