Préambule

Les applications Web enrichies, utilisant JavaScript pour mettre à jour tout ou partie d’une page web, sont officiellement nées en 2005 avec l’apparition du terme Ajax, et sont aujourd’hui communes. De ce concept sont ensuite nées les applications JavaScript « Single Page Interface », modèle dans lequel rentre l’application typique GWT. Le framework propose aujourd’hui un modèle de programmation au juste milieu entre les paradigmes du développement RDA (pour Rich Desktop Application) et du développement Web. Après compilation, une application GWT devient une application JavaScript tout à fait standard du point du vue du browser.

Les applications Ajax n’introduisent pas de nouvelles failles de sécurité. Techniquement, les risques et les techniques d’exploitation sont les mêmes. Si certaines failles sont affaiblies par le modèle, d’autres ont vu leur terrain de jeu évoluer.

Le but de cet article et d’un autre à venir est de rappeler les failles de sécurité qui concernent tout particulièrement la portion JavaScript – et donc GWT – de nos applications Web, puis de présenter les réponses qu’il convient de mettre en œuvre dans une application GWT pour contrecarrer les éventuelles attaques.

En point de départ, nous nous appuierons sur l’OWASP & son top ten 2010 des failles de sécurité des applications Web :

1. Injection
2. Cross-Site Scripting (XSS)
3. Broken Authentication and Session Management
4. Insecure Direct Object References
5. Cross-Site Request Forgery (CSRF)
6. Security Misconfiguration
7. Insecure Cryptographic Storage
8. Failure to Restrict URL Access
9. Insufficient Transport Layer Protection
10. Unvalidated Redirects and Forwards

Deux de ces failles potentielles nous concernent tout particulièrement dans une couche Ajax : les failles XSS [2] et CSRF [5]. Elles auront dans ce contexte la particularité sympathique de rendre l’application vulnérable quelles que soient les protections mises en place uniquement côté serveur. Leur compréhension et la connaissance des mécanismes de protection par le développeur sont donc essentielles. Dans ce premier article, nous nous focaliserons sur les attaques de type CSRF.

A l’écriture de ces lignes, la version courante de GWT est la 2.4.

CSRF : Cross Site Request Forgery

Traduire avec élégance par « falsification de requête inter-site ».

Une attaque CSRF consiste à utiliser les autorisations qu’a un utilisateur sur un site donné contre son gré. Il s’agit de construire sur un domaine sous le contrôle de l’attaquant une requête vers le site attaqué ; la requête sera soumise par le browser de l’utilisateur victime, et exécutée avec les droits de ce dernier. Si le cookie permet de s’assurer que la requête provient du browser du bon utilisateur, il ne permet pas de vérifier que l’appel provient du bon site…

La same origin policy

Petit rappel des règles du jeu. Tout browser se doit de restreindre les capacités de JavaScript à la same origin policy. Cette règle rend impossible un appel asynchrone via XMLHttpRequest sur un autre domaine. Toute manipulation du DOM est aussi restreinte : une iframe ayant pour source une page sur un autre domaine ne sera ni lisible ni pilotable par un script de la page parente.

Il s’agit bien d’empêcher la lecture d’une requête provenant d’un autre domaine : initier la requête est possible (et heureusement), pas traiter son résultat. C’est sur cet état de fait que s’appuient les attaques CSRF.

Une attaque CSRF typique : c’est l’histoire d’un steak

Plantons le décor. Ghislain est boucher, sur son site myboucher.com, il vend des bavettes. Georges, qui possède une brasserie, est son premier client. Richard est boucher lui aussi, mais jalouse Ghislain. A ses heures perdues, il lit des articles underground de l’internet mondial. Et agit secrètement sur iamthevilain.com.

Voici l’histoire de son attaque contre le site de Ghislain. Georges est sa première victime.

1. Georges se connecte sur myboucher.com. Il s’authentifie : login/mot de passe, qui ne seront pas divulgués dans cet article. Son browser reçoit alors un cookie de session ; ce dernier sera systématiquement envoyé par toute requête sur myboucher.com
2. Ce qu’il a fait sur myboucher.com précisément ne nous regarde pas, mais il ne s’est pas déconnecté. Plus tard, du fait d’un mail d’origine inconnue, il atterri sur la page http://iamthevilain.com/hack-myboucher.action . Sur cette page se trouve un formulaire qui correspond très précisément à celui qui est existe sur myboucher.com pour supprimer l’intégralité des informations du compte de l’utilisateur courant. Les champs sont identiques, et l’attribut HTML action du formulaire pointe sur la page correspondant à la suppression sur myboucher.com. Le formulaire est placé dans une frame invisible.
3. Un code JavaScript soumet automatiquement le formulaire, en JavaScript, sans que Georges ne fasse quoi que ce soit. Une requête POST parfaitement valide, ordonnant une suppression de compte est alors soumise à myboucher.com, avec le cookie qui authentifie Georges. Notre brasseur n’a plus de compte, et du fait de la frame, il ne s’est aperçu de rien.
   Ghislain perd bon nombre de ses comptes utilisateurs, sans pouvoir fournir à ces derniers la moindre explication.

Il est à noter que l’attaque CSRF n’a de sens que sur des utilisateurs connectés avec des droits spécifiques (dans 99,72% des cas). D’ailleurs, elle est d’autant plus dévastatrice que la victime a de droits sur le site. L’ensemble des protections est basé sur le fait que la victime potentielle dispose d’une session sur le serveur.

CSRF & HTTP

Dans le scenario ci-dessus, j’ai volontairement pris l’exemple d’une action nécessitant une requête POST. L’attaque CSRF la plus basique se base sur une requête GET. En effet, pour faire une requête GET sur un autre domaine sans que l’utilisateur ne puisse s’en apercevoir, il suffit d’utiliser une frame, une image… C’est possible dans un simple mail !

Sauf qu’une telle attaque CSRF ne devrait pas avoir de sens : une action d’écriture ne devrait jamais être faite via une requête GET. Une requête GET doit toujours pouvoir être exécutée sans mettre en question l’intégrité de vos données. C’est un des principes de HTTP (cf. la RFC), sur lequel est basée la conception des moteurs de recherche, des browsers, etc… Par exemple, un browser aura le droit de précharger les ressources trouvées en lien sur une page : imaginez les dégâts d’un simple lien « supprimer mon compte ». Derrière ce lien devrait en fait se cacher un formulaire HTML et une requête POST. Pour cette raison, ce sont uniquement les requêtes POST que nous voudrons protéger.

Utiliser le referer ? Non

Dans la définition d’HTTP se trouve un champ de header destiné à contenir l’URL de la page qui a initié la requête pour le browser, il s’agit du referer. C’est ce champ qui permet par exemple aux outils de statistiques de dire d’où vient un visiteur. On pourrait dès lors vouloir s’appuyer sur ce champ pour se prémunir des CSRF. Lors d’une soumission de formulaire depuis un site étranger, le referer devrait normalement contenir l’url de la page dans laquelle se trouvait le formulaire initial. C’est ce « normalement » qui nous arrêtera là. Dans la pratique, le referer ne sera pas toujours alimenté, de plus, certaines versions d’Internet Explorer et du player Flash contiennent des failles permettant la construction d’attaque CSRF avec manipulation des headers.

Les techniques de protection.

Dans une application WEB standard, les requêtes POST sont soumises par les formulaires, et la protection aux CSRF passe par l’utilisation d’un jeton. Ce dernier est généré de façon non prédictive côté serveur, et conservé dans la session utilisateur (ou directement construit à partir de l’identifiant de session, typiquement un hash). Il est donc associé à une session donnée. Lors de la construction d’un formulaire dans une page HTML, toujours côté serveur, il est injecté dans un champ caché (<input type= »hidden » … />). Sa présence est vérifiée à la soumission du formulaire. Du fait de la same origin policy, il est impossible à l’attaquant potentiel de récupérer un jeton. Il ne peut dès lors plus construire un formulaire contenant un jeton valide pour une quelconque session existante.

Les applications Ajax utilisent l’objet XMLHttpRequest pour faire des appels HTTP sans recharger la page web, et traiter le résultat de façon asynchrone. Si elles ne sont pas faites de la même façon, il s’agit des mêmes requêtes POST que celles des formulaires. La technique de protection sera la même, et il faudra utiliser un jeton conservé en session. XMLHttpRequest permettant la manipulation des headers HTTP, cette capacité sera souvent utilisée pour glisser le jeton dans un header dédié et ne pas polluer le corps de requête.

La plupart des frameworks web classique récents (Rails, Django, Symfony, ASP.NET MVC, ou encore Seam dans le monde Java, dont les frameworks sont plus globalement de mauvais élèves) proposent une solution de jeton intégrée aux formulaires, plus ou moins transparente pour le développeur. A contrario, les frameworks JavaScript, s’ils simplifient généralement les opérations de requêtes asynchrones, n’apportent pas de solution prémâchée. « Normal », puisque cette intégration passe aussi par l’implémentation côté serveur. A noter le cas de Rails, qui intègre nativement une protection pour la partie Javascript : le token est fourni via une balise dans le HTML, et l’objet JavaScript XMLHttpRequest est enrichi par le framework pour que le token soit systématiquement glissé dans les headers HTTP. Comme pour un formulaire standard, l’ensemble est totalement transparent pour le développeur !

GWT dans cet environnement a un côté vicieux. Le développeur GWT écrit bien souvent des requêtes RPC, et « ignore » le fait que ces requêtes sont techniquement des requêtes POST tout à fait standards, utilisant l’objet XMLHttpRequest. On pourra d’ailleurs faire un rapide aparté sur les applications basée sur Flash, et donc Flex, qui utilisent les mêmes requêtes, sans que les frameworks communément utilisés ne poussent de solution intégrée.

Que faire avec GWT ?

GWT-RPC

