Bonjour
 
J'aurais une question, est -ce que je devrait désactiver les magi_quotes??
apparement ça serait plus prudent,
Qu'en pensez vous??
 
J'ai trouver ça sur le net ça parait pas mal ... et pas trop compliquer..
 
[url]
http://www.phpfrance.com/tutoriaux [...] gic-quotes[/url]
 
 
 
 
 

Bah... Cet article est très bien, il présente les différents aspects du problème.
Les désactiver permet une meilleure adaptation et une portabilité, mais il ne faut pas oublier les *_escape_string après, c'est tout

Ou les requêtes préparées
Ou PDO

merci ... au pasage... j'ai une autre question... je travail les sessions actuellement...Qu'en pensez vous niveau sécurité?
 
voici le traitement des sessions
 

 
Voici le début des pages protégées :
 

Deux choses :
-Comme dis précedemment, utilise des requêtes préparées, surtout pour des données sensibles comme celles ci.
-La redirection coté client, c'est la pire chose que tu puisse faire en cas d'érreur.

Pourquoi mon header ne passe pas..???
 
Il m'affiche page blanche
 
 

impossidble ça marche pas grrrrrrrrrrrr pkoi les choses simple deviennent elles toujours compliquées !!

Isole le code que tu as changé dans une page de test pour identifier clairement le problème

oula... quelle cretin.. simple erreur de syntaxe je savait pas que iln'y avais pas d'espace entre les ":"

je sui super content... je faisai toutes mes redirection en meta.. ça ne me plaisais pas

parcontre les requetes préparés c'est compliquée non?

Non, suffit de lire la doc, ensuite le choix est simple, prendre le risque de subir une injection, ou prendre le temps de faire quelque chose de propre

tu aurais pas un site ou qui me permetrai d'appendre tout ça ?

http://www.siteduzero.com/tuto-3-4 [...] paree.html
 
Google toussa, le tuto est gavé de fautes, mais ça résume bien la situation

<?php
 
$ident = mysql_query("SELECT login, password FROM identification WHERE login='".$_POST['login']."' AND password='".$pass."' " ) or die (mysql_error());
?>

Injection SQL d'entrée de jeu, si quelqu'un rentre le login  

ça fait boum
 
Et comme noté par Shinuza, il y a des headers spécialement faits pour la redirection, au lieu de faire un truc crade à base de metas

une seule requête possible avec mysql_query, donc le drop table ne passera pas

dans ce cas là, c'est guère mieux : le site va accorder l'autorisation de login au gars, avec le premier login dans la table...
généralement, le premier login qu'on saisi dans une table étant le login administrateur... chais pas ce qui est le mieux entre permettre à l'utilisateur de drop au table au hasard, ou accéder avec des droit d'admin à toute l'application afin de faire du sabottage plus précis et moins facilement détectable

A oué, tu t'amuses à mélanger tes users et les admin dans la table toi  

Tu crées une table pour chaque profil d'user toi ?

J'ai un accès BO pour les admin, j'ai jamais mélangé les deux, je vois pas l'intérêt, toi.

l'intérêt ? ça s'appelle "l'interopérabilité".
je peux parfaitement communiquer avec un autre système qui utilise une base d'utilisateurs sans soucis. ça permet aussi et surtout de gérer des profils évolués de type "ACL". permettre à un même login/pass d'accéder à la fois au back office et au front office (c'est quand même pratique quand je veux contrôler que ma modif est effectuée correctement), ou simplement promouvoir et révoquer des droits simplement...
 
au contraire, il n'y a aucun intérêt à séparer les deux, mise à part multiplier la quantité de code par deux, alourdir la maintenance de l'application, et perdre les utilisateurs dans 25 urls et mots de passes à retenir pour accéder à une unique application

En tout cas ça évite de vérifier ta précedente démonstration. J'utilise une classe qui gère l'identification, les sessions et l'acl.
Du coup je n'ai pas de code à copier, je place mes 3 lignes dans un fichier et il est "protégé".  
La majorité du temps je sépare les deux, et se logguer coté BO te loggue coté Front.
Mais c'est peu être pas la bonne méthode, j'ai jamais eu de problème de cette manière néanmoins

sauf que ton système ne résoud rien : je vais sur une pge d'admin, j'utilise la même technique d'injection, et hop ! retour à la case départ (avec surtout une ergonomie pourrie sur le site, puisque tout est séparé, donc impossible à maintenir)

Il faut déja connaitre l'adresse de la page d'admin
 
Plus sérieusement, j'vois pas le problème de maintenance, j'utilise un fichier qui gère les deux cas de figures, les procedures sont communes, seul le niveau par défaut change.
Le tout est paramétré dans un fichier de config.

Ca ne change rien au problème: quand bien même une seule requête est permise, ça suffit à bypasser de manière triviale le système d'auth (et en faisant quelques recherches, on trouve facilement les adresses d'entrée des admins sur 9 sites sur 10)

