Que pensez vous de la sécurité de mon espace membre?

[diodio13fr]

Bonjour, je code un CMS perso, ca m'évite d'utiliser une usine a gaz et c'est bon pour l'apprentissage , tout est au poil et là je viens de finir la partie relative à la sécurité j'aimerai avoir votre avis.
J'ai lu tout un tas de tutos sur le sujet et ai essayé de synthétiser le tout pour faire quelque chose de pas trop dégueulasse, mais n'étant qu'un débutant je ne peux etre sur de la fiabilité de tout ca......

Comme du code sera plus simple à lire qu'une explication de ma part voici toutes les fonctions utilisées:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
 
/* shaPassword
 * chiffre le mot de passe utilisateur ou toute autre donnée
 */
function shaPassword($pass){
    $context = hash_init('sha256');
    hash_update($context, $pass);
    return hash_final($context);
}
 
/* sessionLogin
 * initialise les variables de session lors du login réussi d'un utilisateur
 */
function sessionLogin($login, $time){
    session_regenerate_id(TRUE);
    $_SESSION['user'] = dbSafe($login);
    $_SESSION['time'] = time();
    $_SESSION['id'] = (string)randNumber();
    $_SESSION['nav'] = shaPassword($_SERVER['HTTP_USER_AGENT']);
    $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
    return 0;
}
 
 
/* sessionEnd
 * termine la session
 */
function sessionEnd(){
    session_start();
    session_unset();
    session_destroy();
    return 0;
}
 
function addCookie($name, $value){
    setCookie($name, $value, $_SESSION['time']+3600, '/admin/');
    return 0;
}
 
function delCookie(){
    setcookie('auth', '');
    setcookie('nav', '');
    return 0;
}

voilà la partie de code utilisée lors d'un login réussi:

Code :

1
2
3
4
5
6
7
8
9
 
if($dbPass[0][0] == $passEncrypted){
                    // si tout va bien (login et mot de passe OK on redirige vers
                    // l'espace utilisateur.
                    sessionLogin($name);
                    addCookie('auth', $_SESSION['id']);
                    addCookie('nav', shaPassword($_SERVER['HTTP_USER_AGENT']));
                    redirect('dashboard');
                }

et enfin le code situé dans l'entête de chaque page de la zone membre:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
if(!isset($_SESSION))
        session_start();
    $exploded = explode('/', $_SERVER['REQUEST_URI']);
    $requestedPage = $exploded[count($exploded) - 1];
 
    include_once($_SERVER["DOCUMENT_ROOT"] . '/config.php');
    if(!empty($_COOKIE['auth']) && !empty($_COOKIE['nav'])){
        if($_COOKIE['auth'] != $_SESSION['id'] || $_COOKIE['nav'] != $_SESSION['nav']){
            addCookie('auth', '');
            addCookie('nav', '');
            sessionEnd();
            redirect('piege');
        }
        elseif($requestedPage == 'login.php'){
        redirect('dashboard');
        }
    }
    elseif(empty($_COOKIE['auth']) && empty($_COOKIE['nav']) && $requestedPage != 'login.php'){
        sessionEnd();
        redirect('piege');
    }
    elseif(($_SESSION['ip'] != $_SERVER['REMOTE_ADDR']) && $requestedPage != 'login.php'){
        sessionEnd();
        redirect('piege');
    }

la fonction redirect() redirige l'utilisateur frauduleux vers un autre site, et le bon utilisateur vers le tableau de bord.

Je pense également ajouter un peu de sel a ces 2 variables $_SESSION['id'] et $_SESSION['nav'] ca ne peux pas faire de mal a condition que la gestion de tout cela soit correcte.

Merci pour vos avis et conseils.

[Benjamin Delespierre]

Hello