Il convient tout d’abord de souligner que GWT propose nativement une première ligne de défense en RPC. Le nom d’un des fichiers chargés par le bootstrap interne GWT (pour être plus précis, le nom de la permutation correspondante dans le mécanisme de Deferred Binding du compilateur) est systématiquement envoyé dans un header HTTP dédié lors de toute requête RPC (qui est encore une fois une requête faite via XMLHttpRequest). En son absence ou cas de valeur inattendue, la servlet lance une SecurityException ; le traitement s’arrête là. Ce simple ajout du header complique la tâche au potentiel attaquant. En effet, l’attaque CSRF par requête POST passe par la soumission d’un formulaire, le XMLHttpRequest cross-domain est interdit. Or l’ajout d’un header HTTP n’est pas possible dans un formulaire HTML.

Cependant, comme nous l’avons vu lors de l’élimination du referer dans notre stratégie de sécurisation, des configurations permettront cet ajout. Il ne suffit donc pas pour une protection exhaustive.

Depuis sa version 2.3, le framework propose un mécanisme plus complet. C’est un hash MD5 de l’identifiant de session qui est envoyé avec les requêtes RPC, sa présence est automatiquement contrôlée par le service GWT. L’interface d’un service protégé et son implémentation hériteront respectivement d’une interface et d’une classe spécifique. Enfin, une servlet sera dédiée à la récupération du jeton. La mise en place exacte d’un service RPC jouissant de ce mécanisme passe par les opérations suivantes :

Définition de l’interface du service

// à noter que les développeurs GWT ont préféré l'appellation XSRF - plus rare - à CSRF
public interface SecuredService extends XsrfProtectedService {
	void doSomethingReallyImportant();
}

Implémentation du service

public class SecuredServiceImpl extends XsrfProtectedServiceServlet implements SecuredService{

    @Override
    public void doSomethingReallyImportant() {
        yeahNowWeAreReallyGonnaDoIt();
    }

    // [...]

}

Déclaration de la servlet délivrant le jeton (token)

Dans le web.xml :

<context-param>
	<param-name>gwt.xsrf.session_cookie_name</param-name>
	<param-value>JSESSIONID</param-value>
</context-param><servlet>
	<servlet-name>XsrfTokenServiceServlet</servlet-name>
	<servlet-class>com.google.gwt.user.server.rpc.XsrfTokenServiceServlet</servlet-class>
</servlet>
<servlet-mapping>
	<servlet-name>XsrfTokenServiceServlet</servlet-name>
	<url-pattern>/xsrfTokenService</url-pattern>
</servlet-mapping>

Définition du nom du cookie à utiliser

Le nom du cookie à utiliser est aussi déclaré dans le web.xml. Au besoin il serait possible de créer un cookie dédié à cela, indépendamment de la session.

<context-param>
	<param-name>gwt.xsrf.session_cookie_name</param-name>
	<param-value>session-id</param-value>
</context-param>

Utilisation du service sécurisé

L’utilisation du mécanisme se fait en deux phases dans le code GWT. Il faut d’abord récupérer et stocker quelque part le jeton.

private XsrfToken xsrfToken;

public void fetchXsrfToken() {
	XsrfTokenServiceAsync xsrfTokenService = GWT.create(XsrfTokenService.class);
		// ces interfaces sont fournies par le SDK avec la servlet

	((ServiceDefTarget) xsrfTokenService).setServiceEntryPoint("xsrfTokenService"); // défini
	xsrfTokenService.getNewXsrfToken(new AsyncCallback() {
		public void onSuccess(XsrfToken result) {
			xsrfToken = result;
		}

		public void onFailure(Throwable caught) {
			// une RpcTokenException peut notamment être levée si le cookie
			// est inexistant ou vide

			// [...]
		}
	});
}

Il doit ensuite être injecté aux instances de services d’appel asynchrone.

SecuredServiceAsync securedService = GWT.create(SecuredService.class);
((HasRpcToken) securedService).setRpcToken(xsrfToken);
securedService.doSomethingReallyImportant(new AsyncCallback() {
	@Override
	public void onFailure(Throwable caught) {
		// [...]
	}

	@Override
	public void onSuccess(Void result) {
		// [...]
	}
});

Tous les détails sont documentés dans la Javadoc de la servlet XsrfTokenServiceServlet.

L’utiliser, ou pas ?

Cette même Javadoc commence par l’avertissement suivant :

EXPERIMENTAL and subject to change. Do not use this in production code

Il est fort probable que les développeurs de GWT souhaitent l’intégrer de façon plus transparente, plus élégante et plus propre au framework. On pourrait entre autres générer le hash MD5 du cookie côté GWT.

Que faire en attendant ? Notre préconisation est de préférer l’utilisation de ces classes « expérimentales » si vous souhaitez vous défendre contre ce type d’attaque. Une implémentation de votre cru fera le job, mais vous n’y gagnerez rien. Si une version future de GWT propose une solution mieux intégrée, nul doute que le refactoring sera mineur…

Si jamais, pour une raison ou une autre (je pense notamment au refactoring d’une application existante), la récupération asynchrone du jeton vous pose problème, l’objet Dictionary permet de récupérer une variable définie dans la page HTML hôte de l’application GWT. Il suffit alors de délivrer cette page via une servlet (ou autre si vous avez déjà…) et d’y injecter le jeton.

RequestBuilder et RequestFactory

Un petit avantage des applications Ajax pour lutter contre les CSRF est, encore une fois, que l’objet XMLHttpRequest permet la manipulation des headers HTTP. Utiliser le header pour y glisser un champ dédié à notre jeton sera plus pratique qu’une variable dans le corps de la requête – qui restera dédié à la donnée.

RequestBuilder est le pendant de XMLHttpRequest du monde JavaScript, c’est la classe qui permet de faire des requête GET ou POST « à la main ». Par rapport au XMLHttpRequest initial, RequestBuilder n’est qu’une façade qui reprend une syntaxe plus proche de ce que l’on trouvera dans le monde Java, mais uniquement côté client. De ce fait, elle permet l’utilisation de GWT avec des stacks autres que Java côté serveur.

RequestFactory est l’API proposée avec la version 2.1 de GWT en alternative à RPC. Son principal atout aujourd’hui : elle manipule des DTO outillés, de telle façon qu’une opération save(myDto) ne fera transiter dans la requête HTTP que les champs effectivement modifiés de l’objet.

Contrairement à RPC le framework ne gère seul le jeton ni pour RequestBuilder ni pour RequestFactory. L’opération préconisée sera d’utiliser un champ de header pour RequestBuilder, afin de ne pas polluer le corps de la requête. Dans le cas de RequestFactory, la séparation headers/corps de requête est en fait moins substantielle, du fait de la forme déjà spécifique du corps de requête. L’exemple donné passe cependant par un header.

Notre préconisation sera d’utiliser au maximum l’outillage existant pour RPC, il tient la route et cela semble une bonne stratégie en cas de positionnement futur du framework pour la sécurisation des RequestBuilder et RequestFactory (bien sûr, si vous utilisez RequestBuilder avec autre chose que Java côté serveur, cette remarque n’est pas à prendre en compte).

Pour RequestBuilder

Côté client

Comme en RPC, il conviendra tout d’abord de récupérer le token (pour cela, voir le code fourni pour le mécanisme RPC), puis d’injecter le header :

RequestBuilder requestBuilder = new RequestBuilder(RequestBuilder.POST, "");
requestBuilder.setHeader("X-XSRF-Cookie", xsrfToken.getToken());
requestBuilder.sendRequest(null, new RequestCallback() {
	@Override
	public void onResponseReceived(Request request, Response response) {
		// [...]
	}

	@Override
	public void onError(Request request, Throwable exception) {
		// [...]
	}
});

Dans le cas d’un serveur non-Java, deux solutions : générer le MD5 en utilisant un script JS trouvé sur le net (les principaux frameworks n’en proposent pas, mais voir par exemple ici), ou procéder au hashage côté serveur et le redescendre côté client (comme avec RPC, en asynchrone ou via l’objet Dictionary et la page HTML hôte).

Côté serveur

Voici un exemple avec une simple servlet Java. La validation est grandement reprise du code utilisé pour RPC, et exploite les même classes utilitaires fournies par GWT :

public class SecuredServlet extends HttpServlet {

	@Override
	protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		validateXsrfToken(request);
		super.service(request, response);
	}

	protected void validateXsrfToken(HttpServletRequest request) throws RpcTokenException {
		// RpcTokenException est propre à GWT

		String xsrfToken = request.getHeader("XSRF-Token");
			// le header que nous avons injecté
		if (xsrfToken == null) {
			throw new RpcTokenException("XSRF token missing");
		}

		Cookie sessionCookie = Util.getCookie(request, "session-id", false);
			// com.google.gwt.user.server.Util est une classe utilitaire interne GWT
		if (sessionCookie == null || sessionCookie.getValue() == null || sessionCookie.getValue().length() == 0) {
			throw new RpcTokenException("Session cookie is missing or empty! " + "Unable to verify XSRF cookie");
		}
		String expectedToken = Utility.toHexString(Utility.getMd5Digest(sessionCookie.getValue().getBytes()));
			// de com.google.gwt.util.tools.Utility ...

		if (!expectedToken.equals(xsrfToken)) {
			throw new RpcTokenException("Invalid XSRF token");
		}
	}

	// [...]

}

Pour RequestFactory

Côté client

Etendre DefaultRequestTransport pour injecter le header :

public class SecuredRequestTransport extends DefaultRequestTransport {

	protected XsrfToken xsrfToken;

	public SecuredRequestTransport(XsrfToken xsrfToken) {
		this.xsrfToken = xsrfToken;
	}

	@Override
	protected void configureRequestBuilder(RequestBuilder builder) {
		super.configureRequestBuilder(builder);
		builder.setHeader("XSRF-Token", xsrfToken.getToken());
	}
}

A noter qu’on aurait pu aussi enrichir le corps de requête, comme dit plus haut.

Utiliser ensuite une instance de notre SecuredRequestTransport au lieu de DefaultRequestTransport avec nos RequestFactory :

EventBus eventBus = new SimpleEventBus();
SecuredRequestTransport securedRequestTransport = new SecuredRequestTransport(xsrfToken);
MyRequestFactory myRequestFactory = GWT.create(MyRequestFactory.class);
myRequestFactory.initialize(eventBus, securedRequestTransport);

