The Butterfly Effect (2)

Trop de spam : migration sur Futureblogs

saphyr — Mon, 30 May 2005 15:29:00 GMT

Marre, c'est le mot. Cela fait des semaines que j'attends de voir si les adminstrateurs vont faire quelque chose pour empêcher ces rafales de spam via les commentaires. Rien n'est fait, alors, je change de 'prestataire'.

Il paraît que l'on n'est jamais mieux servi que par soi-même. Raison pour laquelle je tente ma chance sur ma propre plate-forme de blogs (Futureblogs). Ca fera un bon test, la charge DNJ est toute autre que la petite quantité de visiteurs 'régionaux' accèdant aux blogs romands.

Nous verrons bien, si vous avez apprecié les articles publiés sur ce blog, la suite se passera donc sur: http://www.futureblogs.net/butterfly-effect.

En espèrant vous revoir là-bas, je désactive dès à présent les commentaires sur ce blog.

Responsabilités d'une application web face aux attaques

saphyr — Wed, 19 Jan 2005 23:59:00 GMT

Une petite discussion hier soir sur les ‘responsabilités’ qu’une application web devrait être en mesure d’assumer de manière autonome…

Application responsable ?
L’on peut interpréter cela comme un abus de langage, certes. Par responsabilité, il est entendu ici ‘la capacité à rester dans un état tel que les objectifs fixés (d’état ou de transition) soient maintenus, et ceci, de manière autonome, donc sans intervention humaine.

Quelles responsabilités ?
Trois responsabilités ont été identifiés. Cette liste n’est aucunement exhaustive et reste donc sujette à débat:

- Détecter les attaques
- Se défendre contre les attaques
- Réagir aux les attaques: contre-mesures

Responsabilité #1: détecter les attaques
Cette responsabilité regroupe des comportements souvent appelés ‘mesures de surveillance’: l’application se place dans un état d’éveil et doit être en mesure de comprendre son environnement et de détecter si elle se trouve confrontée à des acteurs hostiles ou non.

Dans le concret, des mesures de détection dans une application web seront par exemple:

- détecter si un formulaire d’authentification subit une attaque de type brute force
- détecter l’envoi de fichiers dont l’extension ne correspond pas au type mime détecté
- détecter si tous les champs ‘obligatoires’ d’un formulaire ont bien été remplis
- etc.

Ces comportements peuvent être gérés en deux points stratégiques: ponctuellement (local) ou de manière centralisée.

détection ponctuelle
La détection ponctuelle, là où la fonctionnalité est implémentée, se manifestera souvent par la présence de formants de sélection/condition entourant la procédure utile. L’on aura par exemple un code de type:

if(IsValid(userName) && IsValid(userPassword))
{
  //do something
}

Les avantages sont clairs: les mesures de détection peuvent être extrêmement granulées et adaptées à chaque cas. D’un autre côté, la maintenance d’une telle logique peut en prendre un sacré coût lorsqu’il faudra effectuer des modifications de masse dans l’application, telles qu’un changement de logique dans la validation des formulaires d’un Intranet par exemple.

détection centralisée
D’un autre côté, les comportements de détection peuvent être détectés de manière centralisée, pour autant que la technologie le permette. Microsoft, au travers de la technologie Active Server Pages par exemple a fourni aux développeurs d’applications l’accès à des points de flux stratégiques tels que l’initialisation d’une session ou d’une application. Le concept a été poussé à l’efficacité dans la technologie Dotnet grâce à laquelle un développeur peut intercepter une multitude d’événements bien critiques aux applications web tels que l’arrivée d’une nouvelle requête, la fin du traitement d’une requête, le déclenchement de toute forme d’erreur, etc.

La détection centralisée prendra plutôt la forme suivante, dans l’exemple ci-dessous, l’application est en mesure de détecter de manière centralisée pour tout formulaire soumis si un champ texte dépassera une longueur limite ‘globalement’ imposée à l’application:

Application_BeginRequest(...)
{
  foreach(string Key in Request.Form.Keys)
  {
    string value = Request.Form[key];
    if(value.Length > MAX_FORM_TEXT_LENGTH)
    {
      ...
    }
  }
}

La stratégie optimale consistera, l’on s’en doute, à bien répartir les objectifs entre des points de contrôle ‘localisés’ et des points de contrôle ‘centralisés’.

Responsabilité #2: se défendre contre les attaques
Un peu plus ‘active’ cette fois, cette responsabilité regroupe des mesures dites ‘préventives’. Le but ici sera soit 1) d’isoler ou dévier l’attaque 2) l’ignorer 3) la neutraliser 4) s’y contraindre (dernier cas à éviter, bien entendu).

isoler l’attaque
L’isolation est un concept un peu abstrait en matière d’applications web mais il est hérité de l’administration de certains systèmes au sein desquels il est possible de ‘rediriger’ des flux vers le néant (un bon /dev/null par exemple). L’attaque n’est dans ce cas pas neutralisée mais simplement déviée. Ce concept est rare en termes de sécurité d’applications web.

ignorer l’attaque
Ignorer une attaque est la solution la plus efficace en matière de sécurité. Mais, selon l’orgueil des maîtres d’oeuvre, elle néglige la notion de répression (capture de l’attaque, récupération de l’adresse IP de l’attaquant et suivi pénal ou toute autre mesure de dissuasion) et de statistique. Les stratégie de ‘défense’ par ignorance de l’attaque se manifesteront souvent dans un code par des branchements conditionnels ne comportant pas de cas ‘else’ ainsi que des appels de contrôle retournant des booléens:

if(IsValid(something))
{
  ...do something...
}

neutraliser l’attaque
Dans les structure un peu moins ‘impardonnables’ , telles que les applications web grand public, il peut être nécessaire de placer des mesures préventives/correctives: l’attaque est neutralisée mais le processus est maintenu. Cela se manifestera dans le code soit par des branchements conditionnels sur contrôles booléens, ou, des appels sur des contrôles procéduraux:

