5 ms·

I 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 a

by donatj 7y ago

I 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 ago
Why 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 ago
  You 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 ago
    Hmm, 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.

5 ms·

I 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 a

by donatj 7y ago

Thorrez 7y ago
Why 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 ago
  You 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 ago
    Hmm, 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.