Injection sql php

[thebarbarius]

Bonjour

Je subis actuellement des injection sql.

Est ce que quelqu'un pourrai contact avec moi pour voir d'ou sa provient ?

Merci

[Devildz]

Comment vous savez que vous subissez des attaques par Injection SQL ?
et dans quel page de votre site sont produites ces attaques ?

car il faut savoir quel page pour corriger cette page il faut contrôler tout ce qui passe par vos variable avec se code :

Code :

$variable=mysql_real_escape_string(htmlspecialchars($_POST['nom']));

c'est en ajoutant mysql_real_escape_string et htmlspecialchars dans la variable ou vous subissez vos attaque pour vous protéger.

[Bovino]

En plus des conseils de Devildz, il faut bien garder en tête le principe fondamental : Never trust user input !
Et attention, ce qu'on appelle user input, ce ne sont pas uniquement les valeurs récupérées en GET ou en POST. Un cookie, une variable de session, ...
Toute valeur qui n'a pas été définie dans le code qui l'utilise doit être vérifiée !

Ensuite, tant que cela est possible, il faut définir un format strict pour le genre de données attendues.
Si on attend un nombre, on ne doit pas autoriser d'autres caractères que des chiffres, idem pour les chaines qui doivent être filtrées au maximum.

[redoran]

Salam ; si sa peut t'aidé je vous propose ce lien http://www.php.net/manual/fr/securit...-injection.php
SQL Inject-Me est Extension Firefox utilisé pour tester les vulnérabilités d'injection SQL.
https://addons.mozilla.org/fr/firefo...sql-inject-me/
bonne utilisation Red

[thebarbarius]

Quel est l'équivalend en odbc pour sa :

Code :

1
2
 
$variable=mysql_real_escape_string(htmlspecialchars($_POST['nom']));

[rawsrc]

Bonjour,

quel SGBD est utilisé pour gérer le site ?

[thebarbarius]

Comment on connait son SGBD ?

[transgohan]

A ce que je vois dans la DOC les fonctions ODBC n'échappent rien d'autre que les apostrophes simple.
Tu peux cependant passer par l'interface PDO qui elle échappe correctement les données (PDO::quote() ou bien avec les requêtes préparées).

[thebarbarius]

Moi je fais sa :

Code :

1
2
3
4
5
6
 
 
	function register($pseudo, $password, $email) {		
		$pseudo = addslashes(htmlspecialchars($pseudo, ENT_QUOTES));
		$password = addslashes(htmlspecialchars($password, ENT_QUOTES));
		$email = addslashes(htmlspecialchars($email, ENT_QUOTES));

Sa me semble plus que suffisant non ?

[rawsrc]

Envoyé par thebarbarius

Comment on connait son SGBD ?

Tu lances une requête du genre :
mysql :

Code sql :

SHOW VARIABLES LIKE "%version%"

pgsql :

Code sql :

SELECT version();

sqlserver :

Code sql :

SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')

tu exécutes ces bouts de codes et si ça marche tu fais un var_dump() sur le retour de la requête.

[grunk]

Envoyé par thebarbarius

Moi je fais sa :

Code :

Sa me semble plus que suffisant non ?

Absolument pas.

1- htmlspecialchars n'a aucun effet sur les injection sql , il est en général conseillé de l'appliqué à l'affichage et non à l'insertion.

2- addslashes n'echappe "que" ' " \ et NUL alors que les fonction spécifique au SGBD en on en général plus. Dans le cas ou il n'existe pas de fonction spécifique il est vivement conseillé d'utiliser les requêtes préparée en plus d'un filtrage/validation des données stricte.

[rawsrc]

Voici une discussion qui a déjà abordé cette problématique : ici
Bonne lecture

[transgohan]

Envoyé par grunk

2- addslashes n'echappe "que" ' " \ et NUL alors que les fonction spécifique au SGBD en on en général plus. Dans le cas ou il n'existe pas de fonction spécifique il est vivement conseillé d'utiliser les requêtes préparée en plus d'un filtrage/validation des données stricte.

Les requêtes préparées d'ODBC n'échappent que les apostrophes d'après la doc.

[grunk]

Envoyé par transgohan

Les requêtes préparées d'ODBC n'échappent que les apostrophes d'après la doc.

Une requête préparée ça n'échappe pas, ca compile juste une requête à laquelle on passe ensuite des arguments.
La requête étant compilée , tu peux lui passer ce que tu veux comme argument , il n'auront aucun effet.

[transgohan]

Exact, j'étais pas très bien réveillé.
Je rajouterai cependant ce n'est pas pour autant qu'il faut toujours utiliser des requêtes préparées. C'est utile uniquement dans les cas où on exécute la requête plusieurs fois avec plusieurs injections différentes de données. Dans les autres cas c'est utiliser une bombe nucléaire pour tuer une mouche.

[grunk]

Envoyé par transgohan

C'est utile uniquement dans les cas où on exécute la requête plusieurs fois avec plusieurs injections différentes de données. Dans les autres cas c'est utiliser une bombe nucléaire pour tuer une mouche.

Les SGBD on à peut près tous des caches des plan d'execution de leur requêtes. Donc concrètement tu prépares une fois une requête et la prochaine fois si elle est dans le cache la préparation sera récupérée du cache. Du coup pour des requêtes un peu complexes c'est même plus rapide qu'une query normale.
Donc tout bénéf.

Pour les requêtes simple le gain de tranquillité vaut bien les quelques ms perdues

[thebarbarius]

sinon comme je disais je tourne sous ODBC et non mysql ou mysqli...

Donc quel est l'equivalent de sa en odbc :

Code :

1
2
 
$variable=mysql_real_escape_string(htmlspecialchars($_POST['nom']));

[grunk]

Y'a pas en ODBC puisque ça permet de se connecter à différent SGBD. La seule solution, c'est les requêtes préparées + un filtrage /validation des entrées utilisateurs.