3 ms·
There’s certainly not any inbuilt browser sanitation that prevents you entering XSS or other injection attacks into input fields. Thank goodness. If there was,
by jameshart 5y ago
There’s certainly not any inbuilt browser sanitation that prevents you entering XSS or other injection attacks into input fields. Thank goodness. If there was, how could you discuss examples in web forums like this? Or use a webpage to edit code?
XSS and other injections are not problems with data input, they are problems of data output.
- deleted 5y ago[deleted]
- mhh__ 5y agoWell we are discussing it now with no issue, so clearly the browser could (or could have, probably too late now) picked a sensible default
- avian 5y agoImagine Stack Overflow, but without code snippets. Sounds more like an idea for an art project. It would probably read like early texts on mathematics before modern notation was invented, where it's all just textual descriptions on how to solve various problems.
- deleted 5y ago[deleted]
- gowld 5y agoThat's another way of saying "all code input must be escaped" :-)
- deleted 5y ago[deleted]
- mhh__ 5y agoAdding a flag to allow people to write stackoverlow is perfectly reasonable, the default should not allow non-expert programmers to waltz into issues like this.
- shkkmo 5y agoThis isn't "expert" level knowledge. This is a basic principle of any client / server system. In fact, including default client side protections would not have fixed this issue (since this issue involved bypassing client side protection.)
- jameshart 5y agoThe sensible default is to allow arbitrary text input and pass it on correctly encoded to the next system. Which is what browsers do.
- chmod775 5y agoBrowsers aren't doing anything differently because the people who write browsers happen to understand the threat model. You can sanitize input fields on the client all you want and an attacker would still send whatever the hell they felt like to the server.
- sgerenser 5y agoTrying to sanitize on the input side reminds me of Cisco’s fix for a vulnerability in their routers that involved disallowing requests with a user agent containing “cURL”.
- chrisjc 5y agoI'm not suggesting that it prevent you from being able to enter specific strings of characters. I think I made that clear by comparing this to a SQL injection issue. After all, how would SQL sites and forums discuss SQL without being able to store and display SQL excerpts? I'm suggesting that surely these widgets and respective browser engines that enable them would be mature enough to not ineluctably evaluate anything that's entered.
- chmod775 5y agoThat's not at all what's happening here. It doesn't even have anything to do with input fields, except that the field in the HTTP request that stores the information on Apple's servers was supposed to be filled from one. This kind of attack essentially tricks Apple into including arbitrary HTML/JavaScript in the webpage that shows information when someone scans the tag. There's no reliable way a browser could even know something untoward was happening.
- chrisjc 5y agoAh! I was actually struggling to understand how inputs had anything to do with it. I thought the input was being rendered with some pre-populated/injected value that in this case was the script. <input><script.../></input> Then again, if they were able to inject something into the input, chances are they could inject it anywhere, so as you said it has nothing to do with input fields. Thanks for the clarification.