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:

On désire obtenir toutes les information concernant Louise. Mais que se passe-t-il si on envoie le numéro de Jean même si on est authentifiée en tant que Louise ?
On désire faire afficher une sélection de données selon des paramètres. Mais que se passe-t-il si on envoie le symbole de sélection universelle du SQL qui n’est pas l’étoile ‘*’ mais le pourcentage ‘%’
On désire effacer une de nos fiches d’informations, mais que se passe-t-il si on modifie le formulaire et que l’on inscrit le paramètre universel à la place du numéro d’identification de notre fiche d’information ? Effacera-t-on toutes les fiches ?

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

Afin de rendre impossible la généralisation d’une opération d’effacement ou de mise à jour, il est pertinent dans le SQL d’utiliser la condition = plutôt que la condition LIKE.
Il faut réserver la condition LIKE à des recherches s’opérant dans des données déjà toutes restreintes publiques
Afin d’éviter le détournement d’une opération de sélection, mise à jour ou effacement de données individuelles, il faut que le compte restreint génère les paramètres de conditions à partir de l’authentification revalidée.
L’empêchement de la généralisation des opérations de recherches publiques paramétrées paraît ici moins critique en regard de la protection de l’information. Cependant, pour qui est intéressé a en limiter l’usage, il suffit d’encapsuler le caractère spécial % afin de le transformer en donnée normale (par une ‘escape’). Comme les utilisateurs désireux d’utiliser le wildcard prendront sans hésiter le symbole *, il suffit de travailler sur celui afin de le rendre disponible en complément des données existantes et d’empêcher son utilisation seule.

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 :

Le serveur web est configuré pour supporter la réécriture d’url par l’ajout et l’activation du module mod_rewrite
Le serveur web est informé des réécritures qui auront cours pour chaque site web
Le code du site web doit refléter la réécriture en utilisant les nouvelles versions d’url dans les balises d’hyperlien

Configuration serveur : ajout et activation de mod_rewrite

Installation du module

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

Activation du module

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

La réécriture des URL dynamiques en URL sémantiques - partie 1

Dans un site web dynamique reposant sur une base de données, les différentes pages décrivant le même type de données ont toutes la même adresse web. Ce qui permet de les différencier c’est seulement le paramètre, souvent un identifiant numérique, associé à l’URL.

Exemple d’une URL dynamique

http://www.portail-touristique.com/portailregional.jsp?region=4

Ces pages dynamiques sont celles publiant sur le web les données issues de la base de données, par exemple : la page d’un produit dans un commerce électronique, la page d’un article dans un journal, etc.

Ces pages sont très mal indexées par les moteurs de recherche qui s’intéressent surtout à la sémantique de nos pages. En effet, ceux-ci considèrent les informations suivantes par ordre d’importance :

Le nom du domaine
Le nom de la page et de son hiérarchie
Le titre de la page (balises )
Le contenu

Ces informations permettent au moteur d’indexation de conserver notre page web dans la bonne catégorie de son index et parfois même de tisser des liens sémantiques entre ces contenus et ceux d’autres sites.

Comment un moteur d’indexation, tel que Google, peut-il voir la différence fondamentale entre notre région numéro 4 et notre région numéro 5 s’il n’y a pas d’autre d’informations les décrivant. D’autre part, comment pourrait-il associer cette donnée avec d’autres informations de sa base si les mots-clés décrivant la région manquent !

C’est pourquoi des informations sémantiques plus pertinentes devraient être associées à l’adresse web. Par exemple, il est préférable de publier le mot-clé principal de la région dans l’URL, même si ce mot-clé n’est pas utilisé dans la requête (dans le script de la région c’est l’identifiant numérique qui est utilisé).

Exemple d’une URL dynamique et sémantique

http://www.portail-touristique.com/portailregional.jsp?region=4& nom_region=Quebec

Ainsi, lorsque les ‘crawlers’ iront visiter notre site, ils verront distinctement la différence entre la région 4 et la région 5 et pourront identifier ce contenu avec des mots-clés.

Cependant, l’algorithme de l’engin d’indexation considèrera sans aucun doute que cette information est de second ordre si elle est placée dans un paramètre. Elle ne vaudra pas plus qu’un autre paramètre tel la langue ou le numéro de session ! Un autre facteur défavorisant l’indexation des pages paramétrées est leur nombre impressionnant et leur pertinence toute relative sur le web d’aujourd’hui. Enfin, considérons également le retard dans le développement des moteurs de recherche qui n’aide pas leur cause : celui par rapport à la capacité de gestion de ces url un peu spéciales.

Quoi qu’il en soit, c’est une vérité communément admise de nos jours qu’il vaut mieux avoir une url dans laquelle la sémantique n’est pas distribuée dans les paramètres, mais dans laquelle plutôt, la sémantique serait concentré dans le chemin de la page et le nom de la page. On tente le plus possible de présenter une adresse de page qui serait sémantique en elle-même : les mots-clés font partie du nom de la page et de ses répertoires. Voici quelques exemples ou les mots-clés sont mis en avant et les identifiants numériques sont filtrés.

Exemple d’une URL sémantique (d’apparence non-dynamique)

http://www.portail-touristique.com/portail-regional-quebec.html

Exemple d’une URL sémantique (d’apparence non-dynamique)

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

Comment s’opère cette magie : soit présenter plusieurs noms de pages statiques par un système dynamique opérant un seul script, i.e. une seule page qui les génèrent toutes ?

C’est la réécriture d’URL, aussi connue par les expressions anglophones ‘url rewriting’ ou ‘mod rewrite’.

Dans le prochain article, nous apprendrons comment réaliser cette magie à l’aide du module mod_rewrite de Apache.

Nadine St-Amand

Formatrice et designer J2EE

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 »

Journal du web

La transition web… sémantique, accessible & ergonomique

Archive pour August, 2008

08-24-2008

Attaque web par injection SQL

L’insertion arbitraire de commandes

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

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.

Panneau d’administration

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

Réécriture des URL par le serveur web Apache

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.

Configuration serveur : ajout et activation de mod_rewrite

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

Synchronisation des hyperliens

Architecture favorable de l’application web

08-24-2008

La réécriture des URL dynamiques en URL sémantiques - partie 1

08-24-2008

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

Pages

Archives

Catégories

Liens

Meta