Les brochures sont uploadés par les utilisateurs et utilisatrices sur le site avec leur titre, l'auteur de la brochure et la date du jour. Lors de l'upload, une page HTML est générée contenant ces informations et un lien vers la brochure uploadée. L'URL de la brochure est générée aléatoirement pour que l'utilisateurice puisse retrouver son archive sans qu'il soit possible publiquement de naviger dans les brochures déjà archivées. C'est de sa responsabilité de conserver cet URL (un peu comme un pad publique). Tout cela est fait en javascript coté client (voir index.js et data.js) et l'upload s'éfféctue via un script CGI deno qui écrit les fichiers uploadés dans le dossier brochures du site.

Sécurité

Cette approche laisse beaucoup de liberté aux utilisateur et utilisatrices du site. Leur laissant uploader la page HTML qu'ils et elle veulent sans vérification de leur contenu. Pour empecher les clients de déposer du code malicieux, le header Content-Security-Policy: script-src 'none'; doit etre ajouté a toute donnée qui proviendrait du dossier brochures afin d'interdir l'éxécution des scripts.

Il serait possible de faire une validation du HTML dans le script CGI dans une version futur.

Il serait aussi possible d'autoriser uniquement certaines extensions (car ce sont les extensions qui donnent le type mime de réponse).

Le site ne conserve pas de données des utilisateurs et utilisatrices sur leur navigateur. Ainsi, même si du code malveillant vient à être éxécuté sur le site, il n'aura pas beaucoup de surface d'attaque.

Concernant le script CGI, deno integre de nombreuses fonctionnalités pour restreindre les capacités d'interaction avec l'environnement d'éxécution. Dans le script src/sgi-bin/put.ts par exemple, le script n'a le droit d'écrire que dans le dossier brochures et peut uniquement lire les variables d'environnement PATH_TRANSLATED et REQUEST_METHOD. Cela restrein les capacités d'un attaquant qui exploiterai des failles du script. (Cela ne permet cependant pas d'éviter que des failles dans le système de sandboxing de deno lui-meme soit utilisées, il faut garder deno a jour).

Serveur de dev

/sbin/apache2 -d "$(pwd)" -f dev.conf -X

Installation de production

Voici les étapes d'installation pour un serveur Apache.

Il faut tout d'abord activer les modules cgi, headers et actions.

a2enmod cgi headers actions

Copiez le contenu du dossier src dans le dossier qui sera servi par apache.

cp -r src /srv/www/infokiosque-archives

Assurez vous que l'utilisateur d'apache dispose bien des droits pour acceder au dossier

chown -R www-data:www-data /srv/www/infokiosque-archives

Vous pouvez ensuite ajouter la configuration apache suivante dans le fichier /etc/apache2/sites-available/infokiosque-archives.conf

<VirtualHost *:80>
	ServerName "infokiosque.example.org"
	DocumentRoot "/srv/www/infokiosque-archives/"

	ScriptAlias "/cgi-bin/" "/srv/www/infokiosque-archives/cgi-bin/"

	<Directory "/srv/www/infokiosque-archives/brochures">
    		Header set Content-Security-Policy "script-src 'none';"
	</Directory>

	<Location "/brochures">
    		Script PUT "/cgi-bin/put.ts"
	</Location>
</VirtualHost>

Note

Il est recommandé de mettre en place SSL sur votre serveur afin de chiffrer les communications entre les utilisateurices et le serveur. Voir Mettre en place un serveur Web: Apache, Let's Encrypt sur le site de Grafikart.

Vous pouvez maintenant activer le site et recharger apache.

a2ensite infokiosque-archives
systemctl reload apache2

Vous avez maintenant un site fonctionnnel sur infokiosque.example.org.

Note

Vous aurez probablement besoin d'ajuster l'emplacement d'où sont servis les fichiers (dans mon cas /srv/www/infokiosque-archives) et d'ajuster le nom de domaine dans la directive ServerName.