La Securité en php

[fabien62]

Bonjour,

Je code sur le php depuis quelques semaines, et plus je code, plus je me rend compte des failles de sécurité.

Tout d'abord un htmlspecialchars sur les echo $_GET, $_POST et $_COOKIE est-il vraiment efficace à 100% et qu'elle est la différence d'avec un htmlentities ( si le nom est correct ) ?

Pour ce qui est de la BDD un mysql_real_escape_string est-il suffisant ?

Je suis en train de créer une zone d'administration ( en ce moment je bosse en local ).

1 - Pour le moment, a la première connexion sur le site, j'affiche un formulaire ( formulaire qui s'affiche uniquement si le fichier.poum n'existe pas ) en index du site, il s'afficheras donc une seul fois.

2 - Je traite l'info par un header, la variable renvoyer par le formulaire est crée dans le fichier.poum

Dans le même temps je crée un champs hidden qui à valeur x, que je change en y dans le header pour l'enregistrer dans fichier.paf et dans fihier.kop ensuite retour en index.

3 - Les fichiers fichier.poum/fichier.paf et fichier.kop sont un peu partout sur le site, protégé par un htaccess quand au htpasswrd renommé en .tableau, ou . armoire ce trouve dans d'autre dossier eux même protégé bien sur par un .htaccess, et qui seront une fois sur le web avant le fameux www.

Avec des mots de passe crypter.

4 - Une fois sur l'index, on retape le code dans un autre formulaire (le premier n'est plus visible, logique le fichier est crée ), gérer par un header qui prend le pseudo en cookie(visible par tous car affiche Bonjour pseudo ).

5 -Si le cookie pseudo = fichier.poum et que fichier.paf est = fichier.kop alors un lien vers l'administration apparaît.

6 - En cliquant sur le lien, viens le login/passe du htaccess

7 - Et viens ensuite login/mot de passe d'administration avec enregistrement de l'ip + heure + cookie login de toute personne arrivant dans la partie administration, pour la suite, pas encore réfléchit, mais je pense faire des fichiers crée précédemment un leurre, après la config de la bdd dans l'administration.

7-1 Suppression du cookie à la fermeture de l'administration

Voici mes questions, comme les fichiers seront en lecture/écriture ( pour pouvoir changer le login de départ etc quand je le souhaites ) et que je bosse en local, est-il possible de lire les fichiers par la commande fopen(), ou d'ajouter un passe pour la lecture ?

Ce moyen de protection est-il fiable ?

Faut-il faire des includes pour la lecture des fichiers afin de renforcer encore la sécurité ?

Je ne suis pas parano mais niveau sécurité c'est quand même balaise à réaliser.

Je vous remercie

Modifié 27 Mars 2008 par fabien62

[Dan]

Je pense y connaître un peu en matière de sécurité, mais là j'avoue ne pas comprendre du tout ce que tu fais.Et pourtant j'ai relu 3 fois ton post, en me mélangeant avec les pim, paf et pouf

Une question, pourquoi renommes-tu le fichier .htpasswd ? Par défaut, tous les fichiers .ht* sont protégés par apache, et de plus tu peux les mettre en dehors de ton espace web.

Alors qu'un fichier .tableau reste lisible pour tous ceux qui en connaissent le nom !

[Sarc]

J'avoue ne pas tout comprendre non plus.

Personnellement, je me prends pas autant la tête pour la sécurité, et j'ai pas eu de soucis majeurs. Déjà, choisis un nom original pour ton dossier d'administration, puis protège-le par htpasswd et le tour est joué. Au pire, si tu es méfiant, rajoute un formulaire avec mot de passe crypté et création d'un cookie crypté temporaire. Mais après, te prends pas la tête à créer des pim pam, des boum et bam, des cookies1 et cookies2...

[Dadou]

pim, paf et pouf

C'est une BD ça, il me semble

Sinon, moi non plus je n'ai pas compris grand chose

[pluriels]

je te conseille de laisser reposer ton code une semaine et de venir expliquer ton besoin à tête reposée

[Anonymus]

Bonjour,

+1 avec ce qui s'est dit plus haut

Si tu pouvais nous donner les vrais noms de fichier, ca nous aiderait un peu

Merci.

[Kioob]

Oulah... je vais tenter de décortiquer tout ça, du moins partiellement.

=== htmlspecialchars / htmlentities

La différence entre htmlspecialchars et htmlentities vient surtout des accents : htmlspecialchars n'échape que les caractères "HTML" : < > & et je suppose le " tandis qu'htmlentities fait aussi les accents.

Donc si ta page est en ISO-8859-1, et que tu n'affiches aucun accent, htmlspecialchars suffit.

Si ta page est en ISO-8859-15, et que tu n'utilises que des accents français, htmlspecialchars suffit aussi.

Sinon c'est htmlentities qu'il faut utiliser.

