Le document présente des mesures de sécurité pour renforcer la sécurité des applications web côté client, y compris des recommandations comme l'utilisation des flags sécurisés pour les cookies, les en-têtes HSTS et le pinning des clés publiques. Il décrit également des protections contre les attaques telles que le session hijacking, l'injection de scripts et le clickjacking, tout en soulignant l'importance des bonnes pratiques de programmation sécurisée. Enfin, il conclut que ces contre-mesures sont essentielles pour les développeurs souhaitant améliorer la sécurité de leurs applications web.

1. S
4 contre-mesures pour
renforcer la sécurité de
son application web coté
client
Par Mohammed CHERIFI

2. A propos de moi
Mohammed CHERIFI
Consultant web, bloggeur et chercheur en sécurité informatique
Directeur de la société ConnectInLab
Co-organisateur de MCSC
Contact
http://www.mcherifi.org
mohammed@mcherifi.org

3. La sécurité du coté client

4. S
Sécuriser la
communication
Client/Serveur

5. Session hijacking
• Les communications à travers le protocol HTTP ne sont pas chiffrées
• Un attaquant peut facilement intercepter les échanges et inspecter les êntetes H
Problèmes
Problèmes courants:
• Usage mixé des protocole HTTP/HTTPS
• Par défaut les cookies sont transmises sur les deux protocoles
Solution
• Utiliser le flag “Secure” qui permet
d’envoyer le cookie via un canal crypté
Set-Cookie: PREF=foo-bar;
Domain=domain.ltd; Secure

6. Session hijacking - HSTS
• Envoyée sous forme d’entête HTTP
• Demande au navigateur de visiter le nom de domaine seulement en mode HTTP
• Permet de protéger optionnellement les sous domaines
Strict Transport Security
Compatibilité
Google Chrome 4+, Firefox 4+, Opera 12+

7. Public Key Pinning
S Envoyé sous forme d’une entête HTTP
S Envoie un fingerprint de la clé publique du certificat SSL au navigateur
S Le navigateur vérifie la signature du certificat pour détecter l’usage
d’un certificat frauduleux
S Actuellement un Internet-Draft de l’IETF
S Implémenté seulement dans Chrome 18+

8. Sécuriser la communication
Client/Serveur
S Secure flag for cookies to protect
cookies against leaking over HTTP
S Entête HSTS pour forcer la
navigation sécurisée
S « Public Key Pinning » pour se
protéger contre les certificats
frauduleux.
Contre-mesures :Attaques:
S Session hijacking
S SSL Stripping

9. S
Se protéger des attaques
par injection de scripts

10. Exemple d’attaque par
injection de script (XSS
persistante)

11. HttpOnly
S A attribuer lors de la création d’un cookie
S Permet de restreindre l’accès javascript
via DOM (document.cookie)
S A activer par défaut pour toutes les
informations sensibles
S Compatible avec tous les navigateurs
récents (Google
Chrome, Firefox, Internet Explorer, Safari
et Opera)

12. X-XSS-Protection
S Modes de fonctionnement:
S Protection par défaut
S X-XSS-Protection: 1
S Protection opt-out
S X-XSS-Protection: 0
S Mode blocage
S X-XSS-Protection: 1; mode=block
S interrompe le rendu de la page html
S Compatibilité:
S Internet Explorer 8+, Chrome and Safari

13. Content Security Policy (CSP)
S Fonctionnalités:
S Spécifier explicitement les ressources
autorisées d’accéder au DOM de la page
S Définir des règles spécifiques à travers
des directives.
S Intègre un système de reporting
permettant de notifier le webmaster du site
S Compatibilité:
S Internet Explorer 8+, Chrome and Safari

