PHP - Méthode d'encodage/décodage de lien et de formulaire

shensi · Le 17/07/2010, à 04:50

Bonjour,
Je suis en train de mettre un jour un site web et j'aimerai y rajouter une belle couche de sécurité mais jen'arrive pas trop à m'en dépétrer ! :-(

L'objectif étant de passer toutes les liens de mon site par une moulinette de cryptage des paramètres et de faire pareil pour les formulaires ...

J'ai donc 2 fonctions encode() et decode, un petit formulaire et un lien afin de vous montrer ou j'en suis :

<?php


if(!isset($_SESSION['auth'])){
session_start();
$_SESSION['auth']='ok';
}

function decode($maChaineCrypter){

		$maCleDeCryptage=$GLOBALS['PHPSESSID'];

		$maCleDeCryptage = md5($maCleDeCryptage);
		
		#echo "Clé de cryptage md5 du PHPSESSID :".$maCleDeCryptage."<br>";
		$letter = -1;
		$newstr = '';
		$maChaineCrypter = base64_decode($maChaineCrypter);
		$strlen = strlen($maChaineCrypter);
	for ( $i = 0; $i < $strlen; $i++ ){
		$letter++;
		if ( $letter > 31 ){
			$letter = 0;
		}
		$neword = ord($maChaineCrypter{$i}) - ord($maCleDeCryptage{$letter});
		if ( $neword < 1 ){
			$neword += 256;
		}
	$newstr .= chr($neword);
	}
return $newstr;
}

function encode($maChaineACrypter){

		$maCleDeCryptage=$GLOBALS['PHPSESSID'];

		$maCleDeCryptage = md5($maCleDeCryptage);
		
		#echo "Clé de cryptage md5 du PHPSESSID :".$maCleDeCryptage."<br>";
		$letter = -1;
		$newstr = '';
		$strlen = strlen($maChaineACrypter);
	for($i = 0; $i < $strlen; $i++ ){
		$letter++;
		if ( $letter > 31 ){
			$letter = 0;
		}
		$neword = ord($maChaineACrypter{$i}) + ord($maCleDeCryptage{$letter});
		if ( $neword > 255 ){
		$neword -= 256;
		}
		$newstr .= chr($neword);
	}
	return base64_encode($newstr);
}




if(!isset($_GET['do'])){
	$url="";
}
else{
	$url=decode($_GET['do']);
		
	# Resultat du lien
	echo "URL : ".$url."<br><br>";
	
	#echo parse_str($url)."<br>";
	echo $do."<br>";
	echo $manger."<br>";
	echo $action."<br>";
	
	# Résultat du formulaire
	echo decode($_POST['do'])."<br>";
	echo decode($_POST['manger'])."<br>";
	echo decode($_POST['sortir'])."<br>";
	echo decode($_POST['rire'])."<br>";	
}
?>


<a href='?do=<?php echo encode("test&manger=hihi&action=frite")?>' ><b>Test</b></a>

<div class="formulaire">
<form name="membre" method="post" action="?do=<?php echo encode("test" ); ?>" enctype="multipart/form-data"> 
<input type="hidden" name="manger" value="<?php echo encode('frite')?>">
<input type="hidden" name="sortir" value="<?php echo encode('cinema')?>">
<input type="hidden" name="rire" value="<?php echo encode('hohoho')?>">
<table>	

<tr><td>&nbsp;</td></tr>
<tr>
	<td align="center">
	<input type="submit" value="Envoyer" class="bouton" style="width:250px;">
	</td>
</tr>
<tr><td>&nbsp;</td></tr>
 </table>
</form>
</div>

Qu'en pensez vous ? est-ce assez sécurisé ? Comment faire en sorte que la taille des url soient uniformes ?
J'ai aussi l'impression que la variable de session devant servir de random ne fonctionne pas...
Comment faire en sorte de récupérer toutes les variables (surtout la première quand je passe par le lien cad : test)

Merci d'avance pour votre aide !

Dernière modification par shensi (Le 18/07/2010, à 14:12)

shensi · Le 18/07/2010, à 11:28

Un petit up? Deux petit UP ! trois petits UP! C'est bon !!

