Discussion :

[Doonge]

De ce que j'ai appris en lisant des articles sur la sécurité à droite à gauche

- vérifier l'IP c'est un petit plus pour la sécurité mais ça pose des (gros) problèmes aux utilisateurs à IP changeantes (fonctionne dans un réseau qui distribue les IP, AOL ou réseau entreprise). Une technique consiste à n'activer le verrou IP qu'une fois qu'on a constaté qu'elle n'a pas changé en une dizaine/vingtaine de click.

- Vérifier l'user-agent c'est très très léger comme sécurité en plus. Ca ne bloque que les plus mauvais hackers qui existent. L'user-agent par contre est lui réellement censé rester toujours le même (contrairement à l'IP).

- Regénérer l'ID de session à chaque page ça ne sert à rien du tout. Normalement on regénère l'ID de session à chaque changement de statut du visiteur (login, logout, login admin, logout admin, login connection sécurisée genre HTTPS, logout HTTPS). Je serais intéressé si tu pouvais donner des détails sur les avantages du session_regenerate_id systématique.

[Inazo]

- vérifier l'IP c'est un petit plus pour la sécurité mais ça pose des (gros) problèmes aux utilisateurs à IP changeantes (fonctionne dans un réseau qui distribue les IP, AOL ou réseau entreprise). Une technique consiste à n'activer le verrou IP qu'une fois qu'on a constaté qu'elle n'a pas changé en une dizaine/vingtaine de click.

Pas d'accord, si l'IP change à un moment ou un autre il y a un soucis. De plus il est très rare de nos jours que l'on change d'ip même en rebootant nos Box je ne suis pas en ip fixe chez Free et pourtant elle ne change pas si facilement. En entreprise pitié pas de DHCP...

UserAgent est un plus car l'attaquant ne l'aura pas forcément en ça possession, et donc si le fait de voir une discordance permet la destruction de la session et donc de rendre l'attaque sur cet ID impossible par la suite tu as gagné le match.

- Regénérer l'ID de session à chaque page ça ne sert à rien du tout. Normalement on regénère l'ID de session à chaque changement de statut du visiteur (login, logout, login admin, logout admin, login connection sécurisée genre HTTPS, logout HTTPS). Je serais intéressé si tu pouvais donner des détails sur les avantages du session_regenerate_id systématique.

Hum... Je dirais pour éviter les vols de session ? Si tu ne change jamais ton ID de session sans faire les contrôles au dessus et que je te le vol tu fait quoi ? j'ai moi aussi ta session. Donc le fait d'avoir un ID qui va changer à chaque page va compliquer énormément la tache de fixation de la session.

Car si tu n'as pas d'HTTPS le vol de ton ID de session reste faisable combien de lien nous communique t-on par moment avec des PHPSESSID dans l'url ? Si il ne change pas régulièrement et que tu ne fait pas de contrôle sur l'ip et l'user agent tu es bleu...

J'ajouterais qu'il est primordiale pour un utilisateur de toujours fermer ça session sinon avec certaine attaque on peut récupérer des sessions oublié (et cela facilement).

Cordialement,

[Doonge]

L'IP peut parfaitement changer sans qu'il n'y aie de soucis.
Il est peut-être "rare" pour la plupart des français qu'elle ne change, mais même en France je doute que ce soit vrai pour tous les utilisateurs, particulièrement ceux qui surfent sur leur téléphone.


L'User-Agent, je vois mal comment un pirate qui a l'ID de session n'a pas l'User-agent. Et L'User-agent est facilement modifiable à volonté, contrairement à l'IP.



La regénération d'ID ne change pas grand chose au vol de session.
La seule chose qui permet d'éviter le pire en cas de vol de session, c'est de changer la session (et redemander un password éventuellement) en cas d'opération sensible.

C'est facile à comprendre :

Utilisateur lambda, en pleine session, clique sur un lien du site, donc recharge une page et reçoit un nouvel identifiant de session dans son cookie.
Un pirate sniffe son réseau, a eu également tous les cookies précédent, et décide d'utiliser maintenant la session volée.
Il copie donc le cookie, et va sur le site.
Le site le reconnait comme l'utilisateur lambda, et lui donne un nouvel identifiant de session.
L'utilisateur lambda n'a plus de session valide, le pirate oui.

Si l'utilisateur lambda continue d'aller sur le site, il aura perdu sa session et va devoir se relog (là on peut détecter la fraude et tuer la session du pirate).
Si l'utilisateur ne va pas sur le site (est passé sur un autre site, ce que le pirate peut savoir également), le pirate fait ce qu'il veut sur le site.