Côté serveur

Côté serveur, il sera nécessaire de créer une classe héritant de RequestFactoryServlet. Le code est strictement le même que l’exemple donné pour RequestBuilder, le validateXsrfToken() peut être appelé dans un doPost() enrichi (au lieu de service()).

public class SecuredRequestFactoryServlet extends RequestFactoryServlet {

	@Override
	protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		validateXsrfToken(request);
		super.doPost(request, response);
	}

	// ce code est strictement le même que pour la SecuredServlet plus haut
	protected void validateXsrfToken(HttpServletRequest request) throws RpcTokenException {
		// RpcTokenException est propre à GWT

		String xsrfToken = request.getHeader("XSRF-Token");
			// le header que nous avons injecté
		if (xsrfToken == null) {
			throw new RpcTokenException("XSRF token missing");
		}

		Cookie sessionCookie = Util.getCookie(request, "session-id", false);
			// com.google.gwt.user.server.Util est une classe utilitaire interne GWT
		if (sessionCookie == null || sessionCookie.getValue() == null || sessionCookie.getValue().length() == 0) {
			throw new RpcTokenException("Session cookie is missing or empty! " + "Unable to verify XSRF cookie");
		}
		String expectedToken = Utility.toHexString(Utility.getMd5Digest(sessionCookie.getValue().getBytes()));
			// de com.google.gwt.util.tools.Utility ...

		if (!expectedToken.equals(xsrfToken)) {
			throw new RpcTokenException("Invalid XSRF token");
		}
	}

	// [...]

}

Dans le web.xml, déclarer cette servlet au lieu de RequestFactoryServlet.

Conclusion

Les CSRF rentrent dans la catégorie des failles qui doivent être connues du développeur qui manipule un framework de présentation quel qu’il soit. Étonnamment, nombre de frameworks font preuve de peu de maturité dans l’intégration de solutions pour s’en prémunir.

GWT permet de mettre en place des solutions relativement facile à maintenir et à surveiller. Les failles sont peut-être plus complexes à appréhender, mais sont aussi plus faciles à isoler avec une application riche qu’avec une application web standard. De même, une application GWT existante à sécuriser devrait aisément se refactorer.

Certains frameworks, notamment Rails, résilient la session en cas de jeton attendu non détecté, ce qui peut constituer une sécurité supplémentaire. La RpcTokenException de GWT pourrait par ailleurs nous permettre de prévenir l’utilisateur d’une probable tentative d’attaque, via une alerte JavaScript Window.alert(), afin de sortir d’une éventuelle frame cachée.

En cas de besoin, dans une démarche de qualité, on pourra chercher à l’aide d’un outil comme Sonar des traces de non respects de la marche à suivre. Par exemple en vérifiant que nos interfaces de service RPC héritent de XsrfProtectedService et non plus de RemoteService. Ou encore en créant une classe SecuredRequestBuilder dont le constructeur exige le jeton, et vérifier que la RequestBuilder standard n’est plus utilisée.

Un prochain article abordera les failles XSS, les solutions proposées par le framework pour s’en prémunir, et traitera rapidement des autres points top 10 OWASP dans le contexte d’une application GWT.

Suggestion d'articles :

1. Initiation à la sécurité des Web Services
2. Sécurité des services web – 1ère partie
3. HTML5, offline et sécurité

Avec l’expansion des services en lignes via le cloud ou tout simplement l’interconnexion des SI, le besoin d’exposer des services vers l’extérieur est croissant. Les WebServices sont une solution maintenant éprouvée depuis longtemps pour répondre à ce besoin.

Que l’on utilise SOAP ou REST un problème se pose toujours : comment faire pour sécuriser l’accès à mon SI alors que j’en ouvre une porte en exposant mon métier ?
Souvent utilisés au sein même d’un SI pour gérer des problématiques d’intégration ou d’hétérogénéité des technologies, les Web Services sont aussi de plus en plus souvent exposés sur le web ou à des partenaires.

Lorsque c’est possible, on voit souvent la mise en place d’un canal sécurisé type VPN entre les différents acteurs. Toutefois cela n’est pas toujours possible et cet article a pour but de vous présenter des notions de base liées à la sécurité des web services.

Ayant réalisé des missions, pour OCTO, aussi bien d’architecture que de développement autour ce sujet je vais tenter, via une série d’articles, de vous initier à ce domaine.
La majorité des WebServices de nos clients étant en SOAP je me concentrerais beaucoup plus sur ces derniers.
Cet article se voulant une initiation je ne suis pas rentré dans des détails très techniques, il a uniquement pour but d’attirer l’attention sur la vulnérabilité des protocoles de Web Services.

Identifier le besoin et les risques

Lorsqu’on traite de sécurité il faut toujours commencer par se poser quelques questions

1. Mes données sont elles sensibles?
2. Quel est le risque et quelles sont les conséquences pour mon SI si ces données sont capturées ou utilisés à mauvais escient ?
3. Quelle est la probabilité que quelqu’un attaque mon service ?

Sans rentrer dans les détails de l’analyse de risque qui sort du périmètre de cet article, il est important d’avoir une bonne idée de la réponse à ces questions pour ensuite être capable de déterminer le niveau de sécurité nécessaire.

Valider les données

Une des failles de sécurité qu’on croise le plus dans les applications concerne les points d’entrée des données. Que ce soit un formulaire sur une page web ou un web service, tout point d’entrée de donnée vers votre application est potentiellement une faille de sécurité.
Il est donc essentiel et critique de valider tout ce que les utilisateurs de votre application pourront envoyer à celle-ci.
En effet un WebService est aussi vulnérable qu’un formulaire à l’injection SQL (passage de morceaux de requêtes SQL à un champ de donnée pour les faire interpréter par le serveur) et à d’autres exploit du même acabit. Pour plus de détails je vous invite à consulter cette page de l’OWASP.
De plus, la majorité des WebService utilisant SOAP et donc du XML sont vulnérables à toutes les failles induites par XML.

La validation des données entrées est donc critique pour éviter de nombreuses failles. Pour cela il existe de nombreux moyens.
Première étape, utiliser un WSDL particulièrement stricte sur le typage des données et sur la taille des champs vous protégera déjà de nombreux problèmes.
De la même manière je ne peux rentrer dans les détails sans trop m’étendre, mais la mise en place de DTD, voir mieux de XSD, est un très bon levier.
En effet l’adresse d’un DTD étant indiquée dans le XML, un utilisateur mal attentionné pourra la modifier dans le message qu’il vous envoi, pour changer la méthode de validation des données par celle de son choix (beaucoup plus permissive). Dans le cas d’un XSD seul le serveur sait quel XSD utiliser pour valider le contenu.
Pour les champs spécifiques (adresse email, url…) utiliser des expressions régulières stricte pour valider est une bonne pratique.
Enfin, réfléchissez toujours bien à l’impact des données que l’utilisateur peut vous envoyer et donc manipuler.

Avant de vous présenter quelques failles induites par les WebServices SOAP, je tiens à rappeler qu’il est très facile pour un utilisateur mal intentionné de forger des messages SOAP avec des outils tels que soapUI. A la base conçu pour tester les WebServices cet outil s’avère formidable pour les attaquer en forgeant des messages.

SOAP & XML

Quelques attaques de type DoS (Denial of Service)

Buffer Overflow

SOAP a le gros avantage d’être un protocole très souple, ce qui est une qualité indéniable mais aussi un gros défaut en terme de sécurité.
La souplesse de SOAP réside essentiellement dans la possibilité d’encapsuler à peu près ce que l’on veut (tant que c’est un XML valide) dans un message SOAP.
Premier problème : aucune contrainte de taille.
Ce type d’attaque est généralement couvert par le framework de WebService que vous utilisez (sauf si celui-ci est vraiment obsolète).
Néanmoins un utilisateur mal intentionné qui souhaite réalise un DoS (Denial Of Service) sur votre application pourra s’amuser à essayer d’envoyer un message énorme à vos WebService pour tenter de faire planter le parseur XML qui va démarshaller le message SOAP.
C’est bien entendu les parseurs de type DOM qui chargent tout le message XML en mémoire avant de l’interpréter qui sont vulnérable à ce type de problèmes.
Ce type d’attaque amène à un problème de type BufferOverflow qui induit souvent au plantage complet de l’application.

Il est donc crucial de vérifier la taille des messages reçus avant de tenter de les interpréter.

Récursion infinie

Il s’agit ici d’envoyer un XML récursif au web service. Si le parseur est de type XPath il va partir en boucle infinie.
Exemple :

1

<credit><credit><credit>….

D’autres attaques …

XML Injection

L’idée ici est plutôt d’outrepasser les validateurs de données pour détourner l’usage prévu du Web Service.

Un exemple bien parlant :

1
2
3
4
5
6
7

<transaction> 
<total>4000.00<total>
<credit_card_number>123456789</credit_card_number> 
<total>6.66</total>
<credit_card_number>123456789 </credit_card_number> 
<expiration>17112010</expiration>
</transaction>

En répétant la balise total, l’attaquant tente de changer les valeurs démarshallées par le Web Service pour ainsi payer 6,66 au lieu de 4000 euros. Cet exemple est volontairement simpliste mais, croyez moi, je suis déjà tombé sur des cas ou cela fonctionne.

XPath Injection

L’idée ici est d’attaquer les parseurs de type XPath. En effet si vos requêtes XPath se basent sur les entrées utilisateurs le parseur risque d’interpréter des choses non prévus :

Exemple :
//users/custid[123] va aller récupérer l’utilisateurs ayant pour ID 123, ici l’utilisateur bienveillant à bien mis son Id donc tout va bien.

//users/custid[./age > 1] va aller récupérer tous les utilisateurs dont l’âge est supérieur à 1, ici l’utilisateur malveillant à tenté de mettre un bout de XPath en paramètre et le résultat est assez facile à deviner :)

L’index de requête étant passé en paramètre cela autorise l’utilisateur à utiliser un identifiant client différent du sien. Il est ainsi libre de récupérer les données de tous les utilisateurs de l’application.

