Explication graphique détaillée des précautions de sécurité de CodeIgniter en PHP

Cet article présente principalement les précautions de sécurité de codeigniter en PHP. Les amis intéressés peuvent s'y référer. J'espère qu'il sera utile à tout le monde.

1. httponly

la session doit être httponly, sinon elle peut être attaquée par xxs.

Vous devez utiliser le ci_session du framework, les chiffres plus longs, httponly, ils sont tous configurés par défaut.

N'utilisez pas la phpsession native, mais utilisez ci_session. les chiffres ci_session sont plus longs.

Si vous souhaitez utiliser la session native, vous devez la configurer comme ceci (php.ini) :

session.sid_length //La longueur du sid doit être allongé ici. La valeur par défaut est trop courte

session.cookie_httponly = 1La session native deviendra httponly.

2. phpinfo

Assurez-vous de fermer la page phpinfo, les informations de la demande de dump peuvent être utilisées par des attaquants. Tels que les informations sur les cookies.

3. https obligatoire pour l'ensemble du site

Passez par cdn, et l'environnement de développement local doit également être équipé de https. Si https ne peut pas être utilisé dans certains aspects, tels que le push de messages, vous pouvez créer un nouveau site.

4. Mode strict

session.use_strict_mode = 1

Utilisez uniquement l'identifiant de session généré par le serveur lui-même, et non l'identifiant de session généré par l'utilisateur client.

5. Falsification de demande intersite CSRF

Le cookie de A contient l'identifiant de session du site example.com et n'a pas expiré. passe Mettez une image sur le forum et incitez A à cliquer sur l'image. L'image lancera une demande, et la demande est déguisée en exemple.com. Le navigateur de A croit qu'elle est vraie et attache le cookie de exemple.com au. demande. Les informations de la demande sont que le code de B est intercepté et envoyé à B via une demande asynchrone. B se connecte au compte de A sur example.com via ce cookie.

CI dispose d'un mécanisme anti-CSRF, c'est-à-dire qu'il insérera automatiquement un champ CSRF masqué dans le formulaire. Les paramètres suivants sont requis :

application/config/config.php :

$config['csrf_protection'] = TRUE;

Notez qu'une fois cette option activée, toutes les requêtes vers des stations externes sont bloquées. Si notre site Web a pour comportement d'obtenir des données d'autres sites Web, par exemple en appelant une API, alors ce commutateur ne peut pas être activé.

6.

Tant que vous ajoutez un paramètre true, vous pouvez effectuer un filtrage XSS sur les données de publication.

$this->input->post('a',true);

7. Replay

Vous cryptez votre nom d'utilisateur et votre mot de passe et les envoyez au serveur pour vérification de connexion. Avec ces noms d'utilisateur et mots de passe, il lui suffit d'exploiter à nouveau les paquets de données interceptés pour se connecter. C'est la relecture.

Mesures de défense 5 et 6 : Chaque formulaire contient un jeton de code aléatoire caché qui ne peut être utilisé qu'une seule fois.

Implémentation unique du jeton : redis le supprime directement après l'expiration et l'utilise

8. Résumé : Processus de connexion sécurisé de l'utilisateur

<1>Stratégie de session de base :

(1) La session n'est qu'une session de session et deviendra invalide à la fermeture. le navigateur ;(2) Plus la durée de validité de la session est courte, plus elle est sûre, par exemple 60 secondes

(3) Le temps de rafraîchissement de la session doit être modifié en conséquence, par exemple, 30 secondes ;

(4) Configurer Redis pour stocker la session.

est configuré comme suit :

dans php.ini :

Il s'agit de la période de validité de la session. La valeur par défaut est de 1440 secondes, soit 24 minutes. Changez-la en, par exemple, 60 secondes. Après 60 secondes, si le SID du client correspond au SID du serveur, il sera invalide. La page doit être actualisée avant 60 secondes pour mettre à jour le SID. Comment mettre à jour est décrit ci-dessous ; > dans application/ config/config.php :