Cerise sur le gateau, si tes accents proviennent d'un Windows, c'est du cp1252. Et htmlentities ne travail qu'avec l'ISO-8859-1 ; donc il faudra une fonction maison.

Autre solution, tu fais comme 90% des webmasters, tu ignores complètement ça et tu croises les doigts pour que ça passe chez tes visiteurs. C'est plutôt risqué / crade, mais les webmasters sont souvent fainéants

Pour ce qui est de la fiabilité de htmlspecialchars, bah ça dépend de quoi tu parles Il empèchera systématiquement du code HTML d'être interprété comme tel oui. Mais ce n'est pas du tout un mega firewall de la mort qui tue... rien à voir même

=== mysql_real_escape_string

mysql_real_escape_string est "suffisant" si on respecte quelques règles : déjà c'est à utiliser sur les chaines. Exemple :

$requete = "select unchamp from unetable where autrechamp = " . mysql_real_escape_string( $tavariable );

Dans ce cas mysql_real_escape_string() ne protégera rien du tout... il faut au moins :

$requete = "select unchamp from unetable where autrechamp = '" . mysql_real_escape_string( $tavariable ) . "'";

A condition que tu sois absolument certain que "$tavariable" soit toujours de type numérique quoi.

De plus, suivant les librairies qu'on utilise il est possible d'oublier d'utiliser mysql_real_escape_string().

C'est pour cela qu'on conseille généralement l'utilisation de syntaxes du genre PDO, qui évitent les oublis :

$query = "select unchamp from unetable where autrechamp = ?";
$params = array( $tavariable );

Là tu es certain de ne pas oublier les échapements, c'est pris en charge "automatiquement". Evidément un goret peut toujours s'amuser à mettre directement ses variables PHP dans le code SQL, mais ça on ne pourra jamais l'empècher.

=== pim, pam, poum et sa clique

Là tout comme les autres je sèche. A mon avis tu ajoutes plus de failles potentielles que tu n'en résouds.

Pour un truc sécurisé je conseillerais plutôt :

- SSL, pour que toutes les communications soient cryptés.

- éventuellement un JS pour envoyer une version "hachée" du mot de passe, si jamais tu n'as pas de SSL.

- se baser ensuite sur les sessions, en acceptant les ID de session que via cookie et non URL.

- utiliser un mécanisme de type "regenerate_id" pour limiter les possibilités de vol de session.

[fabien62]

Je vous remercie.

Je vais lire sa à tête reposer, quand à pim-pam-poum, je m'y perd moi même, je vais mettre de côté et relire mon code plus tard.

Merci à vous, je vous tiens au courant.

[Dan]

quand à pim-pam-poum, je m'y perd moi même, je vais mettre de côté et relire mon code plus tard.

Quelque part, tu nous vois rassurés

[Pybou]

Déjà, choisis un nom original pour ton dossier d'administration

