Bonjour,
je lis par ci par là, Securité, ect...

J'aimerai savoir si des testeurs existent :

Savoir si on peut modifier mes bases de données,
Usurper un utilisateur, ect ...

Merci de vos renseignements.

oui, on peut
rien n'est sur

Ne vois aucune aggressivité, mais MERCI pour cette reponse de normand...
Ca fait drolement avancer le schimlblick....

En fait la question c'est ou et quand placer les Htmlentities, addslashes et autres....

Le mot de passe utilisateur doit il est cripté, si on envoie en POST...
Ect...

Merci

En fait la question c'est ou et quand placer les Htmlentities, addslashes et autres....

c'est pas ce que j'avais compris en lisant la question.

Ca fait drolement avancer le schimlblick....

on ne peut pas te faire un exposé complet sur la sécurité
lis ce site http://www.phpsecure.info/v2/zone/pArticle

Salut,

disons que quand tu peux crypter un mot de passe, crypte le!
par exemple, dans un $_post, mieux vaut eviter d'avoir le mdp en clair car prenons un exemple simple : lors de la validation du formulaire, le pirate arrive a le rediriger vers une page de sa creation qui lui donne le contenu du $_post, il peut ainsi avoir le mot de passe en clair simplement.

ensuite pour chaque champ d'un formulaire, mets un htmlentities(addslashes($tavariable)).

<:)
Netsupra

disons que quand tu peux crypter un mot de passe, crypte le!

par exemple, dans un $_post, mieux vaut eviter d'avoir le mdp en clair car prenons un exemple simple : lors de la validation du formulaire, le pirate arrive a le rediriger vers une page de sa creation qui lui donne le contenu du $_post, il peut ainsi avoir le mot de passe en clair simplement.

A preuve du contraire le contenu de $_POST ne sera pas haché/crypté. Il transite en clair sur le net! (sauf connexion ssl).

Il sera haché/crypté, une fois sur sur le serveur, pour la mise en bdd ou pour sa vérification avec un mdp stocké sur le serveur. Si un pirate redirige ou capte les trames IP en chemin, c'est en clair!

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

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

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

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

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

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

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.

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 ?