Ma présentation lors de la journée de la sécurité informatique organisée à l'université internationale d'Agadir Univerpolis sous le thème : « enjeux et défis universels ». la conférence s'est déroulée le Samedi 18 Mai 2013

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