3 ms·
lol, 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 t
by donatj 7y ago
lol, 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.