Monthly Archives: février 2013

www or not www

Petits tour d’horizon des arguments pour et contre l’utilisation du www dans l’url :

Pour :

  • Le www est le sous domaine standard du domaine principale. Comme tout sous-domaine, il peut bénéficier d’une entrée DNS. Qui dit IP différente dit potentiellement serveurs différents.
  • Permet de distinguer les différents sous domaines (www, mail, ftp, blog, …)
  • Symétrie visuelle de l’url (www.XXX.com)
  • Visibilité des cookies : positionner un cookie sur le domaine racine fera qu’il sera visible sur tous les autres sous domaines.

Contre :

  • Les sous domaines ne sont pas obligatoires
  • Difficulté de prononciation du www
  • Rallonge l’url

Dans tous les cas, il est fortement conseillé de faire une redirection propre (301) pour n’autoriser qu’une forme d’URL (problématique SEO). Exemple pour supprimer le www de l’url :

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^www\.jerep6\.fr$
RewriteRule (.*) http://jerep6.fr/$1 [L,R=301]

Sources :
http://stackoverflow.com/questions/1109356/www-or-not-www-what-to-choose-as-primary-site-name
http://www.codinghorror.com/blog/2008/04/the-great-dub-dub-dub-debate.html
http://computer.howstuffworks.com/internet/basics/question180.htm
http://creativebriefing.com/how-to-brand-your-websites-url-part-1-to-www-or-not-to-www/
http://no-www.org/

Hash Length Extension Attacks

Cet article a pour but de résumer mes recherches web sur les attaques par extension des fonctions de hashage. Petit exemple d’attaque par extension sur du sha1.

Problématique

J’ai un message à transmettre et je souhaite garantir que ce message ne soit pas modifié entre son émission et sa réception. Je veux également être le seul à forger des messages à l’intention de mon destinataire. Dans les deux cas, la confidentialité du message n’est pas importante. Autrement dit : tout le monde peut voir le message que j’ai émis, mais personne ne doit pouvoir discuter de façon valide avec mon destinataire.

Prenons l’exemple d’une url. Nous sommes sur un site e-commerce et nous souhaitons rediriger l’internaute vers le site de la banque pour qu’il paie sa commande.

http://url_banque/paiement.cgi?commande=5580&montant=140€&texte-libre=Telephone

Aucune information de sensible ne transite, mais nous ne souhaitons pas que l’internaute puisse modifier le montant de la commande ou rajouter des paramètres à l’url.

MAC

Une solution consiste à signer les données transmises en utilisant un code d’authentification de message (MAC). Une version simple est de concaténer une clé secrète au message et de hasher le tout.

function createMac(key, msg) {
   return sha1(key + msg)
}

Nous allons générer une signature à partir d’une clé secrète et des données métier : la référence de la commande, le montant et un texte libre. Le « <*> » correspond au séparateur des données.

String mac = createMac("AABBCCDDEEFFGGHH", "<*>5580<*>349€<*>Telephone")
mac : af90d9acf27bb11cb7027920fe9b2f51a72ba754

L’url finale est la suivante : http://url_banque/paiement.cgi?commande=5580&montant=140€&texte-libre=Telephone&mac=af90d9acf27bb11cb7027920fe9b2f51a72ba754

API simplifié du site bancaire :

  • commande : référence de la commande
  • montant : montant que le client doit payer
  • texte-libre : chaine de caractère apparaissant sur la facture et renvoyée au site appelant lors de la confirmation.
  • nbre-paiement : nombres de débits à réaliser pour payer la commande.
  • mac : sceau certifiant les données émises par le commerçant. Le calcul du sceau est le suivant : cle secrete<*>commande<*>prix<*>texte-libre[<*>nb-paiement]

Attaque par extension

Les fonctions cryptographique comme MD5, SHA-1 ou SHA-256 qui sont construites selon le principe de Merkle-Damgård sont vulnérables aux attaques par extension. Ces attaques consistent à rajouter des données aux messages original puis à calculer un nouveau MAC sans connaitre la clé secrète. Les ingrédients suivants sont nécessaires à sa réalisation :

  • MAC construit de la sorte : H(cle + message)
  • taille de la clé connue (on peut néanmoins la deviner)
  • message transmis connu
  • algorithme vulnérable (md5, sha1, sha256, sha512)

Lire la suite »