I've read this article about eval security issues.

I need a clarification about this particular situations:

For example, imagine we had a web app with a text field input that we were running eval() on. An attacker could easily run a script into your input field in order to perform a DOM Based XSS (cross site scripting) attack. This is an attack where malicious code is used to make the client-side DOM behave in an unexpected way, and therefore executes code differently within a user’s browser. This can be a route to render a malicious form into the page or redirect the user.

If i'm an attacker i could send my form with a malicious script as a value for that text field. The eval() call is in the javascript() on my browser. It isn't executed server side, how can it change internal application state?

I'm so confused :)

  • that's only a problem if you share the info entered into the box with other users, typically by pre-populating it with URL params or baking it into the HTML source of the page on the server. Remember that anyone can run whatever code they like all by themselves on your page using the developer tools.
    – dandavis
    Commented Jun 17, 2019 at 17:05
  • @dandavis anyone can run whatever code they like all by themeselves on your page using developer tools. yes, i know, this was exactly the reason because i wasn't persuaded about the dangerousness of eval function.
    – Pavoletto
    Commented Jun 19, 2019 at 13:35

1 Answer 1


With XSS (no matter if DOM based or reflected or stored, and no matter if done using eval or in other ways) attacker controlled Javascript is called inside the browser of the victim within the context of the victims current session.

This script can thus interact with the server through the browser the same way the user could interact with the server through the browser: fill in fields, press buttons, click links ... . While this directly only changes the state of the application on the client side it typically results also in requests from the browser to the server, which then change the application state server side.

While this kind of activity might be visible to the victim an attacker could also do it within some hidden iframe, in which case the state still gets changed (iframe shares the session) but is not that obvious to the victim.

  • Attacker and victim share the same session, so by the server point of view, are the same client. Am i right? Thank you
    – Pavoletto
    Commented Jun 16, 2019 at 15:36
  • @Paoletto: Correct, the server can not distinguish if this request intended by the victim since the attacker shares the same session as the victim. Commented Jun 16, 2019 at 17:09

You must log in to answer this question.

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