Comment vous protégez votre site des injections SQL, failles ?

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : Comment vous protégez votre site des injections SQL, failles ?

Re: Comment vous protégez votre site des injections SQL, failles ?

par two3d » 08 juil. 2020, 10:31

"L'habitude et le feeling" oui ;)

J'ai aussi mes fonctions pour les requêtes MySQL pour éviter à chaque fois d'inclure la connexion MySQL

Code : Tout sélectionner

$req=mysqli_query($conn,"requete...")
devient

Code : Tout sélectionner

$req=requete("requete...")
et pour les résultats:

Code : Tout sélectionner

$infos=fetchassoc($req)
ça me permet aussi de gérer les erreurs et de pas faire buguer le reste de la page..

J'avais fait une fonction qui me permettais de faire exactement comme toi:

Code : Tout sélectionner

$conn->insert('table', ...
Mais elle ne ma pas suivie, je dois l'avoir dans un projet ;)

J'ai eu fait des scripts énorme et je pense que la solution d'un framework serait idéale pour avance plus vite, ce sera ma prochaine étape à mon avis, apprendre un framework

Re: Comment vous protégez votre site des injections SQL, failles ?

par Saian » 08 juil. 2020, 00:20

Moi si j'utilise symfony c'est que l'outil colle très bien avec la dimension des sites que je réalise. C'est un véritable apport comparé à un code from scratch, on a une bonne architecture MVC, on peut facilement ajouter des managers et des services, l'api de formulaires est bien faite et twig est également un très bon framework de templates. Doctrine est aussi un bon ORM.

Pour ce qui est de la syntaxe orienté objet, je trouve que ça permet de mieux organiser ses codes et qu'ils aient une écriture plus "naturelle".

Et sinon je pense vraiment pas que ce soit plus long d'écrire des requêtes préparées. Tu peux te faire des api aussi simple que ça :
$id = $conn->insert('table', [
  'col1' => 'valeur1',
  'col2' => 'valeur2',
  'col3' => 'valeur3',
])->lastInsertId();

$object = $conn->select('table')->find($id);

$object->setCol4('valeur4');
$conn->update($object);

$conn->delete($object);
et tu peux en faire autant en procédural mais pas sûr que l'api soit aussi simple à écrire. Après c'est peut être juste une question d'habitude ou de feeling.

Re: Comment vous protégez votre site des injections SQL, failles ?

par two3d » 07 juil. 2020, 21:16

Perso, j'utilise toujours Symfony donc tout est déjà intégré.
J'ai toujours voulu coder moi même mes scripts et pas utiliser de framework, parce que c'est moins lourd et je sais où est quoi. (et aussi parce que j'ai très peu de notion en objet :-* :D )
Pour les injections sql tu peux les sécuriser simplement en utilisant les requêtes préparées.
C'est long à écrire je trouve comparé au style procédural du coup c'est un peu pour ça que je suis resté en procédural :D

Après je me pose souvent la question suivante: est ce plus rapide de coder avec framework ? je penses que oui mais ça me rebute parce que c'est en style objet :P

J'y viendrais peut être un jour mais je ne vois pas l"intérêt, et du coup j'ai regardé des tutos pour comprendre les classes et comprendre le but mais j'ai pas très bien compris le but, je me dit que je peux aussi le faire avec un fonction PHP classique.

Bref, je dev PHP en procédural. :mrgreen:

Re: Comment vous protégez votre site des injections SQL, failles ?

par Saian » 07 juil. 2020, 19:23

Salut two3d,

Perso, j'utilise toujours Symfony donc tout est déjà intégré.

Pour les injections sql tu peux les sécuriser simplement en utilisant les requêtes préparées.

Pour le cross site scripting, les injections de code dans les saisies utilisateurs pour qu'il s'exécute lors de l'affichage, je dirai qu'il y a 2 politiques. La première qui vient est d'encoder les entités html lors de l'enregistrement des données et la deuxième consiste à encoder les données lors de leur affichage. Personnellement j'ai une préférence pour la deuxième. Dans Symfony avec Twig les données sont automatiquement échappées lors de leur affichage. Il faut juste faire attention avec les données que tu ne veux pas échapper.

Et pour vérifier des saisies particulières, email, nombre, etc, il y a aussi toutes les classes nécessaires. Et on peut facilement ajouter ses propres tests. Juste le code est orienté objet.

Comment vous protégez votre site des injections SQL, failles ?

par two3d » 07 juil. 2020, 16:32

Après m'être fait tronquer une base de données, injecter du code malveillant dans le header du site et voir mon htaccess modifié pour rediriger vers des sites bizarres (oui c'est à peu près tout, sauf peut être un site qui ma générer des images bizarres sur mon générateur de bannière pour webmaster où j'avais oublié de sécuriser une variable #-o ) j'ai lu pas mal de tutos sur les injections SQL et j'ai décidé de sécuriser et de ne plus faire confiance à ce que l'utilisateur peut entrer (la première règle!)

Je vous partage mes fonctions qui me suivent dans tous mes projets, qui sont indispensables pour moi et la sécurité des sites que je crée.


Fonction htmlent()

La fonction suivante sécurise les données entrées par l'utilisateur, créée depuis pas mal de temps et améliorée depuis le temps car au début j'utilisais seulement htmlentities($ma_var)
function htmlent($texte){
	$arr=["#","\\","--"];
	$inarr=0;
	do {
		//si le dernier caractère est un signe qu'on ne souhaite pas ($arr) on le retire, pour éviter les injections SQL et autre bug qui pourrait être causé lors du transfert de table (ou autre car le \ pourrait simplement omettre le ' de la requete)
		if(in_array(substr($texte,-1,1),$arr)){
			$texte=substr($texte,0,-1);
			$inarr=1;
		} else 
			$inarr=0;
	} while($inarr==1);
	//on retourne le texte bien écarté de toutes faille (il y en a toujours ceci dit...)
	//on le passe à trim pour supprimer espaces et saut de ligne en début et fin de chaine
	return trim(htmlentities($texte,ENT_QUOTES,"UTF-8"));
}

Du coup je m'en sert pour sécuriser mes requêtes comme ceci:
"INSERT INTO table SET nom='".htmlent($_POST['nom'])."'...
"SELECT * FROM table WHERE id='".htmlent($_GET['id'])."'...


Fonction verif()

La fonction suivante permet de s'assurer que ce qui à été saisie par l'utilisateur et bien ce que l'on attends
function verif($type,$chaine){
	if($type=='mail'){
		if(preg_match("#^[a-z0-9_-]+((\.[a-z0-9_-]+){1,})?@[a-z0-9_-]+((\.[a-z0-9_-]+){1,})?\.[a-z]{2,30}$#i",$chaine))
			return true;//c'est cadeau la regex, quelques années à la peaufiner celle là ;) utilisée pour la page d'inscription, de contact et autre formulaire où il faut saisir un mail
		
	}elseif($type=='num'){
		if(preg_match("#^[0-9]+$#",$chaine))
			return true;//la vérification que j'utilise le plus, simple et effiace, je ne préfère pas utiliser is_numeric() ou is_int car il accepte plus que [0-9]+..., là je suis certifié avoir un chiffre ou une suite de chiffres à l'arrivée ;)
		
	}elseif($type=='site'){
		if(preg_match("#^https?:\/\/(www\.)?[a-z0-9_-]+((\.[a-z0-9_-]+){1,})?\.[a-z]{2,30}((\/[a-z0-9_-]+){1,})?$#i",$chaine))
			return true;//vérifie si c'est un URL, celle ci aussi depuis quelques années à l'améliorer, elle autorise un nombre illimité de sous domaine et vérifie si il y a des dossiers (et seulement des dossiers!) ou pas après le domaine ;)
		
	}elseif($type=='image'){
		if(preg_match("#\.(jpg|jpeg|png|gif)$#i",$chaine))
			return true;// je l'utilise pour l'upload de photo, ça me permet de vérifier l'extension du fichier
		
	}
	//si rien est OK, on retourne false
	return false;
}

Je l'utilise comme ceci (exemple):
if(isset($_GET['action'],$_GET['id']) && verif("num",$_GET['id'])){
	$id=$_GET['id'];
	if($_GET['action']=="supprimer"){
		if(requete("DELETE FROM table WHERE id=$id"))
			echo "Supprimé!";
...
Bien sûr on peut imaginer d'autres vérifications avec cette fonction...


Et vous, qu'utilisez-vous pour protéger vos sites ? Question sensible ? Les pirates peuvent voir comment on procède et tenter de contourner nos protections, j'en doute pas une seconde!