Discussion :

[nazoreen]

Bonjour,

Je viens de mettre au point des fonctions sécurisées compatible UTF-8.

Fonction pour vérifier un email et une autre pour du texte à partir d'un formulaire.

On peut facilement le modifier pour d'autre type de vérification (par ex adresse d'un site)

Concernant l'UTF-8, j'ai fait en sorte d'avoir un regex compatible étant donné que je n'ai rien trouvé sur le net sur une expression rationnelle existante, donc je l'ai fait à ma petite sauce...

Voilà donc le code à mettre dans une page nommée security.php et tester vous-même...

Donc merci de dire si vous voyez des trous de sécurités, ainsi que leurs solutions possible, ça permettra d'améliorer les fonctions pour le grand bien de la communauté.

A bientôt...

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
 
<?php
session_start();
 
function mail_secure($value,$token1,$token2)
{
	if (isset($value) && $value != "" && isset($token1) && $token2 == $token1)
	{
		$verif = eregi('^[a-zA-Z0-9\._-]+@[a-zA-Z0-9\.-]+\.[a-zA-Z]{2,4}$', $value);
		if ($verif == "1")
		{
			$string = mb_convert_encoding(htmlentities(trim(strip_tags(addslashes($value)))),"HTML-ENTITIES","UTF-8");
			return $string;
		}
	}
}
 
function text_secure($value,$token1,$token2)
{
	if (isset($value) && $value != "" && isset($token1) && $token2 == $token1)
	{
		$verif = eregi('^[[:alnum:]\&\;]{1,}$', htmlentities($value));
		if ($verif == "1")
		{
			$string = mb_convert_encoding(htmlentities(trim(strip_tags(addslashes($value)))),"HTML-ENTITIES","UTF-8");
			return $string;
		}
	}
}
 
if (!empty($_POST['register']))
{
	$test1 = mail_secure($_POST['email'],$_SESSION['token'],$_POST['token']);
	echo $test1,"<br />";
 
	$test2 = text_secure($_POST['words'],$_SESSION['token'],$_POST['token']);
	echo $test2,"<br />";
}
 
$token = md5(uniqid(rand(), true));
$_SESSION['token'] = $token;
?>
<form method="post" action="security.php">
<input type="text" name="email">
<br>
<input type="text" name="words">
<br>
<input type="hidden" name="token" value="<?php echo $token; ?>">
<input type="submit" name="register" value="Soumettre">
</form>

[wamania]

Suivant ton SGDB, addslashes ne suffit pas
Pour mysql par exemple, il faut mysql_real_escape_string.

Si on ne prend pas l'aspect SGDB en compte, alors pas besoin du addslashes.
Je serais plus d'avis donc de ne pas mettre le addslashes ici automatiquement, mais au cas par pas à l'insertion dans les requetes.

Toujours pour addslashes, je te conseil,

• soit $str = addslashes(stripslashes($str))
• soit if ( ! get_magic_quotes_gpc() ) { $str = addslashes($str); }

pour éviter les magics quotes.

Je traiterais pas le mail pareil que le text.
Pour moi, si htmlentities($mail) != $mail , alors ALERTE GENERALE
Quand on est dans ce cas la, l'email ne peut pas être accepté.

Sinon, le principe est bon.

[Yogui]

Salut

Non, ce n'est pas tout à fait correct. Dès lors que l'on utilise addslashes() et htmlentities() dans le même objectif, il y a un gros souci.

• addslashes() et ses équivalents (il est préférable d'utiliser mysql_real_escape_string(), comme cela a été suggéré par wamania) sont à utiliser exclusivement avant d'envoyer des données dans une requête destinée à la base de données.
• htmlentities(), en revanche, est à utiliser exclusivement pour les données à afficher dans la page Web.

En effet, un mail est une page Web qui n'est pas nécessairement affichée par un navigateur. À ce titre, il faut traiter son contenu de la même manière que l'on traite le contenu d'une page Web classique.

Lis au moins l'introduction de ce tutoriel : Initiation aux expressions régulières en PHP

[wamania]

htmlentities(), en revanche, est à utiliser exclusivement pour les données à afficher dans la page Web

Oui, c'est vrai, pour facilité la modification, mais c'est pas incorrect de la faire avant l'enregistrement en base.
Mais oui, dans un contexte général (seul à prendre en compte vu que tu partage tes sources), alors le htmlentities doit être fait juste avant l'affichage et pas avant

[Yogui]

Dans le sens où une base de données est prévue pour conserver uniquement des données brutes, dénuées de tout caractère de présentation, c'est une erreur d'utiliser htmlentities() à des fins de stockage. Que se passe-t-il le jour où tu dois utiliser ta BDD pour créer autre chose qu'une page Web, par exemple un PDF, un fichier Flash ou que sais-je encore ? Il te faudra réviser le contenu de la BDD ainsi que tous les scripts...


Non, vraiment, arrêtez d'utiliser htmlentities() à tout va. Laissez son rôle à chaque élément : la BDD stocke des infos brutes, le langage de script remplit la BDD, récupère les infos et les met en forme, etc. Si vous ne vous y conformez pas, vous rencontrerez de gros problèmes un jour ou l'autre.

[berceker united]

Dans le sens où une base de données est prévue pour conserver uniquement des données brutes, dénuées de tout caractère de présentation, c'est une erreur d'utiliser htmlentities() à des fins de stockage. Que se passe-t-il le jour où tu dois utiliser ta BDD pour créer autre chose qu'une page Web, par exemple un PDF, un fichier Flash ou que sais-je encore ? Il te faudra réviser le contenu de la BDD ainsi que tous les scripts...


Non, vraiment, arrêtez d'utiliser htmlentities() à tout va. Laissez son rôle à chaque élément : la BDD stocke des infos brutes, le langage de script remplit la BDD, récupère les infos et les met en forme, etc. Si vous ne vous y conformez pas, vous rencontrerez de gros problèmes un jour ou l'autre.

Prosternez-vous sur ces paroles, développeur infidèles.