[Sécurité] [Optimisation] Sécurisation des Variables POST et GET

**CritikKiller** · 12/03/2006, 21h49

Voila j'ai crée un script pour sécuriser les variables pouvant être modifiées manuellement par un utilisateur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
function secure($nomvar,$type)
{
	if($type == 'post')
	{
		$var = $_POST[$nomvar];
		$_POST[$nomvar] = &$var;
		$var = str_replace('\'', '\\\'',$var);
		$var = str_replace('#', '', $var);
		$var = str_replace('<', '&lt;', $var);
		$var = str_replace('[', '', $var);
		$var = str_replace(']', '', $var);
		$var = str_replace('`', '', $var);
		$var = str_replace('\\', '', $var);
	}
	elseif($type == 'get')
	{
		$var = $_GET[$nomvar];
		$_GET[$nomvar] = &$var;
		$var = str_replace('\'', '\\\'',$var);
		$var = str_replace('#', '', $var);
		$var = str_replace('<', '&lt;', $var);
		$var = str_replace('[', '', $var);
		$var = str_replace(']', '', $var);
		$var = str_replace('`', '', $var);
		$var = str_replace('\\', '', $var);
	}
 
}

Je voudrais savoir si il y avait des améliorations possibles sur le traitement de ma variable, si j'avais oublié des choses ou autres.

Merci d'avance pour votre aide.

**Maxoo** · 12/03/2006, 22h33

et pourquoi tu fais tout ca ??

htmlentities()

addslashes() et stripslashes()

voila.

**CritikKiller** · 12/03/2006, 22h46

Jme disais bien que c'était un peu long comme code

Mici

Edit :

Donc en gros ca donnerait quelque chose comme ca :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?php
function secure($nomvar,$type)
{
	if($type == 'post')
	{
		$var = $_POST[$nomvar];
		$_POST[$nomvar] = &$var;
		$var = htmlentities ($var);
		$var = addslashes ($var);
	}
	elseif($type == 'get')
	{
		$var = $_GET[$nomvar];
		$_GET[$nomvar] = &$var;
		$var = htmlentities ($var);
		$var = addslashes ($var);
	}
 
}
?>

**macbook** · 12/03/2006, 23h46

Ecraser l'environnement global est parfois une bonne idée.
Fais une recherche sur le Poka-Yoké.

**Yogui** · 13/03/2006, 10h03

@macbook : Ça en impose plus si on l'écrit correctement

ポカヨケ

@CritikKiller : Pourquoi ne pas faire un return dans ta fonction ?
Sérieusement, le sujet a été traité maintes fois. Regarde la doc de mysql_real_escape_string(), ils y donnent une fonction intéressante. Ensuite, à l'affichage seulement, utilise htmlentities().

**ShinJava** · 13/03/2006, 10h04

Desolé de squatter ce sujet...
J'ai du mal a comprendre l'interet de securiser les variables GET et POST

Car ces variables ne sont pas là par hasard... et heuh... non je ne vois pas pourquoi

Merci de m'éclairer sur ce sujet

++
ShinJava

**Yogui** · 13/03/2006, 10h06

@ShinJava : Normalement, ce ne sont pas les variables elles-mêmes que nous cherchons à modifier mais leur valeur avant de les utiliser dans une requête. Renseigne-toi sur l'injection SQL.

**macbook** · 13/03/2006, 10h09

Envoyé par Kirkis

@macbook : Ça en impose plus si on l'écrit correctement

ポカヨケ

Mande pardon ????

**ShinJava** · 13/03/2006, 13h39

Envoyé par Kirkis

@ShinJava : Normalement, ce ne sont pas les variables elles-mêmes que nous cherchons à modifier mais leur valeur avant de les utiliser dans une requête. Renseigne-toi sur l'injection SQL.

Houla ! Merci, j'ai commencé à chercher des infos dessus et ca fait peur !
*s'en va verifier son code*

merci

++
ShinJava

**Yogui** · 13/03/2006, 13h58

@macbook : Peut-être ne vois-tu pas les caractères japonais, peu importe.

@ShinJava : Renseigne-toi sur toutes les injections, tant que tu y es !
Au passage : http://thierrylhomme.developpez.com/php/php_secure/

**ShinJava** · 13/03/2006, 14h11

Envoyé par Kirkis

@macbook : Peut-être ne vois-tu pas les caractères japonais, peu importe.

@ShinJava : Renseigne-toi sur toutes les injections, tant que tu y es !
Au passage : http://thierrylhomme.developpez.com/php/php_secure/

Houla merci, entre temps j'ai lu l'article de PHP Secure, ma vision sur les requetes SQL à completement changé ! Je vais faire des test beaucoup plus poussé, interdire certains caractères (meme des mots !) , voir meme limité la taille de certains GET/POST...
Bah dit donc j'ai bien fais d'etre passé par ce sujet.
Merci beaucoup

!

Sinon j'arrive pas a lire les caracteres japonais aussi : o

++
ShinJava

**XtofRoland** · 13/03/2006, 14h12

peux ton provoquer des erreurs, en mofiant un formulaire?

par exemple en creant un input type=text name="$login"
qui créerait un variable $_POST['$login'] ... ou qqc de similaire?