exemple de neutralisation par branchement conditionnel/contrôle booléen

if(IsValid(something))
{
  ... do this...
}
else
{
 ... do that...
}

exemple de neutralisation par appels procéduraux:

string userPassword = Security.Validate(userPassword);
... do this...

Le second cas est bien sûr beaucoup plus risqué dans la mesure où l’on part sur la conviction que nos mécanismes de neutralisation sont efficaces et à jour. Ce qui n’est fréquemment le cas que sur un très court instant…

se soumettre à l’attaque
Se contraindre à l’attaque est le cas à éviter par excellence, mais reste malheureusement un cas bien fréquent. En termes d’analyse de code, cela se manifestera usuellement par des traitements métier sur des données juste après leur récupération:

string username = Request.Form("username");
string userpassword = Request.Form("userpassword");
AuthenticateUser(username, userpassword);

Responsabilité #3: réagir aux attaques par des contre-mesures/contre-attaques

Le troisième niveau de responsabilité est le plus difficile à atteindre si l’on souhaite respecter cette notion d’ “autonomie” de l’application web. Cette dernière est à ce stade capable de détecter les situations hostiles et de se positionner afin choisir le comportement le plus adéquat en vue de conserver un état sûr.

Malheureusement, il y a des cas, le monde nous le prouve chaque seconde, où la meilleure défense peut être l’attaque. Cependant, la notion d’attaque, si l’on s’en tient aux traités de stratégie tels que l’Art de la Guerre pour n’en citer qu’un seul, implique TOUJOURS une fenêtre de vulnérabilité.

Pour illustrer cela, trois situations typiques de contre-mesures/contre-attaques et leur fenêtre de vulnérabilité sont analysées.

Pour rappel: une vulnérabilité en matière de sécurité de systèmes d’information se manifeste par un non-respect partiel ou total de l’un des trois axes CIA (Confidentialité / Intégrité / Disponibilité (Availablity) ).

De plus, une contre-mesure vise à contrer une attaque (attaque/contre-mesure synchrones) alors qu’une contre-attaque vise à attaquer en retour, suite à une attaque (attaque/contre-attaque asynchrones).

Contre-mesure #1: protection contre les attaques brute-force par un mécanisme de verrouillage de compte

Lorsque l’application détecte trois tentatives infructueuses d’authentification, le compte visé est verrouillé. En admettant qu’un attaquant remarque cette contre-mesure, il pourra par exemple surveiller l’activité des responsables (téléphone, site web, connaissances personnelles, etc.) et attendre qu’ils soient absents. Le moment venu, il déclenchera le dispositif de contre-mesures en tentant de se connecter avec tous les comptes importants de l’entreprise, provoquant dès lors un déni de service en bonne et due forme.

Bien que le principe de confidentialité des données soit maintenu, le principe de disponibilité ne serait plus d’actualité dans la mesure où les vrais titulaires des comptes ne pourraient plus effectuer leurs tâches.

Contre-attaque#2: protection contre le spam, un serveur de messagerie renvoie un message d’erreur pour indiquer qu’il a reçu du spam

Ici, l’exemple est pris sur un cas concret où l’administrateur souhaite ‘manifester’ aux spammeurs qu’il a correctement suivi toutes les étapes de sécurisation de son serveur. Un message à caractère “Votre courrier est du spam. Nous n’en voulons pas.” est renvoyé aux expéditeurs de courrier considéré comme indésirable. Nous sommes ici dans une mesure agissant sur l’axe d’intégrité de l’information: le serveur est optimisé pour ne fournir que de l’information utile et ‘vraie’ à ses utilisateurs.

Si un attaquant remarque cette fonctionnalité, il pourra déclencher l’envoi massif de courriers indésirables sur le serveur en ne jouant non pas sur le contenu ‘variable’ mais sur l’expéditeur variable et inexistant: le serveur de messagerie se retrouvera dès lors rapidement avec une queue de messages conséquente s’il n’est pas protégé contre cette situation.

Bien que le principe d’intégrité soit maintenu, c’est ici encore le principe de disponibilité qui s’en retrouve touché, pour une contre-mesure n’apportant peut être pas autant qu’elle ne le devrait…

Contre-attaque#3: le message de dissuasion

J’ai choisi cet exemple pour son ambiguïté: un message de dissuasion peut-il être considéré comme une contre-attaque ou contre-mesure ? Dans la mesure où le message 1) est émis suite à une attaque 2) a pour rôle de dissuader l’attaquant de retenter une prochaine attaque, il peut s’interpréter comme une contre-attaque. Cependant, s’il s’agit d’une ‘phase’ d’attaque (dans le cadre d’un processus enchaînant plusieurs étapes) cette contre-attaque peut s’avérer être une contre-mesure.

Quel message serait le plus dissuasif ?

L’accès à ce service est réservé à un personnel seul autorisé. Toute tentative fructueuse ou non d’accès …blablabla… vertu des articles ..blabla…du code pénal… dénoncé aux autorités compétentes ..blabla.

ou…

Une erreur s’est produite au sein de l’application. Nous vous prions de bien vouloir nous excuser pour ce désagrément. Vous serez redirigé dans quelques secondes sur la page d’accueil de la section actuellement visitée.

ou:

Erreur.

ou finalement, et il n’y a pas de texte type pour cela, rediriger l’utilisateur vers la page d’accueil de l’application.

Le premier message est clairement provocateur, à la limite du défi. Je ne saurais que de conseiller de l’éviter.

Contrairement aux apparences, les trois “messages” suivants sont en revanche également des contre-mesures. Qualifiées de ‘psychologiques’, ces messages n’entrent pas en matière avec l’attaquant mais lui indiquent soit 1) que le site se sent responsable de l’erreur (vol de notoriété), 2) le site remarque les situations incorrectes mais n’y accorde pas plus d’importance et 3) l’application se fout totalement des attaques et il n’est pas possible de se rendre compte via l’extérieur si une attaque a été décelée ou non.