Pour commencer il y a plusieurs points que je ne comprends pas dans ton code:
- pourquoi toutes tes fonction renvoient 0 ?
- pourquoi tu définis une sécurité par cookies ? d'une part c'est pas plus sécurisé que le comportement normal des sessions et d'autre par qu'est ce qui va se passer si le client à désactivé les cookies ?
- ton code fait implicitement plusieurs session_start (par exemple la fonction session_end en fait un à nouveau)
- tu peux vérifier qu'une session existe en utilisant session_id

[Thes32]

Salut,

Déjà bravo pour ce que tu as déjà fait, Qu'est ce qui arrive quand un utilisateur oublie son mot de passe de passe ? ou à une ip dynamique ? A priori il va se faire lapider dans le piège

[jreaux62]

Envoyé par Thes32

... Qu'est ce qui arrive quand un utilisateur oublie son mot de passe de passe ?

Un mot de passe ne suffit pas ?
Il faut aussi un mot de passe de passe ?
Ouah ! drôlement sécurisé !

Plus sérieusement (?!),
ca me fait penser à une porte super-sécurisée, avec 50 verrous, 10 barres de force, 150 cadenas, 3 digicodes, ....
.... alors que la fenêtre est restée ouverte ! ...

Plus sérieusement (pour de vrai cette fois), "trop de sécurité tue la sécurité".
- hashage des données sensibles = OK
- mais ... session + cookies ... ? cookies = "stocké sur l'ordi client" = en dehors de "ta" protection ...

[m4riachi]

Pourquoi tu ne travaille pas avec un framework?

[Thes32]

Envoyé par m4riachi

Pourquoi tu ne travaille pas avec un framework?

Bonjour, je code un CMS perso, ca m'évite d'utiliser une usine a gaz et c'est bon pour l'apprentissage , tout est au poil et là je viens de finir la partie relative à la sécurité j'aimerai avoir votre avis.

Il est pourtant clair, non ?

[Benjamin Delespierre]

ça ne l'empêche pas de construire son propre CMS à l'aide d'un framework exitant

[diodio13fr]

Bonsoir et merci pour vos avis. Je vais répondre dans l'ordre.

Envoyé par Benjamin Delespierre

Hello

Pour commencer il y a plusieurs points que je ne comprends pas dans ton code:
- pourquoi toutes tes fonction renvoient 0 ?
- pourquoi tu définis une sécurité par cookies ? d'une part c'est pas plus sécurisé que le comportement normal des sessions et d'autre par qu'est ce qui va se passer si le client à désactivé les cookies ?
- ton code fait implicitement plusieurs session_start (par exemple la fonction session_end en fait un à nouveau)
- tu peux vérifier qu'une session existe en utilisant session_id

- J'utilise return(0); pour terminer "proprement les fonctions.
- pourquoi les cookies? parce que de tout ce que j'ai pu lire il m'a semblé que les session seules n'étaient pas suffisantes pour une "bonne" sécurité. Pour ce qui est de la désactivation des cookies, je ne me suis pas trop posé la question pour 2 raisons, 1° je ne compte pas diffuser ce CMS, c'est pour une utilisation perso et j'active les cookie dans mon navigateur, 2° je pense que quelqu'un désactivant les cookies dans son navigateur a des intentions suspectes.
Mais il est vrai que meme si l'utilisation est perso, je prefererai coder proprement ca pourrait servir pour d'autre projets.
- la fonction sessionEnd(); fait appel a session_start(); car sessionEnd() est appelée dans le fichier logout.php n'ayant aucune entête, il est appelé par formulaire en cliquant sur le bouton de déconnexion, a la fin de ce fichier on redirige vers l'accueil.
- pour session_id je ne connaissais pas je vais me pencher dessus merci.

Envoyé par Thes32

Salut,

Déjà bravo pour ce que tu as déjà fait, Qu'est ce qui arrive quand un utilisateur oublie son mot de passe de passe ? ou à une ip dynamique ? A priori il va se faire lapider dans le piège

Merci, pour ce qui est du mot de passe l'utilisation étant perso je serai toujours a temps d'en changer dans postgre, pour l'ip dynamique au pire apres la redirection il sera toujour possible de venir se loguer et les cookies ne durant qu'une heure, c'est pas de chance si l'ip change entre temps puis je suis en ip fixe :p.

