views:

42

answers:

2

I have a login form that I am considering if it should be 'ajax'ed or not.
The reason I am contemplating this is because if the response of the ajax call is fixed (like 0 for invalid and 1 for valid) I can redirect the ajax request through the javascript console and log into the system maliciously.
Is there a way to solve this security issue?
Is that why all login forms I've seen so far (including here on stackoverflow) are non-ajax?

+2  A: 

You need to make sure that all content which should be displayed only to logged-in users should only be transferred after the login process. The server-side should check on every request whether the user is logged in or not. This could be done by traditional methods (like session ids in cookie or post/get).

So in short: don't transfer fixed values but transfer a normal session id which vary from user to user.

neo
But how do I answer valid/invalid?You mean I should either pass the session id or 0?But the clientside doesn't know the session id which leaves us with the original problem.
the_drow
Since you shouldn't transfer *any* content for non-logged-in users beforehand which is meant for logged-in it isn't possible for the client-side to use them.
neo
That I understood, but how would the response for the rpc call would look like in order that a hacker wouldn't be able to use it?
the_drow
+1  A: 

You perform your login with ajax.

Server side validates the login and starts a session.

Even if the client ignores the response from the ajax call, it's important that any ajax calls check if the session was properly created when login, and refuse to do what's asked if the session wasn't properly opened at login time.

In PHP (example):

Login:

<?php
header('Content-type: text/json');

session_start();

if ( check_password() ) {
  // send ok response
}
else {
  // send not ok response
}

// if that session variable exists, then we logged in successfully
$_SESSION['user']    = $user;

other ajax calls :

<?php
header('Content-type: text/json');
session_start();

if ( ! isset($_SESSION['user'] )) {
  // send not ok response 
  // on the client, this will redirect to the login page
  exit;
}

$user=$_SESSION['user'];

... rest of the code here

For every ajax call, when the response arrives, you should first check if the response is ok -- up to you to determine how you want this represented.

As an example, a response might look in JSON like

  • not logged : { "ok":"N","error":"not logged in"}
  • logged : { "ok":"Y","data":[{"name":"xxxx","age":19},{"name":"yyy","age":91}]}
  • or { "ok":"Y","data":"Some text"}

etc, etc...

If it's ok, you proceed to handle the response. If not, you can for example redirect to the login page.

Note that with PHP, every ajax call you make includes the session ID automatically (it's a cookie), so PHP knows which session is associated with a particular request.

David V.
but imagine that I am a hacker, I can recreate this response.
the_drow
Sure you can, but since the real info and actions are from the server side, you can't 1) modify the database 2) obtain real information.
David V.
A hacker can make the browser believe you're logged in, but at the same time the hacker is not logged in on the server. So every subsequent request will be denied, and what's the point in forging the response then ? He's still not going to get any meaningful information from the server, or modify anything.
David V.
So basically even if he fooled the browser to be logged in as an administrator and clicks on 'edit post' for example he can't reach that page because he is not logged in.
the_drow
Yes, as long as you properly check that the user is really logged in *on the server*. A good rule is to be cautious of anything that comes from the client.
David V.