Wiki du LAMA (UMR 5127) - Contributions [fr]

Faille CSRF

2018-11-25T19:19:24Z

Basset : /* Différentes méthodes d'attaque */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =

Le mécanisme des sessions '''est à l'origine''' de la faille CSRF.

Une session est un mécanisme technique permettant de sauvegarder temporairement sur le serveur des informations relatives à un internaute. A chaque ouverture de nouvelle session, l'internaute se voit attribué un identifiant de session.

Les sessions sont sauvegardées côté serveur et leurs identifications s'effectuent à l'aide des cookies.

En effet, si une victime (souvent un administrateur) a une '''session ouverte''' sur son site et que celui-ci est vulnérable alors il s'expose à des attaques.

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L'attaquant repère un '''site non protégé''' contre la faille CSRF : ''www.forum.com''

Il sait aussi que l’administrateur utilise cette URL pour supprimer un utilisateur :
''www.forum.com/index.php?profile=toto&action=supprimer''

L'attaquant utilise la faille CSRF qui consiste à rediriger l'administrateur vers cette page, et ainsi lui faire supprimer un utilisateur.

'''Pré-requis''' : l’administrateur doit être connecté sur le site vulnérable en même tant que l'attaque à lieu.

=== Différentes méthodes d'attaque ===

Une victime consulte '''un mail malveillant''' qui le redirige vers une action non consentie du site vulnérable :

[[Fichier:Mail-16.png]]

Une victime visite '''un site web malveillant''' qui le redirige vers une action non consentie du site vulnérable :

[[Fichier:Site-7.png]]

== Optimisation ==

Plusieurs optimisations et vérifications peuvent améliorer l’efficacité de l'attaque.

Prendre '''connaissance de la vulnérabilité''' du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et '''éviter d'être repéré''' avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois '''exemples d’opérations''' qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc '''l’usurpation d’identité et l’exécution d’actions malveillantes''' sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un '''délai d'expiration''' de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant '''gérée''' par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T18:45:39Z

Basset : /* Session */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =

Le mécanisme des sessions '''est à l'origine''' de la faille CSRF.

Une session est un mécanisme technique permettant de sauvegarder temporairement sur le serveur des informations relatives à un internaute. A chaque ouverture de nouvelle session, l'internaute se voit attribué un identifiant de session.

Les sessions sont sauvegardées côté serveur et leurs identifications s'effectuent à l'aide des cookies.

En effet, si une victime (souvent un administrateur) a une '''session ouverte''' sur son site et que celui-ci est vulnérable alors il s'expose à des attaques.

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L'attaquant repère un '''site non protégé''' contre la faille CSRF : ''www.forum.com''

Il sait aussi que l’administrateur utilise cette URL pour supprimer un utilisateur :
''www.forum.com/index.php?profile=toto&action=supprimer''

L'attaquant utilise la faille CSRF qui consiste à rediriger l'administrateur vers cette page, et ainsi lui faire supprimer un utilisateur.

'''Pré-requis''' : l’administrateur doit être connecté sur le site vulnérable en même tant que l'attaque à lieu.

=== Différentes méthodes d'attaque ===

Une victime consulte '''un mail malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Une victime visite '''un site web malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisations et vérifications peuvent améliorer l’efficacité de l'attaque.

Prendre '''connaissance de la vulnérabilité''' du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et '''éviter d'être repéré''' avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois '''exemples d’opérations''' qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc '''l’usurpation d’identité et l’exécution d’actions malveillantes''' sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un '''délai d'expiration''' de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant '''gérée''' par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T18:45:20Z

Basset : /* Session */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =

Le mécanisme des sessions '''est à l'origine''' de la faille CSRF.

Une session est un mécanisme technique permettant de sauvegarder temporairement sur le serveur des informations relatives à un internaute. A chaque ouverture de nouvelle session, l'internaute se voit attribué un identifiant de session.

Les sessions sont sauvegardées côté serveur et leurs identifications s'effectuent à l'aide des cookies.