Conclusion

Beaucoup de blabla mais peu de concret pour cet article. Il peut être cependant utile de ne pas oublier les trois points de responsabilité de l’application (détecter, se défendre, et contre-attaquer) et d’en avoir quelques exemples en tête. De plus, il ne semble pas y avoir de solution miracle. Le bon dosage reste une question de sensations et surtout, de besoins.

Il s’agira ici plutôt de se focaliser sur la phase d’élaboration des charges/spécifications de l’application à concevoir afin de déterminer de quelle manière et jusqu’à quel niveau l’application sera elle-même responsable de sa propre sécurité.

"Oeufs de pâques" (easter eggs) PHP

saphyr — Tue, 30 Nov 2004 09:54:00 GMT

Plus connus sous le nom anglophone 'Easter Egg', l'oeuf de Pâques représente une fonctionnalité non documentée d'un programme informatique. Par une série de manipulations bien précises, il est alors possible de déclencher un comportement 'inhabituel' à l'application concernée.

Certains développeurs utilisent ce genre de subtilité pour faire passer un message du genre "je l'ai fait" ou d'autres messages plus moqueurs (envers un autre développeur par exemple)* voire même des fonctionnalités jusque-là inconnues, telles que le jeu entièrement en 3d dans la suite bureautique Office.

Easter Eggs PHP

Pour en revenir au coeur du sujet, des polémiques sont lancées depuis quelques jours sur les EE se trouvant dans PHP. Trois (quatre pour les pointilleux) Easter Eggs ont été identifiés depuis quelques temps, chacun permettant d'afficher un logo ou une image à caractère ludique. L'accès est simple: il suffit de trouver un site utilisant la technologie PHP et de passer une querystring particulière dans l'URL pour que le moteur PHP ne retourne qu'une image.

La problématique sécurité

Dans les cadres d'application de méthodologies ou normes orientées qualité/sécurité, la présence d'oeufs de Pâques y est formellement interdite. Les motifs précis restaient néanmoins flous et l'on dépassait rarement le cadre du "on en sait jamais ce que cela peut déclencher", "ce genre de fonctionnalité peut avoir un coût associé caché", etc.

En ce qui concerne les oeufs de Pâques mentionnés ci-dessus, nous avons un exemple concret du danger que peuvent représenter ce genre de démarche. L'un de ces oeufs de Pâques donne l'accès aux 'credits', une liste des personnes ayant contribué de près ou de loin au développement de la technologie PHP. L'autre donne l'accès à une image représentant un développeur portant des baguettes à sa bouche...

Malheureusement, ou heureusement pour certain(e)s, ces deux oeufs de Pâques ont évolué dans le temps. La liste de crédits est dépendante dans certains cas de la version de PHP installée sur le serveur, similairement en ce qui concerne l'image, pouvant représenter, selon les versions, un chien, ou le développeur lui-même.

Les risques sont ici clairement identifiables: ces "easter eggs" initialement conçus à des fins anodines offrent aux éventuels pirates un vecteur simple d'identification de version dans de nombreux cas. L'erreur ayant été ici non pas de fournir ces easter eggs mais de les "améliorer" au fil du temps.

Se protéger contre les easter eggs...

Usuellement, ce n'est pas possible. Rares sont les cas où des options explicites permettent de désactiver ce genre de fonctionnalités. Les concepteurs de PHP dérogent à la règle en ayant fourni une variable configurable 'expose_php' dans le fichier de configuration php.ini. Il fallait le savoir tout de même..

Pour en savoir plus...

http://www.eggheaven2000.com/ (oeufs de Pâques célebres dans les applications informatiques)
http://www.dvdeastereggs.com/ (autres oeufs de Pâques, dans les DVD cette fois)

Et vous ?

Allez, main droite levée, jurez-vous solenellement que vous n'avez placé ou ne placerez jamais d'oeufs de Pâques dans vos applications ? ;)

*: si vous utilisez Internet Explorer en cet instant précis, saisissez: 'about:mozilla' (sans les apostrophes) dans votre barre de recherche et vous constaterez un Easter Egg.

Checklist sécurité et méthodes pour développeur

saphyr — Wed, 10 Nov 2004 17:58:00 GMT

- “Tu ne veux pas faire une compilation de tous ces petits trucs dont t’arrêtes pas de parler ?”
- “C’est à dire ?”
- “Genre tout ce qui touche à la sécurité, aux méthodes, tes trucs de principes là genre prog défensive ou lazy prog parce que là à force c’est tous des trucs que je comprends sur le moment mais j’oublie après coup!”
- “Ah… Je veux bien prendre des notes chaque fois que je me souviens d’un truc intéressant mais là comme ça devoir mettre sur papier tous ces détails , désolé mais pas trop le temps!”
- “Bah, ça ira aussi… Et tu vas les mettre où ?”
- “Le mieux est que je mette ça quelque part sur le net, comme ça d’autres (dont moi) pourraient peut être en profiter. (réflexion) Je sais où je vais les mettre!”
- “Où ça ?”
- “Dans ton c… oups! (sale réflexe! merci les amis!)… Je créé une nouvelle catégorie ‘checklist’ sur mon blog. Petit à petit elle se complétera et ça fera une compilation des “trucs à savoir” dans le développement web.”
- “Ok saph! merci saph! t’es un dieu saph! trop kewl saph!”
- “ouais bon ça va hein!”

;)

Console d'administration de site web : simple ou pas ?

saphyr — Sun, 07 Nov 2004 16:38:00 GMT

Dans les commentaires de l'un de mes récents articles est abordée la question de l' "accessibilité" d'un logiciel en ce qui concerne la résolution de pannes, la configuration et toute l'administration associée. Cela m'a rappelé un mandat récent dans lequel j'ai été impliqué, où cette question s'est posée.

Un projet louable...

