Security risk in using jQuery Ajax

Question

This is a question has has been bother me for a while, so I am looking for opinions and solutions to clamp down on the possibility of the app being a security risk.

I use jQuery for lots of things, but mainly I use it for processing jQuery dialog windows. A lot of times there is the need to grab a value from a field on the form, concatenate that information with a .serialize() command and pass it off to jQuery ajax call to head over to PHP files for database interaction.

Here comes my question (finally),

Isn't it riduclasly easy to 'guess' what the url could look like for the PHP processing?
You can open the source in a modern browser and click a link to look at the full JavaScript file containing the ajax call.

I could possibly Minify the JavaScript file for obfuscation, but that's not a form of security to be relied apon.

I am using PDP for databases access with prepared statements for SQL injection attacks, but if someone took to the time to look, couldn't they just form a valid url send it off to the database and insert what they want?

I am not talking about hacking the database to steel information, I am more talking about inserting malicious information as though the data was added from the application itself. Think adding something to your shopping cart that is $50 for only $25.

If it just as simple as turning the ajax request from GET to POST and changing my PHP files?

Edit: The person is logged in and properly authenticated.

Just wondering what other people out there do.

Thanks!

Answer 1

Risks with database usually are: Malicious data, SQL injection, CSRF.

Minifying/uglifying your javascript can help. But your user can easily capture their own request data, regardless what you do. And there is no definite way to prevent users from going through the messy code.

Security is only true, when users cannot hack you, despite knowing all your source code and configurations.

There is no simple solution to security. Here are some general practices to avoid problems in most situations:

Use HTTPS, and POST requests. With POST requests over HTTPS, request datas are encrypted. The URL is exposed but thats usually alright. This prevents man in the middle attack and highly reduces privacy concerns(e.g. password/credit leakage). If you use GET request, all your data are passed as query string in the URL. That means a good chance to alter your data for third parties.

Server side verification Always verify the data at server-side. The user might be malicious, and there might be bugs at client side. For example, calculate the total price on server side, not client side. Otherwise the user might put a 0 there.

Access right control AKA Authorisation Set limitations on the actions allowed, and limit their effective scope. For example, do not allow users to place order on others behalf. And do not let them delete their action history.

Generate tokens to prevent CSRF some libraries can protect against CSRF. Or you may implement your own. The main concept is to generate a random token and request client to pass it back. This prevent other web-sites from triggering requests to your server(with your clients credentials)

Proper back up and loggin Back up your database regularly will help to recover from disasters (Yes, they will happen) And track what users had done through logging modules.

Answer 2

Even if you switch from GET to POST, it will still be very easy for anyone interested to see (and change) any parameter being passed to your server. But here's the kicker: even if you're not using AJAX at all, but plain old forms, it is still extremely easy to see and edit any parameter being passed to your server.

In critical situations, you can never rely entirely on what you receive from your clients.

For instance, if you're adding something to your shopping cart, pass only the ID of the item, and the quantity, to your server. Do not fetch price details from your client, but from your database. If some one tries to hack you and edits the item ID or quantity being sent, the worst thing that happens is that they end up buying something they didn't want; entirely their problem. (But for the very same reasons, if it's a limited offer, you would need to verify that the quantity you receive is not greater than what you allow any one customer to buy, for instance).

So at the end of the day, it's always you the developer who will have to decide which values you want the user to control, and validate at your server side that you have not recevied any requests that are outside the bounds of what the user ought to be able to do.

Answer 3

You are quite correct, anyone who is slightly tech savvy can identify the public server endpoints for any webapp. They don't even need to look at the code. They can just use their webkit/firebug to track the request, or a program like Charles which monitors network activity.

That's why you need authentication and authorization handling in your server side code.

Authentication is typically handled by a username and password; it is the act of verifying a user is who he is.

Authorization can be handled by Roles on the server, and is the check to make sure the user can do what they are trying to do.

Which those two mechanisms in place, even if a user knows a url, they still need to "log-in" and have permission to do what they want to do.

Think about it. If you look at your bank account information online, you can easily identify the requests that load your account info. Without these mechanisms, what is to prevent you from simply changed the account-id you pass to the server to try and get someone else's account info? With authentication/authorization, the server knows that even if it gets a request to load some data, it can check the user's details to see if they have permission to get that data, and deny the request.