Utiliser l’api de recherche Bing

Cet article bien en complément du dernier où j’annonce avoir forké une lib permettant d’accéder simplement à l’API bing search.

Pour utiliser l’API de recherche Bing, il vous faudra obtenir l’autorisation de l’utiliser.

En effet, pour éviter que des abus de soient commis, Microsoft limite le nombre de requêtes opérables par mois sur son API, si vous en voulez plus, il faudra débourser.
La première étape consistera donc à se rendre sur cette page, et d’y sélectionner l’offre qui vous sied le mieux. Un compte Microsoft vous sera demandez, créez-le si vous n’en avez pas.

Continue reading

Interface simple d’accès à BingSearchAPI

Il y a une semaine environ, j’ai eu besoin de chercher une centaine d’image sur le web pour faire un POC d’une appli.

Alors, je me prépare à crawler le site du client. Seulement, dans ce monde javascriptisé, c’est la cata de faire un petit script bâteau qui repère juste les img src.

Alors, partons vers Google: inutile de crawler leur propre page web : elle est en chargement asynchrone. Et google, comme ce sont des gens bien ont décidé de déprécier leur API google search image. Je ne sais même pas si elle est encore opérationnelle.

“Alors”, me dis-je, “allons chez le concurrent direct, vive le marché libre !”.

Continue reading

Rendre accessible à l’émulateur WindowsPhone un site local

Dans notre projet actuel, nous avons une application WindowsPhone qui doit contacter une API que nous développons à côté.

Outre l’environnement de preprod que nous allons rapidement mettre en place (Azure), la totalité de nos tests unitaires et de navigation sont réalisés en local avec un serveur IISExpress.

Rappel sur le localhost

 

Qui dit test en local, dit utilisation d’une adresse en « localhost ». Comme nous sommes avec IISExpress, la notion de virtualhost que l’on trouve chez Apache n’est pas remise en place. Heureusement une notion de « binding » existe qui a des résultats équivalents.

Le problème c’est que si vous utilisez IISExpress pour tester votre application, avec VisualStudio, le « localhost » est juste obligatoire. Sinon, il ne veut pas générer la solution.

Rappel, « localhost », c’est un alias de 127.0.0.1, qui est l’adresse de loopback, c’est-à-dire l’adresse IP qu’utilise l’ordinateur pour communiquer avec lui-même.

Ainsi, mon PC communique avec lui-même quand on appelle localhost, et l’émulateur Windows Phone communique avec lui-même. En gros l’application est inaccessible depuis Windows Phone. J’ai certes 8Go de mémoire vive, mais j’ai un HDD aussi lent qu’une tortue. Déployer des machines virtuelles juste pour mettre un vrai serveur web, et un rôle de DNS, très peu pour moi.

Donc que faire ? Il faut trouver un moyen d’utiliser l’adresse ip que votre ordinateur possède sur le réseau virtuel auquel l’émulateur est branché.

Configurer l’IP

 

Par défaut l’adaptateur réseau virtuel qui est branché à l’émulateur est en résolution dynamique des adresses.

  • Dans la ligne de commande, tapez ipconfig, retenez l’adresse IP qui est associé à l’adaptateur virtuel Windows Phone.
  • Dans le centre réseau et partage> modifier les paramètres de la carte, cliquez droit sur l’adaptateur virtuel Windows Phone>Propriétés.
  • Cherchez  « IPv4 », sélectionnez le, cliquez sur « modifier »
  • Passer adressage statique, entrez l’adresse IP obtenu à la première étape, validez le masque (255.255.0.0 théoriquement) puis validez et fermez.

Figure 1 Configuration Ip Statique

Maintenant, vous êtes prêts à recevoir une connexion à votre serveur via votre IP. Néanmoins pour des raisons de sécurité évidente, le firewall bloque toute connexion entrante.

Il faut donc aller dans le firewall puis dans les paramètres avancés. Ajoutez-y une règle pour les connexions entrantes.

Choisissez une règle de port.

Figure 2 Autorisation de connexion entrante

Le protocole http étant basé sur du TCP, c’est ce protocole de transport que vous devez utiliser. Puis, entrez le port qui vous est nécessaire. Ne sélectionnez pas le réseau « publique » pour éviter les connexions indésirables.

Donnez-lui un nom parlant et validez.

Vous êtes maintenant prêts à recevoir une connexion directe. Maintenant il faut configurer le serveur IIS.

Configurer le serveur IISExpress

 

