Parlons de Sécurité
Atropa
Messages postés
1940
Date d'inscription
Statut
Membre
Dernière intervention
-
Atropa Messages postés 1940 Date d'inscription Statut Membre Dernière intervention -
Atropa Messages postés 1940 Date d'inscription Statut Membre Dernière intervention -
bonjour,
Je lance ce sujet dans le but de créer une discussion autour de la sécurisé en php,MYSQL et apache.
L'objectif de cette discussion sera de faire un tour le plus complet possible de la sécurité dans ces domaines. Il en émanera des codes et des conseils que nous aurons mis au point et que je publierai ici pour la résumer.
Nous utiliserons les dernières versions stable de php, MYSQL et apache.
Commençons :
j'appréhende un peu les réactions sur certaines de mes questions mais il me parait difficile de sécuriser un site web sans savoir comment on les pirate... Et bien souvent ces questions restent sans réponses ou crées des discussions stériles doit qu'un modérateur finit par bloquer pour pouvoir y mettre fin.
Je pense qu'au contraires ces informations devrait être largement publié pour éduquer et renforcer les sécurités. Ce sont en fait deux façons de voir le problème, d'un coté on garde l'information secrète pour éviter de former des pirates, de l'autre on les publie largement pour renforcer les sécurités. Il est aussi évident que l'argent joue un rôle important la dedans, en effet un hacker n'a aucune raison de publier ces techniques, il perdrait son gagne pain en même temps, à moins peut être de devenir chercheur en piraterie. Bref je m'égare.
Je connais les failles XSS ou du moins je l'espère et me paraissent relativement simple à éviter, à part peut être avec les éditeur wysiwyg intégré au page web, mais ça fera l'objet d'une question.
les attaques par brute force sont aussi suffisamment documentées. En même temps quelle idées de mettre une date de naissance ou un nom commun en guise de mot de passe.
Les premières questions porteront sur ce que je fais déjà, ça me permettra de savoir où j'en suis et une première amélioration mes codes avant de les poster.
Q1 : suffit-il de remplacer systématiquement les caractère sensible comme <>/%":?!_&-'{}[]()=+ par leur équivalent ASCII dans toutes les variables get/post/cookie/session de type string pour se prémunir de toutes injections XSS ? (je passe par la fonction html_entities() et j'ajoute celle qu'elle ne prend pas en compte après)
Q2 : Pour protéger l'usurpation de session, je change l'identifiant à chaque chargement de page, et je teste ensuite la cohérence de l'identifiant utilisateur, des droits qui lui sont accordés et l'ip qu'avait le client à sa connexion avec la base de données. si une de ces information n'est pas la strictement identique à celle de la DB, je réinitialise la session comme pour un inconnu. Est-ce suffisant ?
Q3 : Toutes les données get/post/cookie/session sont testé par leur type avant d'être utilisé si un type est incohérent j'arrête j'arrête l'exécution de ma fonction. et je passe systématiquement par la fonction fprintf() pour mes requêtes SQL. Est-ce réellement intéressant de le faire tout le temps ?
Q4 : Pour l'upload de fichier je teste les extensions autorisées, je modifie celle qui n'ont pas a être ouverte sur je site que je rétablie au download. je teste également la taille et "standardise" les caractère. Peux-ton améliorer à ce niveau ?
Q5 : Pour la connexion des membres, je test le md5 du mot de passe entré avec le md5 du mot de passe stocké dans la base de donné. et j'attribue une "clef" [ md5(microtime(true) . mt_rand() ] à la connexion que je stocke dans la base de donnée et que j'utilise pour identifier publiquement un membre. Par exemple pour la confirmation d'inscription par mail ou la communication avec des SWF qui communique avec PHP. Est-ce judicieux et améliorable ?
Q6 : J'inclus toutes mes pages php dans un fichier index.php placé à la racine du site. les autres fichiers sont dans un dossier protégé en accès par un .htaccess contenant "deny from all" je le fais également pour tout les fichiers qui ne doivent être accessible que par php. est-ce suffisant pour empêcher l'accès à ces fichiers ? (mis à part par le protocole ftp j'entends)
Q7 : j'ai également un pseudo cron qui analyse le md5 de chaque fichier de code et qui le remplace par le fichier d'origine stocké dans une archive zip si il ne sont pas cohérent. j'aimerai protéger cette archive par mot de passe.Est-ce possible ?
Q8 : Pour les connexions SQL, j'utilise des identifiants de connexions et des utilisateurs avec des droits les plus restreint possible et le plus "spécialisé" possible (par exemple READ_USER sera l'utilisateur de lecture et il ne pourra faire que ça), ainsi que les mots de passe les plus complexe possible provenant d'un générateur de mot de passe aléatoire que j'ai préparé pour me simplifier la tâche. Qu'en pensez vous ?
Maintenant place aux questions qui risque de partir en vrille...
Q9 : Comment les "virus" sont-ils intégrés aux pages web et est ce que les mesures prises contre les failles XSS empêchent leurs intégrations ?
Q10 : Pourquoi ces mêmes "virus" ne sont-ils pas détecté par le navigateur et qu'il n'affiche pas une fenêtre de téléchargement ? et plus généralement comment cacher un fichier qui sera télécharger sur le système du client ? Qu'est ce qui permet que ça se fasse ?
Q11 : Comment faire pour qu'un éditeur wysiwyg ne crée pas de failles de sécurité en utilisant une blacklist tout en conservant un maximum de possibilités ? Est ce que le remplacement des <object <script <fram <ifram <head <body <link <meta <title <form ainsi que '" par leurs équivalent ASCII suffit ? (je vois un problème au niveau des liens <a href="javascript:..."> mais comment les prévenir ?
Q12 : Ai-je oublié quelque chose ?
Voilà pour commencer, j'attends vos réponses et contributions avec impatience.
Pour les questions 9 et 10, inutile d'y apporter de force réponse, ca ne ferait que prendre de la place inutilement et nuire à la clarté de la discussion. Autant ne pas y répondre si vous ne voulez pas.
Il y a aussi surement beaucoup de fautes d'orthographe, qui s'explique par l'heure tardive. quand je ferai la synthèse de la discussion je ne les laisserai pas filer.
Je lance ce sujet dans le but de créer une discussion autour de la sécurisé en php,MYSQL et apache.
L'objectif de cette discussion sera de faire un tour le plus complet possible de la sécurité dans ces domaines. Il en émanera des codes et des conseils que nous aurons mis au point et que je publierai ici pour la résumer.
Nous utiliserons les dernières versions stable de php, MYSQL et apache.
Commençons :
j'appréhende un peu les réactions sur certaines de mes questions mais il me parait difficile de sécuriser un site web sans savoir comment on les pirate... Et bien souvent ces questions restent sans réponses ou crées des discussions stériles doit qu'un modérateur finit par bloquer pour pouvoir y mettre fin.
Je pense qu'au contraires ces informations devrait être largement publié pour éduquer et renforcer les sécurités. Ce sont en fait deux façons de voir le problème, d'un coté on garde l'information secrète pour éviter de former des pirates, de l'autre on les publie largement pour renforcer les sécurités. Il est aussi évident que l'argent joue un rôle important la dedans, en effet un hacker n'a aucune raison de publier ces techniques, il perdrait son gagne pain en même temps, à moins peut être de devenir chercheur en piraterie. Bref je m'égare.
Je connais les failles XSS ou du moins je l'espère et me paraissent relativement simple à éviter, à part peut être avec les éditeur wysiwyg intégré au page web, mais ça fera l'objet d'une question.
les attaques par brute force sont aussi suffisamment documentées. En même temps quelle idées de mettre une date de naissance ou un nom commun en guise de mot de passe.
Les premières questions porteront sur ce que je fais déjà, ça me permettra de savoir où j'en suis et une première amélioration mes codes avant de les poster.
Q1 : suffit-il de remplacer systématiquement les caractère sensible comme <>/%":?!_&-'{}[]()=+ par leur équivalent ASCII dans toutes les variables get/post/cookie/session de type string pour se prémunir de toutes injections XSS ? (je passe par la fonction html_entities() et j'ajoute celle qu'elle ne prend pas en compte après)
Q2 : Pour protéger l'usurpation de session, je change l'identifiant à chaque chargement de page, et je teste ensuite la cohérence de l'identifiant utilisateur, des droits qui lui sont accordés et l'ip qu'avait le client à sa connexion avec la base de données. si une de ces information n'est pas la strictement identique à celle de la DB, je réinitialise la session comme pour un inconnu. Est-ce suffisant ?
Q3 : Toutes les données get/post/cookie/session sont testé par leur type avant d'être utilisé si un type est incohérent j'arrête j'arrête l'exécution de ma fonction. et je passe systématiquement par la fonction fprintf() pour mes requêtes SQL. Est-ce réellement intéressant de le faire tout le temps ?
Q4 : Pour l'upload de fichier je teste les extensions autorisées, je modifie celle qui n'ont pas a être ouverte sur je site que je rétablie au download. je teste également la taille et "standardise" les caractère. Peux-ton améliorer à ce niveau ?
Q5 : Pour la connexion des membres, je test le md5 du mot de passe entré avec le md5 du mot de passe stocké dans la base de donné. et j'attribue une "clef" [ md5(microtime(true) . mt_rand() ] à la connexion que je stocke dans la base de donnée et que j'utilise pour identifier publiquement un membre. Par exemple pour la confirmation d'inscription par mail ou la communication avec des SWF qui communique avec PHP. Est-ce judicieux et améliorable ?
Q6 : J'inclus toutes mes pages php dans un fichier index.php placé à la racine du site. les autres fichiers sont dans un dossier protégé en accès par un .htaccess contenant "deny from all" je le fais également pour tout les fichiers qui ne doivent être accessible que par php. est-ce suffisant pour empêcher l'accès à ces fichiers ? (mis à part par le protocole ftp j'entends)
Q7 : j'ai également un pseudo cron qui analyse le md5 de chaque fichier de code et qui le remplace par le fichier d'origine stocké dans une archive zip si il ne sont pas cohérent. j'aimerai protéger cette archive par mot de passe.Est-ce possible ?
Q8 : Pour les connexions SQL, j'utilise des identifiants de connexions et des utilisateurs avec des droits les plus restreint possible et le plus "spécialisé" possible (par exemple READ_USER sera l'utilisateur de lecture et il ne pourra faire que ça), ainsi que les mots de passe les plus complexe possible provenant d'un générateur de mot de passe aléatoire que j'ai préparé pour me simplifier la tâche. Qu'en pensez vous ?
Maintenant place aux questions qui risque de partir en vrille...
Q9 : Comment les "virus" sont-ils intégrés aux pages web et est ce que les mesures prises contre les failles XSS empêchent leurs intégrations ?
Q10 : Pourquoi ces mêmes "virus" ne sont-ils pas détecté par le navigateur et qu'il n'affiche pas une fenêtre de téléchargement ? et plus généralement comment cacher un fichier qui sera télécharger sur le système du client ? Qu'est ce qui permet que ça se fasse ?
Q11 : Comment faire pour qu'un éditeur wysiwyg ne crée pas de failles de sécurité en utilisant une blacklist tout en conservant un maximum de possibilités ? Est ce que le remplacement des <object <script <fram <ifram <head <body <link <meta <title <form ainsi que '" par leurs équivalent ASCII suffit ? (je vois un problème au niveau des liens <a href="javascript:..."> mais comment les prévenir ?
Q12 : Ai-je oublié quelque chose ?
Voilà pour commencer, j'attends vos réponses et contributions avec impatience.
Pour les questions 9 et 10, inutile d'y apporter de force réponse, ca ne ferait que prendre de la place inutilement et nuire à la clarté de la discussion. Autant ne pas y répondre si vous ne voulez pas.
Il y a aussi surement beaucoup de fautes d'orthographe, qui s'explique par l'heure tardive. quand je ferai la synthèse de la discussion je ne les laisserai pas filer.
A voir également:
- Parlons de Sécurité
- Question de sécurité - Guide
- Votre appareil ne dispose pas des correctifs de qualité et de sécurité importants - Guide
- Mode securite - Guide
- Clé de sécurité windows 10 gratuit - Guide
- Url masquée pour votre sécurité - Forum Programmation
14 réponses
slt,
Commences par tester les vulnérabilités réelles et/ou potentielles avec un scanner comme nessus...en jetant un oeil sur les règles et en voyant le nombre pléthoriques de règles qu'il recèle, tu pourras te rendre compte que la sécurité est un domaine très vaste et très complexe qui ne se résume pas aux quelques questions que tu poses.
Commences par tester les vulnérabilités réelles et/ou potentielles avec un scanner comme nessus...en jetant un oeil sur les règles et en voyant le nombre pléthoriques de règles qu'il recèle, tu pourras te rendre compte que la sécurité est un domaine très vaste et très complexe qui ne se résume pas aux quelques questions que tu poses.
Pour éviter la faille XSS, il suffit de remplacer les caractères < et > par leur équivalent en entité HTML ou ASCII. Il y a la fonction html_entities qui le fait très bien. Pour ma part, j'utiliser htmlspecialchars. Je n'utilise cette fonction que quand je fais un echo dans une page Web, pas pour l'insertion dans MySQL puisqu'il n'y a aucun risque de ce côté là. La faille XSS ne permet que l'insertion de scripts côtés clients, ce n'est pas possible de télécharger un virus en arrière-plan sur le poste du client sans confirmation.
Pour éviter les injections SQL, je désactive magic_quotes sur les version de PHP inférieures à 6 et j'applique addslashes() sur les variables que j'utilise dans la requête (sauf que j'utilise une requête préparée avec PDO). Si la données est censée être un nombre, je force le type de la variable à être en INT et je mets le type de champ MySQL sur INT (ou TINYINT, SMALLINT, ...).
Pour l'upload de fichiers, il ne faut pas te fier à l'extension (ne soit pas aussi con que Windows :) ) : vérifie le type MIME.
Pour éviter les injections SQL, je désactive magic_quotes sur les version de PHP inférieures à 6 et j'applique addslashes() sur les variables que j'utilise dans la requête (sauf que j'utilise une requête préparée avec PDO). Si la données est censée être un nombre, je force le type de la variable à être en INT et je mets le type de champ MySQL sur INT (ou TINYINT, SMALLINT, ...).
Pour l'upload de fichiers, il ne faut pas te fier à l'extension (ne soit pas aussi con que Windows :) ) : vérifie le type MIME.
Le site de nessus est en maintenance pour l'instant, j'y regarderai plus tard.
pour html_entities je suis d'accord sur le fait qu'elle le fasse très bien, seulement en SQL par exemple ce signe % peut être plus ou moins gênant.
Je n'utilise pas encore la version 6 de PHP n'étant pas celle présentée comme stable. les magic_quotes entrainent quelles failles ? et pourquoi ne plus les désactiver à partir de PHP 6? elles n'existent plus en PHP 6 ?
J'ai pris l'habitude de les désactiver mais je ne me souviens plus exactement pourquoi...
Il faudra que je me mette a PDO je vais voir ça demain. et je vais poster un exemple de code que j'utilise avec mysql.
Pour ce qui est du type MIME je voudrais bien le faire, seulement je me souvient que quand je travaillais sur les fichiers je n'y était pas parvenu à cause d'extensions PHP manquantes. Comment faire pour que ça fonctionne avec la majorité des solutions d'hébergement ?
Pour ce qui est des virus en arrière plan, il y a quelque années, je crois me souvenir que c'était au début de la version 2 de firefox, j'en avais eu de détecté par kaspersky alors que je n'avais rien téléchargé. Je ne suis pas certain a 100 % de ce que j'avance là, ça fait longtemps.
Il faudrait aussi faire une fonction simple a intégrer aux formulaires voir aux requêtes GET pour se prémunir contre les CSRF.
Je vais déjà poster un code contre les injections et pour sécuriser en partis les connexions SQL et les requêtes. Vous me direz ce que vous en pensez et comment les améliorer.
pour html_entities je suis d'accord sur le fait qu'elle le fasse très bien, seulement en SQL par exemple ce signe % peut être plus ou moins gênant.
Je n'utilise pas encore la version 6 de PHP n'étant pas celle présentée comme stable. les magic_quotes entrainent quelles failles ? et pourquoi ne plus les désactiver à partir de PHP 6? elles n'existent plus en PHP 6 ?
J'ai pris l'habitude de les désactiver mais je ne me souviens plus exactement pourquoi...
Il faudra que je me mette a PDO je vais voir ça demain. et je vais poster un exemple de code que j'utilise avec mysql.
Pour ce qui est du type MIME je voudrais bien le faire, seulement je me souvient que quand je travaillais sur les fichiers je n'y était pas parvenu à cause d'extensions PHP manquantes. Comment faire pour que ça fonctionne avec la majorité des solutions d'hébergement ?
Pour ce qui est des virus en arrière plan, il y a quelque années, je crois me souvenir que c'était au début de la version 2 de firefox, j'en avais eu de détecté par kaspersky alors que je n'avais rien téléchargé. Je ne suis pas certain a 100 % de ce que j'avance là, ça fait longtemps.
Il faudrait aussi faire une fonction simple a intégrer aux formulaires voir aux requêtes GET pour se prémunir contre les CSRF.
Je vais déjà poster un code contre les injections et pour sécuriser en partis les connexions SQL et les requêtes. Vous me direz ce que vous en pensez et comment les améliorer.
Les signe "%" est à échapper à l'aide d'un anti-slashe dans certaines requêtes.
PHP6 est encore très peu utilisé. À vrai dire, je ne connais que OVH qui le propose déjà (version compilée depuis les sources).
magic_quotes est une option qui applique automatiquement addslashes sur les variables GPC (GET, POST, Cookies). On pourrait dire "cool" mais le problème est que certains hébergeurs l'activent et pas d'autres : je m'arrange avec un petit script pour retirer son effet si cette option est activée. Cette option est obsolète depuis PHP 5.3 et supprimée dans PHP 6.
Si tu veux apprendre à utiliser PDO, il y a un tutoriel sur le Siteduzero.com. Quand tu auras compris le principe, il y a la doc sur php.net
Le type MIME n'a rien à voir avec l'extension, je ne vois pas pourquoi ça poserai problème. Le type MIME de cette page (qui est un fichier) est "text/html", et pourtant, regarde son url : on voit nul part .html
Pour les virus, si la faille provient du navigateur, tu ne sais rien y faire. Si c'est un autre navigateur qu'IE, la faille sera très vite corrigée.
Pour éviter la faille CSRF, la meilleure des solutions reste les jetons.
Ton ordinateur ne fait pas ce que tu veux ... mais ce que tu lui dis de faire.
PHP6 est encore très peu utilisé. À vrai dire, je ne connais que OVH qui le propose déjà (version compilée depuis les sources).
magic_quotes est une option qui applique automatiquement addslashes sur les variables GPC (GET, POST, Cookies). On pourrait dire "cool" mais le problème est que certains hébergeurs l'activent et pas d'autres : je m'arrange avec un petit script pour retirer son effet si cette option est activée. Cette option est obsolète depuis PHP 5.3 et supprimée dans PHP 6.
Si tu veux apprendre à utiliser PDO, il y a un tutoriel sur le Siteduzero.com. Quand tu auras compris le principe, il y a la doc sur php.net
Le type MIME n'a rien à voir avec l'extension, je ne vois pas pourquoi ça poserai problème. Le type MIME de cette page (qui est un fichier) est "text/html", et pourtant, regarde son url : on voit nul part .html
Pour les virus, si la faille provient du navigateur, tu ne sais rien y faire. Si c'est un autre navigateur qu'IE, la faille sera très vite corrigée.
Pour éviter la faille CSRF, la meilleure des solutions reste les jetons.
Ton ordinateur ne fait pas ce que tu veux ... mais ce que tu lui dis de faire.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
je sais bien ce qu'est le type MIME, ce que je voulais dire c'est que je ne sais pas comment le vérifier en php, c'est pour ça que je ne vérifie pour l'instant que l'extension.
Pour les virus, je me doute qu'il y faut une faille au niveau du navigateur pour qu'ils "passent", mais ce que je voudrais savoir c'est comment il est envoyé depuis une url http.
Pour les jetons, le but est justement de faire un script qui permet d'en intégrer presque automatiquement dans les formulaire. Et de voir si il n'y a pas moyen de faire une sorte de jeton pour la méthode GET.
Pour les virus, je me doute qu'il y faut une faille au niveau du navigateur pour qu'ils "passent", mais ce que je voudrais savoir c'est comment il est envoyé depuis une url http.
Pour les jetons, le but est justement de faire un script qui permet d'en intégrer presque automatiquement dans les formulaire. Et de voir si il n'y a pas moyen de faire une sorte de jeton pour la méthode GET.
$_FILES['tonfichier']['type'] contient le MIME.
Si tu veux que ce soit une image, vérifie qu'il commence par "image/"
Si tu veux le restreinte au PNG (par exemple) : image/png
Si tu veux que ce soit une image, vérifie qu'il commence par "image/"
Si tu veux le restreinte au PNG (par exemple) : image/png
J'ai préparé une première mouture du code, que j'ai mis dans dans une archive zip à cette adresse : http://benjishkhan.u7n.org/securite.html
c'est composé de 2 classes une classe Secure pour les fonctions relative au injections sur les variables GET POST COOKIES et le changement d'id de session, et leur cryptage, il y a donc une classe Crypt que j'avais déjà plus ou moins préparé.
j'attends vos remarques et contributions
je vais maintenant voir pour faire une ou plusieurs fonction relative a l'upload que je placerai dans une classe File.
pour ce qui est des jetons est-ce qu'un suffit pour tout les formulaire d'une page ou est-ce mieux d'en faire un par formulaire ?
c'est composé de 2 classes une classe Secure pour les fonctions relative au injections sur les variables GET POST COOKIES et le changement d'id de session, et leur cryptage, il y a donc une classe Crypt que j'avais déjà plus ou moins préparé.
j'attends vos remarques et contributions
je vais maintenant voir pour faire une ou plusieurs fonction relative a l'upload que je placerai dans une classe File.
pour ce qui est des jetons est-ce qu'un suffit pour tout les formulaire d'une page ou est-ce mieux d'en faire un par formulaire ?
J'ai ajouté une classe File et une classe Regex à l'archive, la classe File contient des fonctions relative à l'upload et au download et la classe Rgex était une classe que j'avais déjà préparé dont je me suis servi pour la classe File
Je passe a PDO
Je passe a PDO
J'ai commencé une classe Sql utilisant PDO mais j'ai un petit problème.
Comment faire des transaction avec des requêtes préparé ?
J'ai également commencé les jetons et je pense qu'ils seront compatibles get et post sans problème apparent...
Comment faire des transaction avec des requêtes préparé ?
J'ai également commencé les jetons et je pense qu'ils seront compatibles get et post sans problème apparent...
une idée pour faire une clef de cryptage qui se détruirait si on essaie de la voir ?
Ce serait idéale mais je ne sais pas comment procéder
Que pensez-vous de ce jeton ?
on peut facilement l'intégrer quand n'importe quel variable ,GET par exemple, étant donné qu'il fait toujours 20 caractère le paramètre temporel si on en veut un n'importe est inclut dedans ce qui évite d'avoir à faire 2 variable de session pour chaque jeton.
Ce serait idéale mais je ne sais pas comment procéder
class Jeton {
public static function create($sessionVar) {
/*
Crée un jeton pour eviter les failles CSRF
Pour joindre le jeton a une variable de type String contenant un valeur mettre le jeton
au début de la variable et faire suivre directement la valeur
ex: $var = Jeton::create('jeton1').$valeur;
1 - $sessionVar : String -> Nom de la variable de session à associer au jeton
retourne le jeton (String)
*/
return $_SESSION[$sessionVar] = substr(md5(uniqid(mt_rand())),0,15).substr(time(),-5);
}
public static function verif($jeton,$sessionVar,$delay = false) {
/*
Vérifie le jeton et retourne la valeur de la variable si elle en contient une
1 - $jeton : String -> Variable contenant le jeton
2 - $sessionVar : String -> Nom de la variable de session associée au jeton
3 - $delay : Int -> délai de validité du jeton en seconde (si vaut false ou 0 pas de délai);
retourne false si le jeton est périmé sinon retourne true ou la valeur de la variable si une lui était associé
*/
$value = (strlen($jeton) > 20)? substr($jeton,20) : true;
$jeton = substr($jeton,0,20);
if($jeton != $_SESSION[$sessionVar]) return false;
if($delay) {
$time = (int)substr(time(),-5) - (int)substr($jeton,-5);
if($time < 0) $time += 100000;
if($time > $delay) return false;
}
return $value;
}
}
/*-- EXEMPLE BIDON--*/
session_start();
$j = Jeton::create('ses').'Salut tout le monde';
$v = Jeton::verif($j,'ses');
var_dump($v);
/*-- -- -- -- -- --*/
Que pensez-vous de ce jeton ?
on peut facilement l'intégrer quand n'importe quel variable ,GET par exemple, étant donné qu'il fait toujours 20 caractère le paramètre temporel si on en veut un n'importe est inclut dedans ce qui évite d'avoir à faire 2 variable de session pour chaque jeton.
ok, mais ca ne m'apprend pas grand chose ça.
à part que je n'aime pas ça façon de codé que je trouve illisible...
et surtout ca ne me dit en rien ce que vos mon code !
il le fait un peu comme moi au final sauf que la valeur aléatoire et sur 20 au lieu de 15 et qu'il utilise une seconde variable pour le paramètre temporel. de plus il ne peut mettre qu'un jeton par page et non par requête !
Ça m'a aussi montré une erreur flagrante dans mon code ! si il n'y a pas de jeton dans la session ça plante !
je met le code corrigé sans les commentaires (qui sont les mêmes qu'au dessus) pour gagner de la place
J'aimerai avoir un avis sur la "justesse" de ce code, comment l'optimiser ou autres...
mais c'est dommage j'espérai qu'il y aurait une vrai discussion voir un débat autour de la sécurité et qu'il en sortirai quelque chose de collectif.
à part que je n'aime pas ça façon de codé que je trouve illisible...
et surtout ca ne me dit en rien ce que vos mon code !
il le fait un peu comme moi au final sauf que la valeur aléatoire et sur 20 au lieu de 15 et qu'il utilise une seconde variable pour le paramètre temporel. de plus il ne peut mettre qu'un jeton par page et non par requête !
Ça m'a aussi montré une erreur flagrante dans mon code ! si il n'y a pas de jeton dans la session ça plante !
je met le code corrigé sans les commentaires (qui sont les mêmes qu'au dessus) pour gagner de la place
class Jeton {
public static function create($sessionVar) {
return $_SESSION[$sessionVar] = substr(md5(uniqid(mt_rand())),0,15).substr(time(),-5);
}
public static function verif($jeton,$sessionVar,$delay = false) {
if(empty($jeton) || empty($_SESSION[$sessionVar])) return false;
$value = (strlen($jeton) > 20)? substr($jeton,20) : true;
$jeton = substr($jeton,0,20);
if($jeton != $_SESSION[$sessionVar]) return false;
if($delay) {
$time = (int)substr(time(),-5) - (int)substr($jeton,-5);
if($time < 0) $time += 100000;
if($time > $delay) return false;
}
return $value;
}
}
J'aimerai avoir un avis sur la "justesse" de ce code, comment l'optimiser ou autres...
mais c'est dommage j'espérai qu'il y aurait une vrai discussion voir un débat autour de la sécurité et qu'il en sortirai quelque chose de collectif.
