11

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!

Kris.Mitchell
  • 998
  • 4
  • 17
  • 34
  • Related: http://stackoverflow.com/questions/198462/is-either-get-or-post-more-secure-than-the-other – Rob W Apr 26 '12 at 12:34
  • I am just curious, why php? most of the time when I want to make a call to the database (I use MVC3) I have the call go to the controller and do what I want with it from there. Personally, I can think of two possibilities. If you would have such a call that posts info to a database via ajax, the best thing would be to add a one time key to any call you would want to make. That would secure it to some extent. All you would have to do is not have the key view-able until the call is made then bam, it is already used. Hmmm, I will have to think more on this issue. – John Sykor Apr 26 '12 at 12:39
  • It's not so much a "jQuery ajax" problem, or a jQuery problem, or an ajax problem, it's more generally a "users can fake the whole client-side" problem." @John Sikora - Why not PHP? The database access is still happening server-side, the equivalent of what you do in MVC3. – nnnnnn Apr 26 '12 at 12:43
  • Well, in MVC, if you simply did a form post, I don't know how you are going to get malicious things into the database when it goes through the controller via a model, they don't know how it is being processed, they can't modify the model besides what is in the boxes, in addition, it still should be run by a validator. I am just wondering where the hole exists? Besides any idiot just adding a billion lines to your database? – John Sykor Apr 26 '12 at 12:50
  • 3
    I don't get why people think that ajax is supposed to disguise the client-server interaction in any form, it is just a method of communicating with the server, an interface nothing else. Using ajax doesn't really change anything at all, if your back-end is safe, your website is safe, regardless of the way to communicate with the back-end. Are you worried about changing of price in your cart? I suggest you don't process any client supplied prices at all, just use IDs and retrieve price from the database... – cyber-guard Apr 26 '12 at 13:05

6 Answers6

15

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.

hvgotcodes
  • 118,147
  • 33
  • 203
  • 236
10

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.

David Hedlund
  • 128,221
  • 31
  • 203
  • 222
3

You can never rely on any actions or data coming from client side, not only related to jQuery.

You must handle every kind of security concerns on your server side. Always double check data coming from user (one is on client side for decreasing number of requests for performance; and the other is on server side for actual confirmation).

The request type (GET or POST) actually does not matter, it may be simulated easily. After user tries to add a $50 item for $25, you should check your DB and confirm the actual price of item.

SadullahCeran
  • 2,425
  • 4
  • 20
  • 34
  • I agree. It was a basic example trying to illustrate a point. – Kris.Mitchell Apr 26 '12 at 12:35
  • I know, and it was a basic suggestion for a basic example :) – SadullahCeran Apr 26 '12 at 12:37
  • I agree, if I was ever passing the pricing info around, I would already feel it is unsecured. If pricing or the bill total was ever passed, you would want to encrypt it so it can't just have a random number thrown in and do a dbl check on items vs price. Otherwise, the most efficient thing to do is is keep the value always serverside and never grab it from the client. only grab the items being purchased and charge them for it. In addition you clearly dont want the products in the list to be modified after final confirmation either. only if they were to go back a step and add or remove product – John Sykor Apr 26 '12 at 12:58
2

You should NEVER write code such way, price is transferred from client separately, cause anybody can send data with price = 0 or 0.01 for any amount of goods/services or whatever.

More general: never trust client data.

kirilloid
  • 14,011
  • 6
  • 38
  • 52
2

yes you need server side security to verify every data were send to your server. For example you validate data in javascript/jquery:

if($(this).val() != ""){
   // post to my server page (mypage.cfm/php/asp)
}

but if you don't secure your server page, i can post empty data to ur server very easy and avoid javascript, so u need to secure server page with another validation script, for example:

<cfif val is "">
  //dont post to my server ...
</cfif>

sometime it's double job, but we all face it sometimes ....

2

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.

Ken Ma
  • 21
  • 2