Archive pour August, 2008

08-24-2008

Attaque web par injection SQL

L’attaque web par injection SQL est réalisée par des experts mettant en relation, d’une manière astucieuse, les entrées utilisateurs et le langage qui parle à la base de données.
Grossièrement, ce qui se produit est soit (1) l’insertion de commandes pour la base de données ou encore (2) la transformation des paramètres de manière à faire appliquer des commandes sur des données non-autorisées.

L’insertion arbitraire de commandes

Ce type d’injection SQL implique qu’il existe des caractères spéciaux capables d’interrompre une commande SQL existante et d’en débuter une nouvelle dictée par l’attaquant. Cette attaque est de loin la pls dangereuse car elle s’exécutera avec les privilèges de l’usager de la base de données et non avec les privilèges de l’usager du site.
La plupart des applications web ne déclinent pas leurs base d’usagers en différentes connections à la base avec différents privilèges. NON. C’est l’application qui gèrent les droits des utilisateurs et l’application se connecte ensuite à la base de données avec un super-utilisateurs qui a tous les droits, et gare à la requête qui serait vicieusement et secrètement transformée par un attaquant.

Le type de caractère spécial capable de provoquer un arrêt de la requête SQL est le ‘;’. Heureusement, la plupart des bases sont prémunies contre cela puisqu’elles n’autorisent qu’une seule commande à la fois et c’est la première qui prévaut. Enfin, certaines applications exécutent des prétraitement sur les variables afin de les filtrer de tout caractères spéciaux ou encore afin de les encoder.

Ce type d’attaque devient de plus en plus difficile à réaliser mais quelques perches subsistent en la nature de transformations mal aiguillées par l’application, qui pourrait par exemple faire l’erreur de laisser passer la requête injectée plutôt que la requête initiale. À cet effet, les requêtes préparées à l’avance (prepared statement) apportent un niveau de sécurité supplémentaire en plus de l’optimisation apportée. Celles-ci, couplées à un engin de traitement automatique des variables injectées dans les requêtes permet d’apporter une sécurisation indépendantes des opérations de programmation opérées lors de la réception des variables.

Cependant, une grande communauté de programmeurs préfèrent opérer la filtration dès la réception des variables afin d’éviter les autres inconvénients possibles de l’injection de données.

Un bon programme de test de l’application devrait donc contenir non-seulement des injections aléatoires de données mais aussi des injections systématiques des caractères dangereux pour en vérifier l’effet réel.

Le détournement de requête par transformation des paramètres

Imaginons des données privilégiées qui sont mélangées à des données publiques dans la base de données ou encore les données personnelles de chacun qui sont contenues dans la même table.

Comme dans un appel de page web dynamique, dans la base de données il ne suffit que d’un paramètre pour modifier l’essence d’une requête. Par exemple:

La réponse à ces questions dépend de l’action coordonnées de l’architecture, de la programmation et de la formulation des requêtes SQL. Une vision d’ensemble est nécessaire et c’est pourquoi la construction des applications web doit être coordonnées et dirigées par un spécialiste du métier. Des connaissances en gestion sont bien insuffisantes car la construction d’applications web n’est pas symétrique à la construction de maisons.

Voici quelques trucs qui permettent dans certaines situations d’éviter les détournements de requêtes

Dans un prochain article, je ferai un essai de procédure systématique et de tableau résumé afin d’obtenir les résultats escomptés sans limiter indûment le pouvoir de l’utilisateur.

Voici un lien complémentaire en attendant ce tableau, qui résume les attaques possibles sous forme d’une “cheat sheet”

Posté par Nadine St-Amand pour Les formations Accent Net dans Sécurité, Base de données | Comments Off

08-24-2008

Réécriture des URL dynamiques en URL sémantiques - partie 3

Cette partie parlera du cas pratique ou les URL dynamiques sont activées dans une application existante et bien connue : WordPress.

WordPress illustre bien cette double action qui doit être menée afin de faire fonctionner la réécriture des URL.

D’une part, les url générée par le CMS sont générées selon le patron préféré tel que spécifié dans la page de configuration.

Panneau d’administration

Premièrement, l’administrateur sélectionne la section nommée ‘Permalinks’

Menu Permalink

Génération des hyperliens par l’application web

Ensuite, il choisit une des formes d’URL pré-fabriquée ou en compose une lui-même en utilisant la syntaxe permettant de spécifier la position pour la date, le titre, la catégorie, l’identifiant ou encore l’auteur du message. C’est donc de cette façon qu’on conçoit l’hiérarchie apparente du site.

