4 ms·
I guess this will lead to a horrible coding style where instead of having this in the form: <input name="email"> We will see stuff like this: <input
by TekMol 7y ago
I guess this will lead to a horrible coding style where instead of having this in the form:
<input name="email">
We will see stuff like this:
<input name="16fkr9547kancot944128sddfksdf934998aafccugt75">
Where developers use some type of abstraction that generates a random id for each field and then assigns it to the original value server side or in javascript.
Just like they already randomise asset filenames to avoid caching.
- wiredfool 7y agoI’m doing this with a field where I provide server side autocomplete of an item. It sucks, but I can’t find a better workaround.
- donatj 7y agolol, years and years ago (like 2005) as an attempt at stopping XSS and CSRF attacks and bots I came up with a system that named all the inputs a salted MD5 of the intended name with the salt randomly generated then stored in the users server side session. It’s still a reasonably effective solution for CSRF, though there are much simpler options, but today’s bots largely have cookie jars so you will likely need a CAPTCHA.
- Thorrez 7y agoHow would it stop XSS? Is it meant to stop attackers from getting JS execution on your site, or to mitigate the attackers' abilities after they have JS execution? I don't see how it would do either.
- justicz 7y agoMaybe they mean CSRF? Then things make more sense since you can’t guess the field names cross-origin.
- donatj 7y agoI mean both CSRF and XSS. If your inputs are named something different on everyone’s machine, per session, you can only XSS yourself. Not very useful, you can already do in many other ways. Also my comment above is not an endorsement of the methodology, it’s just a thing that happened.
- Thorrez 7y agoWhy can you only XSS yourself? If an attacker has javascript execution on the website, the javascript can identify forms not just via their names, but by relation to other elements in the DOM tree. The javascript can for example do document.querySelector("form > input"); That doesn't rely on names at all. Just like a human can use eyes to find the right input, the javascript can use the DOM tree to find the right input. I understand that it provides CSRF protection. It's basically a CSRF token embedded in the name.
- donatj 7y agoYou misunderstand. Specifically on sites without cross-user visible content, the JavaScript needs to get into the system via an input, POST or GET. When every user input is named something different, you have no ability to send a link with a JavaScript payload.
- Thorrez 7y agoHmm, I guess it could provide some protection against some types of XSS, but it's not comprehensive. It doesn't provide any protection against stored XSS. And even for reflected XSS, it assumes the only dynamic thing in your URL is form inputs. An example of something dynamic in your URL that's not a form input would be links to various articles posted through some type of CMS. For example http://example.com/article?id=foo http://example.com/article?id=foo or even http://example.com/article/foo http://example.com/article/foo . In both cases if foo doesn't exist, a badly-written error page could print out "Error, foo was not found" without escaping foo.
- ProfSarkov 7y agoIt's like Internet Explorer 6 all over again. SAD.
- StavrosK 7y agoYour comment about randomizing filenames got me thinking. It would be great if we could add a cache key to the HTML element, that way we could cache everything forever with the same filenames and still invalidate things by just making the key being the SHA of the deploy. Too bad that's not a thing.
- jstanley 7y agoThat is a thing already! https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
- StavrosK 7y agoSubresource integrity is for ensuring that you got the right file (it fails if you didn't), it doesn't do anything with the cache, unfortunately.
- jstanley 7y agoReally? Seems like it would be crazy not to use it for caching.
- summm 7y agoThe problems are 1) side channels. Caching those would mean that a malicious script could use timing to find out if the user accessed specific other websites. Also it enables a channel for cross-domain communication. 2) malicious user tracking would not work as well anymore, which would be good but Google probably will not support that. Currently they get all those nice http log entries from sites that only include fonts etc.
- Natanael_L 7y agoFor sensitive files with known names, you should be able to set that the cache is only valid for requests from the same host website (as the server might decide to send another response when the host is different). That would fix the sidechannel.
- xg15 7y ago> Just like they already randomise asset filenames to avoid caching. But why? Isn't the whole point of caching to improve delivery if static assets? Did they run into staleness problems? Then why not use if-modified-since/if-none-match?
- noselasd 7y agoYou are assuming browsers(there are many more than chrome&ff) ,proxies, etc. do caching correctly.
- summm 7y agoAnd you are assuming web devs could configure their servers properly. Anyway, it all boils down to the mentality of lowest common denominator: using that workaround, nobody has any incentive to fix their proxy.
- masklinn 7y agoMDN literally mentions jquery.disableAutoFill which basically does that for you under the cover (scrambling the name on display, and unscrambling on submission).
- mxxx 7y agoYep. We recently noticed this problem after renaming form fields for the purpose of accessibility (screen readers)