Liste de partage de Grorico

Avec ses 4,4 millions d'années, la petite Ardy devient le plus ancien hominidé dont on dispose du squelette complet. Elle nous en apprend beaucoup sur nos ancêtres et sur nos cousins les grands singes.
Dix-sept ans de travail, quarante-sept scientifiques de dix pays différents, plus de cent individus extraits du sable du désert et onze publications dans Science ont fini par permettre la description complète d'un des plus vieux représentants connus de la lignée humaine, Ardipithecus ramidus....

Armés de simples bâtonnets, des généticiens menés par Spencer Wells ont dressé la carte des grandes migrations humaines depuis 60.000 ans, lorsque des hommes ont quitté le berceau africain. Lancé en avril 2005, ce projet ambitieux sera présenté dans un documentaire sur la chaîne du National Geographic. Intitulé La grande famille de l'Homme, il témoigne combien nous sommes proches les uns des autres.
De façon spectaculaire, l'histoire que nous raconte Spencer Wells, un généticien passionné d'...

Brandon Sterne, qui travaille sur la sécurité de Firefox, vient d'annoncer que des versions de développement de Firefox intégrant la spécification Content Security Policy sont disponibles depuis quelques jours. Cette spécification est une proposition de Mozilla pour renforcer la sécurité des navigateurs contre les attaques de type XSS.

XSS

Les attaques XSS, ou Cross Site Scripting sont parmi les plus courantes sur le réseau. Elles consistent à faire s'exécuter un script, généralement JavaScript, par le navigateur. Imaginons pas exemple un blog qui autoriserait le HTML dans les commentaires sans filtrer les saisies. On pourrait ainsi insérer des scripts dans les commentaires. Ces scripts s'exécuteraient dans le navigateur de toute personne consultant le commentaire comme s'ils étaient des scripts légitimes de l'application. A partir de là, tout est possible, le script peut effectuer toutes les opérations autorisées à l'utilisateur. Si l'administrateur du blog consulte un commentaire piégé, le script pourra par exemple effacer les billets, modifier les droits d'accès au blog, etc. Le jeu pour les auteurs de ce type de script consiste à contourner les protections mises en place au niveau serveur pour réussir à insérer du code qui s'affichera et s'exécutera dans le navigateur des utilisateurs. Par exemple en cachant le code dans l'URL d'une image ou d'un lien. Ces attaques utilisent le fait que le navigateur fait confiance par défaut à tout le contenu en provenance du site Web.

Content Security Policy

Pour y remédier, CSP propose une approche basée sur le principe d'une liste blanche : le site liste explicitement les contenus légitimes. Si un site indique qu'il utilise CSP, le navigateur ne fera donc confiance qu'aux scripts contenus dans cette liste blanche et refusera d'exécuter les autres.

CSP a en fait une double fonction:

• il essaie de prévenir l'exécution de code non désiré, et protège donc les utilisateurs;
• lorsqu'il détecte une tentative de violation des politiques de sécurité, il en informe le site. Les responsables de celui-ci peuvent donc être rapidement prévenus de toute tentative d'attaque contre leur site, et prendre les mesures pour la bloquer;

Un site indique au navigateur qu'il implémente CSP via l'entête HTTP X-Content-Security-Policy. Celui-ci peut soit contenir la description de la politique, soit l'URI d'un document la décrivant.

Les politiques ne s'appliquent bien sûr qu'aux contenus chargés depuis un site distant, pas aux extensions ou aux scripts locaux de l'utilisateur (type bookmarklets).

Un prototype de CSP a d'abord été implémentée sous forme d'une extension, avant d'intégrer récemment le cœur de Firefox. Les politiques de sécurité seront donc disponibles dans une des prochaines versions du navigateur, la 3.6 ou la 3.7.

Comportement par défaut

CSP implémente un certain nombre de politiques par défaut, qui peuvent être débrayées. Sont donc interdits :

