-2

Let's say, I store a plain password of a user in a global JS variable.

May anyone come up with an idea of how a hacker may get that value from user's browser? I now that it's "possible", but I need examples with description.

Improve this question

2 Answers 2

Reset to default
3

Imagine you are using a web site that is a forum (similar to this one) where users can enter their own content and other users can see it. Now imagine this site didn't cleanse my input properly, and I figured out a way to write a post that, when rendered on your browser, embeds executable Javascript. When you go to view my post, that Javascript will execute within your browser and it will be able to access the global JS variable, and therefore obtain the password.

This sort of thing is called a stored XSS attack.

Improve this answer
8
  • 4
    Don't roll your own security. Forget about storing a key in Javascript; use SSL.
    – John Wu
    Aug 22, 2016 at 18:58
  • 3
    Then get it. The scheme you are describing is vulnerable to all sorts of common attacks. If you would like a list of the problems, start a new question and describe your security scheme-- it'll get torn down in short order.
    – John Wu
    Aug 22, 2016 at 19:00
  • 1
    I agree with @JohnWu. If you are interested in learning more about XSS vulnerabilities in order to protect against them while still relying on conventional and accepted security measures, that's one thing. But asking about the potential vulnerabilities of an XSS attack on a "roll-your-own" security scheme is ludicrous. And what do you mean you don't have SSL? Secure communication between a client and server relies on asymmetric (pubic/private key) encryption, or, wait for it, SSL.
    – Verbal Kint
    Aug 22, 2016 at 19:06
  • 3
    Unless you are using a (pre)shared secret there is no way to establish a secure tunnel with the server... in fact there is no way to even be sure you are talking to the server to begin with. You need SSL with certificates and chain of trust, there is no avoiding it.
    – John Wu
    Aug 22, 2016 at 19:07
  • 1
    I'd reiterate what John said - get SSL. It doesn't matter if you don't have it - it is easy to get.
    – Rory Alsop ♦
    Aug 22, 2016 at 20:41
0

JavaScript runs client-side, and can be seen by anyone who has access to the page they are on. When your browser connects to a site, one of the things it can download and execute is JavaScript. So storing any confidential information in a global JavaScript variable is a terrible idea and you wouldn't need a convoluted XSS script to access it if it is on your own page.

Also, JavaScript is not persistent, or at least it shouldn't be, with the exception of cookies. Cookies can be used to authenticates users on a site on a per-session basis. Essentially, when they connect to a site and enter valid login details, they are issued a valid session cookie that acts as an id granting them access to otherwise inaccessible or private content/pages.

Here's where cross-site scripting can be dangerous. Say that a website allows JavaScript in messages between users, and you send a message to the web admin with JavaScript that grabs the admin's cookie. From there you could theoretically steal the admin's user session and would have all of the permissions the admin has.

Going back to your original question, if a user somehow had their password in a JavaScript variable (it only would exist on their computer, because JavaScript is client-side), you could theoretically send them a message or post a comment on a page they visit with malicious JavaScript that sends you a message with the values of every variable in the JavaScript on their browser. But again, if you're storing passwords in plaintext in JavaScript, you have bigger problems.

Improve this answer
4
  • Ok, the idea is, I generate a key on the client side, and write it in a SESSION variable, when the page opens. something like this: glbkey=<?php SESSION["key"] >; This key I want to use to send encrypted data to the server ( the key would be used in AES )
    – Sonya Seyrios
    Aug 22, 2016 at 18:55
  • Then the same thing applies, it is unique to that user's session, which could be accessed from an attacker if he can get the victim to run his code.
    – Verbal Kint
    Aug 22, 2016 at 18:58
  • Basically it relies on the fact that your browser assumes that the script is runs is the script you or the websites you purposefully visit want it to run. The JavaScript that it gets and runs from a website could contain malicious code from an XSS injection, as with a posted comment or message, but your browser has no way of telling apart that script from the legitimate website script.
    – Verbal Kint
    Aug 22, 2016 at 19:00
  • Ok, the problem is, I don't have SSL. But I need to send to the server encrypted data ( not a hash ). So, I need a secure key exchange with the server.
    – Sonya Seyrios
    Aug 22, 2016 at 19:04

You must log in to answer this question.

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