14. Content Security Policy (CSP)
S Directives CSP:
S default-src
S script-src
S object-src
S style-src
S img-src
S media-src
S frame-src
S font-src
S connect-src
S sandbox
S report-uri
Content-Security-Policy: script-src 'self'
https://apis.google.com; report-uri
http://example.org/my_amazing_csp_report_parser
{
"csp-report": {
"document-uri": "http://domain.ltd/page.html",
"referrer": "http://evil.domain.ltd/",
"blocked-uri": "http://evil.domain.ltd/evil.js",
"violated-directive": "script-src 'self' https://apis.google.com",
"original-policy": "script-src 'self' https://apis.google.com;
report- uri http://example.org/my_amazing_csp_report_parser"
}
Exemple de déploiement de CSP
Exemple de rapport de violation d’une règle

15. Content Security Policy (CSP)
reportOnly
S Mode Reporting:
S Permet de détecter les violation de règles
S Très pratique pour l’adaptation technique d’une application web
souhaitant profiter des avantages de CSP
S Ne renforce pas les règles (Policy)
Content-Security-Policy-Report-Only: default-src: 'none'; script-src 'self'; report- uri
/csp-reporting-handler.foo
Content-Security-Policy: script-src https://apis.google.com https://platform.twitter.com;
frame-src https://plusone.google.com https://facebook.com https://platform.twitter.com
Exemple de déploiement de du mode reportOnly
Exemple d’intégration des media sociaux

16. Se protéger des attaques par
injection de scripts
S Flag HttpOnly pour les
informations sensibles
S Entête X-XSS-Protection
S Content Security Policy (CSP)
Contre-mesures :Attaques:
S Crosse Site Scripting (XSS)
S Cross Site Request Forgery
(CSRF)

17. S
Sécuriser l’insertion de
contenu

18. Clickjacking
*Source: “Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular Sites” (W2SP
2010)

19. if (top.location != location) top.location =
self.location;
Contre-mesures classiques:
if (top.location != location) top.location =
self.location;
Clickjacking - X-Frame-Options
X-Frame-Options
• Permet d’indiquer au navigateur
par qui la page peut être
encapsulé dans un cadre
(iframe)
• Supporte 3 options
• DENY
• SAMEORIGIN
• ALLOW-FROM uri
• Compatibilité: tous les
navigateurs récents
• Limitation: Difficile d’isoler un
contenu non-légitime dans le
même « origin »

20. <iframe src= "/suspected-
path/index.html" sandbox></iframe>
Activation via l’attribut sandbox:
<iframe src="/suspected-path/index.html"
sandbox= "allow-scripts"></iframe>
Clickjacking – HTML5 sandbox
Comportement par défaut
• Les Plugins sont désactivés
• Chaque cadre (Frame) est
exécuté dans un contexte séparé
• Les scripts sont désactivés
• La soumission des formulaire
n’est pas autorisée
• Les contextes du haut niveau ne
peuvent pas être accédé par le
cadre en mode sandbox
• Les popups sont bloqué
• L’accès aux coordonnées et
position du curseur est restreint
Options de relaxation:
• allow-forms
• allow-popups
• allow-pointer-lock
• allow-same-origin
• allow-scripts
• allow-top-navigation
Exemple du mode relaxed:

21. Sécuriser l’insertion de
contenu
S Entête X-Frame-Options
S L’attribut HTML5 « sandbox » pour
les cadres (iframes)
Contre-mesures :Attaques:
S Clickjacking
S Cross Site Scripting (même
domaine)

22. S
Activer les intéractions
Cross-Domain

23. Interactions Cross-domain
S Problème:
S La directive « Same-Origin Policy » est très restrictive
S Technologies supportées:
S Cross Origin Resource Sharing (CORS)
S Crossdomain.xml
S Web Messaging (aka postMessage)

24. HTML5: security analysis

25. S
Conclusion
• Le web dispose actuellement d’une multitude de
fonctionnalités standardisées permettant de maitriser
les mécanismes d’isolations d’exécution, ainsi
permettant de renforcer d’avantage la sécurité des
applications web.
• Ces contre-mesures ne peuvent pas être qualifiés de
remplaçant des bonnes pratiques de programmation
sécurisée, il s’agit d’un guide complémentaire est
indispensable.
• Google, Twitter, Facebook ont déjà implémenté une
bonne partie de ces contre-mesures, leur maitrise est
un atout pour tout développeur web.

26. Initiateurs des contre-mesures
S Google (Sandbox)
S Microsoft (httpOnly, secure flag, X-XSS Header)
S Mozzila Fondation (Content Security Policy)
S W3C (spécifications HTML5)

27. Merci de votre attention