L'objectif ? Réaliser un extranet très orienté CMS avec une interface d'administration 'moulée' dans la partie publique. Pas de 'zone administrative' visuellement parlant, juste des petits points rouges opérationnels aparaissant ci et là dans le site public lorsque l'on est authentifié. Le mot d'ordre est clair: rendre l'administration EXTREMEMENT accessible et simple pour le plus commun de mortels!

La démo...

Lorsque nous avons fait la démonstration à une cliente, une gentille dame, un peu plus de 50 ans et surfeuse occasionnelle, elle a été capable de créer un menu, lui assigner un modèle de logique en choissant 'bulletins d'actualités' et d'y ajouter un bulletin.

Le chef de projet a considéré cela comme une énorme réussite; j'ai considéré cela comme un énorme échec.

L'accès à la connaissance

J'estime qu'une interface d'administration ne doit justement pas être trop simple et trop accessible. Elle doit nécessiter des compétences et des connaissances spécifiques; celles-ci, pouvant être si on le souhaite 'simples' à acquérir , mais cette compétence doit néanmoins être 'acquise' d'une manière ou d'une autre.

Certains de mes projets touchent de près ou de loin un concept très à la mode: le knowledge management (KM) ou gestion de la connaissance si vous préférez. Je ne vais pas m'étaler longtemps sur l'explication de ce concept mais juste tenir compte d'un point critique dans le concept de KM: un bon système KM est normalement capable de délivrer l'information souhaitée à la bonne personne , sans qu'elle ne la demande explicitement, et de manière à ce qu'elle puisse l'exploiter.

Je suis très sensible à cela. C'est sympa d'une manière: cela peut sans doute permettre à une entreprise de se protéger contre la perte de connaissances associée à la perte d'un collaborateur. Mais ce dernier deviendrait donc encore plus remplaçable qu'il ne l'était déjà!

Revenons-en à ce projet d'extranet...

En voyant cette dame toute honorable qu'elle puisse être administrer un système que j'ai réalisé, je me suis senti quelque peu insulté et en danger. Une partie non négligeable des revenus de d'une petite société par exemple est réalisée grâce aux formations et aux phases d'intégration.En simplifiant énornément les processus de maintenance et d'administration, cette marge se réduit fortement. Dans l'exemple ci-dessus, une matinée a suffit alors qu'en moyenne un à trois jours sont nécessaires.

Il n'y a que dans un cas que j'imagine cette tournure souhaitable: lorsqu'une entreprise réalise trop de ventes et qu'elle se retrouve dépassée par les demandes en formation, qu'elle doit réussir à rendre l'utilisation de son produit suffisament simple pour qu'elle ne lui pose plus de soucis et qu'elle puisse se concentrer à 100% sur l'amélioration de ce produit qui "marche si bien". Mais là, ce n'est pas le cas, c'était un client, pour une réalisation, juste comme ça.

Là où l'un verrait "cool, elle a réussi à faire ça toute seule", moi j'ai vu : "pffff, deux jours et demi de formation perdus, ma commission mensuelle qui baisse".

Le responsable d'un site 'administré' peut-il être n'importe qui?

Finalement, je tenais à parler des responsables de sites dits "administrés", que ce soit des sites internet, des intranets, ou des extranets. Quel est l'avantage réel pour eux que le processus d'administration soit extrêmement simple et accessible ? Pour moi cette question est sujette à polémique.

Regardons la zone administrative des blogs .Text. Rien à voir avec la partie publique: le contenu est réorganisé, la navigation est repensée, les options sont nombreuses et il faut aller dans la section dédiée pour pouvoir effectuer une opération de gestion de contenu. Pourquoi n'y t'il pas un simple 'add category' à la fin de la liste des catégories ? Pourquoi n'y a t'il pas un petit symbole aparaissant à côté de chaque catégorie, qui lorsqu'il est cliqué nous mène sur sa page d'édition ? Pourquoi ne pas simplement cliquer sur le titre du blog et qu'il passe en mode 'édition' ? Non. Il faut choisir entre les différentes sections: posts, categories, options, links, etc. Il faut 'aller' vers la zone de gestion spécifique à ce que l'on souhaite gérer: il faut 'savoir' ce que l'on souhaite gérer.

Je trouve cela bien.

Faisons l'allusion avec la médecine. Pourrions-nous espérer que les robots d'intervention chirurgicales soient maniables et facilement gérables par n'importe quel touriste souhaitant se faire une ponction à l'intestin lui-même ? Non. Ces robots ne sont pas pensés dans cette idée. Je crois même savoir que les formations à leur utilisation se chiffrent à 4 zéros, facturés à l'établissement hospitalier désireux de 'moderniser' son infrastructure.

Le domaine du droit ? Les masgistrats s'amusent-ils à mettre en place des procédures simplifiées permettant au citoyen moyen de se gérer lui-même juridiquement parlant devant un tribunal ? Faut pas déconner: cela n'arrivera jamais!

Quelle différence entre simplicité et simplicité ? Prenons l'exemple d'un développement Dotnet sur Visual Studio. Pour modifier l'implémentaiton d'une méthode il faudra: ouvrir le fichier source contenant cette méthode, le modifier, l'enregistrer et demander une recompilation.

L'opération est simple pour un développeur. Elle est inaccessible pour un autre utilisateur. Voilà la simplicité vers laquelle je suis d'accord de me diriger en tant que développeur: je suis prêt à aller vers une simplification de mes réalisation mais une simplification rendant les tâches plus 'simples' à réaliser pour les personnes chargées de les réaliser.

Je reste en revanche totalement contre le fait de simplifier un système au point que même une personne n'étant pas spécialement désignée ou formée, pour effectuer des tâches administratives par exemple, puisse le faire.

Qui est d'accord, qui ne l'est pas ? Arriverez-vous à me faire changer d'avis ? ;)

Appliquer la défense en profondeur dans les sites de gestion de contenu

saphyr — Sun, 31 Oct 2004 17:17:00 GMT

Les sites communautaires se qualifient par leur contenu géré par plusieurs utilisateurs distincts. Dans la majeure partie de ces sites, la notion de propriété y est fortement représentée, l’on verra presque dans tous les cas que tout contenu est rattaché à un utilisateur.

