Tester la securité ?

par **netsupra** » 06 avr. 2006, 20:46

De multiples failles ont été découvertes dans toutes les versions PHP, exceptées les dernières qui sont justement pourvues des corrections adéquates. Sont donc concernées toutes les versions antérieures à la 4.3.10 et à la 5.0.3. Ces dernières apportent des correctifs sur les failles suivantes :

* Une faille dans la fonction "pack()" : Dépassement de tampon et exécution de code arbitraire avec privilèges
* Une faille dans la fonction "unpack()" : couplée à la première faille, permet d'outrepasser des mécanismes de protection de la pile
* Une erreur dans safe_mode quand des commandes sont exécutées : uniquement si le PHP fonctionne en multi-threaded sur un serveur Unix, la restriction safe_mode_exec_dir peut être dépassée par l'injection de commandes shell dans le nom du répertoire
* Une autre erreur dans safe_mode : combinée à certaines utilisations de la fonction "realpath()", permet de dépasser safe_mode à travers un chemin d'accès spécial
* Une erreur dans la gestion des chemin d'accès des fichiers : le problème vient de la fonction "realpath()" qui est utilisée pour obtenir le chemin d'accès absolu d'un fichier.
* Plusieurs erreurs dans le code de désérialisation peuvent conduire à révéler des informations ou à l'exécution de code arbitraire à travers la fonction "unserialize()".
* Une erreur dans la fonction "shmop_write()" : permet d'écrire dans une zone non-protégée de la mémoire
* Une erreur non spécifiée dans la fonction "exif_read_data()" pendant la gestion des noms longs de sections.
* Une erreur dans la fonction "addslashes()" : peut être exploitée pour lire arbitrairement des fichiers sur le système.
* Une erreur dans "magic_quotes_gpc"

Si on part du principe que tous les servuers ne sont pas pourvus des dernieres versions de php et que de toute facon de nouvelles failles seront trouvées dans celles ci, mieux vaut mettre en place un minimum de sécurité

Netsupra

par **Luffy Duck** » 06 avr. 2006, 12:02

Pour les buffer overflows

Et comment tu fais des dépassements de tampon en php ?

par **netsupra** » 04 avr. 2006, 21:52

Désolé pour la petite abscence.
Il va de soit que tout cela n'est vraiment utile que lors d'une connection securisé SSL. Dans les autres cas c'est moin utile mais ca sert toujours car certains problemes de securités viennent du reroutage des requetes vers une autre page.
@roups : ton mot de passe, tu es obligé de le poster. UIne fois recupéré, tu le crypte via md5()
<:)
Netsupra

par **Roups** » 04 avr. 2006, 19:34

En fait pour le md5 ne sert a rien ?
Mon mot de passe je le fais transiter en POST ?

par **zeus** » 30 mars 2006, 10:38

Comment est-ce que tu cryptes les données en php sans faire d'aller retour client/serveur ?

Si je comprend bien, dès la récupération des POST, tu cryptes les datas ? Si c'est le cas, il reste tout de même le transit entre le client et le serveur pendant lequel le pass est en clair

par **netsupra** » 30 mars 2006, 10:35

Je ne le fais pas en JS mais en php! avec la fonction md5() dediée. Pour les buffer overflows etc..., on peut (meme via des exploits) faire executer du code a une page lorsque les formulaires ne sont aps protégés efficacement (probleme notament rencontrés sur les programmes open-source).
Il suffit donc d'afficher le contenu de $_POST pour recuperer entre autre le mot de passe. D'ou l'utilité de crypter les données au sein des pages via une une fonction php.
<:)
netsupra

par **naholyr** » 30 mars 2006, 10:31

un MD5 côté client est aussi sécurisé qu'un MD5 côté serveur ça n'est pas le problème, par contre tu fais comment si l'utilisateur a désactivé JS ?

par **zeus** » 30 mars 2006, 10:09

c'est pas ironique du tout, c'est tout ce qu'il y a de plus serieux

Quand on parle de sécurité, j'aime bien pouvoir justifier ce que j'avance et quand on me démontre une faille ou une possibilité de piratage, j'aime bien comprendre pour la prendre en compte dans mes futurs développement.

par **netsupra** » 30 mars 2006, 09:36

c'est ironique ou c'est une vraie question (j'aime pas m'enfoncer quand je dis des betise

)
<:)
Netsupra

par **zeus** » 30 mars 2006, 09:27

Par contre, al ou je ne suis pas d'accord avec toi c'est qu'un pirate peut plus facilement intercepter un $_post en le redirigeant vers une autre page que celle voulue (buffer-overflow, include mal protégé, etc...) que de recuperer le mot de passe qui permet d'acceder au scripts