• l'exécution de code placé directement dans la page, que ce soit au sein de balises script, dans les liens (<a href="javascript..." />) ou les gestionnaires d'évènements (onclick...)^[1];
• l'exécution de code à partir d'une chaîne de caractère, donc par exemple l'utilisation de la fonction eval;
• l'utilisation d'URI de type data:...;
• les binding XBL, hormis ceux provenant du chrome (je crois que Firefox est le seul navigateur à implémenter XBL, donc si vous ne comprenez pas ce que ça veut dire, ça n'est pas bien grave);

La politique de sécurité permet ensuite de définir, pour chaque type de contenu (script, images, etc), les URI à partir desquelles le navigateur est autorisé à télécharger le contenu.

Syntaxe

Une politique de sécurité se compose de directives, séparées par des point-virgules. Chaque directive comporte un nom et une liste de valeurs, séparées par des espaces. Les directives disponibles sont:

• allow définit la politique par défaut. Elle doit toujours être définie;
• options permet de définir... des options. Pour l'instant seules deux valeurs sont possibles : eval-script pour autoriser les fonction de type eval, et inline-script, pour permettre la présence de code directement dans la page;
• font-src pour la source des fontes chargées via la propriété CSS font-src;
• frame-src pour la source des frames et des iframes;
• img-src pour la source des images et de la favicon;
• media-src pour la source des éléments audio et video;
• object-src pour la source des éléments applet, embed et object;
• script-src pour la source des scripts
• style-src pour la source des feuilles de style externes;
• xhr-src pour les requêtes XMLHttpRequest;
• frame-ancestors définit les sources autorisées à afficher le contenu à l'intérieur d'une frame. Cela permet donc d'interdire qu'une page soit insérée dans une autre à l'aide d'une iframe (une technique couramment utilisée dans les attaques par clickjacking);
• policy-uri : URI d'un fichier contenant la description de la politique;
• report-uri : URI où envoyer un rapport en cas de tentative de violation d'une règle

La source peut être soit self, soit none soit une URI. self signifie que ne sont autorisés que les contenus délivré par le même scheme, le même hôte et le même port. Les URI peuvent contenir des méta-caractères, par exemple *.mozilla.org.

Par défaut, les sites ne peuvent pas mélanger de contenu sécurisé et non sécurisé. Pour l'autoriser, il faudra le déclarer explicitement, par exemple:

X-Content-Security-Policy: allow http://*.clochix.net https://*.clochix.net

La description des politiques de sécurité et le comportement à adopter en cas de violation peuvent être décrits dans des documents externes, via policy-uri et report-uri, mais ceux-ci doivent avoir la même origine que le document auquel elles s'appliquent;

Enfin, la spécification précise de plus le comportement à adopter en présence de plusieurs plusieurs politiques.

Les rapports

Si le navigateur détecte qu'une page essaie de violer une des règles définies, il peut envoyer via une requête HTTP POST, un rapport à l'URI définie via report-uri. Ce rapport est un document XML.

Les rapports contiennent la requête avec tous ses entêtes, l'URI du contenu bloqué, la directive à l'origine du blocage, et l'ensemble des directives appliquées. Un rapport pourra ressembler à

<csp-report>
 <request>GET /index.html HTTP/1.1</request>
 <request-headers><![CDATA[
          Host: example.com
          User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008061015 Firefox/3.0
          Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
          Accept-Language: en-us,en;q=0.5
          Accept-Encoding: gzip,deflate
          Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
          Keep-Alive: 300
          Connection: keep-alive
 ]]></request-headers>
 <blocked-uri>http://evil.com/some_image.png</blocked-uri>
 <violated-directive>img-src self</violated-directive>
 <original-policy>allow none; img-src *, allow self; img-src self</original-policy>
</csp-report>

Ce qui signifie qu'une page a essayé de charger une image depuis un site externe, alors que seules les images du site d'origine sont autorisées.

Pour faciliter la mise au point des directives, on pourra remplacer X-Content-Security-Policy par X-Content-Security-Policy-Report-Only. Dans ce cas le navigateur se contentera d'envoyer des rapport sans bloquer le contenu qui viole la directive.

Exemples

Autoriser l'exécution de code placé directement dans la page:

X-Content-Security-Policy: allow 'self'; script-src inline;

ou

X-Content-Security-Policy: allow 'self'; options inline-script;

Autoriser l'utilisation des fonctions qui exécutent du code à partir d'une chaîne de caractère:

X-Content-Security-Policy: allow 'self'; script-src eval;

ou

X-Content-Security-Policy: allow 'self'; options eval-script;

Autoriser les images à utiliser le scheme data: :

X-Content-Security-Policy: allow self; img-src data;

Autoriser les images de toute origine, les plugins de certains sites, les sites uniquement depuis le domaine trustedscripts.example.com et le reste du contenu uniquement depuis le serveur d'origine:

X-Content-Security-Policy: allow 'self'; img-src *; \
                           object-src media1.com media2.com *.cdn.com; \
                           script-src trustedscripts.example.com

N'autoriser que le contenu sécurité par SSL:

X-Content-Security-Policy: allow https://*:443

Pour aller plus loin

Outre le Content Security Policy trois autres projets sont en cours pour renforcer la sécurité de Firefox :

Origin vise à prévenir les attaques dites CSRF. Celles-ci consistent à obtenir du navigateur qu'il effectue une requête déclenchant une action. Par exemple si l'utilisateur est connecté à un webmail, on essaiera de lui faire afficher une image dont l'URL correspond à une action du webmail. Le navigateur, pour récupérer l'image, exécutera la requête et déclenchera l'action. Les CSRF ne fonctionnent que pour les actions accessibles via des requêtes HTTP GET$$pour celles nécessitant un HTTP POST, existent des attaques proches, le vol de clic (clickjacking), qui consistent à amener l'utilisateur à cliquer sur un bouton qui déclenchera le POST. Pour lutter contre les CSRF, Brandon Sterne et les équipes de Mozilla proposent que dans certains cas, le navigateur ajoute aux entêtes qu'il envoie au serveur l'origine de la requête (le site d'où elle provient), charge au serveur de déterminer s'il accepte de la traiter ou non. La proposition est en cours de soumission à l'IETF pour devenir un standard et un prototype est attendu pour la fin 2009.

Force-TLS propose aux sites d'ajouter un entête HTTP indiquant qu'ils ne doivent à l'avenir être contactés que via une connexion HTTPS. Un prototype est disponible sous la forme d'une extension.

Le "gros" morceau est bien sûr Electrolysis qui vise à utiliser des processus séparés pour l'affichage du navigateur, des pages et des plugins, afin de circonscrire au maximum les potentiels problèmes (plantages ou attaques).

En conclusion

La mise en œuvre de politiques de sécurité via le Content Security Policy ne sera pas forcément simple, car pour être efficace il faudra appliquer des règles strictes, et bon nombre d'applications existantes devront être modifiées pour en tirer partie. Mais à terme, cela ne peut que s'avérer payant, car cela fournit un garde-fou précieux contre bon-nombre d'attaques.

Il ne reste plus qu'à espérer que la spécification soit reprises par les autres fabriquants de navigateurs et devienne une norme.

Ajout du 07.10 : billet de Chris Blizzard sur HMO

Une société britannique privée va proposer aux citoyens d'outre-Manche ayant chez eux un ordinateur de visionner en direct des images prises par des caméras de surveillance pour dénoncer les crimes et délits.

C'est un outil assez incroyable que des étudiants chinois seraient en train de mettre au point. Nommé Photosketch (à ne pas confondre avec ce plug-in du même nom pour Google SketchUp), il permettrait ni plus ni moins que de faire un montage photo-réaliste à partir...d'un simple dessin et d'annotations !...

Petite explication en vidéo du fonctionnement du système :

Un outil, qui s'il s'avèrait fonctionner aussi efficacement que décrit dans cette vidéo, relèguerait presque Photoshop au rang de pièce de musée ! On attend une version publique avec impatience ;-)

(Via Gizmodo)

Comme chaque année à la même époque, les recherches improbables ont été couronnées par les Ig Nobels, quelques jours avant que ne soient attribués les "vrais" Nobel.

Les Web Hooks sont une solution pratique pour bidouiller des applications Web côté serveur. Ils jouissent d'une popularité grandissante, et offrent de jolies perspectives. Si vous n'en avez pas encore entendu parler, voici une petite tentative d'introduction.

Nota : ce billet n'a rien d'original puisqu'il se contente de reprendre quelques idées développées par Jeff Lindsay, évangéliste des Web Hooks, sur son blog, dont je vous recommande évidemment la lecture.

Les hooks sont une technique de programmation classique par laquelle un logiciel définit une interface permettant à des composants externes d'étendre ou modifier son comportement. Par exemple, avant et après chaque action, le logiciel regarde si des modules complémentaires ont souhaité être avertis, et si oui il les appelle. Un des exemples les plus connus d'utilisation de hooks est sans doute les logiciels de gestion de source, comme Subversion, qui permettent de définir des actions à exécuter avant ou après chaque commande. Des logiciels comme Drupal, Dotclear, Wordpress... utilisent également ce mécanisme comme base de leur système d'extension. Dans Firefox, les Overlay sont des hooks.

On pourrait sans doute traduire hook par dérivation, comme dans un circuit électrique. Une application utilisant des hooks est dérivable, on peut facilement en modifier le flux standard pour le faire passer par d'autres chemins.

Je pense que c'est une condition de plus de la liberté d'une application: pour être réellement libre, un programme devrait être facilement extensible, dérivable, fournir des points où accrocher des modules additionnels sans devoir toucher à l'application elle-même. Si pour adapter un programme à ses besoins, on est obligé d'intervenir dans son code source, cela oblige à maintenir sa propre version du source, à recompiler l'ensemble à chaque nouvelle révision, etc. Ceux qui ont connu phpBB avant la version 3 se souviennent du cauchemar pour installer un module complémentaire : il fallait appliquer des modifications directement sur le code source, et on n'en finissait plus de devoir lutter avec les problèmes de compatibilité entre modules ou à chaque nouvelle version mineure du logiciel. Les hooks, en facilitant l'extensibilité du code, le rendent plus ouvert.

Cette solution n'est bien sûr pas parfaite. Parmi les problèmes qu'elle pose, j'en relève deux pour mieux appuyer la suite de mon billet:

• sauf rare exception, les extensions doivent être écrites dans le même langage que l'application, ce qui implique que vous soyez relativement à l'aise avec ce langage. Certes des ponts existent entre différents langages^[1], mais ce sont souvent des solutions lourdes à mettre en œuvre;
• elles nécessitent d'installer le module complémentaire, donc du code, sur le même serveur que l'application. Ce qui est rarement possible si vous utilisez une application hébergée. Par exemple, ce blog est hébergé par la plate-forme de Gandi, ce qui a quelques avantages mais m'empêche d'installer les extensions que je veux;

Une solution à ces deux point commence à poindre son nez : utiliser des Web Hooks pour étendre une application en ligne. Les Web Hooks ne sont rien d'autre que des pages web qui exécutent une action et peuvent éventuellement renvoyer un résultat. On peut les voir comme un sous ensemble des services web REST: on déclenche une action en appelant une URL via une requête GET ou POST, et on peut récupérer le résultat, ou pas.

Les Web Hooks sont une réponse relativement élégante à l'extensibilité des applications hébergées. Il suffit de permettre à l'utilisateur de spécifier des URL à appeler pour chaque hook défini dans l'application, en précisant si celle-ci doit attendre ou non un résultat. Dans le premier cas, le coût est élevé en terme de performances, car il faut compter avec la latence du réseau, gérer les indisponibilités, etc. Mais dans le second, le coût est faible, on se contente d'envoyer une requête sans se soucier du résultat. Les applications sont nombreuses, du simple ping d'un Hub pour annoncer la publication d'un contenu, à des interactions plus complexes entre applications, par exemple pour gérer les droits d'utilisateurs. Même si aucune API n'existe entre deux applications, on pourra aisément les faire communiquer via des hooks, avec un minimum d'intervention au niveau des serveurs qui les hébergent.

Les Web Hooks permettent également d'augmenter la réutilisabilité du code, à la manière de bibliothèques externes. Imaginons par exemple un service qui prenne en entrée un document au format Atom et le publie via le mécanisme PubSub de XMPP. Cet hook pourrait lui-même être appelé par des hooks déclenchés depuis Dotclear, WorPress, Status.Net et qui convertiraient juste les données en Atom. On peut ainsi mettre en place une architecture inspirée des commandes Unix, avec des hooks se contentant de tâches élémentaires et reliés les uns aux autres via des tuyaux.

Si vous voulez tester cette solution, un plugin pour WordPress, HookPress, permet déjà d'appeler des URL en réponse à certains évènements. tcWebHooks en fait de même pour TeamCity, un serveur d'intégration continue. Cette présentation montre l'utilisation de Web Hooks avec PBWiki et Yahoo Pipes. De plus en plus de service permettent d'utiliser cette technique : Google Code, github, Shopify (une boutique en ligne)...

En utilisant des Web Hooks, on peut ainsi étendre une application sans la modifier, et en utilisant le langage de son choix. Les hooks favorisent également les logiques de flux et facilitent les communications entre services.

Pour ce qui est de l'hébergement du hook, la meilleure solution est bien sûr de disposer d'un bout de serveur où installer ses scripts. Mais ce n'est pas une condition indispensable, car des solution en ligne existent et vont probablement se multiplier. Google AppEngine vous propose d'héberger des applications Python ou Java^[2] directement sur les serveurs de Google. L'hébergement propose de plus des bibliothèques offrant des fonctions spécifiques au contexte. Feu AppJet, qui a hélas fermé le 1er juillet 2009, proposait lui d'héberger des applications écrites en JavaScript (je reviendrai très bientôt sur le retour de JavaScript sur le serveur). Techniquement, il utilisait je crois le moteur JavaScript Rhino, développé en Java par Mozilla, en le faisant tourner au dessus d'AppEngine. AppJet offrait de plus un IDE en ligne et des bibliothèques spécifiques. En se basant sur la même architecture, et suite à la fermeture d'Appjet, Jeff Lindsay a lancé Scriptlets, dont le code source est disponible. Il se base lui aussi sur AppEngine et supporte pour l'instant JavaScript, PHP et Python. J'ai également découvert le service hookhup qui héberge des scripts JavaScript. Si vous en connaissez d'autres, n'hésitez pas à les signaler dans les commentaires.

Avec Bespin, qui permettra bientôt de disposer d'un véritable environnement de développement complet en ligne, on dispose de pratiquement toutes les briques pour que les Web Hooks prennent leur envol. Et j'espère que ça sera le cas. Car je vois à ce type de plateforme un intérêt majeur : permettre de bidouiller très facilement le Web côté serveur. Il suffit d'écrire un script dans son langage de prédilection, de le déposer sur un serveur, et d'enregistrer l'URI du hook dans l'application que l'on veut modifier. De même que de nouveaux outils rendent chaque jour plus simple la bidouille en JavaScript dans le navigateur, le Web Hook permettent d'expérimenter sur le serveur. Avec un minimum de connaissances, aidé par un IDE en ligne, on va pouvoir commencer à écrire des petits bouts de code pour modifier et étendre les applications en ligne que l'on utilise. C'est un pas de plus dans la ré-appropriation du Web. Et c'est à ce titre que les Web Hook sont pour moi une des briques de l'Open Web. Pour participer, ll ne vous reste plus qu'à rendre vos applications Web dérivables...

Ça donne un aperçu des “fantasmes” technologiques (entre autre) d’il y a 30 ou 40 ans. Au programme : un sauna portable, un robot qui répond automatiquement au téléphone, un parapluie pour cigarettes (je vous jure…), des pneus illuminés… C’est à voir ici. Et c’est quand même “priceless”…

via life

Partager :

Tags:Life, Sur le web

Sur le même sujet :

• Walt Mossberg façon Muppet Show… (2)
• Wall-E est à croquer ! (4)
• Visite d’une usine de smileys (17)
• Utiliser l’interface de Flickr autrement (6)
• Une Zune Girl ? (10)

Un peu comme le Karaoké. Mais pour les gars forts. Vraiments très très très forts.

Permalien | Commentaires