La non-application du principe de défense en profondeur sur certaines opérations de ce type de sites peut placer toute la structure dans un niveau de sécurité critique. Je vous propose ici une petite étude de cas mettant le doigt là où ça fait mal, à savoir, les risques encourus suite au non-respect de ce principe sur un site communautaire…

Les sites de gestion de contenu

Les sites de gestion de contenu se qualifient par leur contenu géré par plusieurs utilisateurs distincts.

Dans la majeure partie de ces sites, la notion de propriété y est fortement représentée, l’on verra presque dans tous les cas que tout contenu est rattaché à un utilisateur.

La gestion d’un contenu regroupe usuellement les opérations suivantes :

créer un contenu
modifier ce contenu
supprimer ce contenu
modifier l’état de ce contenu (approuver, refuser, publier, etc.)

Presque tout portail communautaire entre également sous la coupole de la ‘gestion de contenu’ telle qu’elle est définie dans cet article. Les risques présentés ici s’y appliquent donc également.

Le principe de défense en profondeur

Le principe de défense en profondeur a été décrit dans un précédent article, je ne m’y attarde donc pas ici. Juste une petite phrase résumant la chose:

« La défense en profondeur consiste à ne pas faire
confiance aux mesures de sécurité prises à des couches
supérieures ou adjacentes. »

L’étude de cas: ToutesLesAnnonces.com

ToutesLesAnnonces.com est une plate-forme gratuite de publication de petites annonces. Une seule instance de l’application est installée et elle est capable de gérer l’ensemble des annonces actives sur le serveur.

Il est possible à tout internaute de s’enregistrer sur le site, puis de créer ses propres petites annonces.

Le site permet plusieurs opérations de base sur les petites annonces :

créer une annonce
publier une annonce
modifier une annonce
supprimer une annonce

La conception du site permet, au travers d’une zone membres, de gérer les petites annonces dont l’utilisateur est le propriétaire.

Le flux suivant s’applique à la modification d’une petite annonce :

afficher la liste des annonces crées par soi-même
sélectionner une annonce
cliquer sur ‘modifier’
modifier le texte de l’annonce puis cliquer sur ‘confirmer’

Un développeur n’appliquant pas la défense en profondeur réalisera le pseudo-code suivant :

—listeannonces.php—
sql = " SELECT * FROM annonces WHERE proprietaire = $idProprietaire ";

//affichage des annonces dont il est propriétaire

—modifierannonce.asp—
annID = Request.Form("id")
annTexte = Request.Form("corps")
sql = " UPDATE annonces " & _
" SET texte = '" & annTexte & "'" & _
" WHERE id = " & annID

‘* modification de l’annonce

Vous saisissez où se trouve le problème ?

Le second script, modifierannonce.asp, part du principe que l’utilisateur a demandé la suppression d’une annonce lui appartenant. Où est la garantie ?

Voici ce que le script devrait faire si le développeur applique la défense en profondeur :

—modifierannonce.asp—
annID = Request.Form("id")
annTexte = Request.Form("corps")
sql = "UPDATE annonces " & _
" SET texte = '" & annTexte & "'" & _
" WHERE id = " & annID & _
" AND proprietaire = " & idProprietaire

'* modification de l’annonce

Comme vous pouvez le remarquer, la requête a été modifiée afin d’empêcher la modification d’une annonce par une autre personne que son propriétaire.

Cette modification n’a pas demandé un effort conséquent mais apporte néanmoins un avantage non négligeable en matière de sécurité de l’application : il n’est plus possible de modifier le contenu d’un autre propriétaire, sans réussir à déjouer le mécanisme d’authentification.

Conclusion

Cet exemple peut quelque peu paraître sommaire au premier abord. Je peux néanmoins confirmer qu’au moins quatre sites considérés comme ‘majeurs’ dans la région Suisse-France sont en cet instant précis vulnérables à ce genre de faille, et ceci dans les catégories suivantes :

portail de rencontres et contacts en ligne
portail de petites annonces
service de “bureau virtuel”
forums de discussions sur des sites journalistiques

Sur le trigramme CIA (cf article principes fondamentaux de sécurité) nous sommes ici dans une situation de violation d’intégrité. Si j’applique les risques associés à cet axe de sécurité aux quatre catégories de sites ci-dessus :

modification et suppression de profils
divulgation de propos personnels, ou à caractère illégal
mise à défaut de profils de personnes
modification de conditions d’acceptation des autres contenus afin de revaloriser son propre contenu
déformation des données
usurpation d’idées (faire croire que le contenu est l’expression des idées d’une tierce personne)
détournement de flux (redirection automatique sur un contenu souhaité)
autres risques …

Alors, messieurs les développeurs ou messieurs les responsables de la sécurité, peut être serait-il temps de vous fixer quelques objectifs pour la semaine à venir ! ; )

La défense en profondeur

saphyr — Sun, 31 Oct 2004 17:15:00 GMT

Le principe de défense en profondeur est l’un de mes préférés. Pourquoi ? C’est le plus facile à oublier, et le plus vicieux à attaquer dans le cadre des services orientés web. Ce bulletin n’est publié qu’à titre formel, afin de définir le principe. Je traiterai de ce principe dans diverses études de cas prochainement publiées.

Voici une phrase très réductrice sur le principe de défense en profondeur mais résumant à elle seule toute l’idée :

« La défense en profondeur consiste à ne pas faire
confiance aux mesures de sécurité prises à des couches
supérieures ou adjacentes. »

Les couches de sécurité

saphyr — Sun, 31 Oct 2004 17:12:00 GMT

Le principe des couches de sécurité est assez intuitif mais doit être tout de même formalisé dans ce document, vu que d’autres principes se basent eux-mêmes sur celui-ci.

« L’accès a toute couche du système implique le
passage par la couche supérieure à cette couche. »

Un exemple

