2010-03-22 3 views
0

J'ai un formulaire de connexion que je considère s'il doit être ajaxé ou non.
La raison pour laquelle je considère cela est parce que si la réponse de l'appel ajax est fixe (comme 0 pour invalide et 1 pour valide) je peux rediriger la requête ajax à travers la console javascript et se connecter au système malicieusement.
Existe-t-il un moyen de résoudre ce problème de sécurité?
Est-ce la raison pour laquelle toutes les formes de connexion que j'ai vues jusqu'ici (y compris ici sur stackoverflow) ne sont pas des ajax?Ajax Authentification Réponse

Répondre

1

Vous effectuez votre connexion avec ajax. Le côté serveur valide la connexion et démarre une session. Même si le client ignore la réponse de l'appel ajax, il est important que tous les appels ajax vérifient si la session a été correctement créée lors de la connexion et refusent de faire ce qui est demandé si la session n'a pas été ouverte correctement au moment de la connexion.

En PHP (par exemple):

Connexion:

<?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; 

autres appels ajax:

<?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 

Pour chaque appel ajax, lorsque la réponse arrive, vous devez d'abord vérifier si la la réponse est correcte - à vous de déterminer comment vous voulez que cela soit représenté.

À titre d'exemple, une réponse pourrait regarder dans JSON comme

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

etc, etc ...

Si tout va bien, vous continuez à gérer la réponse. Sinon, vous pouvez par exemple rediriger vers la page de connexion.

Notez qu'avec PHP, chaque appel ajax inclut automatiquement l'ID de session (c'est un cookie), donc PHP sait quelle session est associée à une requête particulière.

+0

mais imaginez que je suis un hacker, je peux recréer cette réponse. –

+0

Bien sûr que vous le pouvez, mais puisque les informations réelles et les actions sont du côté serveur, vous ne pouvez pas 1) modifier la base de données 2) obtenir des informations réelles. –

+0

Un pirate peut faire croire au navigateur que vous êtes connecté, mais en même temps le pirate n'est pas connecté sur le serveur. Donc, chaque demande subséquente sera refusée, et à quoi sert alors de forger la réponse? Il n'obtiendra toujours aucune information significative du serveur, ou ne modifiera rien. –

2

Vous devez vous assurer que tout le contenu qui doit être affiché uniquement aux utilisateurs connectés doit uniquement être transféré après le processus de connexion. Le serveur doit vérifier chaque requête, que l'utilisateur soit connecté ou non. Cela pourrait être fait par des méthodes traditionnelles (comme les identifiants de session dans cookie ou post/get). Donc, en bref: ne transférez pas de valeurs fixes mais transférez un identifiant de session normal qui varie d'un utilisateur à l'autre.

+0

Mais comment répondre valide/invalide? Vous voulez dire que je devrais passer l'identifiant de session ou 0? Mais le client ne connaît pas l'identifiant de session qui nous laisse avec le problème d'origine. –

+0

Étant donné que vous ne devez pas transférer au préalable un contenu * * * pour des utilisateurs non connectés, ce qui est destiné à être connecté, il n'est pas possible que le client les utilise. – neo

+0

Que j'ai compris, mais à quoi ressemblerait la réponse à l'appel rpc pour qu'un pirate ne puisse pas l'utiliser? –