En effet, si une '''victime''' (souvent un administrateur) a une session ouverte sur son site et que celui-ci est vulnérable alors il s'expose à des attaques.

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L'attaquant repère un '''site non protégé''' contre la faille CSRF : ''www.forum.com''

Il sait aussi que l’administrateur utilise cette URL pour supprimer un utilisateur :
''www.forum.com/index.php?profile=toto&action=supprimer''

L'attaquant utilise la faille CSRF qui consiste à rediriger l'administrateur vers cette page, et ainsi lui faire supprimer un utilisateur.

'''Pré-requis''' : l’administrateur doit être connecté sur le site vulnérable en même tant que l'attaque à lieu.

=== Différentes méthodes d'attaque ===

Une victime consulte '''un mail malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Une victime visite '''un site web malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisations et vérifications peuvent améliorer l’efficacité de l'attaque.

Prendre '''connaissance de la vulnérabilité''' du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et '''éviter d'être repéré''' avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois '''exemples d’opérations''' qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc '''l’usurpation d’identité et l’exécution d’actions malveillantes''' sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un '''délai d'expiration''' de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant '''gérée''' par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T18:45:03Z

Basset : /* Session */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =

Le mécanisme des sessions '''est à l'origine''' de la faille CSRF.

Une session est un mécanisme technique permettant de sauvegarder temporairement sur le serveur des informations relatives à un internaute. A chaque ouverture de nouvelle session, l'internaute se voit attribué un identifiant de session.

Les sessions sont sauvegardées côté serveur et leurs identifications s'effectuent à l'aide des cookies.

En effet, si une victime (souvent un administrateur) a une session ouverte sur son site et que celui-ci est vulnérable alors il s'expose à des attaques.

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L'attaquant repère un '''site non protégé''' contre la faille CSRF : ''www.forum.com''

Il sait aussi que l’administrateur utilise cette URL pour supprimer un utilisateur :
''www.forum.com/index.php?profile=toto&action=supprimer''

L'attaquant utilise la faille CSRF qui consiste à rediriger l'administrateur vers cette page, et ainsi lui faire supprimer un utilisateur.

'''Pré-requis''' : l’administrateur doit être connecté sur le site vulnérable en même tant que l'attaque à lieu.

=== Différentes méthodes d'attaque ===

Une victime consulte '''un mail malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Une victime visite '''un site web malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisations et vérifications peuvent améliorer l’efficacité de l'attaque.

Prendre '''connaissance de la vulnérabilité''' du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et '''éviter d'être repéré''' avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois '''exemples d’opérations''' qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc '''l’usurpation d’identité et l’exécution d’actions malveillantes''' sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un '''délai d'expiration''' de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant '''gérée''' par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T18:42:01Z

Basset : /* Session */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =

Le mécanisme des sessions '''est à l'origine''' de la faille CSRF.

Une session est un mécanisme technique permettant de sauvegarder temporairement sur le serveur des informations relatives à un internaute. A chaque ouverture de nouvelle session, l'internaute se voit attribué un identifiant de session.

Les sessions sont sauvegardées côté serveur et leurs identifications s'effectuent à l'aide des cookies.

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L'attaquant repère un '''site non protégé''' contre la faille CSRF : ''www.forum.com''

Il sait aussi que l’administrateur utilise cette URL pour supprimer un utilisateur :
''www.forum.com/index.php?profile=toto&action=supprimer''

L'attaquant utilise la faille CSRF qui consiste à rediriger l'administrateur vers cette page, et ainsi lui faire supprimer un utilisateur.

'''Pré-requis''' : l’administrateur doit être connecté sur le site vulnérable en même tant que l'attaque à lieu.

=== Différentes méthodes d'attaque ===

Une victime consulte '''un mail malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Une victime visite '''un site web malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisations et vérifications peuvent améliorer l’efficacité de l'attaque.

Prendre '''connaissance de la vulnérabilité''' du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et '''éviter d'être repéré''' avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois '''exemples d’opérations''' qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc '''l’usurpation d’identité et l’exécution d’actions malveillantes''' sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un '''délai d'expiration''' de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant '''gérée''' par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T18:41:29Z

Basset : /* Session */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =

Le mécanisme des sessions '''est à l'origine''' de la faille CSRF.

Une session est un mécanisme technique permettant de sauvegarder temporairement sur le serveur des informations relatives à un internaute. A chaque ouverture de nouvelle session, l'internaute se voit attribué un identifiant de session.