Pour accéder à son contenu, un intranet d’entreprise exige que tout utilisateur soit correctement authentifié. Nous pourrions résumer ce besoin en deux couches :

Couche 1 : authentification utilisateur
Couche 0 : accès au contenu

Le principe des couches de sécurité exige que pour accéder à la couche 0 (le centre), il faille préalablement avoir passé les conditions émises par la couche 1.

SI l’autorisation est accordée par la couche 1
ALORS exécuter l’opération de la couche 0
SINON refuser l’accès à la couche 0

Chaque technologie de développement web propose ses propres mécanismes d’implémentation de couches, virtuelles ou réelles.

L’on pourra utiliser les directives d’inclusions en technologie ASP classique ou les commandes ‘include’ en technologie PHP. Dans ces cas, il s’agira de couches virtuelles dans la mesure où il n’y a pas ‘logiquement’ parlant d’accès sur une couche inférieure mais accès à ‘la suite’ du code :

—index.php—
< ?php include("inc_checkauth.php"); ?>
< ?php
//afficher contenu
?>

D’autres technologie telles que ASP.Net proposent des couches réelles par exemple avec la méthode Application_BeginRequest() du fichier Global.asax. Cette méthode est exécutée avant d’appeler la page demandée. Le document lui-même n’inclut donc aucun code pouvant permettre de détecter qu’un module d’authentification est appliqué avant son appel.

Dans la mesure du possible, il sera souhaitable de toujours privilégier l’utilisation de couches réelles plutôt que virtuelles.

Les principes fondamentaux de sécurité

saphyr — Sun, 31 Oct 2004 17:11:00 GMT

La sécurité informatique repose sur plusieurs fondements. Ci-dessous, je vous propose d’approcher les sept fondements qui nous concerneront le plus dans le cadre des prochains articles publiés sur ce blog.

Cette liste n’est bien entendu pas exhaustive et n’est pas encore standardisée (à moins que j'aie mal cherché l'info?). Elle peut donc varier selon la personne à qui vous vous adressez.

Quoi qu’il en soit, elle constitue MA liste de base, nerf de guerre sur lequel s’articuleront tous les articles liés à la sécurité. Il y aura d’autres principes traités, tels que la défense en profondeur, l’obscurité, la confiance ou encore retomber sur ses pattes. Mais ceux-ci seront pour plus tard!

Triade CIA

La triade CIA regroupe trois principes essentiels au maintien de la sécurité d’un système d’information.

Les trois principes sont respectivement: la confidentialité (Confidentiality), l’intégrité (Integrity) et la disponibilité (Availability) des informations.

Certaines nouvelles formations dans la sécurité informatique proposent un quatrième principe (CIAA): l’authentification (Authentication).

Principe de confidentialité

Alice envoie un message à Bob. Qu’est-ce qui garantit à Alice que personne d’autre que Bob n’a pu ou ne pourra consulter le message ?

La confidentialité regroupe tous les mécanismes permettant d’assurer qu’une information ne pourrait être accessible et exploitable que par les personnes autorisées.

Ce principe peut être considéré de manière autonome, par exemple lorsque l’on traite de cryptographie sur un système de fichiers, ou de manière combinée, au principe d’authentification.

Intégrité

Alice envoie un message à Bob. Qu’est-ce qui garantit à Bob que ce message n’a pas été modifié durant son acheminement ?

Le principe d’intégrité vise à assurer qu’une donnée soit ‘réelle’. Cette donnée est censée représenter l’état d’une entité, d’un système ou même d’une pensée ou idée, à un instant donné.

Les contrôles d’intégrité visent à garantir qu’une donnée est représentative d’un certain modèle et qu’elle n’a pas subi de modification ou même détérioration entre deux contrôles.

Disponibilité

Alice envoie un message à Bob. Qu’est-ce qui garantit à Alice que Bob pourra consulter ce message dans les délais prévus ?

Le principe de disponibilité vise à fournir les données ou les informations lorsque les utilisateurs en ont besoin.

En clair : la disponibilité regroupe toutes les mesures visant à permettre à un service d’assurer ses responsabilités sans interruption ou du moins, lorsqu’il doit être disponible.

Authentification

Bob souhaite récupérer le message d’Alice. Comment peut-il prouver qu’il est bel et bien Bob ?

L’authentification consiste à s’assurer qu’un utilisateur est celui qu’il prétend être.

Le principe d’authentification se décline en un sous-principe : l’identification.

L’identification consiste à identifier un utilisateur de manière unique.

Quelques exemples pour différencier l’identification de l’authentification :

Système d’authentification ‘mot de passe’ : vous insérez votre carte bancaire dans un distributeur de billets. La carte sert à identifier le client (et ses comptes) sur lequel le distributeur va effectuer les opérations. Le NIP (Numéro d’Identification Personnel) vous permet de vous authentifier au distributeur : vous lui prouvez que vous êtes bel et bien le titulaire de la carte.

Système d’authentification ‘passeport’ : votre carte d’identité porte votre nom. Elle vous identifie au sein du fichier de la population d’un pays. Sur votre carte d’identité se trouve votre photo. Lorsque vous montrez votre carte d’identité à un douanier, il vous identifie par votre nom et vous authentifie par deux facteurs : le fait que vous possédiez cette carte et par le fait que vous soyez la personne représentée sur la photo.

Autorisation

Anita désire envoyer un message à Bob. A t’elle le droit de le faire ?

L’autorisation (ou permission) consiste à pouvoir déterminer si une opération est autorisée ou non.
Le mécanisme d’autorisation doit normalement être en mesure de répondre aux questions suivantes :

quel acteur désire effectuer une opération ?
quelle opération souhaite t’il effectuer ?
a t’il le droit d’effectuer cette opération ? oui, ou non.

Non-répudiation

Bob a reçu un message d’Alice. Alice prétend qu’elle ne l’a pas envoyé. Qui a raison ?

Le principe de non-répudiation regroupe les mesures permettant d’affirmer avec certitude quel est ou quels sont les auteurs d’une opération.