pouchat · Le 18/07/2010, à 11:41

encoder les paramètres d'une URL n'est pas vraiment une solution, encore moins sécurisée. Qu'essaies-tu de faire exactement :
- encoder pour chiffrer ?
- sécuriser quelle partie ?
- dans quel but ?

edit : je viens de lire vite fait ton code, j'ai pas compris l'intérêt "d'encoder" les GET/POST dans ce cas.
edit2 : si tu cherches à faire un token pour pallier aux attaques CSRF, il y a mieux.

Dernière modification par pouchat (Le 18/07/2010, à 11:45)

shensi · Le 18/07/2010, à 13:37

Salut ! Super !
Je cherche à crypter les valeurs et les paramètres des formulaires et des url côté client, afin qu'il ne sache pas quels sont les ID que je manipule... voir même les champs 'name' de mes formulaires ?!

- Effectivement c'es encoder pour chiffrer .
- Sécuriser en même temps les pages PHP que j'appelle à travers mon CMS maison.
- Dans le but de camoufler un maximum le schéma de ma base de données et le squelette de mon site web..

Il y a des tas de sites PHP qui mettent en place un mécanisme similaire pour encoder les valeurs des formulaires ?

Mon bout de code est un exemple de ce que je voudrais faire, en fait google ou autres moteurs ne m'ont pas permis de mettre la main sur ce que je cherchais...

shensi · Le 18/07/2010, à 13:50

Voici un extrait de documentation de ce que j'essaye de mettre en place.
Dans un premier temps, je souhaite restituer du code côté client qui sois le plus discret possible.
Je validerai l'ensemble des formulaires en ajax afin de ne laisser aucun code côté client
... Je veux préparer mon code aux différentes attaques possible et imaginable par un client: Sql injection, XSS , CSRF

Et donc pour le moment je brouille les pistes sur le contenu de la base de données et le nom des pages php que j'affiche !

Site : http://julien-pauli.developpez.com/tuto … loyer#LIII

Par exemple, un champ de formulaire "hidden" est certes caché de l'affichage par un navigateur, mais il demeure présent dans le code source et donc entièrement lisible.

Il faut aussi garder en tête qu'au moins on en dit sur son code, au plus celui-ci sera sécurité. Il vaut toujours mieux garder les choses cachées, plutôt que de les exposer et faciliter leur manipulation. Ainsi pour une transaction on préfèrera la méthode POST à la méthode GET. En effet, en POST, le paramètre devient un paramètre de la requête HTTP et n'est pas visible dans la barre d'adresse.
Ceci élimine déja les petits curieux s'amusant à changer les types ou les valeurs des variables GET passées dans l'URL. En elle même, cette défense ne va pas vous assurer un site imperméable, il reste possible de modifier une requête POST, mais au moins vous évitez de tenter le diable, ce qui est un point très important en matière de sécurité d'applications web.
Dans la théorie HTTP, la méthode GET est utilisée pour récupérer des informations, pour interroger un serveur, alors que la méthode POST est vouée à l'envoi d'informations et à la modification de données.
L'utilisation du mod-rewrite permet aussi d'embrouiller les éventuels pirates en changeant la logique originelle d'une transaction.
Si on ne peut faire autrement, et que l'utilisation d'un GET s'impose, alors on s'efforcera d'encrypter les paramètres et leurs valeurs afin de ne pas révéler une partie de la logique applicative. Si un site propose une URL du type http://site.com/index.php?show=links&linkID=3 , on devine trop facilement le code qui se cache derrière...
De la même manière, le code rendu final ( typiquement : (x)HTML ) doit être épuré de tout commentaire pouvant donner un indice au pirate. Selon certaines règles, en lisant la source HTML d'une page résultat, on peut retrouver tout ou partie de la logique de découpage derrière. Lorsque on voit des <---! début du header ; on a vite compris.

