Sécurité du transport
Une connexion chiffrée par HTTPS (HTTP+TLS) est le seul moyen de garantir
- Confidentialité : aucun espion peut lire la communication ;
- Authenticité : on parle bien au bon serveur ;
- Intégrité : les requêtes et les réponses HTTP n’ont pas été modifiées.
Mixed content
Lorsque un navigateur rencontre un contenu non-HTTPS dans une page HTTPS :
- Donne un avertissement pour les contenus passifs (images, audio, video, …)
- Bloque la requête pour les contenus actifs (scripts, iframes, AJAX, …)
Strict transport security
L’entête
Strict-Transport-Security
interdit de déclasser en HTTP une page servie à l’origine par HTTPS.
Strict-Transport-Security: max-age=3600
Subresource integrity
Objectif : empêcher les fournisseurs (par ex., un CDN) et les intermédiaires de remplacer des contenus (scripts, feuilles de style).
- Attribut
integrity
sur les balisesscript
oulink
. - Valeur :
sha256-
,sha384-
, ousha512-
,- plus le haché de la ressource codé en base64 ;
<script src="https://example.com/script.js"
integrity="sha256-VNUJvFEYSnn/xZL+dv3c8LEmHNL57wC1DzH5sC6M/m8=">
</script>
Interdit le chargement de la ressource si le haché ne correspond pas.
Frame sandboxing
L’attribut sandbox
permet de restreindre les capacité d’un
<iframe>
:
- Exécuter des scripts,
- Afficher des popups,
- Contrôler le curseur/l’interface,
- Accéder à son origine,
- Naviguer la fenêtre parent, …
<iframe sandbox="" src="http://ent.uvsq.fr/">
Content Security Policy
Problème : Comment limiter les dommages potentiels d’une attaque XSS ?
Content Security Policy (CSP)
- Définir des restrictions d’accès au contenus sur des bases plus restrictives que la Same Origin Policy ;
- Mécanisme opt-in : l’application doit être explicitement configurée pour bénéficier d’une CSP ;
- Configuration à travers les entêtes HTTP, ou une balise
<meta>
.
Ce que l’on peut restreindre
- Sources pour les balises HTML :
<script>
,<object>
,<embed>
,<style>
,<img>
,<audio>
,<video>
,<iframe>
; - JavaScript inlined,
eval
, CSS, transformations XSLT, Web Fonts ; - Sources pour les APIs DOM : formulaires,
XMLHttpRequest
, WebSockets, Server events : - Permet aussi d’affaiblir certaines protections (mixed content, heuristiques anti-XSS).
Standard depuis février 2015, voir : http://www.w3.org/TR/CSP/#sotd
Exemple
Cette page définit la CSP suivante :
<meta http-equiv="Content-Security-Policy" content="child-src 'self'">
Exemple de CSP…
HTTP/1.1 200 OK
...
Content-Security-Policy: default-src 'self';
img-src *;
object-src media.example.com
*.cdn.example.com;
script-src https://js.example.com;
connect-src https:
Les balises <img>
sont toujours permises
<img src="http://farm1.staticflickr.com/1/xxxxxxxxxx.jpg" />
Les plugins sont autorisés uniquement sur certains sous-domaines
<object data="http://media.example.com/video.swf"></object>
<script>
permises uniquement sur https://js.example.com
<script src="https://js.example.com/jquery.min.js"></script>
AJAX est permis uniquement sur TLS
var xhr = new XMLHttpRequest()
xhr.open("GET", "https://api.finance.com/cac40?c=total")
Tout autre contenu est permis uniquement en provenance de la même page
Lectures
- Browser Security Handbook : https://code.google.com/p/browsersec/wiki/Part3,
- The tangled web, Chapitre 16,
- Mixed content,
- Strict transport security
- IFrames sandboxed
- Content Security Policy (MDN),
- Content Security Policy (html5rocks)
- Postcards from the post-XSS world, par Michal Zalewski.