AJAX Security Concepts

dalecosp

We're about to deploy some changes to our business site that will make an old AJAX application much more central to our business model.

In short, a mouse-click sends three integers to the server, which operates on them and sticks 'em in the DB, etc.

So, the first point of security isn't too hard... if the data isn't integers, forget about it.

The other issue, then, is we'd really not like to let just anyone send us some integers ... how do we protect against that? Cookie check? Is the $_SESSION array available to the Ajax server?

johanafm

Apart from a few restrictions on when you may issue AJAX requests (same origin policy), the actual requests do not differ from any other HTTP request. Moreover, it is only by convention among browser vendors that these restrictions exist. If you want to allow requests outside of same origin, you may do so using CORS headers - Cross Origin Resource Sharing.

The same data is sent with AJAX requests as with any other HTTP request. Thus, you may propagate sessions using query string parameters, post data and/or cookies. This means you may handle login, session requests, logout the same way as you have always done previously.

Some people (purists) claim that you should not handle sessions in a REST API, because propagating session between requests means storing state. It is possible to handle things without sessions, for example by using API keys. Sending such data obviously requires encryption, so you should only do that over https.

dalecosp

Well, the problem I seem to be having is something like this.

foo.site.com is sending ajax to www.site.com. This check for $member (userid) fails in the AJAX server:

$the_cookie = $_COOKIE['session_cookie'];
$cookie_sql = "select userid from sessions where cookie_val='$the_cookie'";
$res = mysqli_query($db,$member_cookie_sql);
$member=mysqli_result($res,0,'cookie_val');
if (!$member) die("You must be a member.");

$db is good (eliminating the die() will allow the rest of the script to run "as designed"). mysqli_result is a custom function, but works everywhere else. The problem, seen when I echo the SQL, is that the value for $cookie_val is null in the query...

Firebug shows cookies set, both for "www.site.com" and ".site.com" ... so I know they are present. They aren't marked as HttpOnly, even; I suppose the only thing I can think of it that there are two of them and perhaps it's getting confused? I know I sure am at this point 😉 😃

traq

dalecosp;11038967 wrote:
The problem, seen when I echo the SQL, is that the value for $cookie_val is null in the query...

…meaning that [font=monospace]$_COOKIE["session_cookie"][/font] did not exist (or had a NULL value). Are you sure you have the correct cookie name?

More to the point, if it is a session cookie, why aren't you simply using [font=monospace]$_SESSION[/font] directly?
This would have the added benefit that you wouldn't have to check the DB each time, since you could store an authentication token in the session once the user logs in.

johanafm;11038959 wrote:
Some people (purists) claim that you should not handle sessions in a REST API, because propagating session between requests means storing state. It is possible to handle things without sessions, for example by using API keys. Sending such data obviously requires encryption, so you should only do that over https.

I'd say it's less of a "purist" thing and more of a "technical" thing. If there is state, it's not RESTful. However, IMHO, that's not "good" or "bad" in and of itself. As long as the API is intended for "background" use (e.g., ajax or other resources) during a regular user session, it makes perfect sense to take advantage of the session state. If it's an API intended for independent use (e.g., gravatar.com), then you can't rely on sessions existing, and so it should be RESTful.

bradgrafelman

dalecosp;11038967 wrote:
the only thing I can think of it that there are two of them and perhaps it's getting confused?

Try setting a breakpoint on the AJAX call and see what the HTTP request looks like just before it gets sent? Alternatively, you might just look at the request itself by using something akin to the "Network" tab in Chrome's Developer Tools.

dalecosp

traq;11038983 wrote:
…meaning that [font=monospace]$_COOKIE["session_cookie"][/font] did not exist (or had a NULL value). Are you sure you have the correct cookie name?

Quite certain; I've used it in other places and even had the VP of I.T. check my speling 😉

Of course, it's not actually called "session_cookie" per the example for str_replace("hysterical","security","hysterical raisins"); 😃

More to the point, if it is a session cookie, why aren't you simply using [font=monospace]$_SESSION[/font] directly?
This would have the added benefit that you wouldn't have to check the DB each time, since you could store an authentication token in the session once the user logs in.

This is one of those PITA "maintainability" issues with a piece of software I didn't design or write. 😉

bradgrafelman;11038987 wrote:
Try setting a breakpoint on the AJAX call and see what the HTTP request looks like just before it gets sent? Alternatively, you might just look at the request itself by using something akin to the "Network" tab in Chrome's Developer Tools.

Looking at the request doesn't help (tried that), unless you know something I don't (I just see a POST request with the 3 integers). The breakpoint idea sounds good... 🙂