Je ne suis pas sûr de comprendre ce que tu veux me dire ...

Si tu veux bien développé, je suis également très interessé

Sinon, en ce qui concerne l'algo de cryptage en JS, vu que c'est du côté client, tout le monde peut y avoir accès facilement ...

par **netsupra** » 29 mars 2006, 20:28

Non, l'algorythme ne sert que pour les transferts de données entre les pages entre autres dans les variable globale (on va pas pousser jusqu'a passer le mdp en parametre dans l'url

). Il est donc codé en php sous forme d'une fonction et toutes les données sensibles sont cryptées avec cette fonction. Il peut s'agire d'une fonction qui remplace telle lettre par telle autre (meme si c'est simple, et vu qu'un mot de passe est censé ne pas avoir de signification, pas de problème).
md5 est une fonction de hachage qui permet d'obtenir une chaine de 128bit. Il est supposé incassable puisque pour deux chaines différentes, les chaine de hachage sont différentes. C'est un procédé très utilisé pour des applications ne nécessitant par une sécurité "militaire".
Le md5 ne peut pas etre utilsé pour transmettre des variables puisqu'il n'est pas réversible.
Si tu as d'autres questions je me ferais un plaisir d'y repondre
<:)
Netsupra

par **Roups** » 29 mars 2006, 20:04

Cool, merci de vous etre interessés.
Tout cela m'eclaire un peu...
Je pense que je ne suis pas le seul.

netsupra, tu parles de faire un algorythme avant d'envoyer le pass, tu le fais comment en javascript (visible de tous) ? C'et forcement avant l'envoi donc cote client ?
Ou tu le modifes avant de l'inserer dans la base, et tu fais appel a l'algorythme avant la verification du passe dans la base ?

Comment fonctionne le MD5 ?
Peut etre mieux de crypter directement en md5.

En tout cas merci de vos reponses

par **netsupra** » 29 mars 2006, 17:59

ok, mais je parlais sniffing a part.
Par contre, al ou je ne suis pas d'accord avec toi c'est qu'un pirate peut plus facilement intercepter un $_post en le redirigeant vers une autre page que celle voulue (buffer-overflow, include mal protégé, etc...) que de recuperer le mot de passe qui permet d'acceder au scripts (et encore, cela n'implique pas qu'il ait acces aux mot de passe si le processus de cryptage ne passe pas par l'utilisateur (mot de passe stocké dans la bdd cryptés avec md5(), et les transfert crypé avec un petit algorythme aussi bete soit-il).
<:)
Netsupra

par **zeus** » 29 mars 2006, 17:19

Je pense que, effectivement, tu es à côté de la plaque.

Ta remarque est très pertinente dans le sens que, si il n'y a pas de ssl (https), le mot de passe transite sur le reseau en clair.

Par contre, le fait que la page de traitement soit la page d'affichage du formulaire ne change en rien le problème vu qu'il y a tout de même un aller-retour serveur/client et que le mot de passe transite tout de même sur le réseau.

Le moyen le plus simple pour récupérer un mot de passe n'est pas de remplacer la page cible du formulaire puisqu'elle implique d'acceder au serveur qui heberge les script (à ce moment là, le pirate accède directement à la bdd puisqu'il a accès aux script, il a accès aux identifiants de la base), mais d'écouter les transmissions IP et de récupérer les informations transittants

De même, l'installation de ssl (et donc la mise en place du protocole https) crypte la transmission des données et le mot de passe transite sur le réseau en crypté et si quelqu'un ecoute les paquets IP, il n'aura pas le pass en clair

par **netsupra** » 29 mars 2006, 16:31

Oui bien sur mais la on arrive dans des details (peut-etre pas tant que ca mais bon)...
ce que je dit c'est que lorsque tu as
<form method="post" action="verslapagedetraitement.php">
</form>
si quelqu'un arrive a usurper la page de traitement et arrive, il arrive a avoir le mot de passe. Meme en SSL!
donc autant faire
<form method="post">
</form>
et gerer tous les champs dans la page courante (jusqu'a preuve du contraire le pirate ne peut pas remplacer une page en cours d'execution) et ensuite si les champs ont besoin des envoyés vers une autre page, autant les crypter avant de les envoyer.
(Je suis peut-etre completement a cote de la plaque dans ce cas priere de m'excuser)
<:)
Netsupra

Tester la securité ?

Répondre

Étendre la vue Revue du sujet : Tester la securité ?