Les sessions sont sauvegardées côté serveur et leurs identifications s'effectuent à l'aide des cookies. Le serveur à la possibilité de crypter le contenu des sessions.

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L'attaquant repère un '''site non protégé''' contre la faille CSRF : ''www.forum.com''

Il sait aussi que l’administrateur utilise cette URL pour supprimer un utilisateur :
''www.forum.com/index.php?profile=toto&action=supprimer''

L'attaquant utilise la faille CSRF qui consiste à rediriger l'administrateur vers cette page, et ainsi lui faire supprimer un utilisateur.

'''Pré-requis''' : l’administrateur doit être connecté sur le site vulnérable en même tant que l'attaque à lieu.

=== Différentes méthodes d'attaque ===

Une victime consulte '''un mail malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Une victime visite '''un site web malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisations et vérifications peuvent améliorer l’efficacité de l'attaque.

Prendre '''connaissance de la vulnérabilité''' du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et '''éviter d'être repéré''' avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois '''exemples d’opérations''' qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc '''l’usurpation d’identité et l’exécution d’actions malveillantes''' sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un '''délai d'expiration''' de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant '''gérée''' par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T18:41:05Z

Basset : /* Session */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =

Le mécanisme des sessions est à l'origine de la faille CSRF.

Une session est un mécanisme technique permettant de sauvegarder temporairement sur le serveur des informations relatives à un internaute. A chaque ouverture de nouvelle session, l'internaute se voit attribué un identifiant de session.

Les sessions sont sauvegardées côté serveur et leurs identifications s'effectuent à l'aide des cookies. Le serveur à la possibilité de crypter le contenu des sessions.

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L'attaquant repère un '''site non protégé''' contre la faille CSRF : ''www.forum.com''

Il sait aussi que l’administrateur utilise cette URL pour supprimer un utilisateur :
''www.forum.com/index.php?profile=toto&action=supprimer''

L'attaquant utilise la faille CSRF qui consiste à rediriger l'administrateur vers cette page, et ainsi lui faire supprimer un utilisateur.

'''Pré-requis''' : l’administrateur doit être connecté sur le site vulnérable en même tant que l'attaque à lieu.

=== Différentes méthodes d'attaque ===

Une victime consulte '''un mail malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Une victime visite '''un site web malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisations et vérifications peuvent améliorer l’efficacité de l'attaque.

Prendre '''connaissance de la vulnérabilité''' du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et '''éviter d'être repéré''' avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois '''exemples d’opérations''' qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc '''l’usurpation d’identité et l’exécution d’actions malveillantes''' sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un '''délai d'expiration''' de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant '''gérée''' par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T18:33:25Z

Basset : /* Session */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =

Une session est un mécanisme technique permettant de sauvegarder temporairement sur le serveur des informations relatives à un internaute. A chaque ouverture de nouvelle session, l'internaute se voit attribué un identifiant de session.

Les sessions sont sauvegardées côté serveur et leurs identifications s'effectuent à l'aide des cookies. Le serveur à la possibilité de crypter le contenu des sessions.

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L'attaquant repère un '''site non protégé''' contre la faille CSRF : ''www.forum.com''

Il sait aussi que l’administrateur utilise cette URL pour supprimer un utilisateur :
''www.forum.com/index.php?profile=toto&action=supprimer''

L'attaquant utilise la faille CSRF qui consiste à rediriger l'administrateur vers cette page, et ainsi lui faire supprimer un utilisateur.

'''Pré-requis''' : l’administrateur doit être connecté sur le site vulnérable en même tant que l'attaque à lieu.

=== Différentes méthodes d'attaque ===

Une victime consulte '''un mail malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Une victime visite '''un site web malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisations et vérifications peuvent améliorer l’efficacité de l'attaque.

Prendre '''connaissance de la vulnérabilité''' du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et '''éviter d'être repéré''' avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois '''exemples d’opérations''' qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc '''l’usurpation d’identité et l’exécution d’actions malveillantes''' sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un '''délai d'expiration''' de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant '''gérée''' par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T18:27:19Z

Basset : /* Session */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =

Une session est un mécanisme technique permettant de sauvegarder temporairement sur le serveur des informations relatives à un internaute. A chaque ouverture de nouvelle session, l'internaute se voit attribué un identifiant de session.

Elle stocke donc l’état d’un client sur un site web.

* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L'attaquant repère un '''site non protégé''' contre la faille CSRF : ''www.forum.com''

Il sait aussi que l’administrateur utilise cette URL pour supprimer un utilisateur :
''www.forum.com/index.php?profile=toto&action=supprimer''

L'attaquant utilise la faille CSRF qui consiste à rediriger l'administrateur vers cette page, et ainsi lui faire supprimer un utilisateur.

'''Pré-requis''' : l’administrateur doit être connecté sur le site vulnérable en même tant que l'attaque à lieu.

=== Différentes méthodes d'attaque ===

Une victime consulte '''un mail malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Une victime visite '''un site web malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisations et vérifications peuvent améliorer l’efficacité de l'attaque.

Prendre '''connaissance de la vulnérabilité''' du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et '''éviter d'être repéré''' avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois '''exemples d’opérations''' qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc '''l’usurpation d’identité et l’exécution d’actions malveillantes''' sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un '''délai d'expiration''' de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant '''gérée''' par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T18:15:39Z

