par
Saian » 27 mai 2019, 19:32
Très bien, donc lors du login, tu dois forcément rechercher la ligne du membre dans la table membre pour contrôler le mot de passe et donc ce que tu dois faire, c'est récupérer son id à ce moment là et le stocker dans la session. Ainsi lorsque tu as besoin de l'id du membre il te suffit de le récupérer dans la session et l'id ne transite jamais dans les requêtes http. Impossible pour l'utilisateur de modifier l'id.
Après une session peut être volée mais c'est pas à la porté de n'importe qui. Le HTTPS reste la meilleur protection contre ce type d'attaque. Dans ce cas, seul un man on the middle pourra voler la session à condition d'être présent dès le premier échange entre le client et le serveur. Dans le cas contraire il ne sera pas capable de décrypter à la volée les données échangées. Sinon à part en piratant directement le terminal du visiteur le pirate ne peut plus faire grand chose. Le vole de session pouvait être relativement simple il y a quelques années quand on passait l'id de session dans l'url mais aujourd'hui les serveurs sont bien configurés pour éviter ce genre d'attaque.
Ensuite il ne te reste plus qu'à gérer les attaque XSS et CSRF.
Il y a aussi les injections SQL mais si tu prépares bien les requêtes tu n'as normalement pas à t'en inquiéter.
En fait le principe est de toujours appliquer les règles de sécurité avec les données fournies par le client.
Très bien, donc lors du login, tu dois forcément rechercher la ligne du membre dans la table membre pour contrôler le mot de passe et donc ce que tu dois faire, c'est récupérer son id à ce moment là et le stocker dans la session. Ainsi lorsque tu as besoin de l'id du membre il te suffit de le récupérer dans la session et l'id ne transite jamais dans les requêtes http. Impossible pour l'utilisateur de modifier l'id. ;)
Après une session peut être volée mais c'est pas à la porté de n'importe qui. Le HTTPS reste la meilleur protection contre ce type d'attaque. Dans ce cas, seul un man on the middle pourra voler la session à condition d'être présent dès le premier échange entre le client et le serveur. Dans le cas contraire il ne sera pas capable de décrypter à la volée les données échangées. Sinon à part en piratant directement le terminal du visiteur le pirate ne peut plus faire grand chose. Le vole de session pouvait être relativement simple il y a quelques années quand on passait l'id de session dans l'url mais aujourd'hui les serveurs sont bien configurés pour éviter ce genre d'attaque.
Ensuite il ne te reste plus qu'à gérer les attaque XSS et CSRF.
Il y a aussi les injections SQL mais si tu prépares bien les requêtes tu n'as normalement pas à t'en inquiéter.
En fait le principe est de toujours appliquer les règles de sécurité avec les données fournies par le client.