Envoyé par jreaux62

Un mot de passe ne suffit pas ?
Il faut aussi un mot de passe de passe ?
Ouah ! drôlement sécurisé !

Plus sérieusement (?!),
ca me fait penser à une porte super-sécurisée, avec 50 verrous, 10 barres de force, 150 cadenas, 3 digicodes, ....
.... alors que la fenêtre est restée ouverte ! ...

Plus sérieusement (pour de vrai cette fois), "trop de sécurité tue la sécurité".
- hashage des données sensibles = OK
- mais ... session + cookies ... ? cookies = "stocké sur l'ordi client" = en dehors de "ta" protection ...

- je sais que j'ai peut etre un peu abusé avec 2 cookies et des hash long comme ca, si je suis la c'est justement pour voir si elle existe cette fenetre .
- je sais que les cookies sont hors de ma protection, mais leur vol ne servirai a rien car l'un d'eux est un hash de la signature du navigateur + grain de sel.

@ m4riachi et Benjamin Delespierre: c'est mon premier projet en php, je pense qu'il est bon pour moi de commencer de 0, déja que je n'ai pas codé orienté objet (je sais ....... tapez pas) va falloi r que je m'y penche en php, je n'ai abordé la POO qu'en java. Mais ca sera l'occasion de passer mon CMS en V2.0 .

Donc au final la sécurité que j'ai codé est-elle suffisante, abusive ou dérisoire?

[Benjamin Delespierre]

Envoyé par diodio13fr

- J'utilise return(0); pour terminer "proprement les fonctions.

S'il n'y a aucune raison valable de renvoyer un entier, ne le fais pas.

Envoyé par diodio13fr

- pourquoi les cookies? parce que de tout ce que j'ai pu lire il m'a semblé que les session seules n'étaient pas suffisantes pour une "bonne" sécurité. Pour ce qui est de la désactivation des cookies, je ne me suis pas trop posé la question pour 2 raisons, 1° je ne compte pas diffuser ce CMS, c'est pour une utilisation perso et j'active les cookie dans mon navigateur, 2° je pense que quelqu'un désactivant les cookies dans son navigateur a des intentions suspectes.

Par forcément, tu as des navigateurs mobiles qui ne prennent pas les cookies par exemple

Envoyé par diodio13fr

@ m4riachi et Benjamin Delespierre: c'est mon premier projet en php, je pense qu'il est bon pour moi de commencer de 0, déja que je n'ai pas codé orienté objet (je sais ....... tapez pas) va falloi r que je m'y penche en php, je n'ai abordé la POO qu'en java. Mais ca sera l'occasion de passer mon CMS en V2.0 .

Si tu connais Java, passer en PHP Orienté Objet se fera presque naturellement

[diodio13fr]

ok pour les return(0); je vais les supprimer.
Pour les cookies c'est vrai que je n'avais pas pensé à ce cas là.
Sinon ça y est je commence le php OO, obligé car je jette un coup d'œil à zend... au premier abord je trouve ça assez lourd à mettre en oeuvre, je vais persister et voir si je m'en sort mieux dans quelques temps.

Pour en revenir, au sujet de base, et puisque je ne devrai pas tarder à mettre mon site en production, la sécurité vous en pensez quoi sera-t-elle efficace?

[lucas74]

Envoyé par diodio13fr

ok pour les return(0); je vais les supprimer.

bien

Envoyé par diodio13fr

Pour les cookies c'est vrai que je n'avais pas pensé à ce cas là.

Le problème demeure avec l'usage des sessions suivant la configuration.

Envoyé par diodio13fr

Sinon ça y est je commence le php OO, obligé car je jette un coup d'œil à zend... au premier abord je trouve ça assez lourd à mettre en oeuvre, je vais persister et voir si je m'en sort mieux dans quelques temps.