Basset : /* Exemple d'attaque */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L'attaquant repère un '''site non protégé''' contre la faille CSRF : ''www.forum.com''

Il sait aussi que l’administrateur utilise cette URL pour supprimer un utilisateur :
''www.forum.com/index.php?profile=toto&action=supprimer''

L'attaquant utilise la faille CSRF qui consiste à rediriger l'administrateur vers cette page, et ainsi lui faire supprimer un utilisateur.

'''Pré-requis''' : l’administrateur doit être connecté sur le site vulnérable en même tant que l'attaque à lieu.

=== Différentes méthodes d'attaque ===

Une victime consulte '''un mail malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Une victime visite '''un site web malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisations et vérifications peuvent améliorer l’efficacité de l'attaque.

Prendre '''connaissance de la vulnérabilité''' du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et '''éviter d'être repéré''' avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois '''exemples d’opérations''' qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc '''l’usurpation d’identité et l’exécution d’actions malveillantes''' sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un '''délai d'expiration''' de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant '''gérée''' par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T18:14:36Z

Basset : /* Exemple d'attaque */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L'attaquant repère un '''site non protégé''' contre la faille CSRF : ''www.forum.com''

Il sait aussi que l’administrateur utilise cette URL pour supprimer un utilisateur :
''www.forum.com/index.php?profile=toto&action=supprimer''

L'attaquant utilise la faille CSRF qui consiste à rediriger l'administrateur vers cette page, et ainsi lui faire supprimer un utilisateur.

'''Pré-requis''' : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Une victime consulte '''un mail malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Une victime visite '''un site web malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisations et vérifications peuvent améliorer l’efficacité de l'attaque.

Prendre '''connaissance de la vulnérabilité''' du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et '''éviter d'être repéré''' avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois '''exemples d’opérations''' qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc '''l’usurpation d’identité et l’exécution d’actions malveillantes''' sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un '''délai d'expiration''' de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant '''gérée''' par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T18:14:02Z

Basset : /* Exemple d'attaque */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L'attaquant repère un '''site non protégé''' contre la faille CSRF : ''www.forum.com''

Il sait aussi que l’administrateur utilise cette URL pour supprimer un utilisateur :
''www.forum.com/index.php?profile=toto&action=supprimer''

L'attaquant utilise la faille CSRF qui consiste à rediriger l'administrateur vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Une victime consulte '''un mail malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Une victime visite '''un site web malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisations et vérifications peuvent améliorer l’efficacité de l'attaque.

Prendre '''connaissance de la vulnérabilité''' du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et '''éviter d'être repéré''' avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois '''exemples d’opérations''' qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc '''l’usurpation d’identité et l’exécution d’actions malveillantes''' sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un '''délai d'expiration''' de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant '''gérée''' par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T18:05:15Z

Basset : /* Conclusion */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Une victime consulte '''un mail malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Une victime visite '''un site web malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisations et vérifications peuvent améliorer l’efficacité de l'attaque.

Prendre '''connaissance de la vulnérabilité''' du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et '''éviter d'être repéré''' avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois '''exemples d’opérations''' qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc '''l’usurpation d’identité et l’exécution d’actions malveillantes''' sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un '''délai d'expiration''' de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant '''gérée''' par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:55:27Z

Basset : /* Protection */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Une victime consulte '''un mail malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Une victime visite '''un site web malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisations et vérifications peuvent améliorer l’efficacité de l'attaque.

Prendre '''connaissance de la vulnérabilité''' du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et '''éviter d'être repéré''' avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois '''exemples d’opérations''' qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc '''l’usurpation d’identité et l’exécution d’actions malveillantes''' sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un '''délai d'expiration''' de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant gérée par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:55:14Z

Basset : /* Risque */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Une victime consulte '''un mail malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Une victime visite '''un site web malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisations et vérifications peuvent améliorer l’efficacité de l'attaque.