Très utilisé dans le domaine financier, les mesures de non-répudiation permettent par exemple d’empêcher que des investisseurs ne disent “ce n’est pas moi qui ai acheté ça, on s’est fait passer pour moi!” après que leur action n’ait chuté…

Audit - journalisation

Alice a envoyé un message à Bob le 8 février 2004 à 8 heures 34 minutes et 27 secondes. Bob a consulté ce message 4 minutes plus tard, à savoir, le 8 février 2004 à 8 heures 38 minutes et 31 secondes précises.

QUI a fait QUOI et QUAND ?

La journalisation permet de répondre à cette question, et souvent bien d’autres !

Les mécanismes de journalisation regroupent toutes les techniques permettant de récupérer et stocker les informations d’activité de manière exploitable.

L’audit entre en compte dans les mécanismes de non-répudiation (ne pas pouvoir nier que l’on a fait quelque chose): « ça a eu lieu, c’est même écrit ici » ou encore lors d’analyses statistiques par exemple : « Combien de personnes ont demandé telle ressource durant les premières heures après le passage à la nouvelle année ? ».

Ce qu’il faut retenir ici…

Un système ou application considéré comme “sécurisé” doit au minimum pouvoir fournir les services suivants :

Empêcher la consultation de données par des acteurs à qui elles ne sont pas destinées;
Conserver et fournir les données dans l’état où elles ont été laissées par leur propriétaire;
Fournir les données lorsque les acteurs en ont besoin ;
Identifier et authentifier les acteurs agissant sur le système;
Décider si oui ou non une opération est autorisée à un acteur;
Savoir QUAND a été effectuée une opération et par QUI de manière certaine

A quel moment se mettre à documenter son projet ?

saphyr — Sun, 31 Oct 2004 17:08:00 GMT

Build complete – 0 errors, 948 warnings
Building satellite assemblies…

Voci la réponse. Un projet initialement prévu pour n’être utilisé qu’en interne, dans un langage qu’aucun autre collaborateur que moi ne comprend, et qui ne serait jamais vendu est depuis peu devenu un projet développé en équipe, par des collaborateurs comprenant le langage et qui va être vendu à un client.

Le message ci-dessus est la réponse de Visual Studio à ce changement soudain de direction: 948 entrées de documentations à saisir dans les jours à venir pour se débarrasser de ces messages intrusifs!

Moralité: dans vos propriétés de projet Visual Studio, entrez un nom de fichier dans la case ‘XML Documentation File’. Cela vous forcera dès le début à rentrer dans les rangs des développeurs orientés qualité et qui documentent tout leur code

Si vous avez déjà un projet en cours, essayez, vous verrez, c’est jouissif.

Google: premiers signes de faiblesse ?

saphyr — Tue, 26 Oct 2004 19:40:00 GMT

Les données sont minces, beaucoup de suppositions mais peu d’affirmations: le célèbre moteur de recherche dont la réputation n’est plus à (dé)faire semble afficher ces derniers jours des signes de faiblesse qualitative.

Plusieurs responsables marketing ou communication chargés de surveiller leur ranking se posent des questions: positionnement dégringolant, voire inexistant, requêtes ciblées ne proposant que des résultats dispersés ou encore un manque de cohésion entre le contenu demandé et les résultats obtenus.

Quelqu’un aurait-il une source sûre d’informations sur le sujet ?

10 étapes pour sécuriser un serveur SQL 2000

saphyr — Mon, 25 Oct 2004 16:18:00 GMT

Microsoft propose un résumé composé de dix étapes clés à mettre en place afin de sécuriser un serveur de bases de données SQL 2000. L’article original est disponible ici (version anglaise).

Pour les anglophobes, un résumé de ces dix étapes est disponible ci-dessous.

1. Installer le service pack le plus récent

SQL 2000 Serveur en est au service pack 3a. Si vous ne le saviez pas encore, il est encore temps de faire cette mise à jour au plus vite à partir du portail SQL 2000.

2. Tester le niveau de sécurité avec l’outil gratuit MBSA

L’outil Microsoft Baseline Security Analyser est gratuitement proposé en téléchargement par Microsoft. Cet outil effectue un contrôle exhaustif du niveau de sécurité de votre système et de la qualité du paramétrage de vos applications Microsoft. L’utilisation de cet outil sur un serveur SQL 2000 portera certainement un bon nombre de propositions à votre attention telles que:

les droits accordés au compte invité
la qualité des mots de passe des comptes déclarés
intégrité des droits accordés aux différents rôles
paramétrage incorrect des services associés au serveur
…

Pour récupérer l’outil MBSA: Accueil MBSA (us)

3. Préférez le mode d’authentification Windows

Lorsque c’est possible, placez le serveur en configuration ‘authentification Windows’. Les authentifications bénéficieront dès lors de mécanismes améliorés d’échange de mots de passes, et les mots de passes eux-mêmes n’auront pas besoin d’être indiqués en clair dans vos applications clientes.

Pour passer un serveur SQL 2000 en authentification intégrée Windows, réalisez les trois étapes suivantes:

Lancez le gestionnaire de serveurs SQL 2000
Clic droit sur le serveur concerné, puis ‘propriétés
Dans l’onglet ’sécurité’, puis dans la section ‘Authentification’, activez l’authentification intégrée Windows

4. Isolez physiquement le serveur et sauvegardez régulièrement ses données

Tout est dans la directive.

5. Utilisez un mot de passe complexe pour le compte sa

Remarque personnelle: faites-le aussi pour les autres comptes. Ca ne mange pas pain.

6. Limitez le niveau de privilège des services associés au serveur

Deux services sont principalement associés au serveur: le serveur de bases de données lui-même ainsi que l’agent (SQL Server Agent). Ces services permettent l’exécution de commandes systèmes. Lorsque de telles commandes sont lancées, elles sont associées au compte titulaire de l’exécution du service. Si l’administrateur ou le compte système sont titulaires du service, toutes les commandes systèmes lancées sont exécutées avec leurs droits associés.