IISExpress vous permet d’héberger en local plusieurs applications tout en les faisant répondre à plusieurs adresses. Lorsque vous appelez «http://localhost:8080 », il découvre qu’à cette adresse il y a un site « DefaultWebSite » par exemple.

La seule obligation, c’est que si vous ouvrez un port connu, une adresse IP autre que 127.0.0.1 ou un nom de domaine complet, IISExpress doit être lancé en mode administrateur.

La manipulation à faire est celle-ci :

  • Eteignez VisualStudio et fermez IISExpress
  • Dans la ligne de commande, tapez notepad %userprofile%/IISExpress/config/applicationhost.config
  • Cherchez les balises <sites> puis trouvez-y le site que vous voulez rendre disponible
  • Au sein de la balise <bindings>, ajoutez [cci lang=”xml”] &lt;binding protocol="http" bindingInformation="*:1476:yourIP" /&gt;[/cci] pour rendre le site accessible en http à cette adresse pour le port 1476.
  • Enregistrez, fermez
  • Ouvrez VisualStudio en mode administrateur et lancez le débogage. Si une erreur s’affiche, rallumez l’ordinateur ou bien simplement allez dans la barre de lancement rapide et naviguez comme vous l’auriez fait si l’erreur n’était pas apparu.

Pour automatiser tout ça

 

Ce genre de chose, c’est assez long à faire si on a beaucoup de sites, sans compter qu’il faut taper du XML, ce qui est toujours long, fastidieux. Alors, rien que pour vous, j’ai créé un module Powershell.

Le code est ouvert, sur github, je le ferai évoluer assez rapidement, autant en terme de documentation que de fonctionnalités.

Pour ajouter une IP il suffira d’utiliser [cci lang=”powershell”]Add-WebsiteBinding YourSite –Ip 169.254.221.97 –Port 1476[/cci].

Si vous avez peur de faire une erreur de frappe dans le nom du site (qui est sensible à la casse), il vous suffira d’utiliser le pipe et la fonction Get-Website. Cette dernière trouvera le site dont le nom contient la chaîne de caractère passée en paramètre, cette fois-ci c’est insensible à la casse, sauf si vous le demandez. [cci lang=”powershell”]Get-Website "beggining_of_the_name" | Add-WebsiteBinding –Ip 169.254.221.94[/cci]

 

Sécuriser une API avec HMAC

En plein développement du projet que je présenterai avec le Cii à l’ImagineCup, nous devons exposer une API à nos clients mobiles et desktop. En effet, à l’heure actuelle, un site internet ça ne suffit plus pour accompagner un client dans ses achats, et c’est ce que nous voulons faire. Certes, nous avons un site web, respectant les règles du Responsive Design, mais nous voulons utiliser au maximum les outils mis à disposition par Windows 8.1 pour accompagner la recherche pré-achat (contrats de partage, accès hors ligne, puissance de calcul déportée en local…) et les possibilités des smartphones actuels (localisation, notifications, hub social, capteur photo, accessibilité au touché…).

Nous exposons donc une API à notre public : nos partenaires comme les clients. Certaines données sont ouvertes car elles peuvent être obtenues de manière ouverte chez d’autres fournisseurs. Par contre il faut pouvoir authentifier nos clients…

L’authentification, c’est un peu plus complexe que prévu quand on parle d’API. Utiliser un jeton de session, c’est s’assurer ce qu’on appelle une « side attack », autrement dit, quelqu’un qui sniff le réseau en attente du cookie de session, le prend et se fait passer pour nous avec ce cookie. Comme il nous est impossible d’utiliser de jeton CSRF avec une API, ça complique tout.

Deux grandes solutions s’offrent à nous :

  • Implémenter OAuth 2.0
  • Utiliser une authentification par HMAC

OAuth2.0 c’est bien, mais ça a un coût : il faut un fournisseur d’identité complet et surtout c’est plus lent. Notre choix est donc d’utiliser HMAC.

Le fonctionnement

 

Le but est ici de transmettre au serveur de manière totalement chiffré un couple clef publique/clef privée. Le chiffrement se fait par la méthode HMAC.

Figure 1Formulation de HMAC

h est ici la fonction de hashage (SHA-1, SHA-256…), K est la clé privée, m est dans notre cas la clef publique ainsi que d’autres informations utiles pour sécuriser l’envoie. Opad et ipad sont des constantes internes à la fonction HMAC.

La clef privée est une chaîne de caractère aléatoire qui est connue du client et du serveur seuls. Cette clef ne doit pas être envoyée sur le réseau sauf à envisager un échange plus complexe de type zero knowledge.

