Twitter et sécurité… Arf.
Depuis quelques jours, petit buzz sur la toile française. Nous pouvons changer le statut Twitter d’une personne visitant notre site Internet grâce au chargement d’une URL. Astuce présentée -et non découverte- par le blogueur Korben et reprise un peu partout, là, là ou même là.
C’est la deuxième fois qu’un problème de sécurité est présenté sur le service Twitter, la première était le piratage de quelques gros comptes suite à une attaque par force brute d’un compte d’administrateur.
Beaucoup de personnes ont donc parlées de cette possibilité de changement de statut par un site tiers, mais personne n’a encore solutionné le problème. Donc je vais vous livrer quelques astuces pour sécuriser son site internet contre ces attaques mais aussi, vous sécuriser vous. Car il est en partie possible de se sécuriser contre ces attaques connues appelées CSRF.
Attaque ? Où, où ça ?
Tout d’abord étudions l’attaque. En temps normal, la personne étant loggée envoie son statut par l’intermédiaire d’une requête POST et Twitter le met à jour. Cependant, les requêtes POST et GET peuvent se confondre donc nous pouvons charger dans l’URL les données que nous voulons envoyer par l’intermédiaire de la variables statut. Ex : http://twitter.com/home?status=le statut à mettre.
A partir de là, il devient facile pour une personne de mettre un script dans son site Internet faisant le travail et changeant le statut de n’importe qui loggé sur twitter et visitant le site. Voir le PoC (proof of concept) ici.
Bon, ceci dit, comment se protéger ?
Tout d’abord, le site Internet doit être protégé au niveau du code. Ainsi, on n’accepte pas n’importe quelle variable envoyée depuis n’importe quel site Internet. Pour ce faire, une technique assez simple est de mettre un champ en hidden avec une valeur aléatoire envoyée en même temps que notre valeur (dans le cas de Twitter le statut.). Ainsi, grâce aux sessions, le site Internet garde en mémoire cette valeur. Lorsque la page reçoit le statut, la valeur cachée est comparée à celle en mémoire. S’il y en a pas où si cela n’est pas la bonne, en refuse le changement de statut. (encore dans le cadre de Twitter.)
Je vous ai fait un petit script que l’on peut tester et disponible ICI.
Cette valeur doit réellement être aléatoire et être hashée de préférence en sha1 pour (encore) plus de sécurité. En fait, tout dépend de la longueur de la chaine et du nombre de possibilités pour chaque case. Si cette dernière est élevée (comme dans mon exemple, 32 cases) il n’est pas réellement nécessaire de prévoir un hashage de cette dernière.
De plus l’utilisateur, lui, ne peut jamais être protégé. Ainsi, même en désactivant le Javascript sur son navigateur, en empêchant l’affichage des iframes, cela ne fera que stopper les attaques CSRF complexes, mais pas ce genre de petites attaques, car l’URL peut être appelée depuis n’importe quel code que cela soit une iframe, une image, une feuille de style etc.
Développeurs, développeuses, je vous encourage à patcher tous les champs de vos différents formulaires car cette faille est très – trop ? – répendue ! (Administrations de routeurs, de box, réseaux sociaux, sites bancaires (?), sites d’ecommerce, services de blogs etc.). Bref, maintenant la balle est dans votre camp !