Prendre '''connaissance de la vulnérabilité''' du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et '''éviter d'être repéré''' avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois '''exemples d’opérations''' qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc '''l’usurpation d’identité et l’exécution d’actions malveillantes''' sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant gérée par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:54:41Z

Basset : /* Optimisation */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Une victime consulte '''un mail malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Une victime visite '''un site web malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisations et vérifications peuvent améliorer l’efficacité de l'attaque.

Prendre '''connaissance de la vulnérabilité''' du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et '''éviter d'être repéré''' avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant gérée par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:54:14Z

Basset : /* Différentes méthodes d'attaque */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Une victime consulte '''un mail malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Une victime visite '''un site web malveillant''' qui le redirige vers une action non consentie du site vulnérable :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisations et vérifications peuvent améliorer l’efficacité de l'attaque.

Prendre connaissance de la vulnérabilité du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et éviter d'être repéré avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant gérée par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:53:24Z

Basset : /* Différentes méthodes d'attaque */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Attaquer la victime en mettant la requête illégitime dans un '''mail''' :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Attaquer la victime en mettant lançant la requête depuis un '''site malveillant''' :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisations et vérifications peuvent améliorer l’efficacité de l'attaque.

Prendre connaissance de la vulnérabilité du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et éviter d'être repéré avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant gérée par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:52:32Z

Basset : /* Optimisation */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Attaquer la victime en mettant la requête illégitime dans un mail :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisations et vérifications peuvent améliorer l’efficacité de l'attaque.

Prendre connaissance de la vulnérabilité du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et éviter d'être repéré avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant gérée par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:52:04Z

Basset : /* Introduction */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté. Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Attaquer la victime en mettant la requête illégitime dans un mail :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisation et vérification peuvent améliorer l’efficacité de l'attaque.

Prendre connaissance de la vulnérabilité du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et éviter d'être repéré avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant gérée par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:50:19Z

Basset : /* Introduction */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("'''Cross site request forgery'''") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.

Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Attaquer la victime en mettant la requête illégitime dans un mail :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisation et vérification peuvent améliorer l’efficacité de l'attaque.

Prendre connaissance de la vulnérabilité du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et éviter d'être repéré avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant gérée par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:49:36Z

Basset : /* Introduction */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.

Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Attaquer la victime en mettant la requête illégitime dans un mail :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisation et vérification peuvent améliorer l’efficacité de l'attaque.

Prendre connaissance de la vulnérabilité du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et éviter d'être repéré avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant gérée par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:49:23Z

Basset : /* Introduction */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites.

Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Attaquer la victime en mettant la requête illégitime dans un mail :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisation et vérification peuvent améliorer l’efficacité de l'attaque.

Prendre connaissance de la vulnérabilité du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et éviter d'être repéré avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant gérée par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:49:10Z

Basset : /* Introduction */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.

Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Attaquer la victime en mettant la requête illégitime dans un mail :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisation et vérification peuvent améliorer l’efficacité de l'attaque.

Prendre connaissance de la vulnérabilité du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et éviter d'être repéré avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant gérée par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:48:19Z

Basset : /* Introduction */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Attaquer la victime en mettant la requête illégitime dans un mail :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisation et vérification peuvent améliorer l’efficacité de l'attaque.

Prendre connaissance de la vulnérabilité du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et éviter d'être repéré avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant gérée par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:48:08Z

Basset : /* Faille CSRF */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Attaquer la victime en mettant la requête illégitime dans un mail :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisation et vérification peuvent améliorer l’efficacité de l'attaque.

Prendre connaissance de la vulnérabilité du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et éviter d'être repéré avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant gérée par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:43:17Z

Basset : /* Conclusion */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

== Attaque ==

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Attaquer la victime en mettant la requête illégitime dans un mail :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisation et vérification peuvent améliorer l’efficacité de l'attaque.

Prendre connaissance de la vulnérabilité du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et éviter d'être repéré avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant gérée par la plupart des frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et où le développeur n'a pas ajouté pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:42:08Z

Basset : /* Conclusion */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

== Attaque ==

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Attaquer la victime en mettant la requête illégitime dans un mail :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisation et vérification peuvent améliorer l’efficacité de l'attaque.

Prendre connaissance de la vulnérabilité du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et éviter d'être repéré avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

La faille CSRF est maintenant gérée sur les frameworks d'applications web modernes (Laravel, Yii2 ...).

Elle reste quand même présente sur des sites développées sans framework et si le développeur n'ajoute pas les protections nécessaires.

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:32:48Z

Basset : /* Différentes méthodes d'attaque */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

== Attaque ==

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Attaquer la victime en mettant la requête illégitime dans un mail :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisation et vérification peuvent améliorer l’efficacité de l'attaque.

Prendre connaissance de la vulnérabilité du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et éviter d'être repéré avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:29:00Z

Basset :

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

== Attaque ==

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Attaquer la victime en mettant la requête illégitime dans un mail :

<div style="text-align:center;">[[Fichier:Mail-16.png]]</div>

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

<div style="text-align:center;">[[Fichier:Site-7.png]]</div>

== Optimisation ==

Plusieurs optimisation et vérification peuvent améliorer l’efficacité de l'attaque.

Prendre connaissance de la vulnérabilité du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et éviter d'être repéré avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:25:25Z

Basset : /* Faille CSRF */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

== Attaque ==

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Attaquer la victime en mettant la requête illégitime dans un mail :

[[Fichier:Mail-16.png]]

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

[[Fichier:Site-7.png]]

== Optimisation ==

Plusieurs optimisation et vérification peuvent améliorer l’efficacité de l'attaque.

Prendre connaissance de la vulnérabilité du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et éviter d'être repéré avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:23:07Z

Basset : /* Attaque */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

=== Exemple d'attaque ===

L’administrateur utilise cette URL pour supprimer un utilisateur :
www.forum.com/index.php?profile=toto&action=supprimer

La faille CSRF consiste à le rediriger vers cette page, et ainsi lui faire supprimer un utilisateur.

Pré-requis : l’administrateur doit être connecté sur le site vulnérable.

=== Différentes méthodes d'attaque ===

Attaquer la victime en mettant la requête illégitime dans un mail :

[[Fichier:Mail-16.png]]

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

[[Fichier:Site-7.png]]

== Optimisation ==

Plusieurs optimisation et vérification peuvent améliorer l’efficacité de l'attaque.

Prendre connaissance de la vulnérabilité du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et éviter d'être repéré avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T17:19:55Z

Basset : /* Optimisation */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

Attaquer la victime en mettant la requête illégitime dans un mail :

[[Fichier:Mail-16.png]]

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

[[Fichier:Site-7.png]]

== Optimisation ==

Plusieurs optimisation et vérification peuvent améliorer l’efficacité de l'attaque.

Prendre connaissance de la vulnérabilité du site attaqué :

* Vérifier l'absence de token dans les formulaires
* Connaître les routes sensibles du sites

Cacher les liens malveillant et éviter d'être repéré avant l'attaque :
* Utiliser des redirections
* Utiliser des appels AJAX

AJAX cache totalement l’action malveillante pour un utilisateur lambda. Le CORS du site victime doit autoriser les noms de domaines étrangers.

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T14:54:30Z

Basset : /* Exemples */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

Attaquer la victime en mettant la requête illégitime dans un mail :

[[Fichier:Mail-16.png]]

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

[[Fichier:Site-7.png]]

== Optimisation ==

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

[[Fichier:mcafee.png]] '''McAfee''', la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Fichier:Mcafee.png

2018-11-25T14:53:50Z

Basset :

Faille CSRF

2018-11-25T14:52:13Z

Basset : /* Exemples */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

Attaquer la victime en mettant la requête illégitime dans un mail :

[[Fichier:Mail-16.png]]

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

[[Fichier:Site-7.png]]

== Optimisation ==

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] '''YouTube en 2008''', la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

McAfee, la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T14:52:03Z

Basset : /* Exemples */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

Attaquer la victime en mettant la requête illégitime dans un mail :

[[Fichier:Mail-16.png]]

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

[[Fichier:Site-7.png]]

== Optimisation ==

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

[[Fichier:youtube.png]] YouTube en 2008, la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

McAfee, la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Fichier:Youtube.png

2018-11-25T14:51:22Z

Basset :

Faille CSRF

2018-11-25T14:49:29Z

Basset : /* Exemples */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

Attaquer la victime en mettant la requête illégitime dans un mail :

[[Fichier:Mail-16.png]]

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

[[Fichier:Site-7.png]]

== Optimisation ==

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]] '''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

