Regulating Access to DataSource Backdoor for AJAX Requests

What you be the best way to regulate access to a module specifically designed to call any method in the data access layer? Obviously this brings up a huge security concern in regards to someone hacking the url and issuing their own call to my API which could possibly be reveal internal data or be destructive. So what would be the best way to allow AJAX request to access this API yet restrict the access to only requests coming from the server perhaps?

thanks in advance

Well I guess that I’m saying is the application needs to be able to access the API via AJAX requests for both users and non-users. So is there any solution to this problem or is this a common security pitfall with an open API in general? At which point the only solution seems to be to write specific methods designed for open API that don’t reveal critical data. However, I was hoping for my client-side code to be able to access the same exact methods my server side code has access to to retrieve data. That way nothing needs to be changed and all data layers are reusable for client-side and server-side data retrieval. Guess not though…

The only way you can provide a completely open API is if you can restrict access to the client’s source code completely, which is a very rare situation. Otherwise anything you do can just be reverse engineered.

isn’t what you’re talking about fundamentally exactly the same as form submissions? in fact do you have a non-ajax version as a base, then ajax as a js enhancement for js people, of what you’re asking about? if so, you probably already handle that fine (validation etc); do the same for the ajax. it just seems basically the same thing to me?.. could be wrong.

Its not the same thing at all. What I have is a SOAP like API that can be directly accessed through HTTP. The only difference is the interface is the entire program.

For example, by going to the following URL one would be able to execute the deleteUser(); method of the DAO User.

site.com/DAO/User/deleteUser/1

Which makes it very easy for my client-side interface to fetch data, but is huge security gap.

You could put your api on a server that is only reachable from within a local network.

Javascript requests are issued from the computer of the user visiting the website, not the server.

Not to mention, how would you “verify” if a request originated from your script this way? Remember not all of the $_SERVER variables are reliable since they are set by the sender.

There is no more security risk by using that, than by using “site.com/user.php?action=delete&id=1”. Just append a transparent verification process that only execute the command if the user is logged in, e.g. use sessions.

This is an option, but only when the API can be called from the script running on the other server, or if the server and the user is on the same local network. (Just referring to “oddz” remark that the commands are called by javascript requests.)

The user simple must not be deleted, only marked for deletion. Real elimination is to be performed from some admin script, after deep review of each marked record.

Oh, so you want the client (browser) to be able to reach your api? In that case, I would suggest that you treat it as any other http-request. It doesn’t matter if it was initiated from javascript or from the browser directly. From the server side, you can’t know the difference anyway. So the answer must rely on the answer to another question; Namely, how do you authenticate users to the rest of your application? Do you have some sort of login mechanism? How does it work?

Why not just put a layer in front that also does authentication, rather than providing direct access?

I don’t see how this is different from a form submission. Just because you get to pass back and forth raw data rather than HTML cruft doesn’t mean you get to forgo what you were doing before.

What would I authenticate on? In the background I need to able to access the API for users and non users – what than?

That’s a question only you can answer. We don’t know what the situation is.

There’s no secure alternative. The second best choice is obfuscation, which is not a good choice at all.

Guess I have my answer than. Individual methods or a state based change will have to accounted for with the open API.

I must say, Im slightly confused. I guess the solution you received earlier was not really the kind you wanted, and that is why your ignoring it?

You keep talking as a “open API” can not contain any authentication step, though I have no idea why? As long as you provide the functionality to do specific user changes, you need a way to identify the user doing it.

The way we do this is plainly to append a authorization class before the API is included, then if the user trying to access the API dont have the required clearance to access said part, the script is terminated.

With other words, you need to sit down and take a look what calls your non-users need to access, for example I strongly dubt they need to access the “delete user” call. When you have located the calls that need to have security appended, you will just trigger the authorization class, this will again check if said user is logged in, and if they should have access to this feature. In addition I would have the authorization class pass along the users ID (unless he got administrator rights), and that way assuring he can only update his own account.

In general I believe your thinking about this the wrong way, think of it as you would on a basic script that need parts of it protected.

Prime example would retrieving posts for a blog to display to non-user on the front end. At that point there is nothing to validate on because the user isn’t identifiable.

My goal here is to create a generic open API that provides immediate access to methods within my model layer and outputs the data as XML. That is so that my client side code can reuse the exact same methods as my server side code would. The only difference would be that instead of returning an array it would json or xml for the client side to than parse.

The whole idea here is to keep the interface for client-side and server-side data retrieval the same to support reuse and avoid code duplication based on whether data is being being requested internally or externally. However, from the sounds of everything it seems like an open API is going to require a separation between internal and external retrieval to any security pitfalls. For example, internally when selecting from my users table it does no real harm to select all columns. However, when allowing that method to accessed through a public API there may some columns that vital to security and shouldn’t be shown. In that case it seems like the only solution is to discern an externally vs. internal request for data to restrict certain columns or items being sent back in the result set for a external request. That way if someone issues their own request to my API all the vital security info will at least be suppressed only leaving data they would have access to otherwise that isn’t security vital.

Perhaps the best solution is authorization for deleting, updating and inserting items and omission of security vital columns for select operations?