Autre chose, le double click.
Si un utilisateur clicke deux fois sur un lien, il va ouvrir deux requetes avec le même cookie (le même identifiant).
La première va mettre à jour l'identifiant de session.
La seconde va échouer et mettre à zéro la session, parce que le cookie envoyé ne correspond pas au nouvel identifiant de session créé à la première requete.




Ouais il est "éventuellement" primordial pour un utilisateur de fermer sa session.
Mais on peut pas les y obliger.
Et en plus, on peut les forcer à se réidentifier en cas d'opération sensible, donc même s'ils ne ferment pas leur session on s'en fout un peu.

[Inazo]

Alors,

Le surf sur téléphone je suis pas certain qu'elle change mis à part si tu passe de borne en borne wifi, ce qui en soit n'est pas une connexion sécurisé du tout donc tu joue juste avec le feu.

Pour l'UserAgent complet il n'est pas certain qu'il l'ai notamment dans le cas de récupération d'un session mal cloturé, ou d'un vol d'ID fait d'une manière qui ne lui permettais pas d'avoir l'useragent complet.

Utilisateur lambda, en pleine session, clique sur un lien du site, donc recharge une page et reçoit un nouvel identifiant de session dans son cookie.
Un pirate sniffe son réseau, a eu également tous les cookies précédent, et décide d'utiliser maintenant la session volée.
Il copie donc le cookie, et va sur le site.
Le site le reconnait comme l'utilisateur lambda, et lui donne un nouvel identifiant de session.
L'utilisateur lambda n'a plus de session valide, le pirate oui.

D'ou la complémentarité des contrôles, et dans le pire des cas si les sessions sont couplé à une gestion en base données une fois l'utilisateur reconnecté le pirate va devoir recommencé car il aura été aussi déconnecté. Faire un contrôle seul sur l'ID n'est pas du tout une bonne idée même derrière une connexion en HTTPS. De plus cela ne sert à rien au pirate d'avoir les anciens cookies car les anciennes sessions sont systématiquement détruites, il faut le dernier cookie au moment ou il est actif certes il peut l'être longtemps ou pas.

Le double click point intéressant soulevé qui en effet s'il n'est pas gérer correctement va provoquer la perte des deux sessions, dans le pire des cas l'utilisateur devra se reloguer mais aucune attaque ne sera réalisable.

Et en plus, on peut les forcer à se ré-identifier en cas d'opération sensible, donc même s'ils ne ferment pas leur session on s'en fout un peu.

Si le but de tes remarques depuis le début porte sur "l'ergonomie" de l'utilisateur là tu fais un 180°. Soit tu es sur qu'il est bien identifié soit tu coupe ça connexion mais pas de doute permis.

EDIT : et pour finir une lecture de ceci serait un plus : http://a-pellegrini.developpez.com/t...hp/session-db/

Cordialement,

[Doonge]

La plupart des techniques décrites dans les tutoriels pour débutant cités dans ta propre signature (xss, crf, sniffing réseau) permettent toutes d'avoir l'user-agent en plus de l'identifiant de session, sans effort particulier.


La complémentarité des contrôles c'est bien, mais il faut être conscient que la sécurité parfaite n'existe pas vraiment (surtout sur le net), et qu'il faut mettre en balance le niveau de sécurité par rapport à la lourdeur du système requis pour atteindre cette sécurité, et également par rapport à la nécessité de la sécurité (toutes les pages ne demandent pas le même iveau de sécurité).
Il faut aussi être conscient que le niveau de sécurité général est égal au niveau de sécurité le plus faible des parties du système.



Je vois que tu sembles déprécier au plus haut point les utilisateurs "qui jouent avec le feu" (réseau entreprise qui distribue ses IP, utilisateur qui surfe sur un téléphone à partir de bornes WiFi).
Je n'apprécie pas tellement non plus quand un utilisateur néglige sa propre sécurité, mais il faut quand même en tenir compte.
De plus, AOL.


Le lien que tu as donné est très peu intéressant. Il s'adresse à des débutants. Date de 2006, donc pas top niveau sécurité (les standards changent), et contient des failles.

Notamment celle-ci

$view = '<form enctype="multipart/form-data" action="'.$_SERVER['PHP_SELF'].'" method="post" id="form">'."\n";
$view .= '<label for="username">Username&nbsp;&nbsp;</label>'.textfield('username')."\n";
$view .= '<label for="password">Password&nbsp;&nbsp;</label>'.textfield('password')."\n";
$view .= button('subit', 'Envoyer')."\n";
$view .= '</form>';