Failles XML & SOAP : comment s’en prémunir

Globalement la réponse est très simple : ne réinventez pas la roue.
D’une part pour tout ce qui touche au parsing XML utilisez des frameworks éprouvés et testés par les communautés Open Source par exemple. En réécrivant un parseur XML vous prenez le risque de ne pas penser à tous les types d’attaques présentés précédemment et bien entendus à tous ceux qui ne sont pas exposés ici.
Les frameworks existants sont testés par de nombreux utilisateurs, dont certain très avertis vont remonter ce type de problèmes qui seront très vite corrigés.
Il en va de même pour votre framework de WebService. Utilisez un framework éprouvé et ne réinventer pas la roue en branchant votre parseur XML maison à une socket en écoute sur le port 80. Je caricature mais parfois on croise des choses terrifiantes … Et bien entendu validez tout ce que votre application recevra via des messages SOAP.

Enfin mettez à jour vos frameworks. Les mises à jours de ceux ci (même mineures) incluent souvent des correctifs au failles de sécurités mises en évidences.
Bref à retenir : utilisez des frameworks de parsing XML et de Web Services modernes et éprouvés par la communauté.

Côté réseau et hardware : HTTP, HTTPS, VPN, filtrage IP, filtrage hardware

Une question qui m’est souvent remontée est : quelle type de transport utiliser pour exposer mes Web Services ?

Déjà je tiens à briser un a priori souvent entendu : exposer vos services sur le web en HTTPS ne vous prémunit pas de tous les risques.
Au mieux vous vous protéger des attaques du type man in the middle (et donc qu’un utilisateur intercepte vos messages), mais toutes les autres attaques restent possible.
Il est néanmoins important de savoir que SSL peut, comme un VPN, assurer l’authentification de l’utilisateur si le serveur est correctement configuré.
Cependant, par défaut les canaux cryptés n’ont qu’un seul intérêt : garantir la confidentialité de l’échange. C’est à dire qu’un utilisateur en écoute sur vos échanges ne pourra pas les intercepter (confidentialité de l’échange).
C’est donc très important mais très souvent insuffisant.
Il est toutefois possible de mettre en place une authentification HTTP Basic ou WS Basic devant un WebService via une configuration spécifique du serveur. Néanmoins ces méthodes d’authentification sont peu fiable car le mot de passe circule en clair il est donc interceptable. Donc ces types d’authentification restent tout à fait valables si elles sont utilisées sur un canal crypté.

Les tunnels de type VPN sont déjà un cran au dessus car ils assurent l’authentification de l’appelant (souvent grâce à un certificat) via l’accès VPN. Cela vous protège aussi des écoutes malveillantes car les tunnels VPN sont cryptés. Cela vous apporte, en plus, une limitation sur les utilisateurs qui se connectent à vos services car seuls ceux que vous autorisez explicitement peuvent utiliser le canal VPN. Le canal VPN est donc une très bonne solution mais pas toujours applicable.

Le filtrage d’IP est une protection intéressante pour limiter les appelants de vos services, néanmoins il est relativement facile de masquer son adresse IP par une autre (spoofing d’adresse IP). C’est donc un levier de sécurité intéressant mais insuffisant à lui tout seul.
La mise en place de signature numérique sur les messages permet alors de valider la non répudiation de ceux-ci.

A noter qu’il existe aussi des solutions matérielles type Datapower pour gérer la sécurité de vos services selon les possibilités et la configuration du matériel choisi. Ces solutions sont particulièrement efficaces mais très couteuses. Dans un degrés de risque élevé elles sont toutefois justifiées. Ces solutions ont aussi l’avantage d’être particulièrement efficace pour accélérer la gestion du SSL, gérer l’authentification et les autorisations ainsi que la validation des données des flux.

GDIA : Gestion des identités et des accès.

On en revient finalement toujours au même, lorsque des données et services sont sensibles il est donc nécessaire de les protéger par deux mécanismes classiques : l’authentification et l’autorisation.
Néanmoins ce n’est pas toujours évident à mettre en place sur un Web Service, on ne peut pas simplement mettre un formulaire devant comme sur un site web.

SOAP dans sa souplesse, découpe ses messages en deux parties : un header et un body.
Le body est normalement prévu pour ne contenir que des notions orientées métier. Le header quand à lui est là pour recevoir toutes les notions techniques nécessaires au web service.
C’est donc lui que nous allons utiliser pour contenir les informations d’authentification et d’autorisation.
Les protocoles de sécurité de Web Service tel que WS Sécurity et ses consorts se basent tous sur ce header soap.

De manière un peu généraliste, une bonne pratique est de mettre en place un web service d’authentification. Celui lui ne sera pas filtré car il faut bien qu’il soit appelable la première fois. Il fournira des données de sécurité (comme un jeton unique à durée de vie limitée par exemple) à l’utilisateur qui se sera authentifié via une webmethod prévue à cet effet. L’utilisateur devra ensuite fournir (dans les header soap pour ne pas mélanger les notions techniques et métiers dans le message) son login et son mot de passe ou mieux, ce jeton de sécurité pour chaque appel à vos services métiers.
Côté WebService, un intercepteur devra valider ces données avant de permettre ou rejeter l’appel au service métier.
Cette bonne pratique est de manière très macroscopique le fonctionnement proposé par des protocoles tels que WS Security.

Concernant les mécanismes de gestion des autorisations, nous ne nous étendrons pas sur le sujet car cela peut être soit très simple (read/write ou user/admin) soit très complexe et nécessiter un article complet rien que sur le sujet. On peut toutefois facilement imaginer un intercepteur branché après l’authentification pour vérifier les droits de l’appelant.
Il est bon aussi de savoir qu’un protocole comme OAuth est tout à fait adapté pour gérer les autorisations d’accès à un WebService, d’autant qu’il est fortement compatible avec les services de type Rest qui sont orientés ressources.

Conclusion

Pour conclure il ne faut jamais oublier qu’un WebService est une porte d’entrée vers votre application. Le sécuriser est donc important.
La majorité des failles présentés dans cet article à titre informatif sont couvertes par les frameworks de WebService modernes (Pour java : CXF, Métro, JBossWS ….).
Néanmoins il est important de s’assurer de l’identité et des droits de l’appelant avant de le laisser appeler vos méthodes métiers.
Enfin le cryptage du canal d’échange, quelque soit le moyen, est un très bon levier de sécurité mais comme nous l’avons vu il ne mitige qu’une partie des risques.
La mise en place de signature numérique est aussi un élément aujourd’hui très fiable pour valider la non répudiation de vos messages.
Dans bien des cas, comme dit en introduction, une basic authentification HTTP sur un canal HTTPS s’avèrera suffisant et plus justifié que la mise en place d’outils évolués et relativement complexes à mettre en place tels que WS Security. Il faut donc bien mesurer le besoin et le confronter au risque avant de décider quel niveau de sécurité engager.
Toutefois n’oubliez pas que la notion la plus importante est toujours la validation des données envoyés par vos utilisateurs !

Dans un prochain article je vous présenterais les notions apportées par des protocoles de sécurité de web services tels que WS Security, XML Signature ou XML Encryption.

Suggestion d'articles :

1. Sécurité des services web – 1ère partie
2. HTML5, offline et sécurité
3. GWT et sécurité, se prémunir des CSRF

Votre RSSI vous demande d’intégrer vos applications Flex/BlazeDS à Active Directory ? Vous pourriez le faire via le protocole LDAP, mais pourquoi ne pas offrir plus de confort à vos utilisateurs en leur évitant de taper une énième fois leur mot de passe ? Faites-vous aimer de vos utilisateurs en intégrant votre application au SSO natif d’Active Directory !

Intéressons-nous à une application web disposant d’une partie client codée en Flex, qui communique avec les services métier par le biais d’un canal BlazeDS. Avant de pouvoir utiliser ces services par le biais de l’interface Flex, les utilisateurs doivent s’authentifier avec leur compte Active Directory. Cet article expose la manière de rendre l’authentification transparente en tirant profit du protocole de SSO Kerberos intégré à Active Directory.

L’idéal serait de laisser BlazeDS se débrouiller seul avec Kerberos, malheureusement hors de la sempiternelle combinaison login/mot de passe, le mécanisme d’authentification de BlazeDS est totalement perdu. Mais comme un canal BlazeDS, ça reste un web-service Java, profitons des capacités de ce dernier ! Entre alors Spring Security.

Le framework Spring Security fournit aux applications Java un panel de manières de gérer l’authentification. Depuis sa version 3, la configuration du framework en xml est devenue assez simple. Et, joie, Spring Security supporte Kerberos par le biais d’un module récent. Tous les composants de notre architecture sont maintenant identifiés, reste à les faire communiquer.

Architecture

Le diagramme suivant résumé les interactions entre les différents modules applicatifs qui permettent à l’extension Kerberos de Spring Security pour protéger le canal BlazeDS en SSO.

Kerberos et Active Directory

Publié par le MIT dans les années 80, le protocole Kerberos est le mode d’authentification par défaut sous Active Directory depuis Windows 2000. Il remplace le protocole NTLM qui n’est plus recommandé par Microsoft.

Le fonctionnement de Kerberos est basé sur des échanges de tickets avec un contrôleur de domaine. Le schéma suivant représente l’enchaînement d’opérations mis en œuvre lorsqu’un poste client tente d’accéder à un service protégé par Kerberos :

• (1) L’utilisateur ouvre sa session Windows en s’authentifiant avec son mot de passe Active Directory.
• (2) Le poste de travail récupère alors auprès du contrôleur de domaine un ticket dit TGT (Ticket Granting Ticket).
• (3) Lorsque l’utilisateur veut accéder à un service qui requiert une authentification Kerberos, Windows demande au contrôleur de domaine de lui fournir un ST (Service Ticket) pour le service précisé. Le ST est chiffré, et seul le service possède la clé de déchiffrement.
• (4)Le contrôleur de domaine remet au poste client un Service Ticket, valable uniquement pour le service spécifié.
• (5)Le poste client peut alors s’authentifier auprès du service, sans demander son mot de passe à l’utilisateur.