session.gc_maxlifetime = 60

<2> Actualisation de l'identifiant de session et distinction du délai d'expiration de la session :

Remarque :

Ces paramètres sont étroitement liés à la sécurité et doivent être distingués et utilisés avec précaution.

$config['sess_driver'] = 'redis';//设为用redis存储session
$config['sess_cookie_name'] = 'ci_session';
$config['sess_expiration'] = 0;//设为会话session，关闭浏览器，客户端cookie即失效
$config['sess_save_path'] = 'tcp://127.0.0.1:端口号';//redis地址
$config['sess_match_ip'] = FALSE;//要不要验证ip是否一致
$config['sess_time_to_update'] = 30;//超30秒即刷新sid
$config['sess_regenerate_destroy'] = TRUE;//重新生成sid的时候删除旧sid

Que signifie

session.gc_maxlifetime

ci-dessus ? C'est-à-dire le temps écoulé entre la génération d'une session et le moment où elle expire et ne peut plus être utilisée. En fait, si vous utilisez redis, ce sera clair. Cette valeur est une durée définie lors de l'utilisation de redis pour enregistrer le sid. Lorsqu'un sid est généré, cette heure sera écrite. atteint, cette valeur-clé sera supprimée.

Alors qu'en est-il de ce sess_time_to_update Comme son nom l'indique, il s'agit du temps de rafraîchissement. Ce temps est un seuil, ce qui signifie qu'il sera rafraîchi s'il dépasse ce temps. Il n'est pas rafraîchi automatiquement, mais rafraîchi lors de l'accès à la session ! Lorsque nous utilisons une session, cela déterminera l'intervalle entre la dernière session et cette heure. Si l'intervalle est supérieur à cette valeur, le sid sera actualisé. La performance habituelle de cette utilisation est que lorsque nous actualisons la page, nous devons lire la session pour l'authentification. Ensuite, lors de l'actualisation de la page, l'intervalle entre deux fois dépasse ce temps, c'est-à-dire actualiser le sid puis combiné avec le maxlifetime. ci-dessus, cela signifie que l'actualisation est terminée. Après cela, la session est renouvelée et une nouvelle session est écrite, ainsi qu'un minuteur redémarré.

C'est-à-dire que si nous rafraîchissons la page de temps en temps, notre mécanisme de rafraîchissement se déclenchera lorsque cela sera nécessaire, et alors notre session n'expirera pas, jamais si vous y brossez régulièrement. Si l'intervalle de temps entre deux actualisations dépasse maxlifetime, le délai de connexion sera affiché et la session sera terminée. Car si vous essayez de mettre à jour après l'expiration, cela ne fonctionnera évidemment pas et la mise à jour échouera.

Le résumé est que cette durée de vie maximale détermine la durée que nous ne pouvons pas dépasser entre deux actualisations, sinon la connexion expirera et la mise à jour doit être inférieure à la durée de vie maximale, ce qui est inévitable, car si elle est supérieure à celle-ci, elle sera invalide. L'actualisation est inutile car elle a expiré. Et de préférence, je pense que cette mise à jour devrait être inférieure à la moitié de la durée de vie maximale. Si maxlifetime est très long (dans l'espoir d'améliorer l'expérience utilisateur, il n'est toujours pas bon pour les utilisateurs de toujours se connecter et de se déconnecter), alors peu importe si la mise à jour est définie pour être plus courte, car si elle est définie pour être plus court, en supposant que la session soit volée, le risque sera plus grand. Il est possible que le voleur ait expiré lorsqu'il l'utilise, donc la sécurité sera plus élevée.

<2>jetons uniques :

Jeton unique

Ce qui précède représente l'intégralité du contenu de cet article, j'espère cela sera utile à l'apprentissage de chacun.

Recommandations associées :

PHPComment exécuter des commandes système via les fonctions de désactivation du contournement

Un résumé de l'utilisation des accolades "{}" en php

Envoyer à l'e-mail de PHP

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!