oula aparement ça se défoule ici lol... bon moi me revoila je planche sur PDO... ça m'a l'air detre pas mal pour la sécurité je posterai le resultat ou les erreurs lol

Hop voila voila...qu'en penser vous...
 
Sinon pour les magic quotes je fais koi??
 
 

 
Je modifirai pour le $_POST['login'], Je sait qu'il faut pa les mettre en direct comme ça dans les requete mais c'est deja pour avoir un aperçu

jamais dit le contraire...
 
en tous cas ce qui pondent des tests (cf topic test recrutement) devrait penser à intégrer des questions sur la sécurité, on voit tellement de soit-disant développeurs php qui font ces erreurs que ça en devient inquiétant...

...alors

Et avec les requêtes préparées, pas besoin de *_escape_string ?

Comparez au premier code, ça n'a RIEN a voir

Non

c'est ce que je voudrai savoir lol !!
 
EDIT : donc c'est sécurisée la quand même ??

Ah, c'est cool ça, et pas besoin de gérer non plus les ' autours des chaines (alors qu'on ne met rien autour des entiers), je suppose ?

Personne ne m'a répondu mai du coup pour les magic quotes je fais quoi?? c'est toujours la peine de les levée? Pui le code il es assez sécurisée

C'"est de la merde, poubelle

poubelle mon code ou les magic quote lol...mechant!!

magicquote pose surtout un énorme problème de portabilité.
 
effectivement, il rajoute des " \ " devant les caractères " ' " afin d'éviter le SQL Injection.
 
seulement, cela pose deux problèmes :
1/ programmatiquement parlant, c'est pas toujours très heureux, car ça va modifier les valeurs de certaines variables qu'on ne veut pas forcément impacter par ce changement (calcul MD5 d'un mot de passe par exemple, ou calcul de la longueur d'une chaine, etc.)
2/ si demain on utilise un autre SGBD que MySQL, certaines (SQL Server et Access pour ne citer qu'eux) ne respectent pas la norme ANSI, mais uniquement la norme SQL, qui ne fait aucun cas du caractère " \ ". Ainsi, on n'évite pas le SQL Injection, mais surtout, on ne peux pas échapper correctement les " ' ". Je me suis heurté à ce problème il y a quelques années, ou pour des raisons d'intégration dans un SI existant, un site initialement développé en MySQL a dû être basculé vers SQL Server. Ne connaissant pas PHP, mais étant présenté comme "Expert SQL Server", c'est bibi qui s'est tapé la migration. Seul hic, RIEN ne marchait. Impossible de piger ce qu'il se passait. J'ai passé deux jours avant de trouver ce putain de paramètre, évidement qui n'est visible que dans le fichier de config du serveur, auquel seul l'hébergeur avait accès.
 
Bref, ce truc est une honte, une horreur, le truc à éviter par tous les moyens.
 
Si je ne m'abuse, il était actif par défaut en PHP3, mais depuis le PHP4, les distributeurs du module se sont rendu compte de l'erreur, et ne l'active plus par défaut. C'est bien la preuve qu'il est recommandé de tout faire sauf l'activer. J'espère qu'un jour il sera purement et simplement supprimé. C'est un truc qui n'aurait jamais dû être créé.

sinon, vu que tu passes par des requêtes paramétrées maintenant, désactive magicquote, car tu vas avoir le même problème que moi lors de ma migration vers SQL Server : les " \ " que magicquote ajoute partout vont t'emmerder

Petit MAJ :  
 
IL semblerai que mon hebergeur n'utilise pas PHP 5 (pour mon hebergement) donc je doit laisser tomber PDO...
 
et autre probleme :  
 
mysql_real_escape_string ne passe pas ...
 
j'ai une erreur :  
Warning: mysql_real_escape_string(): Access denied for user: 'nobody@xxxx' (Using password: NO) in /home10/eq42432/html/test/page2.php on line 5
 
Warning: mysql_real_escape_string(): A link to the server could not be established in /home10/eq42432/html/test/page2.php on line 5
 
par contre mysql_esxape_string ça ça passe...
 
je fiat quoi maintenent... cry

tu changes d'hébergeur