Since a login page isn't going to reflect any other user's stored data back, and certainly shouldn't do anything with taking a password from the URL and putting it in the DOM client-side, the only approach that would make sense is reflected XSS.
ABYSS WEB SERVER PASSWORD CODE
You could also return the value in an API response and have client-side code inject it as text (this is what e.g. This applies to all user input that ends up in responses.
Even if, for some security-forsaken reason, you wanted to return a password in a response, you should apply standard anti-XSS measures to it, like output encoding.Hash digests won't contain those characters (under any likely encoding), shouldn't ever be put in responses either, and having those characters in the input is irrelevant to the digest anyhow. Passwords should only ever be persisted in the form of digests from salted and expensive hashing functions.If the quality check (which can be done every time, or only at password creation/rotation) fails, you still should immediately forget what it was (and definitely shouldn't return it, see #1). It shouldn't even be possible to do this the server should not store the password (even in memory) for any longer than is needed to verify its quality and then hash it.There's just no situation where a user-specified password should ever be present in any content returned from a server.
Foremost, passwords in general should literally never be in responses.However, that shouldn't ever be a problem, for so many reasons. The typical danger in such characters is if they're ever output into the response, in which case they could lead to XSS. (Less-generous possible explanations are up to the reader.) Generously? Because that restriction was created by somebody with no understanding of web security.
0 kommentar(er)
