Many developers believe that JavaScript's eval()
method should be avoided. This idea makes sense from a design perspective. It is often used as an ugly workaround when a simpler, better option is available.
However, I do not understand the concerns about security vulnerabilities. Certainly, running eval()
gives the hacker the ability to run any JavaScript code that you can run.
But can't they do this anyway? In Chrome, at least, the Developer Tools allow the end-user to run their own JavaScript. How is eval()
more dangerous than the Developer Tools?
An attacker doesn't have access to the user's browser's Developer Tools. The attacker is likely not the user sitting at the computer.
The danger of
eval()
is that an attacker may be able to manipulate data that is eventually run througheval()
in other ways. If theeval()
'd string comes from an HTTP connection, the attacker may perform a MITM attack and modify the string. If the string comes from external storage, the attacker may have manipulated the data in that storage location. Etc.As B-Con mentioned, the attacker is not the one sitting at the computer so could be using the
eval()
already in your script as a means to pass malicious code to your site in order to exploit the current user's session in someway (e.g. a user following a malicious link).The danger of
eval()
is when it is executed on unsanitised values, and can lead to a DOM Based XSS vulnerability.e.g. consider the following code in your HTML (rather contrived, but it demonstrates the issue I hope)
Now if the query string is
?foo
you simply get an alert dialog stating the following:Your query string was ?foo
But what this code will allow a user to do is redirect users from their site to a URL such as
http://www.example.com/page.htm?hello%22);alert(document.cookie+%22
, where www.example.com is your website.This modifies the code that is executed by
eval()
to(New lines added by me for clarity). Now this could be doing something more malicious than showing the current cookie value, as the required code is simply passed on the query string by the attacker's link in encoded form. For example, it could be sending the cookie to the attacker's domain in a resource request, enabling the authentication session to be hijacked.
This applies to any value from user/external input that is unsanitised and executed directly in the
eval()
, not just the query string as shown here.