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

[CritikKiller]

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

Code :

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]

et pourquoi tu fais tout ca ??

htmlentities()

addslashes() et stripslashes()

voila.

[CritikKiller]

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

Mici

Edit :

Donc en gros ca donnerait quelque chose comme ca :

Code :

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]

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

[Yogui]

@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]

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]

@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]

Envoyé par Kirkis

@macbook : Ça en impose plus si on l'écrit correctement
ポカヨケ

Mande pardon ????

[ShinJava]

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]

@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]

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]

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]

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

C'est à dire ca :

Code :

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.]

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]

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.]

Envoyé par CritikKiller

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

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

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

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]

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.]

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]

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.

[Mr N.]

Gné ? Quelle doc ? apparemment tu t'es trompé de bible
http://g-rossolini.developpez.com/tu...ncepts#LVI-D-6