Pour identifier le service demandé et générer le Service Ticket adéquat, le contrôleur de domaine identifie les services par leur Service Principal Name (SPN). Chaque service est enregistré comme un compte utilisateur Active Directory. A partir de ces comptes, le contrôleur de domaine génère au préalable à toute authentification la clé qui permettra au service de valider les Service Tickets envoyés par les clients, et l’associe à un SPN donné en paramètre de l’outil ktpass qui génère les clés.  Dans le cas d’un service web, notre SPN est de la forme HTTP/serveur-app.octo.com@DOMAINE-AD.

Le service accédé dans notre architecture sera bien entendu la partie serveur de notre application Flex. Voyons comment intégrer cette dernière au système d’authentification Kerberos.

Configuration de BlazeDS

Spring Security s’intègre à BlazeDS grâce au projet Spring-Flex, malheureusement ce support se limite actuellement aux authentifications de type utilisateur/mot de passe. Impossible donc de profiter des facilités de Spring-Flex pour l’authentification par SSO. La solution alternative que nous avons mise en place est détaillée ci-dessous.

Nous utilisons les filtres Spring Security sur les URLs pour protéger deux types de ressources :

• Les ressources statiques de l’application (html, css, …), et notamment le fichier .swf qui forme la partie cliente de l’application
• L’endpoint BlazeDS (le côté serveur du canal BlazeDS)

Le fichier de configuration de Spring Security se présente alors comme suit :

<sec:http entry-point-ref="spnegoEntryPoint" auto-config="false">

  <sec:intercept-url pattern="/**" access="IS_ AUTHENTICATED_FULLY"  />

  <sec:custom-filter ref="spnegoAuthenticationProcessingFilter" position="BASIC_AUTH_FILTER" />

</sec:http>

La ligne intercept-url exige que l’utilisateur soit authentifié. La ligne custom-filter précise que l’authentification se fera par le protocole SPNego (voir ci-dessous).

Lors de l’accès du navigateur à une de ces URLs, Spring Security déclenche l’authentification et déclenche des échanges suivant le protocole SPNego. SPNego est un protocole qui permet de négocier le mode d’authentification utilisé (par exemple NTLM ou Kerberos) en fonction des capacités communes au client et au serveur. La négociation se matérialise par une réponse HTTP (code 401) de la part du serveur d’application, qui contient les headers SPNego précisant que le serveur supporte Kerberos.

Une fois que le navigateur et le serveur se sont accordés sur l’utilisation du protocole Kerberos, le navigateur utilise l’API Windows pour demander au contrôleur de domaine un Service Ticket pour le serveur d’applications. Le ticket est ensuite validé par l’extension Kerberos de Spring Security en utilisant la clé de service créée précédemment par le contrôleur de domaine.

Si le ticket est validé, l’utilisateur est authentifié et  les mécanismes d’habilitation (Rôles, ACLs) de Spring Security entrent en jeu pour autoriser ou refuser l’accès à une ressource donnée. Les habilitations sont totalement indépendantes de Kerberos.

Petite surprise offerte BlazeDS : l’utilisation d’un channel HTTPs avec BlazeDS (SecureAMFEndpoint) impose d’utiliser un mécanisme de login matérialisé côté serveur par une classe LoginCommand. Nous avons donc implémenté notre propre LoginCommand (PreAuthLoginCommand) qui… n’effectue aucune vérification, l’authentification ayant déjà été effectuée par Spring Security/Kerberos.

public class PreAuthLoginCommand implements LoginCommand, LoginCommandExt {

  public Principal doAuthentication(String username, Object credentials) {
    //On n’effectue aucune verification !
    logger.info("doAuthentication " + username + ", returning a PreAuthPrincipal");
    return new PreAuthPrincipal(username);
  }

  public boolean doAuthorization(Principal principal, List arg1) {
    logger.info("doAuthorization " + principal + ", returning true");
    return true;
  }
…
}

Pour aller plus loin

Cet article passe sous silence la configuration du poste client. Elle est très simple et se résume en deux points :

• Utiliser un navigateur compatible avec SPNego et Kerberos (Internet Explorer, Firefox et Chrome le sont)
• Indiquer au navigateur que votre application est un site de confiance, et qu’à ce titre il est autorisé à lui transmettre des tickets Kerberos. Cette configuration peut être déployée sur un parc de machines en utilisant les stratégies de groupe (GPO) d’Active Directory

Pour plus de détails, voyez la section « Références » ci-dessous.

Une idée pour terminer et peaufiner la sécurité de votre application : offrez à vos utilisateurs la possibilité de se dé-logger de la session Kerberos et repasser à une authentification par mot de passe, pour permettre à un autre utilisateur que le détenteur du compte Active Directory de s’authentifier.

Références

• La documentation de l’intégration Spring-Security/BlazeDS, qui ne fonctionne que pour une authentification de type utilisateur/mot de passe :
  http://static.springsource.org/spring-flex/docs/1.5.x/reference/html/#security
• The Spring Security Kerberos extension:
  http://static.springsource.org/spring-security/site/extensions/krb/index.html
• The extension’s manual (including Internet Explorer configuration) :
  http://blog.springsource.com/2009/09/28/spring-security-kerberos/
• A guide to enable Kerberos in Firefox :
  http://grolmsnet.de/kerbtut/firefox.html
• A guide to enable Kerberos in Chrome :
  https://sites.google.com/a/chromium.org/dev/developers/design-documents/http-authentication

Suggestion d'articles :

1. Quand Spring s’invite dans une application Flex …
2. Sécurisation à double référentiel avec JBOSS
3. Flex vs Silverlight

La dernière fois nous avons vu comment réparer, sous certaines conditions, la FAT de votre partition.

Dans cette dernière partie nous allons voir quoi faire lors d’un crash physique de disque dur. Comme pour les articles précédents, c’est en anglais.

Suggestion d'articles :

1. Comment sauver vos données, 1/3
2. Comment sauver vos données, 2/3
3. Ranger sa chambre, ou l’archivage de données

Nous avons vu la dernière fois comment sauver grâce à testdisk une partition malencontreusement effacée.

Nous allons voir dans cet article comment récupérer, sous certaines conditions, la table d’allocation de fichier de votre partition.

Comme précédemment, l’article est en anglais ici.

Suggestion d'articles :

1. Comment sauver vos données, 3/3
2. Comment sauver vos données, 1/3
3. Consistent Hashing ou l’art de distribuer les données

Cette série de 3 articles, basée sur une histoire vraie, va vous conter comment sauver (les données de) votre disque dur quand celui-ci vous annonce sa décision de ne plus fonctionner, soit de part sa vieillesse, soit par erreurs de votre part.

Vous retrouverez les protagonistes suivant :

• Dans le rôle des méchants : sfdisk, pvcreate et la fainéantise
• Dans le rôle des gentils : testdisk, photorec, dd, ddrescue et la matière grise.

En avant pour le premier, en anglais, qui traite de la suppression de partitions.

Je m’inscris au petit-déjeuner OCTO : infocentre de Sécurité

Suggestion d'articles :

1. Petit-déjeuner : Comment bâtir votre Cloud ? 15 novembre
2. OCTO organise un petit-déjeuner sur l’agilité, jeudi 12 novembre
3. OCTO organise un petit-déjeuner Gestion des Identités le 27 janvier – Témoignage d’Air Liquide

Un article récent publié sur InfoQ abordait la sécurité de HTML5 dans sa globalité, et notamment sur des attaques concernant les nouvelles fonctionnalités de navigation hors-ligne de HTML5.

Quelles sont donc ces fonctionnalités et qu’en est-il vraiment des risques associés?

Rappel historique

La seule possibilité pour une application web HTML/JavaScript de stocker des données dans un navigateur était jusqu’à récemment de les stocker dans un cookie. Limités en taille (la spécification exige seulement des navigateurs qu’ils puissent gérer 4096 octets par cookie!), parfois refusés par les navigateurs et nettoyés régulièrement, et assimilés à des logiciels espions par les antivirus, leur fiabilité restait très limitée.
D’autres technologies à base de plugins, comme Adobe Flash, utilisaient des procédés propriétaires ne répondant pas aux normes du W3C (les « super cookies« ) et très critiquées pour leur opacité (manque de contrôle pour l’utilisateur pour savoir quelles informations sont stockées ou les supprimer). En 2007, Google a sorti Google Gears qui a permis de stocker des données dans le navigateur sous la forme d’une base de  données relationnelle et de disposer en local d’un cache de ressources (cf. les articles publiés par Olivier Mallassi sur le blog OCTO).

Cette nouveauté a permis le développement de véritables applications web stockant un nombre conséquent de données en local, permettant un fonctionnement déconnecté de l’application et une meilleure réactivité en évitant d’inutiles aller-retours avec le serveur. L’exemple le plus marquant étant naturellement le client mail de Google, Gmail, qui innovait en plus avec le « flaky mode » où l’utilisateur naviguait en permance en local, utilisant les ressources stockées dans son navigateur, et où l’application mettait à jour ces données quand une connexion à Internet était disponible. Cependant, Google Gears restait un produit de Google, et son implémentation sur les navigateurs n’était pas garantie.

Le groupe de travail sur HTML5, auquel contribue fortement Google, a alors déclaré vouloir inclure dans la spécification HTML5 des normes de stockage local s’inspirant de Google Gears. En parallèle, début 2009, Google a d’ailleurs arrêté le développement de Google Gears, au profit de l’implémentation de la norme HTML5.

Cette normalisation contraint déjà les navigateurs web à implémenter ces mécanismes, entraînant à coup sûr une démocratisation de leur utilisation par les applications web.

Quels sont les risques liés au stockage local?

Parmi les sites précurseurs dans l’utilisation de stockage local se trouvent les webmails. Les données stockées dans  le navigateur sont donc les courriers électroniques de l’utilisateur, qui sont des données très critiques par-rapport au respect de la vie privée, sans parler des cas où certains mails contiendraient des données plus sensibles, comme un numéro de compte bancaire…
Il convient donc impérativement de s’assurer qu’aucun tiers ne puisse accéder à ces données.

