@ -138,7 +138,7 @@ Pour faciliter la description qui suit, nous allons d'abord introduire quelques
Un rôle représente une collection de *permissions* (p. ex. créer des articles, mettre des articles à jour). Un rôle peut être assigné à un ou plusieurs utilisateurs. Pour vérifier qu'un utilisateur dispose d'une permission spécifiée, nous pouvons vérifier si un rôle contenant cette permission a été assigné à l'utilisateur.
Associés à chacun des rôles, il peut y avoir une *règle*. Une règle représente un morceau de code à exécuter lors de l'accès pour vérifier si le rôle correspondant, ou la permission correspondante, s'applique à l'utilisateur courant. Par exemple, la permission «mettre un article à jour» peut disposer d'une règle qui vérifie si l'utilisateur courant est celui qui a créé l'article. Durant la vérification de l'accès, si l'utilisateur n'est PAS le créateur de l'article, il est considéré comme ne disposant pas la permission «mettre un article à jour».
Associée à chacun des rôles, il peut y avoir une *règle*. Une règle représente un morceau de code à exécuter lors de l'accès pour vérifier si le rôle correspondant, ou la permission correspondante, s'applique à l'utilisateur courant. Par exemple, la permission «mettre un article à jour» peut disposer d'une règle qui vérifie si l'utilisateur courant est celui qui a créé l'article. Durant la vérification de l'accès, si l'utilisateur n'est PAS le créateur de l'article, il est considéré comme ne disposant pas la permission «mettre un article à jour».
À la fois les rôles et les permissions peuvent être organisés en une hiérarchie. En particulier, un rôle peut être constitué d'autres rôles ou permissions; Yii met en œuvre une hiérarchie *d'ordre partiel* qui inclut la hiérarchie plus spécifique dite *en arbre*. Tandis qu'un rôle peut contenir une permission, l'inverse n'est pas vrai.
// ... ajoute les permissions en tant qu'enfant de $admin ...
```
Notez que dans ce qui est présenté ci-dessus, comme «author» est ajouté en tant qu'enfant de « admin», lorsque vus implémentez la méthode `execute()` de la classe de règle, vous devez respecter cette hiérarchie elle aussi. C'est pourquoi, le nom de rôle est «author», la méthode `execute()` retourne `true` (vrai) si le groupe de l'utilisateur est soit 1, soit 2 (ce qui signifie que l'utilisateur est soit dans le groupe «admin», soit dans le groupe «author»).
Notez que dans ce qui est présenté ci-dessus, comme «author» est ajouté en tant qu'enfant de « admin», lorsque vous implémentez la méthode `execute()` de la classe de règle, vous devez respecter cette hiérarchie elle aussi. C'est pourquoi,lorsque le nom de rôle est «author», la méthode `execute()` retourne `true` (vrai) si le groupe de l'utilisateur est soit 1, soit 2 (ce qui signifie que l'utilisateur est soit dans le groupe «admin», soit dans le groupe «author»).
Ensuite, configurez `authManager` en listant les deux rôles dans [[yii\rbac\BaseManager::$defaultRoles]]:
@ -123,7 +123,7 @@ Par exemple, un site web `an.example.com` a une URL `/logout`, qui, lorsqu'ell
C'est l'idée de base. D'aucuns diront que déconnecter un utilisateur n'a rien de très sérieux, mais les gens mal intentionnés peuvent faire bien plus, à partir de cette idée. Imaginez qu'un site web possède une URL `http://an.example.com/purse/transfer?to=anotherUser&amout=2000`. Accéder à cette URL en utilisant une requête GET, provoque le transfert de 2000€ d'un compte autorisé à l'utilisateur vers un autre compte `anotherUser`. Nous savons que le navigateur envoie toujours une requête GET pour charger une image. Nous pouvons donc modifier le code pour que seules des requêtes POST soient acceptées sur cette URL. Malheureusement, cela ne nous est pas d'un grand secours parce qu'un attaquant peut placer un peu le JavaScript à la place de la balise `<img>`, ce qui permet d'envoyer des requêtes POST sur cette URL:
Afin d'éviter le CSRF vous devez toujours:
Afin d'éviter la falsification des requêtes inter-sites vous devez toujours:
1. Suivre la spécification HTTP c.-à-d. GETne doit pas changer l'état de l'application.
2. Tenir la protection Yii CSRF activée.
@ -176,7 +176,7 @@ Si c'est le cas, n'oubliez-pas de refuser l'accès à tout sauf au dossier `web`
Éviter les informations et des outils de débogage en mode production
En mode débogage, Yii présente les erreurs de façon très verbeuse, ce qui s'avère très utile en développement. Le problème est que des erreurs aussi verbeuses sont pleines de renseignement pour l'attaquant lui aussi et peuvent révéler la structure de la base de données, les valeurs de configuration et des parties de votre code. Ne faites jamais tourner vos application avec `YII_DEBUG` définit à `true` dans votre fichier `index.php`.
En mode débogage, Yii présente les erreurs de façon très verbeuse, ce qui s'avère très utile en développement. Le problème est que des erreurs aussi verbeuses sont pleines de renseignement pour l'attaquant lui aussi et peuvent révéler la structure de la base de données, les valeurs de configuration et des parties de votre code. Ne faites jamais tourner vos applications avec `YII_DEBUG` définit à `true` dans votre fichier `index.php`.
Vous ne devriez jamais activer Gii en production. Il pourrait être utilisé pour obtenir des informations sur la structure de la base de données, sur le code et tout simplement réécrire du code avec celui généré par Gii.
Dans cette section nous allons passer en revue les aspects suivants relatifs à la sécurité:
- Génération de données aléatoires
- chiffrage et déchiffrage
- Chiffrage et déchiffrage
- Confirmation de l'intégrité des données
Génération de données pseudo-aléatoires
---------------------------------------
Les données pseudo-aléatoires sont utiles dans de nombreuses situations. Par exemple, lors de la réinitialisation d'un mot de passe via courriel, nout devez générer un jeton, le sauvegarder dans la base de données, et l'envoyer à l'utilisateur afin qu'il puisse prouver qu'il est le détenteur de compte concerné. Il est très important que ce jeton soit unique et difficile à deviner, sinon il y aurait une possibilité que l'attaquant le devine est réinitialise le mot de passe de l'utilisateur.
Les données pseudo-aléatoires sont utiles dans de nombreuses situations. Par exemple, lors de la réinitialisation d'un mot de passe via courriel, vous devez générer un jeton, le sauvegarder dans la base de données, et l'envoyer à l'utilisateur afin qu'il puisse prouver qu'il est le détenteur du compte concerné. Il est très important que ce jeton soit unique et difficile à deviner, sinon il y aurait une possibilité que l'attaquant le devine et réinitialise le mot de passe de l'utilisateur.
Les fonctions d'aide pour la sécurité de Yii facilite la création de données pseudo-aléatoires:
Les fonctions d'aide à la sécurité de Yii facilite la création de données pseudo-aléatoires:
Yii fournit des fonctions d'aide pratiques qui vous permettent de chiffrer/déchiffrer les données en utilisant une clé secrète. Les données sont passées à la fonction de chiffrage de façon à ce que, seule la personne qui possède la clé secrète soit en mesure de les déchiffré.
Yii fournit des fonctions d'aide pratiques qui vous permettent de chiffrer/déchiffrer les données en utilisant une clé secrète. Les données sont passées à la fonction de chiffrage de façon à ce que, seule la personne qui possède la clé secrète soit en mesure de les déchiffrer.
Par exemple, nous avons besoin de stocker quelques informations dans notre base de données mais nous avons besoin de garantir que seul l'utilisateur qui dispose de la clé secrète soit en mesure des les visualiser (même si la base de données de l'application est compromise):
@ -46,7 +46,7 @@ Il est également possible d'utiliser une clé à la place d'un mot de passe via
Confirmation de l'intégrité des données
---------------------------------------
Il y a des situations dans lesquelles vous avez besoint de vérifier que vos données n'ont pas été trafiquées par une tierce partie ou corrompue. Yii vous offre un moyen facile de confirmer l'intégrité des données sous forme d'une fonction d'aide.
Il y a des situations dans lesquelles vous avez besoin de vérifier que vos données n'ont pas été trafiquées par une tierce partie ou corrompue. Yii vous offre un moyen facile de confirmer l'intégrité des données sous forme d'une fonction d'aide.
Préfixez les données par une valeur de hachage obtenue à l'aide de la clé secrète et des données.
@ -56,7 +56,7 @@ Préfixez les données par une valeur de hachage obtenue à l'aide de la clé se
Une bonne sécurité est vitale pour la santé et le succès de toute application. Malheureusement, beaucoup de développeurs lésine un peu quand ils en arrivent à la sécurité, soit par manque de compréhension ou parce que sa mise en œuvre n'est pas une mince affaire. Pour rendre votre application Yii aussi sûre que possible, Yii inclut plusieurs fonctionnalités de sécurité, excellentes et faciles à mettre en œuvre.
Une bonne sécurité est vitale pour la santé et le succès de toute application. Malheureusement, beaucoup de développeurs lésinent un peu quand ils en arrivent à la sécurité, soit par manque de compréhension ou parce que sa mise en œuvre n'est pas une mince affaire. Pour rendre votre application Yii aussi sûre que possible, Yii inclut plusieurs fonctionnalités de sécurité, excellentes et faciles à mettre en œuvre.
La plupart des développeurs savent que les mots de passe ne peuvent pas être stockés «en clair», mais beaucoup d'entre-eux croient qu'il est toujours sûr des les hacher avec `md5` ou `sha1`. Il fut un temps où utiliser ces algorithmes de hachage était suffisant, mais les matériels modernes font qu'il est désormais possible de casser de tels hachages – même les plus robustes – très rapidement en utilisant des attaques en force brute.
Pour apporter une sécurité améliorée pour les mots de passe des utilisateurs, même dans le pire des scénario (une brèche est ouverte dans votre application), vous devez utiliser des algorithmes de hachage qui résistent aux attaques en force brute. Le choix le meilleur couramment utilisé est `bcrypt`.
En PHP, vous pouvez créer une valeur de hachage `bcrypt` à l'aide de la [fonction crypt](http://php.net/manual/en/function.crypt.php). Yii fournit deux fonctions d'aide qui facilitent l'utilisation de `crypt` pour générer et vérifier des valeurs de hachage de manière sure.
Quand un utilisateur fournit un mot de passe pour la première fois (p. ex. à l'enregistrement), le mot de passe doit être haché:
@ -13,7 +14,7 @@ Quand un utilisateur fournit un mot de passe pour la première fois (p. ex. à l
La valeur de hachage peut ensuite être associée à l'attribut du modèle correspondant afin de pouvoir être stocké dans la base de données pour utilisation ultérieure.
La valeur de hachage peut ensuite être associée à l'attribut du modèle correspondant afin de pouvoir être stockée dans la base de données pour utilisation ultérieure.
Lorsqu'un utilisateur essaye ensuite de se connecter, le mot de passe soumis est comparé au mot de passe précédemment haché et stocké:
José Fournier
8 years ago