Un site dynamique possède la particularité de récupérer des informations de l'utilisateur, afin de créer une page personnelle propre à chacun. Ceci doit être fait de manière sécurisée : Ne jamais utiliser directement une valeur qu'un utilisateur envoie.
Par exemple, si on veut afficher le nom de l'utilisateur, pour lui sortir un joli "Hello user", on s'assurera que le nom de l'utilisateur ne comporte pas de Javascript susceptible de causer une faille XSS qui pourrait mener au vol de session, ou à la manipulation du site.
Toutes les entrées de l'application doivent systématiquement vérifier qu'aucun code de script n'est inséré, et qu'aucun caractère n'est encodé de manière à avoir une signification particulière lors de son interprétation.

Dernière modification par shensi (Le 18/07/2010, à 13:51)

pouchat · Le 18/07/2010, à 18:26

oulah. J'aimerais voir un peu la tronche d'une appli de celui qui a marqué ça. Certaines idées sont justes d'autres en contradiction.

D'abord ce qui est vrai :
tout ce qui passe par le client peut-être récupéré et analysé : ça veut dire le css, le js et le code html. Donc les formulaires, peut-importe le type <input>, le nom des champs, les hidden (...) il ne faut absolument pas basé sa sécu la dessus. D'autant plus qu'une pile d'extensions firefox (firebug, webdev, http) permettent de récupérer le tout d'une facilité déconcertante, voire de modifer et de rejouer.

Partant de ce constat, ça ne sert absolument A RIEN de chiffrer le nom des champs de formulaires ou des variables post/get. C'est même pire, je m'explique.

Ce qui est à corriger :

Il faut aussi garder en tête qu'au moins on en dit sur son code, au plus celui-ci sera sécurité. Il vaut toujours mieux garder les choses cachées, plutôt que de les exposer et faciliter leur manipulation.

Là c'est un peu contradictoire : quid de la philosophie libre et surtout le fait qu'un code ouvert peut-être relu et analysé, les failles découvertes/corrigés plus rapidement. De plus, publier un code c'est faire un minimum attention à ce qu'on écrit. Un code fermé non. Mais ce n'est pas le sujet de ma réponse.

Ainsi pour une transaction on préfèrera la méthode POST à la méthode GET. En effet, en POST, le paramètre devient un paramètre de la requête HTTP et n'est pas visible dans la barre d'adresse.

