Is it considered bad form to execute javascript returned by an AJAX call?_问答_开发者

I'm modifying an existing web application that features the ability to administrate users who are able to log into the system. When modifying a user's details via a dialog, update data is sent to the server via AJAX. A few lines of javascript to th开发者_Go百科en update the current page to reflect these changes is returned with the intention of being executed. This strikes me as poor form - isn't executing remotely acquired JS dangerous?

If I were to modify this, I would have the AJAX call that sends the updated information then call another function that gets the latest data from the server via AJAX (or just refresh the page, if I am feeling lazy). Is there any advantage (mainly security, but from an architectural perspective as well) to making this change, or am I being anal?

Assuming we're talking about eval used on non-json.

People will tell you all sorts of things, most of it has some basis in reality. I'd say one reason that is really understandable: it will make the code a nightmare to maintain and it will be very hard to trace bugs.

There are security concerns, a lot of people like to jump on the "javascript is the clients problem" bandwagon. I say if it comes from your site, it's your problem too.

In the end, there is no good reason I can think of to eval javascript from the server. Pass data from the server, and write the javascript on the client-side to react to that data.

All JS executed by the browser is remotely acquired.

The server that returned the JS/JSON via AJAX is the same server that returned the HTML that did the AJAX call in the first place.

It if's possible to do something bad, it can be done whether you eval the result of the AJAX call or not.

Personally, I don't see the issue. Sure, people say things such as "It allows code execution client-side" however if the potential attacker is able to affect that, then that's your problem - not the ability to modify the code.

Seriously, I think you have far more pressing concerns than that. I'd personally spend that 10 minutes or so reviewing your code and looking for flaws instead of working on an alternative to eval(). I think it'll improve your security a fair bit more.

Mike Samuel mentions MITM. I don't see why. If you're susceptible to a MITM attack then chances are that code can be injected straight into the initial HTML page (again, sure, slightly higher risk but is it really worth worrying about? Your choice.)

If a trusted developer wrote all of it and you protect it the way you do the rest of your HTML page, then no.

But even if it is JavaScript written by trusted developers, if it is served over HTTP, then an attacker can modify it in-flight because HTTP over free wireless is often susceptible to MITM.

This can be used to effectively install a keylogger in the current browser window to steal user passwords, redirect them to phishing pages, etc.

The attack might work like this:

Web page does a GET to http://example.com/foo.js.
Attacker modifies foo.js mid-flight to add JavaScript that does window.addEventListener("keypress", /* a keylogger that sends all keys to evil.com cross domain by image loading tricks */)
Browser loads modified JavaScript.
User enters a password in an <input type=password>.
Evil wins.

Since HTTPS (assuming no mixed content) is not susceptible to MITM, it is not vulnerable to this attack.

You probably don't want to just call another function after you send the data update because you could then display information that isn't true if an update fails. At least with the current model, your service can tailor the javascript based on whether or not the update was successful. You may want to consider having the service just return a true/false and have the call back function handle the updating of the UI.

Sort answer: Yes

Long answer: You should just send data for both security reasons and to keep your implementations separate.

Improperly sanitized user-submitted content or advertisements could inject code and get it run. Granted, this would have to be a targeted attack, but hey maybe you're working for a startup that's going to be the next Google or a forum system that's going to be the next vBulliten. Even if you have 10 users, security holes are still holes and are still bad for you and your users. Also, bad security advice left lying around SO will lead others to make bad decisions.

Do you really want to have to make sure the code you generate on the fly and send to the client is correct in all possible cases? What if someone else works on just one half of the system? Are they going to know every variable name to avoid stomping on? Just sending data is the best way to keep a 'small' change in your client/server communication from breaking everything in ways that aren't obvious and will take forever to debug.