Quels sont les mécanismes de stockage local?

HTML5 prévoit deux systèmes de stockage de données en local :

• le Web Storage, comprenant local storage, toujours accessible à l’application et permettant par exemple à des onglets différents de partager des données, et le session storage, accessible uniquement à une fenêtre donnée. Les données sont stockées sous la forme de clés/valeurs,
• la Web SQL Database fournissant cette fois une base de données relationnelle, implémentée par les navigateurs avec SQLite. Signalons au passage que le choix de SQLite a été fait par les éditeurs de navigateurs au détriment de la proposition initiale de « Indexed DB » proposée par le W3C.

Un autre système de stockage local est fourni sous la forme de caches permettant cette fois-ci de stocker des ressources (images, fichiers JavaScript, etc.) et non plus des données.

Dans leurs spécifications respectives, le W3C aborde la sécurité, et décrit les mêmes problématiques pour les deux.

Quels risques et quelles protections?

La seule protection spécifiée par le W3C concerne l’origine des sites : des données stockées par un site A ne doivent pas être visibles pour un site B, en se basant sur l’hôte du site et le port. Cela empêche par exemple une iframe inclus dans un site, typiquement un encart publicitaire, d’avoir accès aux données stockées localement par ce site.

Ce systèmes ne protège pas de certaines attaques, d’ailleurs décrites dans la spécification :

- les attaques par usurpation de DNS, qui consistent à usurper une adresse IP d’un serveur pour envoyer des paquets à sa place. Ce risque sera toutefois mitigé en utilisant SSL, et concerne le web dans sa globalité.

- le partage de nom d’hôte entre plusieurs sites : si le site d’adresse http://www.mon-site.com/site1 stocke des données, un autre site d’adresse http://www.mon-site.com/site2 y aura accès sans resctriction. Le risque étant faible de se faire attaquer par ce biais, car on a déjà fait confiance au premier site.

On remarquera que les attaques par XSS (cross site scripting) ne sont pas mentionnées et constituent pourtant un risque important, bien mis en valeur par l’OWASP. On pourra le mitiger avec notamment un contrôle du code côté serveur et une validation des données passées dans les formulaires.

La spécification ne prévoit pas d’autre mécanisme de sécurité.

Un point très important n’est pas abordé dans la spécification et pourrait pourtant s’avérer crucial : la spécification ne prévoit que les données stockées en base locale soient cryptées, elles sont toujours stockées en clair.
Ce point a été soulevé par Nicholas C. Zakas (un des référents mondiaux sur le langage JavaScript notamment, qui contribue à HTML5). Il a même proposé une proposition très détaillée d’évolution de la spécification vers un cryptage des données, décrite dans ce billet.
Dans ce système, un serveur d’application web aurait la responsabilité de chiffrer les données sur le client, avec une clé de cryptage gérée par l’application. Concrètement, une application web devrait exécuter la méthode Javascript suivante pour ouvrir la connexion en base de données :

window.openSecureStorage("mystorage", window.AES_128, key, function(storage){
//use storage object
});

L’application web choisirait donc l’algorithme de cryptage et la clef. Ainsi, même si un attaquant parvenait à récupérer des données, il ne pourrait les exploiter. On remarquera d’ailleurs que sans cryptage, toute personne ayant acccès physiquement au poste client pourra lire toutes ces données…

Bien que sa proposition soit assez complète et détaillée, il n’y a pas encore eu de suite à ma connaissance de la part d’autres acteurs du web.

On peut tout de même se rassurer concernant les postes publiques (cyber cafés, etc.). En effet, les données sont stockées dans le navigateur dans un profil créé pour l’utilisateur, qui est normalement effacé lorsqu’il quitte le poste et que le compte est ré-initialisé, ce qui doit être l’usage pour ce type de poste. L’utilisateur devant tout de même s’en assurer, ce qui est loin d’être évident pour un utilisateur non initié. Il est ici plus question d’éducation des utilisateurs que de technologie.

Enfin, les caches peuvent quant à eux être attaqués par « Cache poisoning ». L’objectif de l’attaquant est alors d’injecter dans le cache du navigateur un fichier JavaScript en remplacement d’un fichier fourni par le serveur « sain », et dont le script malicieux serait exécuté par le client. Ce risque est à prendre en compte particulièrement dans les réseaux wifi ouverts comme on en trouve par exemple dans des restaurants, mais si ces attaques sont difficiles à détecter et à contrer, le risque s’avère relativement faible d’après les conditions requises pour permettre l’attaque, citées par l’OWASP.

Conclusion

Malgré cette énumération de risques, qui plus est incomplète, il convient d’insister sur le fait qu’ils ne sont pas spécifiques à HTML5 mais au contraire inhérents au web depuis ses débuts.
La nouveauté avec HTML5 est qu’il offre la possibilité de faire des application plus riches, stockant plus de données localement.
Cela doit simplement inciter les concepteurs et développeurs d’applications web à une certaine vigilance concernant la sécurité des données locales, mais ne vous y méprenez pas, HTML5 constitue bien dès aujourd’hui une formidable opportunité pour vos applications web!

Suggestion d'articles :

1. HTML5 : la promesse d’un browser qui devient VM
2. Tous les navigateurs acceptent HTML5 et CSS3
3. Applications natives ou web HTML5 pour mon mobile ?

Les architectures d’exécution « modernes » comme Java et .Net ont apporté des gains indéniables comme la standardisation de l’infrastructure, portabilité, sécurité, performances dans certains cas, l’outillage pour les développeurs …

Dans ces environnements, on peut obtenir facilement le code source de l’application à partir d’une application packagée (JAR/WAR/EAR ou EXE/DLL). Il suffit d’utiliser un « décompilateur », par exemple jad, JD ou Jode dans le monde Java, et .Net Reflector pour .Net. Il n’existe pas de solution équivalente dans le cas de code natif (par exemple produit par un compilateur C/C++).

Dans certains cas, cela n’est pas souhaitable :

• Si mon application contient des algorithmes qui constituent un avantage concurrentiel pour ma société et que le code est facilement accessible (par exemple si l’application est distribuée sous forme de client lourd). On peut citer par exemple les algorithmes de pricing dans le domaine de la finance ;
• Un utilisateur qui a accès à l’application peut la modifier pour contourner un mécanisme de contrôle de licence ou contourner des mécanismes de contrôle d’accès implémentés dans le code client.

Ces exemples s’appuient sur des solutions qui sont rarement choisies en cible pour les nouvelles applications (client lourd, contrôle d’accès sur le client …), mais beaucoup d’applications « legacy » sont bâties sur ces principes et modifier l’architecture d’une application existante peut se révéler très coûteux voire irréalisable à court-terme.

Les outils d’obfuscation (anglicisme, en français je n’ai trouvé que « obscurcissement » ou « offuscation » qui ne correspondent pas vraiment) proposent de remédier à ce problème. Ils modifient le code compilé (byte code Java,IL ou Intermediate Language en .Net) afin de le rendre incompréhensible. Certains produits annoncent même être capables de bloquer le fonctionnement des décompilateurs.
On peut donc se poser la question de l’efficacité de tels outils. Je vais essayer d’apporter des éléments de réponse au travers 2 articles :

• Ce premier article « Obfusquez vous ? » expliquera leur fonctionnement des outils d’obfuscation au travers d’exemples concrets ;
• Le deuxième article « Protégez vous ! », plus à destination des chefs de projet et architectes, permettra de s’écarter du code et prendre le recul nécessaire et proposera des bonnes pratiques, des éléments de démarche et des solutions alternatives lorsqu’on souhaite protéger son code.

Voici donc les exemples de code :

Premier exemple : obfuscation basique
Ce premier exemple présente un mécanisme simple et implémenté par tous les outils du marché. Il consiste à renommer tous les symboles (noms de classes, méthodes, packages …). Les informations de « debug » (numéros de lignes, noms de variables locales …) sont aussi supprimées pour limiter les informations disponibles sur le code original.
Voici le code original de notre exemple :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

package com.octo.pokermanager.core;
 
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.util.HashMap;
import java.util.Map;
 
import com.octo.pokermanager.client.model.Tournament;
import com.octo.pokermanager.exception.InitializeException;
 
public class TournamentPersisterSerialisableImpl implements TournamentPersister {
 
	private Map< String , Tournament > tournaments = null;
	public static final String DB_FILE_NAME = "persist.db";
 
	/*
	 * @see
	 * com.octo.pokermanager.server.TournamentPersister#save(com.octo.pokermanager
	 * .client.model.Tournament)
	 */
	public void save(Tournament tournament) {
		if (tournament.getName() == null) {
			throw new IllegalArgumentException(
					"Tournament name should not be null [tournament:"
							+ tournament + "]");
		}
 
		tournaments.put(tournament.getName(), tournament);
		try {
			persistInFile();
		} catch (IOException e) {
			//TODO : do something
			e.printStackTrace();
		}
	}
 