**CritikKiller** · 13/03/2006, 16h52

@CritikKiller : Pourquoi ne pas faire un return dans ta fonction ?

C'est à dire ca :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<?php
function secure($nomvar,$type)
{
   if($type == 'post')
   {
      $var = $_POST[$nomvar];
      $_POST[$nomvar] = &$var;
      $var = htmlentities ($var);
      $var = addslashes ($var);
      return($var);
   }
   elseif($type == 'get')
   {
      $var = $_GET[$nomvar];
      $_GET[$nomvar] = &$var;
      $var = htmlentities ($var);
      $var = addslashes ($var);
      return($var);
   }
 
}
?>

Je ne vois pas l'interet du return en faite... Le code php après n'est pas lu?

**Mr N.** · 13/03/2006, 17h00

Et si la variable derriere $_POST[$nomvar] est un tableau ?
Pourquoi appliquer htmlentities avant d'insérer en base ?
Pourquoi appliquer addslashes avant d'afficher sur le navigateur ?
Pourquoi appliquer addslashes qui ne sera pas suffisant pour certains moteurs de recherche (comme mysql par exemple) ?

**CritikKiller** · 13/03/2006, 17h22

Envoyé par Mr N.

Et si la variable derriere $_POST[$nomvar] est un tableau ?

Dans mon cas, les données qui transitent sont des variables envoyées par un formulaire.

Envoyé par Mr N.

Pourquoi appliquer htmlentities avant d'insérer en base ?

Que ca soit fait avant ou après ca revient en meme. (Enfin c'est vrai qu'après ca pourrait être plus judicieux dans certains cas)

Envoyé par Mr N.

Pourquoi appliquer addslashes avant d'afficher sur le navigateur ?

C'est pas pour afficher sur le navigateur, mais pour pouvoir les traiter sans risques (Injection SQL par exemple...)

Envoyé par Mr N.

Pourquoi appliquer addslashes qui ne sera pas suffisant pour certains moteurs de recherche (comme mysql par exemple) ?

La je ne comprends pas ce que tu veux dire par contre.

**Mr N.** · 13/03/2006, 17h34

Envoyé par CritikKiller

Envoyé par Mr N.

Et si la variable derriere $_POST[$nomvar] est un tableau ?

Dans mon cas, les données qui transitent sont des variables envoyées par un formulaire.

Je ne vois pas le rapport. Les données d'un formulaire peuvent très bien arriver sous forme de tableau, suivant comment tu nommes tes champs.

Envoyé par CritikKiller

Envoyé par Mr N.

Pourquoi appliquer htmlentities avant d'insérer en base ?

Que ca soit fait avant ou après ca revient en meme. (Enfin c'est vrai qu'après ca pourrait être plus judicieux dans certains cas)

Non ca revient pas au même puisque tu va te retrouver avec des entités dans ta base et du coup les recherche seront légèrement plus difficile. De plus le contenu d'une base n'est pas forcément à destination de html, donc des entités n'ont pas forcément lieu de s'y trouver.

Envoyé par CritikKiller

Envoyé par Mr N.

Pourquoi appliquer addslashes avant d'afficher sur le navigateur ?

C'est pas pour afficher sur le navigateur, mais pour pouvoir les traiter sans risques (Injection SQL par exemple...)

Oui, mais une donnée qui provient d'un formulaire peut très bien être affichées sur un écran intermédiaire de confirmation par exemple. Du coup le addslashes n'est pas pertinent.

Envoyé par CritikKiller

Envoyé par Mr N.

Pourquoi appliquer addslashes qui ne sera pas suffisant pour certains moteurs de recherche (comme mysql par exemple) ?

La je ne comprends pas ce que tu veux dire par contre.

Tout simplement que addslashes n'est pas suffisant pour se prémunir des injections SQL sous mysql. Chaque moteur pocède ses caractères d'échappements, et addslashes n'est pas suffisant dans tous les cas.

**CritikKiller** · 13/03/2006, 17h40

Tout simplement que addslashes n'est pas suffisant pour se prémunir des injections SQL sous mysql. Chaque moteur pocède ses caractères d'échappements, et addslashes n'est pas suffisant dans tous les cas.

C'est à dire?

Et que me propose tu comme solution alors pour eviter les injections SQL et les attaques XSS? Le Poka Yoké? (je suis en train de lire l'article)

**Mr N.** · 13/03/2006, 17h48

Deux types d'attaques différentes == deux méthodes de protection différentes.
pour XSS, htmlentities (a priori et ca dépend des cas)
pour SQL, ca dépend de ton moteur. Si c'est MySQL alors mysql_real_escape_string sera sufffisant dans 99% des cas.

Sinon l'article de pokatruc je l'ai pas encore lu donc je ne peux rien dire dessus...

**CritikKiller** · 13/03/2006, 18h04

Par contre je suis sur la doc de la fonction :
mysql_real_escape_string()

Mais je n'arrive pas à comprendre les arguments :
mysql_real_escape_string(MYSQL *mysql, char *en, const char *de, unsigned long longueur)

[MYSQL *mysql] : ?
[char *en] : ?
[const char *de] : ?
[unsigned long longueur] : ?

Si on pouvait m'éclairer, merci d'avance.