Protection d'une application Web
- L'échange de ressources sur le réseau: integralité / confidentialité
- Protection contre l'utilisation de contenu frauduleux dans le navigateur
- L'autorisation des requêtes script inter-origine
Nous ne traiterons pas là l'authentification et le contrôle d'accès aux ressources privées
Les serveurs web du W3C
- Plus de 2,5 millions de documents existent sur les serveurs principaux
- Deux types de ressources
- Publiques: DTDs, namespaces, spécifications, linked data, ontologies, ...
- Privées: Documents internes ou accessibles uniquement aux Membres du Consortium
- Notre infrastructure permet une granularité très fine de contrôle d'accès, ressource par ressource
source: http://wellorderedlife.com/691/
Protection des échanges réseaux
- Une seule solution : HTTPS
- Évolution politique de sécurité du W3C
| Année | Ressources publiques | Ressources privées |
|---|
| 1995 - 2010 | HTTP | HTTP + authentification + contrôle d'accès |
|---|
| 2010 - 2015 | HTTP | HTTPS + authentification + contrôle d'accès |
|---|
| 2016 - | HTTP et HTTPS | HTTPS + authentification + contrôle d'accès |
|---|
| 20xx | HTTPS | HTTPS + authentification + contrôle d'accès |
|---|
HTTPS: Première étape HSTS
- (Pour désactiver HSTS, utiliser
max-age=0)
- Supporté par tous les navigateurs (source: caniuse.com)
- ... mais ne gère pas le mixed content
HTTPS: Problème Mixed Content
source: https://developer.mozilla.org/en-US/docs/Security/Mixed_content
HTTPS: Deuxième étape Upgrade-Insecure-Requests (UIR)
HTTPS: Deuxième étape UIR (suite)
- Problème: Header stripping d'en-tête HTTP
Upgrade-Insecure-Requests: 1
- Solution : HSTS + listes preloading des navigateurs
- Problème: Seulement supporté par FF, Chrome, Opera, Android (source: caniuse.com)
- HSTS sans UIR => Mixed content warnings ou contenu bloqué
- Solution temporaire: désactiver côté serveur HSTS/UIR pour Edge/IE/Safari
Protection contre contenu frauduleux
Problème: Injection du contenu
(Cross-Site Scripting - XSS)
- Injection des données arbitraires dans un site web
- formulaires, blogs, wikis, paramètres d'URLs, ...
- Objectif: Faire tourner du code malveillant dans le navigateur
- N'est pas affecté par Same-Origin Policy
Solution: filtrer le contenu
- HTMLawed,
htmlspecialchars(), htmlentities(),
strip_tags()
- Filtrer le contenu à la saisie ou l'encoder à la sortie n'est jamais 100% sûr
- Nouveaux tags, attributs, nouveau contenu actif
source: http://www.slideshare.net/BradHill2/w3-conf-hillhtml5securityrealities-22563779
Content Security Policy (CSP)
- Recommandation en cours d'élaboration par le groupe de travail WebAppSec du W3C
- CSP: appliquer la politique d'utilisation de contenu directement dans le client
- Octroyer le minimum de permissions
- L'application peut uniquement utiliser du contenu venant des origines autorisées
- Mécanisme de whitelisting
- Par défaut tout est interdit sauf si déclaré explicitement
Mode d'emploi
- En-tête réponse HTTP qui définit l'origine et le type de contenu qui peuvent être utilisés par une application
- Exemple: Autoriser tout contenu venant de
w3.org et les scripts de jquery.com
:
default-src *.w3.org;
script-src *.w3.org https://jquery.com;
| |
V V
directive valeur(s)
Notifications d'incidents CSP sur la console
Exemple: clickjacking
- Principe: afficher une page à l'intérieur d'une frame et la rendre invisible au moyen des CSS
- Solution:
frame-ancestors 'self';
- Remplace
X-Frame-Options: SAMEORIGIN
Directives CSP
| default-src | Tout sauf frames |
| font-src | fontes |
| img-src | images |
| media-src | audio + vidéo |
| object-src | plugins |
| script-src | scripts |
| style-src | CSS |
| form-action | formulaires |
| frame-ancestors | frames |
| plugin-types | MIME types autorisés pour les plugins |
| base-uri | HTML base |
| child-src | workers, frames |
| connect-src | Contenu récupéré par XMLHttpRequest (XHR) |
| sandbox | Équivalent à HTML5 iframes sandbox |
| report-uri | Envoi de rapports de violation de politique |
Report-only
- Permet de tester les directives CSP sans les imposer
- envoi par HTTP POST d'un rapport json à un endpoint agrégateur de rapports
:
default-src *.w3.org;
font-src *.w3.org https://fonts.gstatic.com data:;
script-src *.w3.org https://jquery.com;
report-uri https://www.w3.org/my_csp_report/test_fonts
report-uri indique l'adresse de l'endpoint agrégateur de rapports- (On peut également utiliser la directive
report-uri avec l'en-tête Content-Security-Policy)
Exemple de rapport CSP
{
"csp-report": {
"document-uri": "https://www.w3.org/blog/2008/10/understanding-http-put/embed/",
"referrer": "https://intojava.wordpress.com/",
"violated-directive": "script-src *.w3.org 'unsafe-inline'",
"effective-directive": "script-src",
"original-policy": "default-src *.w3.org; img-src *; style-src ...",
"blocked-uri": "https://www.w3.org",
"source-file": "https://www.w3.org",
"line-number": 8,
"column-number": 688,
"status-code": 0
}
}
Refactorisation de l'application
- CSP impose par défaut la séparation du code des données
- application, CSS, javascript
- Suppression du code javascript inline == suppression attaques XSS
- Supression du code CSS inline == supression altération du contenu malveillant
- Suppression de la fonction javascript
eval
Exemple de refactorisation
- Avant refactorisation
myapp.html:
<button id="button1" onclick="doSomething()">
- Après refactorisation
myscript.js:
...
document.getElementById("button1").addEventListener('click', doSomething);
...
myapp.html:
...
<script src="myscript.js"></script>
...
<button id="button1">
- Il existe également d'autres alternatives (hash, ...)
- La politique peut autoriser explicitement le code en-ligne au détriment de la sécurité
script-src *.w3.org 'unsafe-inline' 'unsafe-eval';
CSP: Résumé d'experience
- CSP 1.0 supporté par presque tous les navigateurs (source: caniuse.com)
- CSP 2.0 supporté essentiellement par FF, Chrome, Android et Opera (source: caniuse.com)
- Dépréciation / renommage / nouvelles directives à chaque nouvelle version de CSP
- Souvent dur de reproduire un cas d'erreur ou d'interpréter un rapport CSP
- Avec du code legacy, mediawiki et wordpress, on est obligé pour le moment d'autoriser le code en-ligne
- Notre objectif de politique CSP initiale: très ambitieux
- Notre objectif actuel de politique CSP: très modeste
- Meilleurs pratiques
- console chrome + report-only + agrégation de rapports
- CSP et le principe de séparation sont solides, mais plus simples à mettre en place sur des nouveaux systèmes.
- Possible d'exploiter CSP 1.0, mais attendre que CSP 2.0/3.0 soient plus répandus
L'autorisation des requêtes script inter-origine
Requêtes inter-origines avec CORS
- XMLHttpRequest (XHR) (WhatWG Living Standard depuis fin 2012)
- API javascript permettant d'effectuer des requêtes HTTP depuis une page
- Same-Origin Policy
- Restreint les requêtes d'un script au site d'origine qui héberge la page
- Cross Origin Resource Sharing (CORS) (W3C Recommendation Jan 2014)
- Mécanisme autorisant les requêtes HTTP inter-origines
- Permet le partage opaque des informations d'authentification (cookies, login)
- Permet l'envoi et l'accès contrôlé aux en-têtes HTTP inter-origines
- Supporté par tous les navigateurs (source: caniuse.com)
- Fetch Living Standard va remplacer CORS et XHR
Exemple CORS
- Aucun changement dans le code pour les requêtes CORS simples
http://example.org/cors.html
<html>
<body>
<script>
var xhr = new XMLHttpRequest ();
xhr.open ('GET', 'https://www.w3.org/ns/anno.jsonld', true);
xhr.onreadystatechange = handler;
xhr.send ();
...
- La requête HTTP indique l'origine de l'application
GET /ns/anno.json.ld HTTP/1.1
Host: www.w3.org
Origin: https://example.org
...
Exemple CORS (suite)
- La réponse HTTP indique la décision d'autorisation avec l'en-tête
Access-Control-Allow-Origin
- Le navigateur interdit l'accès à la ressource si
- l'en-tête
Access-Control-Allow-Origin n'est pas présente
- La valeur n'est ni "
*" ni la valeur origine de la requête
- Précaution : association de la valeur "
*" à des ressources privées
Politique CORS au W3C
- Imposée globalement par un module propriétaire Apache
- Autorisé uniquement pour les méthodes HTTP GET et OPTIONS
- Accès depuis toute origine aux ressources publiques
- RDF, RDFa, n3, turtle, json linked data, json, owl
- web open font format (woff)
- tout l'espace
/TR/ (specs, dtds)
- namespaces
- autres cas particuliers
- Interdiction de CORS sur toute ressource protégée ou associée à des cookies
Conclusions
- Existence d'outils intéressants pour augmenter le niveau de sécurité du Web
- Le support navigateur est déjà bon pour pouvoir profiter d'une bonne partie
Upgrade Insecure Requests va simplifier le passage à HTTPS pour les sites legacy- CSP donne une bonne défense contre XSS mais dûr à appliquer sur du contenu / applications legacy sans réécriture
- Écrire les nouvelles applications en séparant le code des données
- Ce n'est pas simple de savoir quel ensemble de directives CSP un navigateur peut supporter au delà de CSP 1.0
- Le navigateur devient de plus en plus une Trusted Computing Base (TCB)
- Les politiques CSP et CORS sont imposées par le navigateur aux applications
