Sécurité de session PHP

Quelles sont les lignes directrices pour maintenir une sécurité de session responsable avec PHP? Il y a de l'information partout sur le Web et il est temps que tout se passe au même endroit!

0
ajouté édité
Vues: 2

14 Réponses

Voici ce que je pense que vous devez faire

Créez un nouveau blog multi-sites sur le nouveau domaine "maître" avec WP 3.0

Créer un nouveau blog vide l'url h..p: //www.mysite.com/oldblogname

Exporter votre ancien site et entrer dans le nouveau blog

Vous devez vérifier que toutes les images sont copiées sur le nouveau site. Sinon, gardez l'ancien blog en place pour diffuser les images.

Et tu vas avoir un joli nouveau blog

Pour le garder bien rangé, vous devriez mettre une redirection 304 de l'ancienne URL vers la nouvelle URL

Quelque chose comme ceci devrait (pas testé) dans un fichier .htacces dans l'ancien dossier de blog

RewriteEngine on
#
RewriteRule ^(.*)$ http://www.websiteA.com/oldblogname/ $1 [R=301,L]
1
ajouté

Je pense que l'un des problèmes majeurs (qui est traité en PHP 6) est register_globals. Actuellement, l'une des méthodes standard pour éviter register_globals est d'utiliser le $ _ REQUEST , $ _ GET ou $ _ POST tableaux.

La "bonne" façon de le faire (à partir de la 5.2, bien que ce soit un peu buggé là-bas, mais stable à partir de 6, qui arrive bientôt) passe par filtres .

Donc, au lieu de:

$username = $_POST["username"];

vous feriez:

$username = filter_input(INPUT_POST, 'username', FILTER_SANITIZE_STRING);

ou même juste:

$username = filter_input(INPUT_POST, 'username');
0
ajouté
Je suis d'accord, cela ne <100> répond pas entièrement à la question, mais c'est certainement une partie de la réponse à la question. Encore une fois, cela étoffe un point dans la réponse acceptée, «Ne pas utiliser les globales de registre». Cela dit quoi faire à la place.
ajouté l'auteur cmcculloh, source
Vraiment? Alors pourquoi, dans la réponse acceptée, mentionnent-ils de ne pas utiliser les globals de registre? Ne serait-ce pas, dans la mesure où la plupart des développeurs banals sont concernés, enregistrer globals et former la gestion des variables tombent sous le parapluie de "sessions" même si elle ne fait pas techniquement partie de l'objet "session"?
ajouté l'auteur cmcculloh, source
Cela n'a aucun rapport avec la question.
ajouté l'auteur The Pixel Developer, source
-1 Cela ne répond pas à la question.
ajouté l'auteur Tomas, source

Une directive est d'appeler session_regenerate_id chaque fois que le niveau de sécurité d'une session change. Cela permet d'éviter le détournement de session.

0
ajouté

Je voudrais vérifier à la fois IP et User Agent pour voir si elles changent

if ($_SESSION['user_agent'] != $_SERVER['HTTP_USER_AGENT']
    || $_SESSION['user_ip'] != $_SERVER['REMOTE_ADDR'])
{
    //Something fishy is going on here?
}
0
ajouté
@scotts Je suis d'accord avec la partie IP mais pour la mise à niveau du navigateur, vous devez définir la session lors de la connexion, donc je ne vois pas comment ils vont mettre à jour leur navigateur sans créer une nouvelle session.
ajouté l'auteur JasonDavis, source
@jasondavis Il y a un navigateur appelé Chrome.
ajouté l'auteur Pacerier, source
Je crois que le user_agent peut également changer quand basculer entre le mode compatible dans IE8. C'est aussi très facile de faire semblant.
ajouté l'auteur Heather Herbert, source
L'adresse IP peut légitimement changer si l'utilisateur est derrière une batterie de serveurs proxy équilibrée.
ajouté l'auteur Kornel, source
Yep mais qu'en est-il des utilisateurs qui avaient IP IP eq GSM et est changé toutes les demi-heures. Donc, IP stocké dans Session + nom d'hôte, WHEN IP! = REMOTE_ADDR vérifier l'hôte et comparer hostanmes eq. 12.12.12.holand.nl-> quand est holand.nl == vrai. Mais certains hébergeurs avaient un nom d'hôte basé sur IP Puis besoin de comparer le masque 88.99.XX.XX
ajouté l'auteur user956584, source
Et user_agent peut changer chaque fois qu'un utilisateur met à jour son navigateur.
ajouté l'auteur scotts, source

