2016-07-18 2 views
0

je jusqu'à présent pu accéder à _REQUEST $ dans mon PHP comme suit:

//JS 
xmlhttp.open("GET", "logic.php?q=" + itemOne + "&w=" + itemTwo, true); 

//PHP 
$q = $_REQUEST['q']; 
$w = $_REQUEST['w']; 

Les articles envoyés par obtenir utilisé pour les requêtes serveur MSSQL (de sqlsrv).

Ma question est de savoir quelles seraient les meilleures pratiques pour faire ce qui précède différemment/correctement? Je lis quelque part que ce n'est pas bon en termes d'être vulnérables aux attaques par injection SQL, etc.

+0

C'est totalement acceptable d'utiliser $ _REQUEST. vous devez prendre soin des requêtes. utilisez simplement ajax get/post request pour cela. – Bhavin

+1

Il n'est pas possible d'indiquer à partir de ce code s'il est vulnérable ou non à l'injection sql. Mais jetez un oeil à [Comment puis-je empêcher l'injection SQL en PHP?] (Http://stackoverflow.com/questions/60174/how-can-i-prevent-sql-injection-in-php) – FirstOne

+1

Une note de côté est d'utiliser le 'correct' global en fonction de la demande. Si vous utilisez un 'post', accédez aux variables de' $ _POST', si 'get', puis' $ _GET'. Jetez un oeil à [Quel est le problème avec l'utilisation de $ _REQUEST [\]?] (Http://stackoverflow.com/questions/2142497/whats-wrong-with-using-request) – FirstOne

Répondre

1

Ma question est ce que serait les méthodes les plus pratiques pour faire le ci-dessus différemment/correctement?

L'exemple JavaScript que vous avez utilisé a utilisé une demande GET. La façon "correcte" d'accéder aux paramètres serait via le tableau $_GET de PHP. L'utilisation de $_REQUEST est une mauvaise habitude car vous perdez le contrôle de l'arrivée des données. Je vais vous donner un exemple simple:

Les sites Web qui utilisent l'authentification par base de jetons nécessitent souvent que vous envoyiez le jeton en tant que données POST. Si l'échange d'informations confidentielles via le paramètre URL est considéré comme non sécurisé, un script PHP qui obtient les données de $_REQUEST n'a aucun moyen de savoir comment les données sont arrivées et acceptera par erreur un jeton mal envoyé. Un meilleur script rechercherait le jeton dans $_POST. Si ce n'est pas là, alors il n'y a pas de jeton; même si un utilisateur a essayé de l'envoyer dans l'url.

Je lis quelque part que ce n'est pas bon en termes d'être vulnérables aux attaques par injection SQL, etc.

injection SQL n'a rien à voir avec $_REQUEST spécifiquement. Cela peut arriver à chaque fois que vous insérez des données soumises directement dans vos requêtes SQL, que les données proviennent de $_REQUEST, $_GET, un fichier ... Cette conception de code terrible permet à un attaquant de prendre le contrôle de votre SQL et d'ordonner à votre DB il ou elle souhaite (par exemple: exfiltrer ou supprimer vos données). Pour vous protéger contre cela, renseignez-vous sur instructions préparées et requêtes paramétrées

+0

Merci pour la réponse! Je vais regarder dans l'utilisation correcte du tableau '$ _GET'. Je pense que heureusement, du point de vue de l'injection SQL, je devrais me débrouiller comme je l'ai fait: a) valider complètement le champ avant JS avant qu'il n'atteigne ce point pour aligner les données sur ce que je veux b) utiliser des instructions préparées avec seulement des paramètres c) l'utilisateur MSSQL avec lequel je me connecte ne peut lire que des données de la base de données. – BernardV

+1

Si ma solution répond à votre question, sélectionnez-la! :-) Vous devriez considérer la validation frontale comme un service de commodité pour l'utilisateur, pas comme une fonction de sécurité pour le serveur.C'est parce qu'il est vraiment facile d'envoyer des requêtes http à votre serveur en utilisant de mauvais paramètres sans jamais utiliser votre site frontal. – BeetleJuice

+0

Merci! Je le ferai donc! Juste en termes d'utilisation de '$ _GET' correctement, le résultat ci-dessous est-il meilleur? '$ _GET [" q "] = $ q; $ _GET ["w"] = $ w; ' – BernardV