Afin de prévenir ce risque, il est conseillé de modifier les comptes titulaires de ces deux services et de préférer des comptes dotés de droits utilisateurs simples.

Attention cependant, dans certains cas bien précis cette opération n’est pas possible.

7. Empêchez l’accès au serveur par l’extérieur

Si votre structure réseau ne dispose pas encore d’un pare-feu, il est grand temps de vous réveiller. Si ce n’est pas le cas, vérifiez que le pare-feu refuse toute tentative de connexion sur les ports TCP 1433 et UDP 1434 du serveur SQL 2000.

8. Utilisez le système de fichiers NTFS

Il est également possible d’utiliser le système de fichiers EFS (chiffrement transparent des fichiers). Veillez cependant à ne pas vous faire avoir: les données sont chiffrées selon une clé associée au compte utilisateur titulaire des données. En cas de perte de ce compte, toutes les données seront perdues.

9. Supprimez ou protégez l’accès aux fichiers d’installation

L’installation du serveur génère des fichiers inutiles s’il n’y a pas eu de problème particulier. C’est le cas par exemple des fichiers logs. Consultez l’article original pour obtenir les chemins précis de ces fichiers.

Sinon, Microsoft propose un outil gratuit, Killpwd, pouvant effectuer ce travail pour vous en nettoyant les fichiers journaux de toute information critique.

10. Auditez les connexions sur le serveur SQL 2000

Il est important d’avoir une trace des événements lorsque l’on souhaite mettre en place des mesures de sécurité. Les échecs de connexion constituent une information particulièrement importante, qui doit être surveillée au possible.

Pour activer cette journalisation, lancez le gestionnaire de serveurs SQL 2000, clic-droit sur le serveur concerné, puis ‘propriétés’. Dans l’onglet ’sécurité’, section ‘niveau d’audit’, activez l’option ‘auditer les échecs’.

The server committed an HTTP protocol violation

saphyr — Fri, 15 Oct 2004 22:41:00 GMT

“The underlying connection was closed: The server committed an HTTP protocol violation.

Error reading URL: The underlying connection was closed: The server committed an HTTP protocol violation.
Please try to validate this feed. If this feed validates as correct RSS, you can send an error report. “

If you use an RSS feeds agregator like SharpReader, SauceReader or FeedReader, this error might sound familiar to you. Here is an explanation on how to prevent this…

The issue

The HTTP header keys for example shoud specifically not include any spaces in their names. However, some web servers do not fully respect standards they’re meant to.

Applications running on the Dotnet framework and making heavy use of http requests usually use the “httpWebRequest” class, which encapsulates everything a web oriented developer could dream of. With all the recently issues related to security, the “httpWebRequest” class provides a self protection mechanism preventing it to accept HTTP answers which not fully qualify to the specifications.

The common case is having a space in the ‘content-length’ header key. The server actually returns a “content length” key, which, assuming no spaces are allowed, is considered as an attack vector (HTTP response split attack), thus, triggering a “HTTP protocol violation error” exception.

The workaround

It is possible since the 1.1 SP 1 DotNet version (UPDATE: see comments for instructions prior to version 1.1, credits to Krys Oye) to disable this error check. (Un)Fortunately, DotNet allows you to modify some parameters directly through a simple text configuration file, thus not requiring the user to have some strong developer skills.

I tested this on SharpReader and it immediatly unlocked all the ‘red’ feeds I had.

1. Create a file and name it like ‘yourapplication.extension.config‘. If for example you’re using SharpReader, then create a file named ‘SharpReader.exe.config‘.

2. Open this file with a notepad or any text-based editor and paste the following text in it:

*: Be carefull: if you already see that file in the folder, edit it, and only insert the missing sections in it. Do not try to reproduce a second ‘configuration’ area for example as it will invalidate that configuration file.

3. Save it, then restart your application. That should work now.

Thanks to…

This workaround was found on Gille’s weblog, thanks to him: I can keep my favourite SharpReader

DNS Error messages with Wordpress admin

saphyr — Fri, 15 Oct 2004 22:40:00 GMT

There’s a bug in Wordpress which prevents administrators to return into the wp-admin zone. Many conditions are required but I think some information I give hereby could help locating the critical path to reproduce it and also help working around it til it gets fixed. Below is a copy of a message sent to Wordpress support some minutes ago…

----

Hi all !

Some people noticed that there might be problems entering into the administrative section of a WP enabled site. They often tend to end in a DNS ERROR message, typically provided by Internet Explorer.

I think I found some informations which might lead to this bug fix.

I recently began having similar errors: DNS timeout, DNS error, and so on. Even when turning off http friendly messages option off would produce the same error so I guessed that would not be really an ‘error’.

Web development security is my job so… I can say that those errors already happened to me in during many audits. There’s only one solution to find a bug like this: sniffing the packets and trapping all requests and replies coming from/going to the server. If you want to try this, you can install an http proxy tool such as Achilles or Paros (requiring Java VM installed on your workstation).

Here is what I got: requesting an administrative page access leads into an infinite “header location” calls (response redirects) between auth.php and the requested page.

I can’t precisely enough isolate and reproduce the error yet, but I (almost sure) know that it is related to one factor: I have multiple blogs running on the same domain (www.nxtg.net) and this happens when I did some stuff as an admin in one of my blogs, then tried to switch to another blog as an admin.

Reproduction path was not found yet, but I found the workaround:

- explicitely logout when finishing your admin stuff
or
- delete your cookies

One of those two actions will allow you to access the administrative pages again.

Finally, I think the error is located into the cookie path or information stored in it.

Hope this can help…BTW, great great great job you’re doing with WP!!!

Cheers, regards, and all stuff…

.antoine

----

Petites réflexions sur les weblogues en entreprise

saphyr — Wed, 13 Oct 2004 12:44:00 GMT

Petites réflexions sur les weblogues en entreprise, par François Nonnenmacher