Je suis assez d'accord avec toi. Il faut en effet éviter les noms anglais, basiques tels que : admin, panel ... C'est ce genre de choses que les petits robots cherchent en fait. Nous parlons français ? Donc autant opter pour un bon vieux mot français du style : panadministration (un peu long mais en même temps on s'en fou un peu), espacewebmaster voire administration voire même un truc qui n'a aucun rapport. Mais je pense que le plus important est de bannir ces mots génériques anglais qui sont souvent rechercher par les robots.

Moi perso je protège mon panel avec un htpasswd, pas trop de problème quand il est bien régler ... Après tu peux faire avec des sessions mais est-ce vraiment utile si tu as déjà un bon htaccess et que ton dossier a un nom correct, je ne sais pas.

[Kioob]

En cas de "sniffer" réseau, ou même d'attaque "man in the middle" (généralement assez facile affaire par les autres clients de votre hébergeur), même sur court instant le pirate obtiendra le mot de passe (en clair) du fichier .htpasswd ainsi que la jolie URL...

Au moins avec les sessions et un mécanisme anti "vol", il n'y a que la soumission du formulaire de connexion qui reste sensible.

[captain_torche]

[...]même sur court instant le pirate obtiendra le mot de passe (en clair) du fichier .htpasswd

Comment ça serait possible ? Le mdp est toujours haché, et à moins d'avoir un mdp présent dans le dictionnaire, je ne pense pas qu'il soit possible d'inverser le hachage.

[Kioob]

Non, le mot de passe circule dans les entêtes HTTP en clair (en base64), ce n'est qu'une fois obtenu par Apache que celui ci utilise crypt() pour le comparer avec la version hachée stockée dans le .htpasswd.

Le fichier ".htpasswd" est sécurisé oui ; mais le protocole ne l'est absolument pas.

Pour remédier à cela il y a l'identification "Digest" prévue dans la RFC ; mais aucun navigateur de la gère...

Essaye par toi même tu verras bien. Il existe de nombreux outils de ce genre, qui affichent en temps réel les mots de passe HTTP, SMTP, POP, IMAP et FTP qui circulent sur le réseau...

Modifié 28 Mars 2008 par Kioob

[captain_torche]

Ok, j'avais mal compris : je croyais que tu parlais de lire dans le fichier.

[fabien62]

Bonjour,

Alors après lecture à tête reposer :

Préliminaire :

Lors de la toute première connexion au site, un formulaire s'ouvre, dans ce formulaire je rentre mon login d'accès (+ 1 champs cacher par mesure de contrôle ) qui me permettras d'avoir un lien vers l'administration.

Ce login et champs cacher sont stocker dans deux fichiers, fichiers stocker dans un dossier protégé par .htaccess

Une fois le login et champ cacher stocker le formulaire n'apparaît plut.

Je stock ces fichiers aussi bien dans du .gif .jpg fichier sans extension, fichier.rrgt et j'en passe, avec des noms de fichier tout aussi farfelue du genre telephone.fty, oncle_sam.png.

1 - On arrive sur la page d'accueil, sur la page d'accueil ce trouve un formulaire ( différent du précèdent ) qui demande un prénom/nom.

2 - Quand on entre le prénom/nom et que l'on valide, le traitement ce fait dans un header.

3 - Dans ce header, je crée un cookie avec le pseudo/prénom entrer sur le formulaire et je reviens en page d'accueil.

4 - Si le login n'est pas bon, la page dit Bonjour " nom du cookie "

- Si le login est bon le liens vers l'administration apparaît. > Je compare le nom du cookie ainsi que le champs cacher dans les deux dossiers du préliminaire.

Fin partie 1 je n'es aucune conscience de la qualité de cette protection, si qualité il y a

----------------------------------------------------------------------------------------------------------------------

1 - En cliquant sur administration on tombe sur le .htaccess

Si je renomme le .htpasswrd c'est suite a des lectures sur le net, ensuite certains préconise de mettre le .htaccess dans le dossier à protéger et le .htpasswrd avant www lui même protégé par .htaccess mais en aucun cas dans le même dossier.

Fin partie 2

----------------------------------------------------------------------------------------------------------------------

Partie 3 : je viens de la terminer, je vais donc laisser un peu d'eau coulé sous les ponts

En passant, comme je vous l'est dit, je suis en local, mais une fois sur le net, ne faut-il pas des passes pour lire/écrire dans un fichier du genre fopen() "login" "mot de passe " comme pour la connexion à la bdd ?

Ou alors si il est exécuté de l'intérieur pas besoin ?

Pour le JS je n'y connait rien du tout

Je vous remercie

Modifié 28 Mars 2008 par fabien62

[captain_torche]

On peut aussi tenter d'imposer le hashage md5 au navigateur en JavaScript; de ce fait, les informations circuleront forcément protégées.

Par contre, cela empêche toute navigation dans cette zone sans JavaScript, mais comme c'est pour une interface d'admin, j'estime qu'on peut s'en passer.

[Kioob]

Bonsoir,

donc pour la première partie, en fait tu crées un "compte administrateur" (couple login/pass) que tu stocks dans un simple fichier. A la limite pourquoi pas. Mais as tu vérifié les droits d'accès à ce fichier ? Car après tout, c'est sûrement le plus important : une fois créé, il devrait avoir 0600 voir 0400. C'est à dire que seul l'utilisateur faisant tourner PHP devrait pouvoir lire ce fichier.

Pour ce qui est de la "sécurité" apportée, elle est très très relative : à la moindre "faille" sur ton site permettant d'inclure ou lire un fichier arbitraire, ces identifiants seront accessibles. Ce qui ne serait pas forcément le cas s'ils étaient stockés en base de données (les identifiants d'accès à la base de données peuvent être eux aussi compromis, mais celle ci est rarement accessible de l'extérieur, contrairement à ton site).

Pour le deuxième point, pourquoi pas. Je ne pense pas que ça ne changera grand chose non plus, le contenu de ce fichier bénéficiant d'un hachage avec grain de sel, même l'attaque par dico prendrait des plombes.

Ce qui me fait peur, c'est surtout la suite. Pour moi là on a juste évoqué des "petits plus" qui sont à mon sens très loin de constituer des failles de sécurité... Si au final tu mets tout ça en place pour utiliser une bête identification à la ".htaccess/.htpasswd" c'est vraiment se donner du mal pour rien : le protocole n'étant pas sécurisé, tu pourras faire toutes les galipettes que tu veux que ça n'y changera rien du tout.

Quant aux permissions d'accès à des fichiers/dossiers, tu n'as pas te ré-identifier : le script tourne déjà sous un certain compte utilisateur, et hérite donc des droits d'accès associés. D'où l'importance des droits sur les dossiers et fichiers.