Il y a plusieurs choses à faire pour que votre session soit sécurisée:

  1. Utilisez SSL pour authentifier les utilisateurs ou effectuer des opérations sensibles.
  2. Régénérez l'ID de session chaque fois que le niveau de sécurité change (comme la connexion). Vous pouvez même régénérer l'identifiant de session à chaque demande si vous le souhaitez.
  3. Les sessions sont-elles expirées
  4. N'utilisez pas de globals de registre
  5. Enregistrez les détails d'authentification sur le serveur. Autrement dit, n'envoyez pas de détails tels que le nom d'utilisateur dans le cookie.
  6. Vérifiez le $ _ SERVER ['HTTP_USER_AGENT'] . Cela ajoute un petit obstacle au détournement de session. Vous pouvez également vérifier l'adresse IP. Mais cela cause des problèmes aux utilisateurs qui ont une adresse IP changeante en raison de l'équilibrage de charge sur plusieurs connexions Internet, etc. (ce qui est le cas dans notre environnement ici).
  7. Verrouillez l'accès aux sessions sur le système de fichiers ou utilisez la gestion de session personnalisée
  8. Pour les opérations sensibles, envisagez de demander aux utilisateurs connectés de fournir à nouveau leurs informations d'authentification
0
ajouté
Si vous régénérez l'identifiant de session, l'identifiant de session qu'un intrus vole sur une requête non-HTTPS est inutile.
ajouté l'auteur grom, source
@The Rook, cela peut être une barrière triviale (l'attaquant peut capturer l'user-agent d'une victime en utilisant son propre site) et repose sur la sécurité par l'obscurité, mais c'est encore un obstacle supplémentaire. Si le HTTP utilisateur-agent devait changer pendant l'utilisation de la session, il serait extrêmement suspect et probablement une attaque. Je n'ai jamais dit que vous pouvez l'utiliser seul. Si vous combinez cela avec les autres techniques, vous avez un site beaucoup plus sécurisé.
ajouté l'auteur grom, source
@The Rook, oui l'agent utilisateur peut être usurpé. C'est juste une petite petite barrière. Et que voulez-vous dire par à aucun moment le cookie peut être divulgué sur http. Oui, il peut être volé. http est un texte brut.
ajouté l'auteur grom, source
@grom Chrome ne change-t-il pas automatiquement son user-agent quand il se met à jour silencieusement en arrière-plan pendant que l'utilisateur utilise le navigateur? De cette façon, vous bloquez les utilisateurs réels sans véritable raison. Ne pas oublier que la convivialité améliorée est également une sécurité renforcée.
ajouté l'auteur Pacerier, source
@grom Je pense que c'est comme mettre un morceau de scotch sur votre porte et dire que cela empêchera les gens d'entrer par effraction.
ajouté l'auteur rook, source
@grom la seule barrière est celle dans votre esprit, vous n'arrêtez aucune attaque.
ajouté l'auteur rook, source
Merde je voudrais pouvoir vous donner un autre -1 pour l'utilisation de SSL. À aucun moment, le cookie ne peut être divulgué sur http, c'est prévu dans OWASP A3.
ajouté l'auteur rook, source
-1 l'agent utilisateur est trivial à usurper. Ce que vous décrivez gaspille du code et n'est pas un système de sécurité.
ajouté l'auteur rook, source
L'utilisation de SSL uniquement pour certaines opérations ne suffit pas, à moins que vous n'ayez des sessions distinctes pour le trafic crypté et non crypté. Si vous utilisez une session unique via HTTPS et HTTP, l'attaquant la dérobera lors de la première requête non-HTTPS.
ajouté l'auteur Kornel, source
Ne pas régénérer la session à chaque requête. Il est sensible aux conditions de course et vous perdrez la séance tôt ou tard.
ajouté l'auteur Kornel, source
Je suis d'accord avec porneL. En outre, pour le numéro 6, si un attaquant a votre identifiant de session, n'auraient-ils pas également accès à votre agent utilisateur?
ajouté l'auteur Chad, source
Si vous vérifiez l'agent utilisateur, vous bloquerez toutes les demandes des utilisateurs IE8 lorsqu'ils basculeront en mode de compatibilité. Voyez le plaisir que j'ai eu à dépister ce problème dans mon propre code: serverfault.com/questions/200018/ http-302-problème-sur-ie7 . Je prends l'agent d'utilisateur pour vérifier, parce que c'est une chose banale à usurper, comme d'autres l'ont dit.
ajouté l'auteur bestattendance, source

C'est assez trivial et évident, mais assurez-vous de session_destroy après chaque utilisation. Cela peut être difficile à mettre en œuvre si l'utilisateur ne se déconnecte pas explicitement, donc un minuteur peut être configuré pour le faire.

Voici un bon tutoriel sur setTimer() et clearTimer ().

0
ajouté

Utiliser l'adresse IP n'est pas vraiment la meilleure idée de mon expérience. Par exemple; mon bureau a deux adresses IP qui s'utilisent en fonction de la charge et nous rencontrons constamment des problèmes en utilisant les adresses IP.

Au lieu de cela, j'ai opté pour stocker les sessions dans une base de données séparée pour les domaines sur mes serveurs. De cette façon, personne sur le système de fichiers n'a accès à cette information de session. Cela a été très utile avec phpBB avant 3.0 (ils l'ont corrigé depuis) ​​mais c'est toujours une bonne idée je pense.

0
ajouté

Mes deux (ou plus) cents:

  • Ne faites confiance à personne
  • Filtre d'entrée, sortie d'échappement (cookie, les données de session sont votre entrée aussi)
  • Évitez XSS (gardez votre HTML bien formé, jetez un oeil à PHPTAL ou HTMLPurifier )
  • Défense en profondeur
  • Ne pas exposer les données

Il y a un petit mais bon livre sur ce sujet: Essential PHP Security par Chris Shiflett .

Sécurité PHP essentielle http://shiflett.org/images/essential-php-security-small.png

Sur la page d'accueil du livre, vous trouverez des exemples de code intéressants et des exemples de chapitres.

You may use technique mentioned above (IP & UserAgent), described here: How to avoid identity theft

0
ajouté
+1 pour la prévention XSS. Sans cela, il est impossible de protéger contre CSRF, et donc quelqu'un peut "monter" la session sans même avoir l'ID de session.
ajouté l'auteur Kornel, source

Si vous vous utilisez session_set_save_handler() pouvez définir votre propre gestionnaire de session. Par exemple, vous pouvez stocker vos sessions dans la base de données. Reportez-vous aux commentaires de php.net pour des exemples d'un gestionnaire de session de base de données.

Les sessions DB sont également utiles si vous avez plusieurs serveurs. Si vous utilisez des sessions basées sur des fichiers, vous devez vous assurer que chaque serveur Web a accès au même système de fichiers pour lire / écrire les sessions.

0
ajouté

This session fixation paper has very good pointers where attack may come. See also session fixation page at Wikipedia.

0
ajouté

php.ini

session.cookie_httponly = 1
change session name from default PHPSESSID

eq Apache ajouter un en-tête:

X-XSS-Protection    1
0
ajouté
Sachez que X-XSS-Protection n'est pas vraiment utile du tout. En fait, l'algorithme de protection lui-même pourrait être exploité, ce qui le rendrait pire qu'avant.
ajouté l'auteur Pacerier, source
Peux-tu élaborer?
ajouté l'auteur domino, source
httpd.conf -> Jeu d'en-têtes X-XSS-Protection "1" </ FilesMatch>
ajouté l'auteur user956584, source

Le principal problème avec les sessions PHP et la sécurité (outre le détournement de session) vient de l'environnement dans lequel vous vous trouvez. Par défaut, PHP stocke les données de session dans un fichier du répertoire temporaire du système d'exploitation. Sans aucune réflexion ou planification particulière, il s'agit d'un répertoire lisible à l'échelle mondiale, de sorte que toutes vos informations de session sont publiques pour toute personne ayant accès au serveur.

Comme pour maintenir des sessions sur plusieurs serveurs. À ce stade, il serait préférable de basculer PHP vers des sessions gérées par l'utilisateur où il appelle vos fonctions fournies à CRUD (créer, lire, mettre à jour, supprimer) les données de session. À ce stade, vous pouvez stocker les informations de session dans une base de données ou une solution semblable à memcache afin que tous les serveurs d'applications aient accès aux données.

Le stockage de vos propres sessions peut également être avantageux si vous êtes sur un serveur partagé car il vous permettra de le stocker dans la base de données, ce qui vous permet souvent de mieux contrôler le système de fichiers.

0
ajouté

Vous devez vous assurer que les données de session sont sécurisées. En regardant votre php.ini ou en utilisant phpinfo (), vous pouvez trouver vos paramètres de session. _session.save_path_ vous indique où ils sont sauvegardés.

Vérifiez la permission du dossier et de ses parents. Il ne devrait pas être public (/ tmp) ou être accessible par d'autres sites sur votre serveur partagé.

En supposant que vous voulez toujours utiliser la session PHP, vous pouvez configurer PHP pour utiliser un autre dossier en changeant _session.save_path_ ou enregistrer les données dans la base de données en changeant _session.save_handler_.

Vous pourriez être en mesure de mettre _session.save_path_ dans votre php.ini (certains fournisseurs permettent) ou apache + mod_php, dans un fichier .htaccess dans votre dossier racine du site: php_value session.save_path "/home/example.com/html/session" . Vous pouvez également le définir lors de l'exécution avec _session_save_path() _.

Cochez Didacticiel de Chris Shiflett ou Zend_Session_SaveHandler_DbTable pour définir et gérer un autre gestionnaire de session.

0
ajouté

J'ai mis mes séances en place comme ça ...

sur la page de connexion:

$_SESSION['fingerprint'] = md5($_SERVER['HTTP_USER_AGENT'] . PHRASE . $_SERVER['REMOTE_ADDR']);

(phrase définie sur une page de configuration)

puis sur l'en-tête qui est dans le reste du site:

session_start();
if ($_SESSION['fingerprint'] != md5($_SERVER['HTTP_USER_AGENT'] . PHRASE . $_SERVER['REMOTE_ADDR'])) {       
    session_destroy();
    header('Location: http://website login page/');
    exit();     
}
0
ajouté