YouTube en 2008, la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

McAfee, la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T14:49:05Z

Basset : /* Exemples */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

Attaquer la victime en mettant la requête illégitime dans un mail :

[[Fichier:Mail-16.png]]

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

[[Fichier:Site-7.png]]

== Optimisation ==

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

[[Fichier:ing.png]]'''L'application Web de banque en ligne d'ING Direct''', la faille permettait :
* des transferts d'argent illicites

YouTube en 2008, la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

McAfee, la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Fichier:Ing.png

2018-11-25T14:48:28Z

Basset :

Faille CSRF

2018-11-25T14:45:42Z

Basset : /* Protection */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

Attaquer la victime en mettant la requête illégitime dans un mail :

[[Fichier:Mail-16.png]]

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

[[Fichier:Site-7.png]]

== Optimisation ==

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

L'application Web de banque en ligne d'ING Direct, la faille permettait :
* des transferts d'argent illicites

YouTube en 2008, la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

McAfee, la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger '''leurs utilisateurs'''.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T14:45:31Z

Basset : /* Protection */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

Attaquer la victime en mettant la requête illégitime dans un mail :

[[Fichier:Mail-16.png]]

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

[[Fichier:Site-7.png]]

== Optimisation ==

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

L'application Web de banque en ligne d'ING Direct, la faille permettait :
* des transferts d'argent illicites