Normalement la POO en PHP devrait être bien similaire à ce qu'elle est en java ou en c#..

Envoyé par diodio13fr

Pour en revenir, au sujet de base, et puisque je ne devrai pas tarder à mettre mon site en production, la sécurité vous en pensez quoi sera-t-elle efficace?

elle sera aussi efficace que sur un système se contentant d'utiliser des sessions mais ce sera plus lourd.

[Doonge]

Il me semble que de toute façon les cookies sont nécessaires même pour les sessions standards (il faut bien que l'ID de session transite dans la requete HTML, donc soit par les cookies, soit _GET ou _POST).


Niveau sécurité, je te conseille de te pencher sur mon thread (auquel j'ai répondu récemment). J'y parle d'une technique de hashage/cryptage (c'est différent mais bon) performante. Un des soucis de ta technique de hash, c'est que tu te bases sur le navigateur. Tester la "régularité" de l'user agent est intéressant, mais c'est un maigre verrou. Et utiliser l'useragent (ou son hash) comme élément de hash ou grain de sel est peu performant : c'est un élément prévisible et peu variable.





Une chose que je n'ai jamais comprise par ailleurs, pourquoi le logout force-t-il une redirection ?
Normalement un logout c'est juste un kill de session (et de cookie). Qu'est ce qui rend la redirection nécessaire ?

[diodio13fr]

@lucas74: Merci, si c'est efficace c'est bon, meme si c'est un peu plus lourd. J'ai quand meme tendance a croire que cela sera un peu plus efficace.

@Doonge: Salut, j'ai lu ton thread, effectivement utiliser une table de la base est une bonne idée, il y a d'ailleurs un tuto sur developpez, mais je ne voulais pas surcharger la base et lui envoyer trop de requetes "surperflue". Par contre je ne pense pas qu'utiliser l'useragent soit un maigre verrou, il est n'est pas variable pour un même utilisateur au cours d'une même session (et tant mieux) par contre pour le prédire.... par exemple voici mon actuel sur une machine du boulot :

Code :

Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.20) Gecko/20110803 Firefox/3.6.20 ( .NET CLR 3.5.30729)

il y a le navigateur mais aussi l'OS sa version, la langue du système et d'autre choses que je connais pas. Donc à prédire!! en plus je l'utilise en hash ajouté à une autre valeur totalement imprévisible donc je pense que ça doit etre plutot fiable.

pour ce qui de la redirection lors d'un logout, elle permet juste de revenir à l'index du site, car je me dis que selon d'ou est faite la deconnexion (espace membre ou pas) le mieux est de revenir à l'index, il est possible aussi de rester sur la page courante mais si elle appartient à l'espace membre ce la sera considéré comme une usurpation puisque la session est detruite en cours de route. Je ne trouve pas necessaire de detruire les cookies car ils deviennent unitilisable et que des nouveaux seront renvoyés à la connexion suivante .

[Djakisback]

Salut,
loin d'être un expert mais a priori je dirais que ce ne sera pas plus efficace et que le seul truc utile ici est le session_regenerate_id(true). Mais il est mal placé, il faut regénérer l'id à chaque requête.
Pour étayer ce qu'a dit jreaux62, tout est transmis dans ta requête, user-agent, noms et valeurs des cookies, ça ne change donc rien au problème de vol de session, d'ajouter des cookies ou de crypter quoique ce soit.
Je te conseille de lire ceci : http://guillaume-affringue.developpe...rement/?page=4
Je crois qu'il y a d'ailleurs un oubli important dans cette page, c'est que si l'on arrive à écouter le réseau dans un sens, on peut également le faire dans l'autre ainsi on peut a priori récupérer le nouvelle identifiant avant que le client originel ne l'ait reçu, à moins que je ne me plante complètement mais il me semble avoir compris le mécanisme.
Pour info, le mécanisme de stockage/vérification d'ip me semble bien plus efficace que ce que tu proposes, couplé avec la regénération d'id et en plus la protection htaccess ça commence à être intéressant même si c'est plus galère à mettre en oeuvre.

