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.

How to make website run only when Javascript is enabled?

It seems to be simple to find but when I searched for this I only found how to enable or disable Javascript on your browser. There are many websites which make it compulsory for Javascript to be enabled and I want to know how. Is there any setting? I want this facility on a website developed using PHP.

This question explains some great solutions for checking whether or not JavaScript is enabled.
You can take those answers and try to implement them. You can do what Marc Gear said
There isn't a good way to perform server-side JavaScript detection. Instead, use JavaScript to set a cookie, and then test for that cookie using server-side scripting upon subsequent page views; deliver content appropriately.
However on the first visit there would be no good way to test for Javascript, so you could use the <noscript> tag to possibly display some alternate text like "Pleas enable JavaScript then reload," though that solution doesn't really let you control whether or not java script is enabled.
In the end, there is no way for you, the server, to enable JavaScript. It is a client-side seting that the user has complete control over. You can only check to see if it is enabled, and if it's not, then encourage the user to enable it.

On the fly website manipulation using

I am trying to work out if I can alter the functionality of a website preferably through vba (access) or any other way that I can centrally manage. What I am trying to achieve is, depending on permissions, I would like users to log onto a website and the website is then changed on the fly to stop the user using normal functions of the website. For example some users have access to a submit button while others do not.
I have seen that you can use VBA to parse websites and auto logon. I'm just not sure if its capable of doing any local scripting like greasemonkey does.
Maybe I am looking at this wrong and can achieve this at the firewall level instead of running website scripts.
Any ideas?

You should not manage website permissions using a client-side technology like JavaScript. Users can easily either just disable JavaScript/VBScript or tamper with the page.
The best approach is to manage permissions by emitting the HTML from a server-side scripting language such as ASP.Net or PHP.
ASP.Net has built-in, generally adequate support for membership, roles and permissions that would meet this need.
http://msdn.microsoft.com/en-us/library/yh26yfzy(v=vs.100).aspx
If that is not an option for whatever reason, and you can accept the risk of someone tampering with the permissions you setup, you can certainly use something like jQuery to hide portions of an HTML document that a user should have no access to. You can accomplish the same thing using JavaScript without jQuery, but I would suggest jQuery because it abstracts away many of the cross-browser issues.
If you do that, hide everything by default and then show selectively based on permissions. That way, the simplest method of just disabling JavaScript will not reveal anything special (though it is still quite easy to hack).

Make programming langugage for your web app in JS that compiles to JS w/ PHP to ensure thorough filtering of user-uploaded html5 canvas animations?

A persistent follow-up of an admittedly similar question I had asked: What security restrictions should be implemented in allowing a user to upload a Javascript file that directs canvas animation?
I like to think I know JS decent enough, and I see common characters in all the XSS examples I've come accoss, which I am somewhat familiar with. I am lacking good XSS examples that could bypass a securely sound, rationally programmed system. I want people to upload html5 canvas creations onto my site. Any sites like this yet? People get scared about this all the time it seems, but what if you just wanted to do it for fun for yourself and if something happens to the server then oh well it's just an animation site and information is spread around like wildfire anyway so if anyone cares then i'll tell them not to sign up.
If I allow a single textarea form field to act as an IDE using JS for my programming language written in JS, and do string replacing, filtering, and validation of the user's syntax before finally compiling it into JS to be echoed by PHP, how bad could it get for me to host that content? Please show me how you could bypass all of my combined considerations, with also taking into account the server-side as well:
If JavaScript is disabled, preventing any POST from getting through, keeping constant track of user session.
Namespacing the Class, so they can only prefix their functions and methods with EXAMPLE.
Making instance
Storing my JS Framework in an external (immutable in the browser?) JS file, which needs to be at the top of the page for the single textarea field in the form to be accepted, as well as a server-generated key which must follow it. On the page that hosts the compiled user-uploaded canvas game/animation (1 per page ONLY), the server will verify the correct JS filename string before echoing the rest out.
No external script calls! String replacing on client and server.
Allowing ONLY alphanumeric characters, dashes and astericks.
Removing alert, eval, window, XMLHttpRequest, prototyping, cookie, obvious stuff. No native JS reserved words or syntax.
Obfuscating and minifying another external JS file that helps to serve the IDE and recognize the programming language's uniquely named Canvas API methods.
When Window unloads, store the external JS code in to two dynamically generated form fields to be checked by the server in POST. All the original code will be cataloged in the DB thoroughly for filtering purposes.
Strict variable naming conventions ('example-square1-lengthPROPERTY', 'example-circle-spinMETHOD')
Copy/Paste Disabled, setInterval to constantly check if enabled by the user. If so, then trigger a block to the database, change window.location immediately and check the session ID through POST to confirm in case JS becomes disabled between that timeframe.
I mean, can I do it then? How can one do harm if they can't use HEX or ASCII and stuff like that?

I think there are a few other options.
Good places to go for real-life XSS tests, by the way, are the XSS Cheat Sheet and HTML5 Security Cheetsheet (newer). The problem with that, however, is that you want to allow Javascript but disallow bad Javascript. This is a different, and more complex, goal than the usual way of preventing XSS, by preventing all scripts.
Hosting on a separate domain
I've seen this referred to as an "iframe jail".
The goal with XSS attacks is to be able to run code in the same context as your site - that is, on the same domain. This is because the code will be able to read and set cookies for that domain, intiate user actions or redress your design, redirect, and so forth.
If, however, you have two separate domains - one for your site, and another which only hosts the untrusted, user-uploaded content, then that content will be isolated from your main site. You could include it in an iframe, and yet it would have no access to the cookies from your site, no access to redress or alter the design or links outside its iframe, and no access to the scripting variables of your main window (since it is on a different domain).
It could, of course, set cookies as much as it likes, and even read back the ones that it set. But these would still be isolated from the cookies for your site. It would not be able to affect or read your main site's cookies. It could also include other code which could annoy/harrass the user, such as pop-up windows, or could attempt to phish (you'd need to make it visually clear in your out-of-iframe UI that the content served is not part of your site). However, this is still sandboxed from your main site, where you own personal payload - your session cookies and the integrity of your overarching page design and scripts, is preserved. It would carry no less but no more risk than any site on the internet that you could embed in an iframe.
Using a subset of Javascript
Subsets of Javascript have been proposed, which provide compartmentalisation for scripts - the ability to load untrusted code and have it not able to alter or access other code if you don't give it the scope to do so.
Look into things like Google CAJA - whose aim is to enable exactly the type of service that you've described:
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.
One issue here is that people submitting code would have to program it using the CAJA API. It's still valid Javascript, but it won't have access to the browser DOM, as CAJA's API mediates access. This would make it difficult for your users to port some existing code. There is also a compilation phase. Since Javascript is not a secure language, there is no way to ensure code cannot access your DOM or other global variables without running it through a parser, so that's what CAJA does - it compiles it from Javascript input to Javascript output, enforcing its security model.

htmlprufier consists of thousands of regular expressions that attempt "purify" html into a safe subset that is immune to xss. This project is bypassesed very few months, because it isn't nearly complex enough to address the problem of XSS.
Do you understand the complexity of XSS?
Do you know that javascript can exist without letters or numbers?
Okay, they very first thing I would try is inserting a meta tag that changes the encoding to I don't know lets say UTF-7 which is rendered by IE. Within this utf-7 enocded html it will contain javascript. Did you think of that? Well guess what there is somewhere between a hundred thousand and a a few million other vectors I didn't think of.
The XSS cheat sheet is so old my grandparents are immune to it. Here is a more up to date version.
(Oah and by the way you will be hacked because what you are trying to do fundamentally insecure.)

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.