Chacun fait comme il veut : POST/GET le résultats est le même à la fin. Cependant, une bonne habitude à suivre (http://fr.wikipedia.org/wiki/Representational_State_Transfer) c'est d'utiliser GET pour récupérer et POST pour modifier ce que tout développeur web devrait faire naturellement.

Ceci élimine déja les petits curieux s'amusant à changer les types ou les valeurs des variables GET passées dans l'URL.

Dans chaque appli web que je développe, je me méfie autant des petits curieux que des grands. Faire déjà une différence à ce niveau c'est augmenter le risque de se faire passer de la vaseline.

L'utilisation du mod-rewrite permet aussi d'embrouiller les éventuels pirates en changeant la logique originelle d'une transaction.

Archi faux. Le mod_rewrite - la réécriture d'url - c'était à la base pour avoir des urls propres et être enfin référencé par google. C'est donc exactement l'inverse, le mod_rewrite est là pour exposer plus clairement l'url et la logique de la page ! Le mod_rewrite n'est absolument pas fait pour protéger !
Exemple :
sans rewrite : une page de ton site est accessible genre "page.php?order=nom&orderby=asc&page=2".
avec rewrite : "page/nom/asc/2".
Dans les 2 cas tu récupères ta variable par un GET et donc dans les 2 cas je peux en faire ce que je veux. La différence est qu'en tant que visiteur je trouve la 2ème plus sympa à lire et plus "sûr" et en tant qu'attaquant plus simple à forger : ben oui je me contre-fou du nom des GET j'ai simplement à forger un truc du genre "/page/([a-z]+)/([asc|desc]+)/([0-9]+)", de toute façon c'est le mod_rewrite qui mappera ça vers un GET.

Si on ne peut faire autrement, et que l'utilisation d'un GET s'impose, alors on s'efforcera d'encrypter les paramètres et leurs valeurs afin de ne pas révéler une partie de la logique applicative. Si un site propose une URL du type http://site.com/index.php?show=links&linkID=3 , on devine trop facilement le code qui se cache derrière...
De la même manière, le code rendu final ( typiquement : (x)HTML ) doit être épuré de tout commentaire pouvant donner un indice au pirate. Selon certaines règles, en lisant la source HTML d'une page résultat, on peut retrouver tout ou partie de la logique de découpage derrière. Lorsque on voit des <---! début du header ; on a vite compris.

D'abord je vois pas bien ce je pourrais faire d'un commentaire dans le code html... Je fais exactement l'inverse : j'expose au maximum la logique de présentation de mes pages. C'est non seulement clair pour mes visiteurs mais clair pour moi. Et si c'est clair pour moi c'est donc plus simple à sécuriser. J'ajoute que je me méfie plus d'un développeur qui structure son code et affiche une logique : je me dis qu'il a bien fait le tour parce que ça a été pensé et donc sécurisé. Un développeur qui fait un truc brouillon, compliqué voire tordu je me dis qu'à un moment ou un autre il a fait une boulette et là je vais tenter de voir laquelle ^^

La vrai sécurité se trouve dans cette phrase :

Toutes les entrées de l'application doivent systématiquement vérifier qu'aucun code de script n'est inséré, et qu'aucun caractère n'est encodé de manière à avoir une signification particulière lors de son interprétation.

Ca veut dire qu'absolument tout ce qui vient du client (_GET, _POST, _COOKIE) doit être checké pour te protéger toi (ta base, ton appli, ton serveur). Et tout ce qui est affiché ensuite doit aussi être de nouveau checké pour protéger tes visiteurs.

À partir de là, tu te fous complètement du nom des variables de l'url ou des posts, puisque tu les checks ! Au passage, des petites fonctions comme escape_string, htmlentities... t'évitent toute attaque XSS ou SQLInjection. Pour les CRSF, c'est un chouya plus long à mettre en place mais pas bien compliqué.

Pour faire simple, gère bien les entrées-sorties c'est 99% du boulot de sécurisation fait.

Dernière modification par pouchat (Le 18/07/2010, à 18:31)

shensi · Le 18/07/2010, à 19:31

Houla... Tu t'emportes Merci pour la réponse en tout cas.

Effectivement je me suis peut être un peut laché sur certaines de mes envies d'encryption de données
Le coup du champs "name" dans les formulaires, c'est sur on peut oublier ! Ca sert à rien

Il faut aussi garder en tête qu'au moins on en dit sur son code, au plus celui-ci sera sécurité. Il vaut toujours mieux garder les choses cachées, plutôt que de les exposer et faciliter leur manipulation.
Là c'est un peu contradictoire : quid de la philosophie libre et surtout le fait qu'un code ouvert peut-être relu et analysé, les failles découvertes/corrigés plus rapidement. De plus, publier un code c'est faire un minimum attention à ce qu'on écrit. Un code fermé non. Mais ce n'est pas le sujet de ma réponse.

Ce projet ci n'est pas un projet communautaire mais perso. DOnc le côté "quid de la philosophie libre" ou "relu et analysé" ou "failles découvertes/corrigés" n'ont malheureusement rien à voir avec ma question initiale qui était simplement d'exposer un bout de code pour faire un truc que j'ai retrouvé en application sur certains sites.

Ex : Une url pendant la navigation sur le site de ma banque : Les parmaètres envoyé enn méthode GET sont bien cryptés !

https://particuliers.secure.mabanque.fr/page.html?src=aWRzZXNzaW9uPTEwNTEyNjE4NTQmaWRwcmVzdD0zMDAwMzAwMDAwMDAxNTM1MDAwNTA3OTIxNTAwMDA1MCZsaXBlcnM9JmRldGFpbGNvbnM9TyZjZGdycGI9Q0FWJmNkcHJvZD0wNTAmbnVjYW1vPSZsaXByY289azeazeazeazeazehaXJlJmNkc3A9MDAxJl9uc2VjPTkmX25uZXc9Mg==&sign=95zvr1LAbDmdDF4qrYCDZ9MZZzI=

Effectivement méthode POST ou GET, je m'en fous ! Tout ce que je voulais c'est savoir si quelqu'un c'est le faire, l'a déjà fait ..

Ceci élimine déja les petits curieux s'amusant à changer les types ou les valeurs des variables GET passées dans l'URL.
Dans chaque appli web que je développe, je me méfie autant des petits curieux que des grands. Faire déjà une différence à ce niveau c'est augmenter le risque de se faire passer de la vaseline.

C'est ça ! Tu sais lire. Le gars qui a écrit cette doc, il dit la même chose que toi... Et tu le dis très bien au début de ta réponse :
D'autant plus qu'une pile d'extensions firefox (firebug, webdev, http) permettent de récupérer le tout d'une facilité déconcertante, voire de modifer et de rejouer.

- Pour le mod-rewrite je suis d'accord avec toi.

La vrai sécurité se trouve dans cette phrase :
Toutes les entrées de l'application doivent systématiquement vérifier qu'aucun code de script n'est inséré, et qu'aucun caractère n'est encodé de manière à avoir une signification particulière lors de son interprétation.
Ca veut dire qu'absolument tout ce qui vient du client (_GET, _POST, _COOKIE) doit être checké pour te protéger toi (ta base, ton appli, ton serveur). Et tout ce qui est affiché ensuite doit aussi être de nouveau checké pour protéger tes visiteurs.

Oui ! L'origine de mon post c'était bien ça ! C'est ce que je cherche à faire !! Mais en rajoutant une surcouche d'encodage sur les valeurs de mes formulaires et de mes liens ...

Ce que je cherche c'était peut être tout simplement me protéger contre les attaques CSRF en mettant en place :
- des noms de variables aléatoires (implémenter une table de nombre aléatoires qui sert à définir le nom d'une variable en fonction d'une session donnée)
- l'utilisation d'un secret (utilisation de token aléatoire sur toutes les pages sensibles

Si c'est cela que tu me proposes de faire dans ce cas oui je veux bien des info ?

Merci pour ton coup de main et ta perception de la sécurité... mais ce n'était pas la réponse que j'attendais...:D:cool:

Dernière modification par shensi (Le 18/07/2010, à 20:15)

HP · Le 18/07/2010, à 21:21

shensi a écrit :

Ex : Une url pendant la navigation sur le site de ma banque : Les parmaètres envoyé enn méthode GET sont bien cryptés !
https://particuliers.secure.mabanque.fr/page.html?src=aWRzZXNzaW9uPTEwNTEyNjE4NTQmaWRwcmVzdD0zMDAwMzAwMDAwMDAxNTM1MDAwNTA3OTIxNTAwMDA1MCZsaXBlcnM9JmRldGFpbGNvbnM9TyZjZGdycGI9Q0FWJmNkcHJvZD0wNTAmbnVjYW1vPSZsaXByY289azeazeazeazeazehaXJlJmNkc3A9MDAxJl9uc2VjPTkmX25uZXc9Mg==&sign=95zvr1LAbDmdDF4qrYCDZ9MZZzI=

Elles ne sont pas cryptées mais encodées ! Et çà, c'est une énorme différence…
C'est un peu dommage que tu ne sembles pas maîtriser ces concepts ni leurs méthodes !

shensi · Le 18/07/2010, à 21:32

Aoutch Ok ! Je vais relire les définitions ...
Bon ce que je souhaite faire c'est de l'encodage !
Mille excuse pour ma bourde, surtout si elle en a embrouillée certains.
Pour reprendre la première phrase de pouchat, et bien oui ce que je voulais faire c'est de l'encodage pour chiffrer mes url et formulaires.

HP · Le 18/07/2010, à 21:38

shensi a écrit :

c'est de l'encodage pour chiffrer mes url et formulaires.

l'encodage ne chiffre pas… à mon sens…
je pourrais réitérer mon précédent message !

shensi · Le 18/07/2010, à 21:47

Désolé si j'en froisse j'essaye juste de défendre mes bourdes...
Je maitrise mal les concepts, certes, mais dans le jargon, ce que je veux faire c'est :

crypter - Chiffrer, coder une information afin de la rendre incompréhensible à toute personne ignorant la méthode ou la clé de chiffrement;
fr.wiktionary.org/wiki/crypter

Encoder - Transcription de données vers un format ou un protocole codé
fr.wiktionary.org/wiki/encodage

pouchat · Le 06/09/2010, à 23:32

Je déterre, c'est la rentrée.

shensi a écrit :

Désolé si j'en froisse j'essaye juste de défendre mes bourdes...
Je maitrise mal les concepts, certes, mais dans le jargon, ce que je veux faire c'est...

Il n'y a pas de mal . C'est juste que comme on te l'a dit, il n'y a pas de réel intérêt à encoder le nom des champs ou les rendre aléatoires.

Maintenant si tu as un cas précis et concret, exposes-le et on pourra voir comment gérer ça.

shensi · Le 18/11/2010, à 00:24

Je re déterre, j'étais passé à autre chose le temps de méditer sur cette histoire d'encodage d'url.

Si toutefois vous avez une solution à m'apporter je suis toujours preneur !

Voilà un exemple de ce que je veux faire :

Côté navigateur client :

<table width="80%" align="center" height="30px" cellspacing="0" cellpadding="0"> 
    <tr>
        <td class="formValue">
            <?php
            if($mode == 1) $c="Situation 1"; $c1=1;
            if($mode == 2) $c="Situation 2"; $c1=2;
            ?>        
            <a href='?do=<?php echo encode("pi_traitement&action=change_mode&id=$c1");?>' > <?php echo $c ?></a>
        </td>
    </tr>    
</table>    >

Côté serveur

if(!isset($_GET['do'])){
    $url="";
}
else{
    $url=decode($_GET['do']);
}

switch($url) {
    default:
        $page="php/index.php";    
    break;

    case "pi_traitement" :
        $page="php/traitement.php";    
    break;
}

Pour le moment les fonctions encode/decode ne font strictement rien !

Comme je l'ai présenté dans le premier message je cherche une fonction encode/decode pour encoder l'url, de manière à ce que :

1 - Lorsqu'on passe le curseur de sa souris sur le lien on ignore les variables que j'utilise.
2 - Par la même occasion je masque la structure de mon site puisque que la seule partie visible en permanence de l'url est la suivante : http://192.168.23.12/index.php?do=aze67 … ablablabal

A rajouter à ca un petit cryptage SSL + plus fail2ban facon PHP ... et le tour est joué.

J'imagine qu'il existe des solutions puisque d'autres le font sur des sites PHP. En revanche je n'ai aps eu le temps de chercher et je n'ai pas trouvé de solution toute faite.

Les fonctions PHP ressemblant à ce que je veux faire sont les fonctions "urlencode" et "urldecode". En fait ma solution est peut être tout simplement sous mes yeux depuis le début.....

Merci d'avance

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 17/07/2010, à 04:50

PHP - Méthode d'encodage/décodage de lien et de formulaire

#2 Le 18/07/2010, à 11:28

Re : PHP - Méthode d'encodage/décodage de lien et de formulaire

#3 Le 18/07/2010, à 11:41

Re : PHP - Méthode d'encodage/décodage de lien et de formulaire

#4 Le 18/07/2010, à 13:37

Re : PHP - Méthode d'encodage/décodage de lien et de formulaire

#5 Le 18/07/2010, à 13:50

Re : PHP - Méthode d'encodage/décodage de lien et de formulaire

#6 Le 18/07/2010, à 18:26

Re : PHP - Méthode d'encodage/décodage de lien et de formulaire

#7 Le 18/07/2010, à 19:31

Re : PHP - Méthode d'encodage/décodage de lien et de formulaire

#8 Le 18/07/2010, à 21:21

Re : PHP - Méthode d'encodage/décodage de lien et de formulaire

#9 Le 18/07/2010, à 21:32

Re : PHP - Méthode d'encodage/décodage de lien et de formulaire

#10 Le 18/07/2010, à 21:38

Re : PHP - Méthode d'encodage/décodage de lien et de formulaire

#11 Le 18/07/2010, à 21:47

Re : PHP - Méthode d'encodage/décodage de lien et de formulaire

#12 Le 06/09/2010, à 23:32

Re : PHP - Méthode d'encodage/décodage de lien et de formulaire

#13 Le 18/11/2010, à 00:24

Re : PHP - Méthode d'encodage/décodage de lien et de formulaire

Pied de page des forums