La liste des variables disponible pour la création de la syntaxe sémantique est disponible sur le site officiel :

http://codex.wordpress.org/Using_Permalinks#Choosing_your_permalink_structure

Chois des variables et de la structure sémantique

Réécriture des URL par le serveur web Apache

Cette indication de syntaxe permet à l’engin PHP de générer les hyperlien correspondant au rewrite mais cependant, ce n’est pas la partie qui effectue la réécriture proprement dite afin de fournir à l’engin PHP les pages paramétrisée qu’il doit travailler à partir pourtant de requête vers des pages statiques HTML.

Ces indications sont faites avec le fichier .htaccess qui peut être généré automatiquement par WordPress si le répertoire et/ou le fichiers sont accessibles en écriture.

Ensuite, l’engin réécrit, s’il en a les droits, le fichier .htaccess afin de signifier cette nouvelle configuration des URL

# BEGIN WordPress

RewriteEngine On

RewriteBase /portail-regional/

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /portail-regional/index.php

# END WordPress

Ici, la réécriture spécifie qu’elle ne doit s’accomplir que SI et seulement SI le fichier ou le répertoire demandés n’existent pas physiquement dans l’hébergement.

L’écriture des règles au niveau des fichiers locaux .htaccess ne nécessite pas le redémarrage d’Apache comme les règles indiquées dans le fichier de configuration central.

Cependant, la surcharge doit être permise par la configuration centrale et conséquemment, l’autorisation de fichiers .htaccess ralentissent le service des pages puisque le serveur doit à chaque fois vérifier la configuration locale !

Nadine St-Amand

Formatrice et designer de logiciels

Posté par Nadine St-Amand pour Les formations Accent Net dans Référencement, Sémantique | Pas de commentaires »

08-24-2008

Réécriture des URL dynamiques en URL sémantiques - partie 2

La réécriture des URL n’est malheureusement pas une opération atomique.

Si celle-ci est dictée à Apache au moyen de l’un de ses fichiers de configuration, les liens émanant des autres pages vers un lien modifié ne sont pas automatiquement réécris.

Voici donc les trois étapes nécessaires à la réécriture d’url dynamiques en url sémantiques :

Configuration serveur : ajout et activation de mod_rewrite

Premièrement on vérifie que le module mod_rewrite est bien installé. De nos jours, ce module est souvent installé par défaut. Il suffit de vérifier qu’il est bien installé sur le serveur linux et chargé par le serveur web.

Premièrement, on peut vérifier la présence physique du module sur le serveur Linux :

> ls /usr/lib/apache2/modules

mod_rewrite.so

Ensuite, on s’assure que Apache charge ce module lors de son exécution

> ls /etc/apache2/apache2.conf