traq

dalecosp;11038991 wrote:
Looking at the request doesn't help (tried that), unless you know something I don't (I just see a POST request with the 3 integers).

Did you find the Cookie header you expected?

dalecosp

traq;11038995 wrote:
Did you find the Cookie header you expected?

I confess to not knowing exactly what you mean? The debugger has a COOKIE tab, which shows two cookies, same name and value, on two different paths (.www.foo.com and .foo.com), which I did expect and appear to be correct in value and name.

Other than that, I don't know of any way to get cookie information from it. The NETWORK tab doesn't show anything related to cookies, near as I can tell, just a POST request with the 3 parameters set....

bradgrafelman

dalecosp;11039085 wrote:
just a POST request with the 3 parameters set....

That is where the cookie should be - inside the headers of the POST request.

dalecosp

bradgrafelman;11039091 wrote:
That is where the cookie should be - inside the headers of the POST request.

D'oh, indeed. Thank you.

The cookie appears in the headers, indeed. So, why doesn't the AJAX handler recognize this fact? 😕

johanafm

traq;11038983 wrote:
If there is state, it's not RESTful.

Using an api key actually ends up being the same thing in my opinion. There is state in both cases - refered to either by an api key or a session cookie. What I would care about is wether I have built-in cookie handling from where I issue my requests. But either way, I totally agree with you: do whatever makes sense with a minimum of fuzz for you and your users.

dalecosp;11038967 wrote:
I suppose the only thing I can think of it that there are two of them and perhaps it's getting confused? I know I sure am at this point 😉 😃

If there are two of them, you are probably setting (one of) them incorrectly at some point. For the cookie to be valid for both example.com, foo.example.com and www.example.com, you may need to use a . before the domain and leave the subdomains out.

.example.com

From the docs of [man]setcookie[/man]

path
The path on the server in which the cookie will be available on. If set to '/', the cookie will be available within the entire domain. If set to '/foo/', the cookie will only be available within the /foo/ directory and all sub-directories such as /foo/bar/ of domain. The default value is the current directory that the cookie is being set in.

domain
The domain that the cookie is available to. Setting the domain to 'www.example.com' will make the cookie available in the www subdomain and higher subdomains. Cookies available to a lower domain, such as 'example.com' will be available to higher subdomains, such as 'www.example.com'. Older browsers still implementing the deprecated » RFC 2109 may require a leading . to match all subdomains.

httponly would also screw things up, if the browser at hands respects this setting.

dalecosp;11039093 wrote:
The cookie appears in the headers, indeed. So, why doesn't the AJAX handler recognize this fact? 😕

The AJAX handler? I'm not sure I understand what part of the process you are talking about. Especially since I originally understood it as if the cookies where null server-side.

Cookies work in the following way. The server only sends cookie info when it wishes to set (including modify / delete) cookies. Moreover, a call to setcookie (server side) will NOT affect the $COOKIE array. The $COOKIE array is constructed from cookie header field data on incoming requests only.

The browser always sends all cookies - assuming valid settings for domain etc.

Time used to be an issue, and may still be in IE X (solve for x). Originally expiration was set as a fixed time. But with differing time zones, this leads to problems. Now you may specify duration instead, at least for newer browsers. So if your server and browser differ in opinions of time and you set expires with fixed time rather than duration, this will also have to be checked.

Other than that, the last thing that may cause problems is if you issue an ajax request to some OTHER sub(domain). In this case, you would have to resort to CORS - Cross Origin Resource Sharing. CORS will allow foo.example.com to send XHR, including cookie information, across domains, such as to bar.example.com. Iirc: GET/HEAD requests can be sent without pre-check if it includes proper CORS headers, while any request which (may) results in server side changes requires a pre-flight request to verify that the cross origin request is allowed.

But as far as the "AJAX handler" goes - when the response comes back from the server, the browser should update its cookie information as per the "set-cookie" header. Unchanged cookies should remained, unless they expired.

Things you may need to inspect
1. Does the browser send the cookie? Inspect the request from your browser
If no
- CORS or respect SOP (which includes port)
- may need to alter domain / path for which the cookie is valid when initially sent from server
- may need to set httponly
- may need https or disable "secure"

Does the server accept the cookie? Inspect incoming http headers and inspect the cookie array.
If no:
CORS is the only thing I can think of.

Does the server set the cookie? Use the browser to inspect the response. Is the proper information included in the set-cookie header?
Does the browser accept the incoming cookie, set it and subsequently send it?
I doubt this would break unless the cookie header is malformed.