[Doonge]

Heu je sais pas où t'as lu que je conseillais d'utiliser une table de la base de données. Etant donné que je sujet principal de mon thread n'est pas vraiment les "détails" des tricks de sécurité et de hashage, mais plutot la vulnérabilité des types de connections par rapport au hijacking, je vais supposer que c'est pas bien expliqué dans le thread et essayer de préciser ici:


- L'user-agent est un faible verrou, parce qu'il se choppe très facilement (la victime va sur un site que tu contrôles => elle envoie ses en-tête => tu les as, point, et ce sans technique de sniffage ou autre).

- Un attaquant, puisqu'il connait le grain de sel, peut mener une attaque type dictionnaire, ou bruteforce, puisque le grain de sel ne change pas (et pire : est connu, ce qui lui permettrait de construire ses propres cookies/sessions valides), et qu'il reçoit beaucoup de hashages différents avec le même grain de sel (qu'au pire il connait).


Okay pour la redirection chez toi.
Je ne détruis pas les cookies, je pensais juste à une session_destroy (qui chez moi détruit beaucoup d'information stockée sur le cookie, parce que je choisis parfois de les stocker sur le cookie -par exemple les paniers).
Je vais pas entrer dans les détails de mon code (qui permet une redirection interne plutot qu'une redirection forcée chez l'utilisateur), mais puisque les utilisateurs cliquent sur un lien [ logout ], pourquoi ne pas faire en sorte qu'il pointe sur la page d'index avec en get un parametre logout (ou un autre format si tu utilises le redirect via htaccess) ?
L'essentiel c'est que ca fonctionne bien sûr, et chez toi ça fonctionne déjà impec, de plus l'action logout n'est pas tellement fréquente, mais je trouve pas ça tellement optimisé de doubler la requete en forcant une redirection.


edit:
Tiens ton article est marrant Djakisback, c'est la technique que j'ai décrite dans mon thread, et ses défauts ont été mis en évidence.
L'un des défauts, qui est donné dans l'article, c'est que la méthode ne fonctionne pas si le pirate prolonge la session, simplement.
Un défaut 'oublié', c'est l'utilisateur qui double click.

[Djakisback]

En fait je crois que le problème dans le code proposé par diodio c'est qu'il stocke le résultat du hash dans un cookie et cette valeur est donc transmise dans chaque requête http, ce qui n'a aucun intérêt vu qu'elle peut être capturée au même titre que l'id de session.

[diodio13fr]

Donc si je comprend bien (comme l'a dit lucas74) je n'apporte réellement rien de plus en terme de sécurité par rapport à un système classique de session avec PHPSESSID. Juste qu'il faut capturer plus d'informations pour usurper une identité? Néanmoins le contrôle de l'IP du visiteur est une protection efficace non? Disons que mon site n'aura pas suffisamment d'importance pour que quelqu'un passe du temps à le craquer en capturant les cookies et usurpant l'IP d'un utilisateur valide? Après il va falloir que je m'assure qu'il "réagi" bien au niveau des iSQL, XSS et autres conneries facilement mise en oeuvre par un script kiddie....

[Doonge]

Les sessions vivent essentiellement grâce aux cookies.

Le cookie contient généralement l'ID (encodée ou non) de session, et comme le cookie est envoyé à chaque fois qu'un utilisateur visite ton site, c'est comme ça que tu sais que c'est lui.

Tu peux éventuellement, si tu veux, vérifier l'IP, ou l'User-agent, mais cela n'apporte en général aucune réelle sécurité en plus (et ça apporte des problèmes, car l'IP n'est pas toujours fixe, même pour un bon utilisateur).


Pour frauder une session, un pirate doit être capable "d'inventer" une session valide, ou de "modifier" les informations de sessions, ou encore de "voler/copier" une session existante.

Pour inventer ou modifier une session, il doit connaitre ou deviner à peu près ton code. Il vaut mieux être sûr qu'un pirate soit incapable de le faire, et d'habitude un script php avec sessions SQL refuse les PHPSESSID qu'il n'a pas créées (pas d'inventions). Il vaut mieux être sûr également qu'il n'est pas possible de modifier des infos de sessions (ça ne te concerne pas des masses vu que tu stockes probablement les infos de sessions via SQL, coté serveur donc).

Le truc le plus ennuyeux c'est le vol de session.
Un premier truc pour s'en prémunir, c'est rendre longs et aléatoires les identifiants de sessions (donc on peut pas deviner facilement les ID en cours d'utilisation).
Mais cela n'empêche pas le vol de cookie.

Je crois qu'une technique courante pour "voler" les cookies, c'est sniffer les connections au site (ou celles d'une victime). Cela implique que l'attaquant connaît forcément :

- l'IP du visiteur
- ses entêtes HTML, c'est à dire l'user-agent, le contenu du cookie (donc l'identifiant avec), et même les informations GET et POST (tout le bazard quoi).

Donc à mon avis, si un attaquant connait le PHPSESSID (qu'on choppe dans le cookie), il connait le reste aussi.

[Djakisback]

A vérifier mais il me semble que c'est un peu plus compliqué d'usurper une ip, tu tapes pas dans la même couche OSI et je pense que le niveau devient un peu plus élevé contrairement à l'envoi d'une simple requête HTTP à la portée de tout le monde.
Enfin, tout ça pour dire qu'à mon avis, dans ton cas seul l'id de session suffira et peut-être le régénérer à chaque requête, ce qui empêchera le vol direct de cookie mais pas le vol par capture sur le trafic. S'il y a d'autres avis, je suis très intéressé également

[Inazo]

Bonjour à tous,

Si j'ai un premier conseil à donner évitez de faire des pages de piège, car c'est une perte de temps (un vrai honeypot est plus pertinent) de plus cela montre au potentiel Hacker que ces essai sont plus ou moins fructueux et lui donne des indications.

Ensuite une chose me gêne :

Bonjour, je code un CMS perso, ca m'évite d'utiliser une usine a gaz et c'est bon pour l'apprentissage , tout est au poil et là je viens de finir la partie relative à la sécurité j'aimerai avoir votre avis.

Tu as commencé à coder ton CMS sans penser à la sécurité ? La sécurité est l'élément que tu dois avoir en tête dans chaque script avant même de les écrire, pas uniquement sur des identifications. Dans se genre d'outil la sécurité est un tout il te faut donc penser "sécurité" du début à la fin.

Ensuite comme je l'ai lu dans plusieurs commentaire il faut que tu cloisonne un peu plus tes COOKIES, voir même que tu ne stocke rien dans les cookies mais que tu utilises une Table MySQL pour stocké les données en les liants à l'ID de session.

Mais pour cela tu dois faire en sorte que l'ID de session change à chaque page avec session_regenerate_id()

et aussi ceci :

Code :

1
2
3
4
5
6
7
8
 
//-- Interdiction d'agir sur le cookie en dehors de HTTP, donc pas d'alert(document.cookie)
ini_set('session.use_only_cookies',1);
//-- Pas de PHPSESSID dans l'url histoire de ne pas faciliter son vol
ini_set('session.use_trans_sid',0);
 
//-- Paramètre pour le cookie notamment très important pour le nom de domaine
session_set_cookie_params(0,'/','google.com',FALSE,TRUE);

Ensuite je continuerais par dire qu'aucune des protections que tu as mise n'est inutile oui le USER AGENT c'est faible, oui on peut spoofer des IP mais le tout ajouter commence à faire beaucoup.

Les "Script Kiddies" attention car ils sont de plus en plus nombreux et le plus triste c'est que le nombre d'outils simple d'utilisation pour faire des petits Hack explose et qu'ils sont à la portés de tous... Donc ne négligé pas la sécurité de vos applications et je dirais même faites contrôler vos sources voir pentester vos applis.

Cordialement,