Je construis un jeu de navigateur et je suis en utilisant une grande quantité d'Ajax au lieu de rafraîchir la page. J'utilise php et javascript. Après beaucoup de travail, j'ai remarqué que Ajax n'est pas exactement en sécurité. Les menaces m'inquiètent de savoir que quelqu'un veut rechercher des informations de quelqu'un sur mon serveur SQL qu'ils avaient juste besoin de saisir les bonnes informations à mon fichier .php associé à mes appels Ajax. J'utilisais des appels de get Style Ajax qui était une mauvaise idée. Quoi qu'il en soit, après beaucoup de recherches, j'ai en place les mesures de sécurité suivantes. Je suis passé à la poste (qui n'est pas vraiment plus sécurisé mais c'est un détenteur mineur). J'ai une référence en place, ce qui peut encore être falsifié, mais à nouveau son autre dissuasion.
La mesure finale que j'ai en place et est au centre de cette question, lorsque mon site Web est chargé, j'ai une clé hexagonale de 80 caractères générée et enregistrée à la session, et lorsque je suis envoyé à l'appel AJAX, j'envoie également le défi. Touche sous la forme de p>
challenge= <?php $_SESSION["challenge"]; ?>
3 Réponses :
Votre définition de "sécurisé" est vague. Vous semblez moins intéressé par la prévention des données d'être interceptées et plus intéressée à garder les personnes de soumettre des demandes personnalisées à votre serveur. Ce n'est pas la sécurité, c'est juste une bonne conception d'applications - votre programme ne devrait pas accepter les demandes qui provoquent l'état interne de se casser. Il n'y a absolument rien que vous puissiez faire pour empêcher les personnes de soumettre les données qu'ils souhaitent. La solution consiste à valider les données qu'ils soumettent du côté serveur et non à éviter de les empêcher de soumettre le côté client de données, qui échouera toujours.
je suis passé à post
Vous ne devriez pas vous déranger; Cela n'a rien à voir avec la sécurité. Utilisez le verbe HTTP approprié pour la demande. Êtes-vous interrogé d'informations? Utilisez une demande d'obtention. Est-ce que vous mettez à jour / insérer / supprimer des informations? Utiliser post.
Dites que quelqu'un veut rechercher des informations de quelqu'un sur mon serveur SQL, il a juste besoin de saisir les informations correctes à mon fichier .php associé
Vous devez authentifier toutes les demandes pour vous assurer qu'ils ont accès aux données qu'ils interrogent. SSL vous aidera à effectuer l'authentification de manière sécurisée.
Lorsque mon site Web est chargé, j'ai une clé hexagonale de 80 caractères générée et enregistrée dans la session, et lorsque je suis envoyé à l'appel AJAX, j'envoie également la clé de défi
Cela ne va pas aider. L'ensemble de votre question semble être que l'utilisateur a Firebug ou un outil de débogage HTTP similaire installé. S'ils le font, votre clé de session est rendue inutile.
Peut-être que vous pourriez vous aider à vous obliger à vous obliger, comment mes données pourraient-elles être interceptées et s'ils ont Firebug, ils peuvent simplement regarder mes données de session? Je pensais que cela a été sauvé côté serveur et ne pouvait pas être consulté.
Les données peuvent être interceptées via Packet reniflant sur le réseau local
Ne serait-il pas très difficile d'obtenir quelque chose sur le réseau local?
@Tye Vous êtes correct, les données de session sont stockées côté serveur. Le problème est que vous envoyez la clé de 80 caractères du client; Peu importe qu'ils puissent lire la version stockée dans la session, vous leur envoyez la même chose en texte brut.
Oui, je comprends que, c'est pourquoi j'étais inquiet, mais maintenant je l'ai changé de manière à ce que, une fois utilisée dans le fichier Ajax PHP, elle le modifie à un autre nombre aléatoire qui soit effectué sur le côté serveur sans le renvoyer au client. Il ne serait plus envoyé au client jusqu'à ce que la demande AJAX soit renvoyée à nouveau. Cela a-t-il un sens et devrait-il fonctionner?
@tye Non, ça ne devrait pas fonctionner. Vous ne pouvez pas conserver les secrets du code côté client; Il est trivialement facile de regarder les données transférées. Vous êtes toujours sur cette "sécurité" stupide lorsque vous devriez vous concentrer sur la création de votre script de serveur plus robuste. Il ne devrait pas y avoir de demande que quelqu'un puisse soumettre à votre programme qui le brisera.
Je suis absolument d'accord et je prévois de modifier certaines modifications pour que cela ne soit pas possible de casser mon programme. Cependant, je ne suis toujours pas sûr de savoir pourquoi ce que j'avais intentionnel ne fonctionnerait pas cependant. Peut-être que je n'étais pas assez clair ou peut-être que je suis juste retardé. Dans le fichier PHP, je définirais la clé de défi de la session à quelque chose d'autre, donc une fois que cela se fait, je ne vois pas comment cette nouvelle information serait transmise au client, qu'elle ne serait pas transmise au client jusqu'à ce que la requête Ajax soit envoyé.
@tye Quel est le but de la clé, si ce n'est pas réussi au client? Vous continuez à dire que cela ne sera pas transmis avant que la demande soit envoyée; Vous pouvez inspecter la réponse à une demande AJAX tout aussi facilement que possible d'inspecter la demande elle-même.
Eh bien, il est passé lorsque vous appelez la demande Ajax, mais la première ligne du fichier PHP que la demande AJAX tire va vérifier et défier la clé et le modifier afin que ce soit modifié et que ce nouveau changé ne soit pas réussi à passer au client jusqu'à ce qu'il vienne De retour ici lors d'une nouvelle Ajax RUEST, désolé si cela n'a pas été clair, je n'essaie pas de sonner retardé et je comprends que cela est inutile mais je suis maintenant curieux.
Donc, sur demande A , vous soumettez la clé et cycle une nouvelle valeur aléatoire qui est stockée côté serveur. Vous dites que vous ne réussirez pas cette valeur à l'utilisateur jusqu'à la demande B . Comment l'utilisateur est-il censé faire une demande B en premier lieu, s'ils n'ont pas encore la clé? Si vous souhaitez que l'utilisateur soumet une clé, vous devez DO les envoyer cette clé avant de faire la demande.
Eh bien, la clé est stockée dans la droite de la session, donc lorsque le JavaScript va faire une autre demande AJAX, les données envoyées sont quelque chose comme "Type = FOO & NAME = Bar & Challenge = " et ensuite, les premières lignes de l'Ajax PHP appelées sont comme si _Post [«Challenge»] == $ _session [«Challenge»] {$ _session ['Challenge] = Newkey;} Cela a-t-il plus de sens, Encore une fois, désolé c'est difficile de m'expliquer sans certains code, je suppose.
@tye qui fonctionne si vous allez seulement permettre une demande AJAX par demande de page complète. Et si vous voulez faire une deuxième demande Ajax? La clé ne correspond pas.
Depuis que IVE a mis à jour la session ['Challenge'] ne devrait pas que la fonction AJAX envoie la nouvelle mise à jour et la correspond à la touche de session mise à jour à nouveau. Alors ne devrait-il pas autoriser autant de demandes que je veux par cette page?
@tye pas à moins d'envoyer la nouvelle touche en réponse à la demande AJAX et à mettre à jour tous les liens de la page avec elle ou d'actualiser la page entière. Les liens de la page ne seront pas mis à jour par magie eux-mêmes; n'est évalué qu'une fois lorsque la page est demandée. Modification de la valeur Server-Server n'affectera pas le code déjà rendu et envoyé au navigateur.
@tye Look, l'informatique est une science expérimentale. La meilleure chose à faire pour vous est de l'essayer. Je vous dis que cela ne fonctionnera pas, mais ne prenez pas ma parole pour cela, essayez de me prouver.
Forsure, bien merci beaucoup d'un homme, j'apprécie vraiment votre aide, désolé de manger une bonne partie de votre journée. Merci encore. EDIT: En fait, puis-je effacer une chose avec vous?
Je voulais juste vérifier Modifier IM allant publier ce code comme une réponse faite ci-dessous, si nécessaire, cela devrait envoyer la clé de session mise à jour autant de fois que nécessaire pour envoyer le droit?
Voir la réponse de 'MEAGAR'.
J'aimerais mentionner:
En passant autour d'un identifiant en session, vous faites ce que la session fait déjà. Il y a généralement un cookie avec un identifiant unique semblable à celui que vous générez, qui raconte votre application, essentiellement à qui cette personne est. C'est ainsi que fonctionnent les sessions PHP, en général.
Qu'est-ce que vous auriez besoin de faire, dans ce cas, vérifie que, pour une demande donnée - post ou get - que l'utilisateur particulier (dont l'identifiant unique unique, ou similaire, est stocké dans le Session) a la permission d'ajouter / modifier / supprimer / peu importe avec cette demande particulière.
Donc, pour une demande "Recherche", vous ne renverriez que les résultats que l'utilisateur X a la permission de visualiser. De cette façon, vous ne vous inquiétez pas de ce qu'ils envoient - si l'utilisateur n'a pas la permission de faire quelque chose, le système sait de ne pas les laisser faire.
Par conséquent "Vous devriez authentifier toutes les demandes".
Quelqu'un n'hésitez pas à ajouter à cela.
Cela semble exactement comme ce que je veux accomplir, pourriez-vous me donner des informations sur la manière dont j'aurais authentifier une personne à l'aide de cet identifiant unique?
Si vous travaillez sur un jeu, je suppose que vous pourriez avoir des utilisateurs et une inscription a fonctionné. Au-delà de cela, vous recherchez quelque chose de «ACL» communément appelé «ACL». Essentiellement, les utilisateurs (ou les groupes d'utilisateurs) sont donnés des ensembles d'autorisations pour ce qu'elles sont autorisées à faire ("peut ajouter du widget", "peut modifier posséder widgets", "ne peut supprimer widgets", etc.) . C'est un excellent sujet pour une autre question - et une personne qui a probablement déjà été posée / répondit bien.
function mysqlRequest(type,server,name,value,sync){
$.ajax({
type: 'POST',
url: 'sql.php',
data: "server=s"+server+"&type="+type+"&name="+name+"&value="+value+"&challenge=<?php echo $_SESSION['challenge']; ?>",
cache: false,
dataType: 'json',
async: sync,
success: function(data){
},
complete: function(){}
Avez-vous essayé cela? Inspectez la page avec Firebug, et vous trouverez la valeur après "& Challenge = ne change jamais, quel que soit le nombre de fois que vous modifiez la valeur de $ _ session [" Challenge '] côté serveur. Vous devez manuellement mettre à jour la valeur basée sur le résultat de la demande AJAX. Cela ne se produit pas automatiquement. Cela implique que vous devez envoyer la nouvelle clé en réponse à la demande Ajax temps, qui défait le but de la clé.
En terminez-vous, utilisez-vous des requêtes SQL au serveur via le paramètre de valeur ? C'est une terrible idée terrible et imparfaite. Tout le monde peut écrire quelle que soit la requête SQL qu'ils veulent et l'envoyer. C'est le malentendu fondamental ici - la solution n'est pas de "sécuriser" l'envoi de requêtes SQL sur le serveur; La solution consiste à jamais Envoyer des requêtes SQL.
Oui, ce sont les changements que je prévoyais de faire de la fabrication de lol. Et ok merci d'obtenir des informations sur le fait que ce code n'enverra pas la variable de session mise à jour. Donc, vous ne pensez pas que je devrais utiliser Ajax à des fins SQL. Toute la base de ce jeu que je faisait était d'éliminer le besoin de rafraîchir la page. C'est aller à un style mmo rts.
Vous devez utiliser Ajax, mais vous devez également construire vos instructions SQL Server côté. Par exemple: au lieu de passer la requête Sélectionnez * à partir d'unités ID = 3` dans la chaîne de requête, vous devez utiliser une URL comme mysite.com/units.php?id=3 . L'ensemble du point est d'empêcher les gens de modifier votre requête d'insérer des objets tels que Supprimer les déclarations .
Maintenant, sur ce sujet est acceptable d'envoyer des informations sur lesquelles = (var) déclarations sur les requêtes SQL, tant qu'ils sont éprouvées par injection. Pour l'une de mes demandes Ajax, j'envoie habituellement certaines des informations pour une requête que l'utilisateur puisse sélectionner les données à faire correspondre, mais quelles valeurs correspondent. c'est acceptable correct?
@Tye Vous ne pouvez pas être trop méfiant des données entrantes. Je n'accepterais pas même une clause où. Il sera très difficile de nettoyer les injections SQL d'une chaîne qui est, par conception, est censée contenir SQL.
OK qui répond aussi ma prochaine question. Je voulais juste vérifier cela, je ne veux tout simplement pas que quelqu'un puisse utiliser ces fichiers .php pour sélectionner quelles données est en cours d'écho, alors valeurs bonnes, la table de données Coloumn Noms n ° bien?
Vous vous sentez donc de protéger qui ou ce qui accepte ces fichiers ne compte pas, ne comporte que ce qui est fait à l'intérieur d'eux? Je viens de comprendre que c'était une pratique courante pour sécuriser ce qui appelle ces fichiers. Ceci est mon premier programme Ajax, donc je n'ai vraiment aucune idée de la pratique courante et de ce qui n'est pas.
Vous ne pouvez rien faire pour sécuriser qui / ce qui apporte des demandes à votre serveur Web. Ce n'est pas la façon dont Internet fonctionne.
ok je gocha, merci encore mec. Je l'apprécie vraiment. Maintenant, quand vous avez été confus quand j'ai dit avoir obtenu mon Ajax, quel type de sécurité devrais-je regarder, vous parliez d'interception de données?
Si vous transférez des données sensibles telles que des mots de passe, vous devez utiliser SSL.