Include /etc/apache2/mods-enabled/*.load

> cat /etc/apache2/mods-available/rewrite.load

LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so

> ls -l /etc/apache2/mods-enabled/rewrite.load

rewrite.load -> /etc/apache2/mods-available/rewrite.load

Pour activer ou désactiver le rewrite pour un site particulier il faut utiliser l’instruction RewriteEngine On/Off

> cat /etc/apache2/sites-available/ www_mon-portail-touristique_com

RewriteEngine On

Bien sur, la configuration du site prend effet seulement si elle connectée par la liste des sites actif

> ls -l /etc/apache2/sites-enabled/www_mon-portail-touristique_com

www_mon-portail-touristique_com

->/etc/apache2/sites-available/www_mon-portail-touristique_com

Note: dans l’ancienne version d’Apache, il était une pratique courante de ne pas utiliser les includes et de lister toutes les directives dans httpd.conf qui était le seul fichier de configurations plutot que d’utiliser les fichiers de sites-available/ et de mods-available/

Règles de réécritures édictées pour chaque site

  • Fichiers de réécriture : le fichier de configuration principal ou le fichier local

Il est possible d’édicter des règles de mod_rewrite directement dans le fichier de configuration du site, soit dans le répertoire de configuration de Apache, là ou il était indiqué que nous activions à On le RewriteEngine.

Il est aussi possible d’édicter les règles directement dans les répertoires du site web avec les fichiers locaux de configuraiton .htaccess

  • Langage de la réécriture : les expressions régulières

On veut transformer une url dynamique :

http://www.mon-portail-touristique.com

/portailregional.jsp?region=4&nom=Quebec

en url sémantique :

http://www.mon-portail-touristique.com/portail-regional/Quebec/

RewriteEngine On

RewriteRule ^portail-regional/([0-9]+)/ ([^_]+) \.html$ portailregional.jsp?region=$1&nom=$2

Après avoir effectué les ajustements à la configuration, il faut redémarrer Apache :

sudo apache2ctl graceful

  • Modes ou modificateurs de réécriture

Il existe différents modes d’applications des règles de réécriture.

Par exemple, le drapeau [R] placé après une règle de réécriture provoque le rechargement de l’url par le navigateur.

Synchronisation des hyperliens

Si le site est dynamique, comme le sont les url paramétrisées, il faudra affecter les url générées par l’application web.

La manière la plus élégante de procéder est de travailler systématiquement. Pour chaque règle énoncée dans le fichier de configuration de Apache, il faut créer une règle de transformation dans le code dynamique de l’application web.

Par exemple, dans le site de portail touristique, il faudrait que toutes les listes de liens vers les portails régionaux voient leurs url des hyperliens ajustées à la nouvelle nomenclature.

Ainsi, avant nous faisions une boucle qui ressemblait à ceci :

&nom=<%=nom %>”><=%nom %>

Maintenant, il faut ajuster ce code et écrire :

/<=%nom %>.html”><=%nom %>

Architecture favorable de l’application web

C’est pourquoi il est important d’architecturer l’application en centralisant autant que possible l’écriture des liens vers les autres pages: donc les menus, les fils d’ariane et les listes de sous-pages sont centralisés.

L’architecture sera d’autant plus cohésive si les fichiers .htaccess sont hiérarchisés de la même manière que les générateurs d’url.

Posté par Nadine St-Amand pour Les formations Accent Net dans Référencement, Sémantique | Pas de commentaires »

08-24-2008

J’utilise déjà les CSS, oui mais après ?

Il y a quelques temps, je proposais à mon patron de l’aider dans la conversion de ses sites actuellement en tableau vers des versions parfaitement propres basées sur le XHTML/CSS. Merci, me répond-il avec un petit sourire, mais nous avons déjà un programmeur qui connait les CSS. J’étais incapable de lui expliquer en mots simples qu’il y avait une différence majeure entre un site qui contient des CSS et un site basé sur celles-ci. Je bredouillai quelque chose de diplomatique et le sujet était clos.
Cycle commercial — les uns ont avertis de l’importance des CSS dans le développement de sites modernes, optimisés ‘SEO’ pour les engins de recherches — et les autres ont répondus à cet avertissement en ajoutant les CSS dans leurs sites. Le plaster est posé sur le bobo et tout est réglé.
Est-ce suffisant ? De la même manière, ajouter des aliments régime par dessus une alimentation trop riche en graisse vous fera-t-il maigrir ? La réponse est non.

L’ajout de CSS à un site web qui n’est pas sémantique n’apportera pas la flexibilité et l’optimisation que l’on associe à cette technologie. Il est difficile d’expliquer cette notion sans entrer dans les détails techniques de programmeurs.

Disons seulement que les CSS ont permis la factorisation des détails de présentation dans un lieu commun. Ils ont aussi évité la redondances de ces indications de présentation dans diverses page. Ceci révolutionna la manière de disposer les pages web, qui était jusqu’alors basée sur les tableaux, les objets étant positionné comme on déposerait divers article sur un étagère de verre pour les positionner dans l’espace.

Cette fragmentation historique du contenu, par les cellules de notre étagère-tableau, rend les pages web illisible à leur état pur, lorsq’elle ne sont pas rendues visuellement par un navigateur tel que mozilla ou internet explorer. Les aveugles, les visiteurs en mode texte et les moteurs d’indexation ne voient pas le contenu tel qu’il est dans la page visuelle.

C’est pourquoi une nouvelle méthode de conception des pages web a été inventée. On crée un fichier sémantique, sous une forme similaire au XML, avec seulement de l’informations bien structurée et étiquettée avec les balises. C’est avec la couche CSS que les éléments sont positionnés dans l’espace, colorés, et a besoin remplacé par des images décoratives. C’est toute cette technique qui est sous-entendue lorsqu’on parle du bienfait des CSS ou encore des pages web sémantiques ou même de la SEO.  Cette technique est enseignée à l’école dans le cours des Ateliers pratiques de CSS
C’est pourquoi le fait d’ajouter un peu de CSS tout en continuant de découper en petits carrés la page ne sert pas les intérêts de la page. Cette utilisation incomplète ne permet pas d’optimiser les pages d’une manière significative.

Posté par Nadine St-Amand pour Les formations Accent Net dans CSS, Sémantique | Pas de commentaires »