Feed Back, stage en imprimerie.

août 21st, 2009

Et me revoilà, de retour après une semaine intense de stage en imprimerie dans le cadre de ma formation à SRC Bordeaux. Car il faut bien le dire, nous ne faisons pas que du web et nous voyons bien d’autres choses !

Bref, j’ai passé ce stage dans une petite imprimerie de Poitiers afin d’observer tout le processus de la chaine graphique mais aussi et bien entendu, mettre un peu la main à la patte là où je pouvais me rendre utile. Donc en une semaine, on va dire que j’ai fait quelques trucs intéressants. Tout d’abord, je me suis initié à Quark Xpress, ne l’ayant pas à mon IUT (tout du moins, pas à ma connaissance.) j’ai pu enfin voir ce que valait ce logiciel – dont on me vante les mérites depuis quelques années maintenant – comparé à Indesign d’Adobe. Bref, je n’ai pas fait de très grandes maquettes dessus mais seulement quelques faire-parts et cartes de visites.

D’ailleurs, outre le fait que cette imprimerie possède certains grands comptes comme clients, elle est aussi spécialisé dans les faire-parts. En voir un d’accord, mais en voir dix de suite devient plus que marrant ! Toujours les mêmes formulations, toujours les polices anglaises pour faire chique et pour plaire aux clients. De plus, sur certains siégeaient de très grosses fautes de formulation. Maintenant, je sais pourquoi il faut soigner son orthographe (même si cela m’arrive évidemment de faire des fautes) car faire des fautes sur un schéma de faire-part que l’on donne à un imprimeur, cela ne se fait pas.

Donc il y avait des moments « cools », ceux où je faisais de l’infographie et d’autres moins « cools », ceux où je remplissais des cartons de 27000 feuilles. Par ailleurs, étant en SRC, on m’a demandé de réaliser une maquette de présentation pour leurs email mais aussi afin de faire un petit peu de PUB autour d’eux (oh le vilain spammeur !). Donc j’ai passé environ cinq heures à faire le design ou à développer le code. Mais aussi à faire des tests pour voir ce qui était interprété et ce qui ne l’était pas par nos amis les webmails et de plus (hacker inside) j’ai élaboré des stratégies afin de contourner certains filtres interdisant l’affichage direct de la moindre petite image dans un mail…

Bref, c’est fini, maintenant je passe à autre chose. Je remercie tous les employés pour m’avoir donné de leurs temps afin de m’expliquer tous les rouages d’une imprimerie et de certaines machines. De plus, j’essaye encore de garder cette vision d’artisan même si la technologie est aujourd’hui partout ce qui dé-nature un peu l’esthétisme qu’avait le typographe d’antan mettant à la main des chaînes de caractères. Aujourd’hui l’offset est partout, les imprimeurs n’ont plus le temps, mais bien l’heure.

SaaS et vulnérabilités

août 21st, 2009

Je vais présenter dans cet article un service qui tend à s’étendre dans l’avenir avec le développement de nouvelles applications et nouveaux procédés. Tout le monde et ce depuis quelques années maintenant, s’émerveille devant la venue des SaaS sur le web et des avantages que cela procure.

De plus en plus de personnes font appel à ces services [1] en entreprise afin d’optimiser leurs coûts. Cependant, beaucoup d’entreprises ne réalisent pas qu’en utilisant ces types de services, elles soumettent certaines informations contenues à des tiers.

Ceci peut augmenter à terme le risque de vol d’informations, de viol de la confidentialité des données et de plus la possibilité de récolte d’informations en vue du piratage du réseau de l’entreprise si les serveurs du prestataire des SaaS s’avèrent compromis ou si des fichiers de connexions à ces derniers sont détournés.

Les risques sont multipliés lorsque ces SaaS utilisent par ailleurs un navigateur Internet lambda comme client. Des failles sur le site du prestataire (surtout si ce dernier développe d’autres services étendus orientés sur le web) permettent là aussi d’accéder à vos documents. Nous retiendrons une faille présente malheureusement dans beaucoup d’applications web qui sont autre que les XSS, permettant suite au vol de cookies sur un service d’étendre son emprise sur la totalité des services du prestataire utilisés par l’Internaute.

Ainsi, la logique du prestataire, qui n’est autre que de ne pas changer les informations de sessions entre les SaaS afin de ne pas gêner le client passant d’un service (ex : webmail) à un autre (ex : Editeur en ligne) se révèle une vulnérabilité potentielle pour la compromission totale des informations soumises par l’internaute au SaaS.

C’est le cas par exemple lorsque de grands noms du web ayant des SaaS se retrouvent avec une vulnérabilité dans une de leurs pages dynamiques et ceci arrive plus que souvent. Nous pouvons aussi noter de par le passé un SaaS qui pouvait permettre à n’importe qui de visionner les documents de chaque utilisateur en prédisant le nom relatif au document utilisé par l’application.

Bref, les SaaS c’est beau. Mais il ne faut pas en abuser ! Surtout lorsqu’on a aucune information relative à la sécurité du système traitant les documents envoyés dans le cadre de suites de bureautique Online ou autres. Selon moi, une entreprise ne devrait pas soumettre n’importe quel document interne (quel que soit son niveau de divulgation) à un SaaS sans être assuré de la préservation de la confidentialité de ces derniers. Pour les particuliers (CV etc.) ceci est une autre histoire et une autre échelle de risques.

Twitter a risqué gros !

août 21st, 2009

Bon, je ne vais pas m’éterniser, mais il était possible de faire un petit CSRF-viruz made in Twitter suite à l’ancienne vulnérabilité CRSF (elle a été corrigée grâce à la mise en place d’un token). Rappelez-vous, il était possible à la suite d’un appel d’une URL de changer le statut twitter d’un visiteur de son site internet.

A partir de cela, comment un virus pourrait-il fonctionner ?

Eh bien, mettre dans le message posté sur le Twitter de la victime l’adresse du site internet ayant le script permettant l’attaque CSRF dans sa version la plus basique. Ainsi, ceci permettait une récursivité dans le style des virus MSN bien connus. En cliquant sur le lien, on postait l’accès à la page sur notre twitter, et nos followers, feront de même en cliquant et les followers de nos followers feront pareil.

En plus, nous aurions pu faire un générateur de phrases alléchantes en JS attirant nos followers à aller voir cette page piégée…

En bref, beaucoup de perspectives et je n’ai pas parlé d’autres – exécutions d’autres codes malicieux à partir de la page etc. – étaient possibles malheureusement.

Aujourd’hui, la récupération des tokens en Cross-domain grâce à AJAX suite à l’utilisation de XMLHttpRequest et grâce à JSON suite à l’utilisation de la classe JSONscriptRequest est impossible (sur Firefox et certains autres navigateurs acceptant JavaScript). Cependant, il n’est pas rare de voir des chercheurs arrivant à détourner les protections contre les Httprequests en cross-domain établies par les navigateurs.

Donc ce n’est que partie remise…