YouTube en 2008, la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

McAfee, la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger leurs utilisateurs.

La façon la plus répandue étant l'utilisation d'un '''jeton''' (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le '''token''' dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T14:45:02Z

Basset : /* Exemples */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

Attaquer la victime en mettant la requête illégitime dans un mail :

[[Fichier:Mail-16.png]]

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

[[Fichier:Site-7.png]]

== Optimisation ==

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006''', la faille permettait :
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

L'application Web de banque en ligne d'ING Direct, la faille permettait :
* des transferts d'argent illicites

YouTube en 2008, la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

McAfee, la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger leurs utilisateurs.

La façon la plus répandue étant l'utilisation d'un jeton (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le token dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T14:44:47Z

Basset : /* Exemples */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

Attaquer la victime en mettant la requête illégitime dans un mail :

[[Fichier:Mail-16.png]]

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

[[Fichier:Site-7.png]]

== Optimisation ==

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006, la faille permettait :'''
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

L'application Web de banque en ligne d'ING Direct, la faille permettait :
* des transferts d'argent illicites

YouTube en 2008, la faille permettait :
* de réaliser presque toutes les actions de tout utilisateur.

McAfee, la faille permettait :
* de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger leurs utilisateurs.

La façon la plus répandue étant l'utilisation d'un jeton (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le token dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T14:43:51Z

Basset : /* Exemples */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

Attaquer la victime en mettant la requête illégitime dans un mail :

[[Fichier:Mail-16.png]]

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

[[Fichier:Site-7.png]]

== Optimisation ==

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :

[[Fichier:netflix.png]] '''Netflix en 2006 :'''
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

L'application Web de banque en ligne d'ING Direct :
* permettait des transferts d'argent illicites

YouTube en 2008 :
* permettait de réaliser presque toutes les actions de tout utilisateur.

McAfee :
* permettait de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger leurs utilisateurs.

La façon la plus répandue étant l'utilisation d'un jeton (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le token dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T14:43:44Z

Basset : /* Exemples */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

Attaquer la victime en mettant la requête illégitime dans un mail :

[[Fichier:Mail-16.png]]

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

[[Fichier:Site-7.png]]

== Optimisation ==

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

Les 4 exemples réels ci-dessous montre les possibilités qu'offre cette faille :
[[Fichier:netflix.png]] '''Netflix en 2006 :'''
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

L'application Web de banque en ligne d'ING Direct :
* permettait des transferts d'argent illicites

YouTube en 2008 :
* permettait de réaliser presque toutes les actions de tout utilisateur.

McAfee :
* permettait de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger leurs utilisateurs.

La façon la plus répandue étant l'utilisation d'un jeton (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le token dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T14:42:02Z

Basset : /* Exemples */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

Attaquer la victime en mettant la requête illégitime dans un mail :

[[Fichier:Mail-16.png]]

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

[[Fichier:Site-7.png]]

== Optimisation ==

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

[[Fichier:netflix.png]] '''Netflix en 2006 :'''
* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

L'application Web de banque en ligne d'ING Direct :
* permettait des transferts d'argent illicites

YouTube en 2008 :
* permettait de réaliser presque toutes les actions de tout utilisateur.

McAfee :
* permettait de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger leurs utilisateurs.

La façon la plus répandue étant l'utilisation d'un jeton (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le token dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Faille CSRF

2018-11-25T14:41:44Z

Basset : /* Exemples */

Auteurs : Victor BASSET et Vincent PEILLEX

= Introduction =
= Session =
* Stocke l’état d’un client sur un site web
* Identification de la session avec des cookies
* Sessions sauvegardées côté serveur
* Un cookie est configuré pour être envoyé sur un ou plusieurs domaine
* Possibilité de générer un nouvel id pour chaque requête (exemple : Laravel)
* Possibilité de crypter le contenu des sessions sur le serveur de stockage (utile si on on utilise un autre serveur pour le stockage

= Faille CSRF =

== Attaque ==

La faille CSRF ("Cross site request forgery") qui, si l’on essaie de donner une définition en français, signifie Falsification de requête inter-sites. Elle cherche à faire exécuter des actions directement sur l’ordinateur de la victime à son insu.
Cette faille est compatible avec n'importe quel site, pour peu que vous y soyez connecté.
Elle demande à celui qui l'exploite de connaître les liens utilisés par la victime.

Attaquer la victime en mettant la requête illégitime dans un mail :

[[Fichier:Mail-16.png]]

Attaquer la victime en mettant lançant la requête depuis un site malveillant :

[[Fichier:Site-7.png]]

== Optimisation ==

== Risque ==

Le risque est inhérent au site visité par la victime puisque le CSRF consiste à effectuer des opérations sur un site sans le consentement de l’utilisateur et à son insu.

Voici trois exemples d’opérations qui étaient possibles par un attaquant sur des sites ou produits connus et vulnérables :

* opérations à l’insu de l’utilisateur sur un site bancaire (par exemple, virement d’argent vers un autre compte) ;

* changement de la configuration du routeur WiFi de la victime (via l’interface d’administration web accessible en réseau local) ;

* changement de la configuration d’un webmail (notamment, l’ajout de filtres pour transmettre automatiquement les courriels reçus à une autre adresse).

Le risque principal est donc l’usurpation d’identité et l’exécution d’actions malveillantes sur un site.

== Exemples ==

Cette faille a touché plusieurs sites connus durant la première décennie des années 2000.
Aujourd'hui la faille est mieux protégée mais elle est malheureusement encore présente sur la toile.

'''Netflix en 2006 :''' [[Fichier:netflix.png]]

* l'ajout d'un DVD à la file d'attente de location de la victime
* la modification de l'adresse de livraison sur le compte
* la modification des informations d'identification de la victime

L'application Web de banque en ligne d'ING Direct :
* permettait des transferts d'argent illicites

YouTube en 2008 :
* permettait de réaliser presque toutes les actions de tout utilisateur.

McAfee :
* permettait de modifier le système de leur entreprise.

== Protection ==

Le CSRF est une attaque contre les visiteurs d’un site et non contre le site lui-même. Les moyens de protection pour les développeurs servent donc à protéger leurs utilisateurs.

La façon la plus répandue étant l'utilisation d'un jeton (token) unique en session qui sera vérifié à chaque modification, ici un exemple en PHP :
<pre>
<?php
$token = bin2hex(mcrypt_create_iv(32, MCRYPT_DEV_URANDOM));
$_SESSION['token'] = $token;
?>
</pre>

Il suffit ensuite d'ajouter le token dans chaque requête envoyée au serveur.

Ici un formulaire HTML où l'on a ajouté le token qui doit être le même que celui en session :
<pre>
<form>

<input type="text" name="pseudo" id="pseudo" />
<input type="submit" value="valider" />


<input type="hidden" name="token" value="<?php echo $token; ?>" />
</form>
</pre>

Puis côté serveur, avant chaque modification, on vérifie que le token en session et celui du formulaire sont égaux :
<pre>
// On vérifie que les deux token correspondent
if ($_SESSION['token'] == $_POST['token']) {
// Vérification terminée
// On peut supprimer l'utilisateur
}
</pre>

On peut améliorer la protection par token avec l'ajout d'un délai d'expiration de celui-ci (10 min).

= Conclusion =

=Sources=

https://openclassrooms.com/fr/courses/2091901-protegez-vous-efficacement-contre-les-failles-web/2863569-la-csrf

https://www.cert.ssi.gouv.fr/information/CERTA-2008-INF-003/

https://www.leblogduhacker.fr/sandbox/csrf.php?#.W-gXIXVKgqo

https://en.wikipedia.org/wiki/Cross-site_request_forgery#Example_and_characteristics

Fichier:Netflix.png

2018-11-25T14:41:04Z

Basset : Basset a téléversé une nouvelle version de Fichier:Netflix.png