La clef publique est une clef qui est utilisée pour déterminer la personne qui demande l’authentification. Elle ne permet pas de l’authentifier en soit.

  1. Côté client : On calcule le Hashmac(clef privée, clef publique). HASHMACSHA256 ou HASHMACSHA512 sont conseillés.
  2. Côté client : On insère la clef publique et le hashmac dans l’url sous forme de paramètre GET ou bien on glisse ça dans une entête http étendue.
  3. Côté client : On insère les données demandées par le programme.
  4. Côté serveur : On récupère la clef publique et on regarde si elle correspond à un utilisateur et que cet utilisateur a le droit d’accéder aux données. Sinon 401 :UnAuthorized
  5. Côté serveur : On calcule le Hashmac(clef privée, clef publique) avec le même algorithme que le client. On compare le hashmac fournie par le client et celle calculée. Si elles ne sont pas identiques => 401 Unauthorized
  6. Côté serveur : On exécute la requête envoyée et on renvoie les données, si possible de manière cryptées.

Le problème réside donc dans la clef privée : comment la rendre privée ?

Dans le cas de Amazon, c’est assez simple, quand on inscrit un compte développeur, ils nous donne cette clef et nous disent de ne pas la compromettre. Mais dans le cas d’une application mobile ?

On ne peut pas demander à nos utilisateur d’entrer une suite indescriptible de chiffres et de lettres par pure plaisir, non ?

Et puis comment on gère le fait qu’il y a une clef privée par personne ? Impossible.

Un moyen est simplement de compiler la clef privée avec l’application et de la changer régulièrement, à chaque mise à jour de l’application par exemple. C’est relativement sécurisé mais ça n’empêchera pas les utilisateurs dont le téléphone est rooté de tenter de décompiler le programme et d’en extraire la clef privée et la manière dont vous hashez le tout.

A partir d’un moment il semble donc que OAuth soit nécessaire mais pour la plupart des utilisations, HMAC semble être un très bon compromis entre facilité de développement, sécurité, et rapidité d’exécution.

 

Les failles qu’il faut combler

 

Les attaque par « replay »

 

Ces attaques se servent d’une fonctionnalité qui est souvent souhaitable pour les API destinées à la mobilité : la possibilité de retenter la requête plusieurs fois.

L’attaquant observe le réseau et prend votre signature ainsi que la clef publique puis lance une flopée de requêtes qui ne sont pas celles que vous désiriez lancer. Quand l’utilisateur a un accès restreint, ça va, mais quand c’est un utilisateur à haut niveau de privilège, je vous laisse imaginer le désastre.

La première idée sera donc marquer temporellement la clef publique pour que sa validité ne soit bonne que durant un temps donné, une, deux, dix minutes par exemple.

Les attaques par replay sont toujours possibles, mais elles offrent moins de temps.

Une seconde idée est de fournir dans la clef publique un jeton unique qui identifiera la requête. Cet identifiant est simplement un compteur de requêtes.

Lorsque vous envoyez votre requête, vous incluez le jeton dans la clef publique et l’incrémentez aussi bien côté client que côté serveur. Lorsque l’attaquant voudra récupérer la hashmac de la première requête celle-ci ne sera plus valide. En effet si le serveur a renvoyé une réponse à cette requête alors il s’attend au jeton suivant et non plus à celui qui a permis de générer la signature usurpée.

Les attaques par changement de méthode.

 

Dans le cas d’un homme dans le milieu, ce dernier tentera d’utiliser l’authentification de l’utilisateur pour envoyer un POST/DELETE/PUT alors que la requête de départ est un GET par exemple. Cela peut générer des gros problèmes, surtout quand, par exemple, le routeur de ASP.NET MVC se base sur les méthodes pour désigner quelle action exécutée.

La parade est ici très simple : on inclut la méthode dans la signature. Ainsi si l’attaquant usurpe votre signature, il ne peut pas usurper votre demande.

L’URI de base doit être, dans ce modèle elle aussi ajoutée à la signature.

 

Et bien d’autres encore… Il est aussi toujours nécessaire d’utiliser une connexion HTTPS pour transmettre les données de manière cryptée !

Les macros/script sur google spreadsheet

Le JavaScript est vraiment LE langage du moment. Non seulement Office 2013, Windows RT l’utilisent mais aussi les documents google (gdoc/spreadsheet). Voilà bien une raison de plus -s’il en fallait- que ce n’est pas une mauvaise idée de commencer le développement par le web -surtout quand on est jeune.

Aujourd’hui fut pour moi un grand moment pour tester la fameuse “courbe du geek” : une répétition en grand nombre de la séquence filter-copy-past.

Continue reading