	private void persistInFile() throws IOException {
		FileOutputStream underlyingStream = new FileOutputStream(DB_FILE_NAME);
		ObjectOutputStream serializer = new ObjectOutputStream(underlyingStream);
		serializer.writeObject(tournaments);
		serializer.flush();
		underlyingStream.flush();
		serializer.close();
		underlyingStream.close();
	}
// ...

Et voici le code récupéré après passage d’un obfuscateur et décompilation :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

package a.a.a.b;
 
import a;
import a.a.a.a.a.i;
import a.a.a.d.a;
import java.io.*;
import java.util.HashMap;
import java.util.Map;
 
public class c
    implements a.a.a.b.a
{
    private Map a;
 
    public void a(i j)
    {
        if(j.M() == null)
            throw new IllegalArgumentException((new StringBuilder()).append(a.a("nTLHPZP_\\O\021TWVP\032YSFOB_\rTMO\001XC\033KOvW9ajThH|Z|_xOo")).append(j).append(a.a("\b")).toString());
        a.put(j.M(), j);
        try
        {
            B();
        }
        catch(IOException ioexception)
        {
            ioexception.printStackTrace();
        }
    }
 
    private void B()
        throws IOException
    {
        FileOutputStream fileoutputstream = new FileOutputStream("persist.db");
        ObjectOutputStream objectoutputstream = new ObjectOutputStream(fileoutputstream);
        objectoutputstream.writeObject(a);
        objectoutputstream.flush();
        fileoutputstream.flush();
        objectoutputstream.close();
        fileoutputstream.close();
    }
// ...

On remarque sur cet exemple qu’un même nom de symbole a été utilisé plusieurs fois pour réduire encore la lisibilité du code.

On peut aussi remarquer que les chaînes de caractères ont été chiffrés (cf. ligne 18) par la fonction de « string obfuscation » proposée par certains produits. Son objectif est de masquer des informations présentes dans le code comme des mots de passe ou autre information sensible. Le lecteur attentif aura remarqué que le code permettant de déchiffrer ces informations se trouve quelque part en clair dans l’application packagée et qu’il est facile de le retrouver.

Deuxième exemple : obfuscation « avancée »
Le dernier mécanisme étudié ici est le « control-flow obfuscation » (obfuscation des structures de contrôle). En Java et .Net, les structures de contrôles du langage (if, for, while, exceptions …) se traduisent en byte code par des branchements simples (l’équivalent d’un « goto » pour ceux qui s’en souviennent). Il est possible d’écrire du byte code correct qui ne correspond à aucune structure de contrôle du langage de haut niveau,

Un obfuscateur va donc modifier légèrement une classe de manière à ne pas modifier son comportement, mais à faire échouer un décompilateur, ce qui se traduit en général par un résultat faux du décompilateur (code qui ne compile pas, ou qui n’est pas équivalent au code original), ou même faire planter le décompilateur.

L’impact du « control flow obfuscation » est très variable selon les produits.

Voici le code original :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

package com.octo.pokermanager.client.model;
import java.io.Serializable;
import java.util.List;
 
public class RandomPlayerSelector implements Serializable, PlaceSelector {
	public void reorderPlayers(List< Players > players) {
		Player tmp = null;
		int nbPerm = players.size();
		while (nbPerm>0) {
			int i = (int) Math.round(Math.random()*(players.size()-1));
			int j = nbPerm---1;
			tmp = players.get(i);
			players.set(i, players.get(j));
			players.set(j, tmp);
		}
	}
}

Et le code obfusqué décompilé :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

package a.a.a.a.a;
import java.io.Serializable;
import java.util.List;
 
public class k
    implements Serializable, d
{
    public void a(List list)
    {
        Object obj = null;
        int i = list.size();
_L3:
        JVM INSTR ifle 83;
           goto _L1 _L2
_L1:
        int j = (int)Math.round(Math.random() * (double)(list.size() - 1));
        int i1 = i-- - 1;
        l l1 = (l)list.get(j);
        list.set(j, list.get(i1));
        list.set(i1, l1);
        i;
          goto _L3
_L2:
    }
}

Le décompilateur n’a donc pas su produire du code recompilable.

Conclusion
Cette description n’est pas exhaustive, il existe d’autres mécanismes comme par exemple :

• l’injection de code mort (code non appelé, ou n’ayant pas d’impact sur le fonctionnement du code) dans le corps des méthodes pour réduire la lisibilité ;
• le remplacement de code par du code équivalent fonctionnellement (par exemple avec de l’ »inlining » de méthodes, ajouts de tests toujours vrais, etc …);
• le chiffrement des fichiers jar ou assembly (il ne s’agit pas d’obfuscation à proprement parler).

On peut donc se demander si ces outils sont réellement efficaces ? S’il existe des moyens de contournement ? D’autres méthodes plus efficaces sont-t-elles à privilégier ?

Mon prochain article essaiera de répondre à ces questions et abordera en particulier les points suivants :

• Quelles sont les limitations des obfuscateurs ?
• Quelles sont les bonnes pratiques pour réussir la mise en œuvre d’un outil d’obfuscation ?
• Les outils d’obfuscation se présentent comme des « moulinettes » qui protègent automatiquement le code et les coûts de licence de ces produits sont en général raisonnables, donc à première vue le coût de mise en oeuvre ne semble pas important. Mais y-a-t-il des coûts cachés ? Quel est l’impact sur le processus projet ?
• Existe-t-il des solutions alternatives ?

En attendant, n’hésitez pas à réagir sur ces exemples et sur l’obfuscation en général.

Suggestion d'articles :

1. « Obfusquez-vous ? » Saison 2
2. Et si vous rendiez vos applications Web Offline [Part #3]
3. Et si vous rendiez vos applications Web Offline [Part #2]

La Mobile Payment Expo 09 s’est déroulée à Paris les 17 et 18 Juin 2009. C’était une occasion de découvrir une nouvelle activité regroupant différents acteurs : les banquiers, les opérateurs téléphoniques et les fournisseurs de service (software et hardware).

L’expansion rapide de la banque mobile

La banque mobile peut être définie comme étant la possibilité de réaliser des opérations bancaires via un téléphone mobile. Ces activités bancaires sont principalement :

• Le « mobile payment » pour les paiements et les achats via le téléphone mobile.
• La remittance (1) nationale et internationale pour les transferts d’argent.

Ces opérations sont classiques et peuvent être réalisés par internet. Cependant, l’innovation concerne la mise à disposition de celles-ci pour des personnes non bancarisées et également offrir de nouveaux services :

• Charges en urgence des cartes prépayées.
• Offrir la possibilité de souscrire des contrats (assurance, garantie…) directement à partir de son téléphone portable en utilisant l’appareil photo intégré pour envoyer une photo de l’annonce ou du contrat à sa banque.
• Le crédit mutuel a même mis en place un coffre fort bancaire pour les papiers officiels simplement pris en photo avec le téléphone mobile.

Le crédit mutuel s’est clairement positionné sur ce nouveau marché. Un service pilote lancé en Février 2009 compte déjà 400 000 clients, IBM, de son coté, présente son expérience avec deux projets mondiaux réussis :

• Au japon, une banque a développé toute son activité sur un seul canal : le téléphone mobile avec le canal internet en backup. Par exemple, pour souscrire à un contrat et rejoindre leurs services, il suffit de prendre en photo les papiers officiels avec le téléphone mobile et de les envoyer par MMS pour que le contrat soit conclu.
• Au Corée du sud, une carte à puce multi-services peut servir comme une carte SIM pour le téléphone mobile, une carte de crédit, un coffre fort de mots de passe et même comme clé pour le véhicule. Cette carte permet de réaliser de vraies transactions bancaires. La Corée du sud compte déjà 30 millions d’utilisateurs de cette carte.

Gemalto (un fournisseur de solutions technologiques pour la banque mobile) résume le marché de la banque mobile en deux segments : les clients bancarisés et ceux qui ne le sont pas. Ces populations sont réparties sur trois zones de pays en voie de développement : Amérique latine (principalement la Colombie et le Mexique), l’Afrique (pays subsahariens) et l’Asie. Cependant des freins et des pistes d’amélioration existent et couvrent deux aspects :

• La sécurité : au travers de l’identification, le contrôle d’accès, la confidentialité des échanges, l’intégrité des données et la non répudiation.
• L’usabilité des interfaces, l’ergonomie et qualité du service : ces points seront couverts avec une amélioration de la bande passante et un réseau de qualité.

Le transfert d’argent par Mobile en pleine croissance

Les rapports estiment à 250 millions de dollars le montant des transferts mobiles mondiaux en 2008. Ce marché très prometteur a vu l’émergence de beaucoup de solutions :

• La plateforme « Flouss.com » : permet le transfert d’argent entre particuliers en utilisant  les cartes prépayées. La plateforme travaille en association avec MasterCard et Western Union et assure un transfert en temps réel.
• VISA n’est pas resté en retrait sur ce segment du marché en développant des initiatives autour du paiement de proximité (la technologie NFC (2)), le transfert d’argent par mobile (entre particuliers et à destination de l’étranger) et également le paiement en ligne avec le mobile.
• La caisse d’épargne est en train de développer des offres autour du NFC P2P et le transfert de l’argent mobile à l’international.

Les fournisseurs de solutions ou de services sont aussi assez présents sur le marché. C’est le cas d’Eserv Global, un fournisseur de solution pour opérateur mobile, qui a mis sur le marché une solution de transfert d’argent de mobile à mobile certifié GSMA (3). Cette solution consiste à mettre à disposition des utilisateurs un ensemble d’APIs libres permettant l’accès à leur hub.

La « success strory » la plus connue est le transfert d’argent par mobile M-Pesa (service de Safaricom et de Vodafone) au Kenya avec 6,5 millions d’utilisateurs. Cette initiative vise à résoudre le problème local de banking avec un niveau de bancarisation très bas de la population mais paradoxalement un niveau de possession de téléphone portable assez élevé (exemple l’Afrique du sud, entre 8 et 12% de la population est bancarisée mais plus de 95% possèdent un téléphone mobile). Ces initiatives locales sont difficilement dissociables des projets internationaux de remittance car les flux entrants alimentent les systèmes locaux. D’où le besoin de création de corridors internationaux à destination surtout des pays en voie de développement. Les couples émetteur – récipiendaire couvre une large palette de solutions possibles :

• Pour l’émetteur : cash, compte, téléphone mobile ou portefeuille électronique.
• Pour le récipiendaire (4) : téléphone mobile, carte prépayée et DAB.  Le problème pour cette catégorie est le manque d’agence bancaire pour la gestion locale.

Cet engouement pour le transfert mobile d’argent exige principalement la gestion de deux risques majeurs :

• Le blanchiment d’argent : Ce risque exige la supervision de toutes les transactions et la mise en place d’une réglementation pour encadrer toute l’activité.
• La gestion de la sécurité des transactions et des données sur le téléphone mobile. Pour pallier à ce risque, les acteurs concernés travaillent sur la mise en place de solutions de sécurité forte (software et hardware) et des passerelles sécurisées.

Le rôle du mobile dans la sécurité des transactions sur internet

Les transactions en ligne sont déjà nombreuses (paiement, achat, transfert d’argent…) mais sont appelées à augmenter significativement dans un futur proche avec l’apparition de nouveaux services (e-justice, vote…). De multiples solutions sont à disposition pour sécuriser ces transactions :

• Les mots de passe statiques.
• Les mots de passe dynamiques : OTP (One Time Password).
• Les certificats électroniques : PKI (Public Key Infrastructure).

D’un autre coté, les transactions frauduleuses se développent avec la croissance d’internet avec 2 grandes variantes:

• Les fraudes à la carte bancaire : en 2007, ces fraudes ont significativement augmenté pour devenir pratiquement équivalentes aux fraudes dans les commerces de proximité.
• Le Phishing : afin d’obtenir les renseignements personnels des internautes.

Afin de remédier à ces menaces sur le téléphone mobile, de nombreuses solutions d’identification forte existent ou sont en cours de développement :

• Les solutions OTP online :
  • OTP / SMS : c’est la solution classique d’envoi de mot de passe dynamique par SMS.
  • OTP / USSD et OTP / SMS+ : pour ces deux solutions, la demande est à l’initiative du mobile.
  • OTP / SVI : orienté téléphone fixe.
• Les solutions OTP offline :
  • Magasin d’OTP : le magasin est stocké dans le mobile et consommé au fur et à mesure.
  • Génération d’OTP : un device est utilisé pour générer des mots de passe dynamiques.
• Les solutions OTP sans ressaisie : pas de saisie manuelle, l’OTP est transcodé et renvoyé au serveur par le canal adapté
  • OTP Audio
  • OTP Visuel
• Les solutions PKI mobile : une clé privée et un certificat sont stockés sur la carte SIM.

Il existe également des solutions de signature électronique basée sur un certificat. Et on distingue:

• Une signature électronique simple, stockée sur un média non sécurisé (exemple la signature pour les impôts)
• Une signature électronique sécurisée / qualifiée, stockée sur un média sécurisé (exemple la signature d’un contrat électronique). La carte SIM est considérée comme un média sécurisé.

Les bénéfices de la signature électronique sont

• Gain de productivité : dématérialisation des certificats.
• Développement durable.
• Accroissement des ventes : contractualisation en temps réel.
• Réduction des files d’attente aux guichets par anticipation des signatures.

La carte SIM associée au mobile est la meilleure solution pour répondre aux besoins actuels et futurs d’authentification et de signature électronique car le dispositif se distingue grâce à des caractéristiques clés : sécurisé, universel et interactif.

La vraie nouveauté de NFC, c’est le mode P2P

La technologie la plus aboutie est le NFC (Near Field Communication) qui est un mode de communication basé sur une technologie d’échanges de données en champ proche avec une courte portée (quelques centimètres). Il a été standardisé par plusieurs organismes : ISO, ECMA, ETSI et NFC Forum. Le NFC prend en charge trois types de fonctionnement :

• Emulation de cartes : le terminal mobile émule le fonctionnement d’une carte à puce sans-contact. Ce mode de fonctionnement requiert un élément sécurisé, la carte SIM dans le cas des téléphones portable. Ce mode est généralement utilisé pour les paiements et les contrôles d’accès.
• Lecture de carte ou tags : ce mode permet la lecture des cartes ou des tags passifs sans contact ainsi que le réveil des applications (norme JSR 257).

• P2P (pair-à-pair) : ce mode est le plus intéressant car il implémente un mode de communication symétrique (échange d’information entre les deux appareils). L’une ou l’autre partie peut initier la communication (poser des questions / réponses). Ce mode présente un débit assez intéressant : jusqu’à 424 kbps actuellement et prochainement 1Mbps avec les nouvelles spécifications. Le plus grand avantage de ce mode est qu’il ne requiert pas d’élément sécurisé (la sécurité est supportée par la couche applicative).

Le NFC P2P est une technologie dérivée du RFID avec comme avantages : une plus grande taille des données en échange et 3 modes de fonctionnement différents. Cependant, le NFC P2P a une plus courte portée que le RFID. La comparaison par rapport au Bluetooth est tout aussi intéressante. Le NFC P2P présente un débit inférieur (jusqu’à 24 Mbps pour le Bluetooth) mais il ne nécessite pas d’échange de code pour le pairage contrairement au Bluetooth. Le NFC P2P est plus approprié pour les échanges courts alors que le Bluetooth est destiné aux échanges plus longs. En conclusion, NFC P2P et Bluetooth sont intrinsèquement différents mais peuvent être utilisés d’une façon complémentaire. L’architecture de la technologie NFC est composée de :

• Un « Application Processor » composé essentiellement d’un « midlet ».
• Un « Secure Element », ce composant est généralement une carte SIM qui permet d’assurer la sécurité des communications. L’avantage du mode NFC P2P est de ne pas avoir besoin d’implémenter cette couche « Secure Element ».
• Un « NFC Controller » implémentant l’un des trois types de fonctionnement du NFC (émulations de carte, lecture ou P2P)

Les contraintes du NFC P2P sont :

• Il n’y a pas de sécurité dans le protocole NFC P2P, mais elle peut être assurée par la couche applicative. Un standard de sécurisation, le NFC-SEC, est en cours de finalisation par l’ECMA.
• Le processeur (« midlet ») n’est pas un emplacement aussi sécurisé que la SIM. Cependant, toutes les données ne nécessitent pas une haute sécurité et le stockage local des données peut être crypté avec PIN et décrypté par un serveur sécurisé.
• Le NFC P2P n’est pas encore complètement standardisé. La version finale va être publiée très prochainement, la Release Candidate a déjà été diffusé au NFC Forum par Digital Protocal et LLCP.
• L’utilisation généralisée de la technologie NFC P2P nécessite le déploiement de composants « Full NFC ».

Les exemples d’usage de cette technologie sont nombreux :

• Pairage et échange de contenus multimédias (entre téléphones mobiles).
• Les « Friends Request » sur les réseaux sociaux.
• NFC Ticketless : une utilisation principale pour remplacer les billets de transport et les cartes de fidélité.
• NFC Purse : pour le paiement et le transfert d’argent entre particuliers.

En conclusion, la plus grande contrainte de l’utilisation du NFC P2P est le déploiement nécessitant un équipement spécifique. Egalement, cette architecture légère est destinée principalement aux applications ayant des besoins de sécurité faibles. Malgré ces deux inconvénients, la technologie du NFC P2P présente de nombreux cas d’usage intéressants et d’avenir.

Autres applications du mobile payment

Mobile P2P, du paiement au prêt entre particuliers

Dans ce contexte, mobile P2P (person-to-person) signifie l’envoi d’argent à partir du mobile d’une personne à une autre. Les cas d’usage de ce modèle sortent du modèle du paiement / achat mobile pour viser plutôt l’envoi d’argent dans une communauté (famille ou amis). Quelques exemples sont:

• Remboursement d’une dette ou d’un prêt à un ami.
• Usage communautaire du type collecte d’argent (pour un évènement). Ce type d’usage est communautaire. L’entreprise FriendsClear a implémenté sa solution en vue de répondre à ce besoin. PayPal s’intéresse aussi à ce type d’usage et son application pour iPhone devrait sortir d’ici l’été.
• A une échelle plus grande, on trouve la solution de Babyloan orienté micro-crédit. Des particuliers choisissent les bénéficiaires du crédit et paient la totalité ou une partie du crédit demandé. Le remboursement du prêt sans intérêts se fait au bout de 6 ou 12 mois.

Du m-Commerce au marketing mobile

Un autre contexte d’utilisation très proche de la banque et du commerce mobiles est le marketing mobile qui signifie l’envoi d’offres ciblées sur le mobile. Cette activité est poussée par un ROI plus rapide et une cible plus directe et non plus pour faire simplement de la publicité. Un exemple récent est la campagne lancée par Renault pour sa Twingo Nokia sur les téléphones mobiles qui a généré 130 essais automobiles. Le grand avantage de cette démarche est la réactivité du média mobile considéré comme un média « chaud ». D’un coté, les freins du le m-Commerce sont principalement que l’offre et la cible ne sont pas encore bien claires. D’un autre coté, Les leviers sont bien plus nombreux et concrets :

• Les forfaits data de moins en moins chers et permettant un accès illimité à internet.
• Des téléphones de plus en plus évolués et aboutis.
• Des applications mobiles de plus en plus disponibles et ergonomiques surtout à destinations des smarts mobiles.

Un enjeu important du m-Commerce est la géolocalisation du client permettant l’envoi d’offres ciblées. Les contraintes techniques ont été résolues et des solutions viables sont disponibles pour n’importe quel terminal. Cependant, le consentement des clients d’être localisés et le souhait de ne pas être traqués restent des freins à la diffusion de cette approche à grande échelle.

Conclusion

L’offre de banque mobile regroupe deux acteurs venant de deux mondes différents : les banquiers et les opérateurs téléphoniques. Les premiers sont destinés par définition à gérer les transactions bancaires de tout genre, mais pour développer cette offre de mobilité ils ont besoin de bénéficier de l’étendu des réseaux et des connections téléphoniques mobiles. C’est pour cela que toutes les offres existantes regroupent une banque et un opérateur téléphonique. Historiquement, cette offre de banque mobile était destinée aux pays en voie de développement afin de répondre aux besoins des populations non bancarisés et la rareté des agences bancaires. Cependant, ces offres ont abouti à d’excellents résultats (surtout M-Pesa au Kenya) ce qui a fait naître l’idée d’étendre cette offre aux pays développés pour répondre à des aspects pratiques et de facilité de gestion bancaire avec le téléphone mobile. Les offres techniques et matérielles, la réglementation et les accords banquiers-opérateurs téléphoniques sont en cours de maturation ce qui présage l’explosion de ce marché et des projets associés dans un avenir proche.

Suggestion d'articles :

1. OCTO au salon Mobile IT expo les 18-19-20 octobre – Paris Porte de Versailles
2. Retours sur le JavaCampParis II
3. OCTO au salon Cloud & IT Expo 2011, mercredi 19