Si le but de tes remarques depuis le début porte sur "l'ergonomie" de l'utilisateur là tu fais un 180°. Soit tu es sur qu'il est bien identifié soit tu coupe ça connexion mais pas de doute permis.

Tu peux pas être sûr qu'un utilisateur ferme manuellement sa session, donc compte pas dessus. C'est ce que je voulais dire : on s'en fout qu'il ferme ou non sa session, ca change rien à notre façon de voir la sécurité de notre script. Tu peux pas baser la sécurité de ton script sur l'intégrité de ton client.

[Inazo]

Ok donc,

La complémentarité des contrôles c'est bien, mais il faut être conscient que la sécurité parfaite n'existe pas vraiment (surtout sur le net), et qu'il faut mettre en balance le niveau de sécurité par rapport à la lourdeur du système requis pour atteindre cette sécurité.
Il faut aussi être conscient que le niveau de sécurité général est égal au niveau de sécurité le plus faible des parties du système.

Là déjà on est d'accord ça ne fait aucun doute. Ensuite pour l'useragent je maintien ce que je dit si il récupère un ID de session par Smugling (pas sur de l'orthographe) il n'a pas le user-agent.

Je vois que tu sembles déprécier au plus haut point les utilisateurs "qui jouent avec le feu" (réseau entreprise qui distribue ses IP, utilisateur qui surfe sur un téléphone à partir de bornes WiFi).
Je n'apprécie pas tellement non plus quand un utilisateur néglige sa propre sécurité, mais il faut quand même en tenir compte.

Une fois encore on est sur la même longueur d'onde, mais même si il passe de borne en borne ça doit se faire avec des coupures même sur le téléphone je dirais à moins qu'il soit vraiment configuré pour se connecter à tout ce qui passe et là on peut plus rien pour lui

Le lien que tu as donné est très peu intéressant. Il s'adresse à des débutants. Date de 2006, donc pas top niveau sécurité (les standards changent), et contient des failles.

Ah oui en effet le coup de PHP_SELF est pas mal

Tu peux pas être sûr qu'un utilisateur ferme manuellement sa session, donc compte pas dessus. C'est ce que je voulais dire : on s'en fout qu'il ferme ou non sa session, ca change rien à notre façon de voir la sécurité de notre script. Tu peux pas baser la sécurité de ton script sur l'intégrité de ton client.

En fait ma remarque portez surtout sur le fait de redemander à l'utilisateur de s'identifier pour des actions précise alors qu'il est déjà identifié, mais j'ai du mal m'exprimer

Cordialement,

[Doonge]

Même par Smuggling il a l'user-agent.

Basiquement, dès qu'un pirate est capable de contrôler le HTML qu'une victime reçoit, il le force à visiter son propre site avec le contenu du cookie. Comme la victime visite le site du pirate, l'user-agent est stocké.



Entendons-nous bien, j'utilise l'User-agent comme élément de sécurité. Mais c'est juste parce que c'est facile à mettre en place, et que c'est mieux que rien, même si c'est trèèèèèès superficiel.
Je ne relève que rarement la présence ou l'absence de cet élément de sécurité lorsque je regarde un script d'un autre, sauf s'il n'y a aucune autre faute (beaucoup plus conséquente sur la sécurité).

[Inazo]

Hum, je viens de relire ceci : https://www.owasp.org/index.php/HTTP_Request_Smuggling

Pour ceux que cela intéresse (mais pas de user agent à l'horizon promis j’arrête )

Cordialement,

[Doonge]

Description

The HTTP Request Smuggling attack explores an incomplete parsing of the submitted data done by an intermediary HTTP system working as a proxy. HTTP Request Smuggling consists of sending a specially formatted HTTP request that will be parsed in a different way by the proxy system and by the final system, so the attacker could smuggle a request to one system without the other being aware of it. This attack makes it possible to exploit other attacks, like Cache Poisoning, Session Hijacking, Cross-site Scripting (XSS) and most importantly, the ability to bypass web application firewall protection.

To exploit the HTTP Request Smuggling, some specific conditions must exist, such as the presence of specific proxy system and version such as SunOne Proxy 3.6 (SP4) or FW-1/FP4-R55W beta or an XSS vulnerability in the web server.

Cache Poisoning (controle HTML envoyé à la victime), XSS = User-agent connu.
Et en général, il n'est même pas besoin de connaître l'User-agent, c'est déjà mort si le Smuggling fonctionne, parce qu'on peut forcer la victime à faire ce qu'on veut.

C'est une faille serveur, qu'on ne peut pas corriger avec le contrôle sur l'user-agent (il faut mettre à jour le serveur au plus vite).