Sécurité et célérité proxy - GeoportalExtended - PHP - PERL/CGI - WFS

**elonguemare** · 02/07/2014, 08h08

Bonjour,

Le proxy nécessaire à la récupération de couches en dehors de celles fournies par l'IGN nécessite l'utilisation d'un "proxy", c'est une contrainte liée à l'utilisation de javascript (http://api.ign.fr/tech-docs-js/fr/we.../js/proxy.html).

2 version d'un script de proxy sont proposées (http://api.ign.fr/tech-docs-js/fr/de...ownload.html):

- l'une en PHP
- l'autre en PERL (CGI)

1 - as t-on quelque part une documentation sur la sécurisation de ces 2 scripts ? (l'url fournie en paramètre peut être n'importe laquelle, il convient de limiter cela #TODO dans le script PERL)

Le script a t-il été vérifié par un expert ?

La limitation du domaine de l'url fournie en paramètre ou même la fourniture de l'url compléte est elle suffisante (sachant que la limitation sur referer ... n'est pas réaliste) ?

2 - as t-on constaté et mesuré les différences de performances ?

Pour ma part, l'utilisation en CGI simple (ni mod_perl, ni fastcgi) du script PERL donne un rapport de x1/2 sur le temps de chargement et d'execution du script par rapport au script PHP (PHP/FCGI).

3 - quelqu'un a modifié le script PERL pour fonctionnement en FCGI (à l'instar de l'utilisation du mod_perl)?

Cordialement,

Eric

**gcebelieu** · 02/07/2014, 09h11

Bonjour Eric,

Envoyé par elonguemare

1 - as t-on quelque part une documentation sur la sécurisation de ces 2 scripts ? (l'url fournie en paramètre peut être n'importe laquelle, il convient de limiter cela #TODO dans le script PERL)

Le script a t-il été vérifié par un expert ?

La limitation du domaine de l'url fournie en paramètre ou même la fourniture de l'url compléte est elle suffisante (sachant que la limitation sur referer ... n'est pas réaliste) ?

2 - as t-on constaté et mesuré les différences de performances ?

Pour ma part, l'utilisation en CGI simple (ni mod_perl, ni fastcgi) du script PERL donne un rapport de x1/2 sur le temps de chargement et d'execution du script par rapport au script PHP (PHP/FCGI).

3 - quelqu'un a modifié le script PERL pour fonctionnement en FCGI (à l'instar de l'utilisation du mod_perl)?

Nous n'avons pas vraiment d'expertise sur ces scripts que nous avons récupéré, parfois adaptés et que nous mettons à disposition des utilisateur pour faciliter l'utilisation de l'API. Effectivement, des améliorations peuvent - ou pas - être faites sur ces scripts sur des questions relatives à la sécurité ou l'efficacité.

**elonguemare** · 02/07/2014, 10h26

Bonjour,

J'ai fait des recherches sur des bouts de code du script PERL, j'ai trouvé cela :

http://www.programmershare.com/669692/

La source du script est elle communicable ?

Cordialement,

PS : je ne suis pas expert non plus, je vais donc "enquêter" et voir si je peux apporter des améliorations, je pense que vérifier et limiter les url passées en paramètre est déjà un premier pas vers un comportement plus légitime.

PS1 : rendre le script immuable : http://fr.wikipedia.org/wiki/Chattr : chattr +i (ce devrait être le cas pour tous les CGI je pense - http://www.perlmonks.org/?node_id=1064757)

PS2 : le script (PERL/CGI) est lancé avec les options Tainted, strict et warnings :

**gcebelieu** · 02/07/2014, 16h14

Envoyé par elonguemare

Bonjour,

J'ai fait des recherches sur des bouts de code du script PERL, j'ai trouvé cela :

http://www.programmershare.com/669692/

La source du script est elle communicable ?

La source est en entête du script (en fait, ça vient de chez nous

) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
#!/usr/bin/perl -T
#
# (c) 2008 IGN - Didier.Richard@ign.fr
# License : http://creativecommons.org/licenses/by-nc-sa/2.0/fr/
#

Pour le php, on a aussi des sources bien connues du forum :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
// proxy http
// auteur: Marc Gauthier
// 02/09/2009
// les erreurs dans les log du serveur
// http://www.papygeek.com/download/53/
// Transfer-Encoding: chunked
//
// Didier Richard - IGN - dérivation pour publication
// (c) IGN 2010
// License : http://creativecommons.org/licenses/by-nc-sa/2.0/fr/

Pour les scripts JSP et ASP, ils ne sont pas signés. Ils ont peut être été écrits chez nous, mais je n'en suis pas sûr...

PS : je ne suis pas expert non plus, je vais donc "enquêter" et voir si je peux apporter des améliorations, je pense que vérifier et limiter les url passées en paramètre est déjà un premier pas vers un comportement plus légitime.

PS1 : rendre le script immuable : http://fr.wikipedia.org/wiki/Chattr : chattr +i (ce devrait être le cas pour tous les CGI je pense - http://www.perlmonks.org/?node_id=1064757)

PS2 : le script (PERL/CGI) est lancé avec les options Tainted, strict et warnings :

Merci pour ces infos.

**elonguemare** · 02/07/2014, 17h48

Bonsoir,

J'ai apporté quelques corrections au script proxy.pl pour au moins controler l'url demandée (limiter les urls à celles necessaires) et le referer (meme si ce n'est pas 100% fiable pour le referer)

Le diff :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
--- /home/eric/Téléchargements/proxy.pl
+++ /home/eric/Téléchargements/proxy_new.pl
@@ -9,7 +9,7 @@
 
 # modules
 use CGI qw/:cgi/;# pour dialoguer sur http
-$CGI::POST_MAX=1024 * 1000;  # max 1000Kb posts
+$CGI::POST_MAX=1024 * 1000;  # max 1000Kb posts (was 1000)
 use LWP::UserAgent;
 use HTTP::Headers;
 use HTTP::Message;
@@ -22,9 +22,11 @@
 #  variables globales
 our $VERSION= '0.0.1';
 
-# TODO : fichier de configuration par défaut
-# il peut être écrasé par la directive SetPerlVar
+# TODO : fichier de configuration par defaut
+# il peut etre ecrase par la directive SetPerlVar
 my $configfile= '';
+my @urllocking=("urlduservice");#liste des URL autorisées ("url1","url2") par exemple http://services.sandre.eaufrance.fr/geo/zon_FXX? 
+my $domain='domainedusiteweb'; #domaine des pages utilisant l'API geoportail
 
 #
 # Sortie en erreur
@@ -225,7 +227,7 @@
 #
 # Programme principal :
 #
-# On récupère la GlobalRequest en premier
+# On recupere la GlobalRequest en premier
 my $gr= undef;
 my $cgi= undef;
 if ($ENV{MOD_PERL}) {
@@ -246,6 +248,11 @@
 if (!defined($url) || length($url)==0) {
     notify_proxy_failure($cgi,400,'no url parameter');#RC_BAD_REQUEST
 }
+# is url in @urlocking // check url and referer domain 
+notify_proxy_failure($cgi,403,'Not an authorized url') unless grep {$_ eq $url} @urllocking;#RC_BAD_URL
+#check if referer domain is empty or bad domain
+notify_proxy_failure($cgi,403,'Not authorized') if ($cgi->referer() !~ m|^https?://$domain/|);#RC_BAD_REFERER
+# else continue and proxyfy
 if ($url=~m/^https?:\/\//) {
     proxyfy_remote($cgi,$url);
 } else {

J'ai un fichier dispo pour envoi si OK.

PS : j'ai utilisé grep même si ce n'est pas le plus rapide, si une seule url à "proxyfier" pour utilisation de l'API, @urllocking peut être remplacé par une variable.

Cordialement,

Eric

**mga_geo** · 02/07/2014, 21h39

Bonsoir,

Lorsque l'on durcit du code, une bonne pratique est de ne pas avoir des "code erreur" significatifs. Il faut réserver ceux-ci à un mode "DEBUG".

**elonguemare** · 03/07/2014, 11h47

Bonjour,

C'est une bonne remarque. Il faudra modifier les lignes concernées.

C'est un domaine difficile à aborder, puisque chacun entoure d'un peu de secret ses mesures de sécurisation. Par exemple : http://www.perlmonks.org/?node_id=1064757, faut il en parler ou pas ?

Ici, j'ai été un peu surpris de voir qu'un "proxy" était "livré" sans contrôle sur les urls "proxyfiables" : un utilisateur non averti l'utilisera sans plus de précaution.

C'est toujours le cas du fichier PHP, qui plus simple à mettre en service, concerne peut être davantage un public moins averti.

Fallait-il en parler ou pas ?

Cordialement,

Eric

**mga_geo** · 04/07/2014, 21h38

L'objectif de forum est l'API Géoportail, et souvent les scripts montrés ne sont qu'une démonstration de faisabilité.
Sécuriser une application comporte plein de volets et même si souvent l'accent est mis sur le code la très forte majorité des défaillances provient d'autres éléments.

Dans le cas du proxy, il est plus simple d'utiliser le parefeu qui protège l'application.

**elonguemare** · 05/07/2014, 07h20

Bonjour,

Le fichier .htaccess avec le mod_rewrite conviendra pour tout le monde - tous les types d'hebergement proposent maintenant cette possibilité.

Cordialement,

Eric

Sécurité et célérité proxy - GeoportalExtended - PHP - PERL/CGI - WFS

IGN API Géoportail

Discussions similaires

Partager

Partager