Application Web

Partie relative au développement du site marchand. Elle traite donc de l'architecture de site, du développement PHP, ainsi que de la structure de la base de données.
Nous pourrons aussi y évoquer les problèmes de sécurité relatifs à la programmation PHP ou à la configuration d'Apache.

Serveur

Le site utilisera un serveur Apache ou un serveur Lighttpd.
Lighttpd a finalement été préféré, pour sa légereté, et sa configuration plus simple que Apache.

Sécurité du service Web

Dédoublement du service

Un service web de secours pourra être prêt à être lancé en cas de défaillance du premier. Il suffit pour cela de dédoubler complètement le cloisonnent (cf. ci-dessous), et de prévoir un second script de démarrage pour ce service. Une vérification régulière de l'exécution du premier service se chargera de lancer le service de secours en cas de problème (en utilisant cron par exemple).

Procédure rapide
-copie de /etc/lighttpd
-copie de /etc/init.d/lighttpd
-copie du chroot de lighttpd
-modification de /etc/init.d/lighttpd-bis (fichier de configuration)
-modification de /etc/lighttpd-bis/lighttpd.conf (repertoire chroot et fichier pid)

Cloisonnement du service

Le service est cloisonné à l'aide de l'utilitaire chroot. Ainsi le processus dispose de son propre système minimal, avec uniquement les binaires, librairies et fichiers de configuration nécessaires.
Pour le mettre en place, nous nous sommes inspirés de ce tutoriel : Chroot de lighttpd.

Url Rewriting

L'urlrewriting est un module du service web permettant de réécrire une URL reconnue par une expression régulière. Cela permet :

  • de masquer les extensions de nos fichiers ;
  • de masquer les variables passées en URL ;
  • de camoufler la structure du site web ;
  • de permettre l'indexation des pages par les bots des moteurs de recherche (inutile dans notre cas).

L'accès direct aux pages en utilisant les URL réelles n'est pas empêché, mais l'attaquant devra alors les deviner.

Listing des répertoires

Le listing des répertoires est désactivé au niveau de la configuration du serveur, complété par un fichier index dans tous les sous-répertoires, dans le but de rendre plus difficile la récupération du contenu d'un répertoire.

Masquage de l'empreinte du serveur

La configuration du serveur web contient également un ensemble de règles permettant d'empêcher l'identification du service Web (type, version, …) afin d'empêcher l'attaquant d'exploiter une faille particulière à notre type de serveur.
Cela inclut les headers renvoyé par le serveur, les pages d'erreur (404, 403, …), etc.

Sécurité de l'application web

Mise en place d'https

L'ensemble du site utilisera https. Le certificat sera généré à l'aide d'openssl.
L'intérêt est d'empêcher le sniffing sur l'ensemble des connexions. L'inconvénient est la demande supplémentaire en ressource. Néanmoins, notre analyse nous fait noter que le nombre de connexions n'atteindra jamais un niveau inquiétant (l'application web ne sera pas public).

Vérification des données provenant du client

gestion de la sécurité

Gestions des erreurs

L'affichage des erreurs sur la page est désactivé en production (ie. pendant la phase d'attaque), pour éviter de fournir des informations à l'attaquant (par exemple : la syntaxe d'une requête SQL, le fonctionnement interne des scripts, etc).
Ces erreurs seront redirigées vers un fichier de log.

Gestion des logs

L'application Web utilisera plusieurs types de log :

  • Log d'accès du service Web ;
  • Log d'erreurs du service Web : contient les erreurs du processus Web (chargement d'un module, …) et les erreurs php détaillées précedemment ;
  • Log de l'application : contient les informations fournit par l'application, comme la connexion d'un utilisateur, l'enregistrement d'un utilisateur ou d'une commande, mais également les erreurs lancées par l'application (accès à une page inexistante, mauvaise syntaxe d'un champs du formulaire) permettant d'étudier l'utilisation du site, et de détecter les tentatives d'attaques sur celui-çi.

Base de données du site marchand

  • réflexions sur la structure de la base de données MySQL ;

Script de création de la base de données

Réplication, Haute Disponibilité

Sécurité

Lors de la première phase de mise en place (mahine unique), l'instance de base de données n'écoutera uniquement qu'en local. Pour s'y connecter à distance, nous pourrons nous connecter en ssh sur la machine, puis lancer l'utilitaire mysql en local, ou effectuer une redirection local temporaire (toujours à l'aide de ssh).

La base de données ne contient que 2 utilisateurs :

  • root : l'administrateur de la base de donnée, également le propriétaire des objets de la base de l'application web
  • ecommerce : l'utilisateur applicatif du site web, ses accès seront limités et donnés un à un pour chaque table, à l'aide de grant.

Historique

Pour la gestion des versions, consultez cette discussion

Version 0.1 (14/11/08 21:33)
Version 0.2 (17/11/08 21:46)
Version 0.2.1 (18/11/08 21:31)
Version 0.3 (19/11/08 19:45)
Version 0.4 (22/11/08 15:28)
Version 0.4.1 (27/11/08 21:14)
Version 0.5 (05/12/08 21:30)
Version 0.6 B (14/01/09 21:56)
Version 0.7 RC (16/01/09 19:14)

Date : 14/11/08 21:33

Release notes

Application Web

  • Ajout : Base de la mise en page du site
  • Ajout : Implémentation de la navigation dans l'arborescence

Base de données

  • Ajout : Création de la base de données
  • Ajout : Création de la table categorie
  • Ajout : Jeu de données pour la table categorie

Source

Website 0.1 (zip)

Contenu

--|
  - index.php         version 0.1
  - style.css         version 0.1
  - creation.sql      version 0.1
  - remplissage.sql   version 0.1

Prévisions

  • version 0.2 : ajout des produits dans la base de données, et de la navigation correspondante dans l'application web ;
  • version 0.3 : ajout des fonctionnalités des clients (au moins inscription, puis login)
  • version 0.4 : ajout des commandes

A déplacer, ou à supprimer
Remarques :

  • le script php contient un certain nombre de fonctions or die(). Celles-ci stoppent le script si la fonction placée avant le or lance une erreur. C'est utile pour le déboguage ; en production le site ne doit générer aucune erreur php, il faut donc prévoir toutes les erreurs possibles, et le vérifier avec une phase de test (qui sera courte malheureusement). Il est également possible de désactiver l'affichage des erreurs dans le php.ini.
  • Ça manque cruellement de commentaire. Si vous avez des questions, n'hésitez pas à poster sur le forum.
  • La mise en page n'est qu'indicative. Je n'ai aucune idée de ce que nous pourrions mettre dans la colonne de droite (peut-être tout ce qui est login, panier, modifier son profil, …).
  • Pour le design, on verra sur la fin. Gràce au CSS, c'est très rapide à corriger. En un jours ou deux, nous pourrons avoir un design plus qu'acceptable.
  • Pour la base, l'application utilise l'utilisateur ecommerce, ecommerce, et la base projet_ssic.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License