Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage Perl Modifier password.cgi

Modifier password.cgi

21 réponses
Avatar
Paul Sellis
J'utilise le script password.cgi.

Pour faciliter l'administration, je souhaiterais que sur la page où l'on
présente des utilisateurs déjà inscripts (Current Users), en plus de
leur nom on ait aussi leur Password non crypté.

Mais évidemment je n'y connais rien en Perl... comment faire ça ?




#!/usr/bin/perl
# Copyright by Floyd Morrissette Floyd@NewWebSite.com
# Make sure you chmod 755 or make it executable by everybody.
# And of course make sure you rename this file to password.cgi
# Change the following variable to the way your forms should call cgi
scripts on your system. No trailing slash.

$action = "http://www.you-site.com/cgi-bin";

print "Content-type: text/html\n\n";
$pwd = `pwd`;
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
foreach $pair (@pairs) { ($name, $value) = split(/=/, $pair);
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$value =~ s/~!/ ~!/g; $FORM{$name} = $value;}
$directory = $FORM{'directory'};
$user = $FORM{'user'};
$path = $FORM{'path'};
$name = $FORM{'name'};
$password = $FORM{'password'};
$newpass = crypt($password, tnnntv);
if ($FORM{'submit'} eq "Add") {
&encrypt
}elsif ($FORM{'submit'} eq "Submit"){
&form2;
}elsif ($FORM{'submit'} eq "Delete"){
&delete;
}else{
&form;
}
sub form{
print <<HTML;
<html>
<head>
<title>Password Manager</title>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0">
<tr>
<td bgcolor="#008080"><font color="#FFFFFF" size="2"
face="Verdana"><b>Password Manager</b></font></td>
</tr>
</table>
<p>Which directory would you like to manage passwords for?</p>
<form method="POST" action="$action/password.cgi">
<p>
The current full directory path for the password.cgi is
<b>$pwd</b><br><br>
Directory: <input type="text" name="directory" size="20"><br>
<input type="submit" value="Submit" name="submit"></p>
</form>
<p>&nbsp;</p>
</body>
</html>
HTML
}
sub form2{
print <<HTML;
<html>
<head>
<title>Password Manager</title>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="0">
<tr>
<td bgcolor="#008080"><font color="#FFFFFF" size="2"
face="Verdana"><b>Now
Managing Passwords for:<br> $directory</b></font></td>
</tr>
</table>
<form action ="$action/password.cgi" method="post">
<table>
<tr>
<td>New member:</td><td><input type="text" name="name"></td>
</tr>
<tr>
<td>Password:</td><td><input type="text" name="password"></td>
</tr>
<tr>
<td colspan=2><input type="submit" value="Add" name="submit"></td>
</tr>
</table>
<p>Current Users:<br>
HTML
open (FILE1, "$directory/.htaccess") || print "There does not appear to
be a .htaccess file here yet. <br>Will attempt to create when you add a
new user.\n";
@ht=<FILE1>;
close(FILE1);
foreach $ht(@ht){
chomp($ht);
if ($ht =~ /require/){
@require = split(/ /, $ht);
@require = reverse(@require);
$old = pop(@require);
$old2 = pop(@require);
@require = reverse(@require);
foreach $require(@require){
print "<input type=\"radio\" name=\"user\"
value=\"$require\">$require<br>\n";
}
}
}
print <<HTML;
<p><br>
<input type="submit" value="Delete" name="submit">
<input type="hidden" name="directory" value="$directory">
</form>
<p>&nbsp;
<p>&nbsp;
<p>&nbsp;
<p><br>
</form>
</body>
</html>
HTML
}
sub encrypt{
if (-e "$directory/.htaccess"){
open (PANEL, "$directory/.htaccess") || print "Can't open
$directory/.htaccess\n";
@panel = <PANEL>;
close (PANEL);
open (FILE2, ">$directory/.htaccess");
foreach $panel(@panel){
chomp($panel);
if ($panel =~ /require/){
$panel = $panel.$FORM{name}." ";
}
print FILE2 "$panel\n";
}
close (FILE2);
$newpass = crypt($FORM{password}, tnnntv);
open (PANEL, ">>$directory/.htpasswd") || die print "Can't open
.htpasswd";
print PANEL "$FORM{name}:$newpass\n";
close (PANEL);
}else{
open (FILE, ">$directory/.htaccess") || die print "Can't open
$directory/.htaccess";
print FILE "AuthUserFile $directory/.htpasswd\nAuthName
\"Access\"\nAuthType Basic\n<limit GET>\nrequire user
$FORM{name}\n</limit>\n";
close(FILE);
open (FILE2, ">$directory/.htpasswd") || die print "Can't open
$directory/.htpasswd";
print FILE2 "$FORM{name}:$newpass\n";
close(FILE2);
}
&form2;
}
sub delete{
if ($user ne ""){
open (FILE, "$directory/.htaccess");
@htaccess=<FILE>;
close(FILE);
open (FILE2, ">$directory/.htaccess");
foreach $htaccess(@htaccess){
chomp($htaccess);
$htaccess =~ s/$user\s//;
print FILE2 "$htaccess\n";
}
close(FILE2);
open (FILE3, "$directory/.htpasswd");
@password=<FILE3>;
close(FILE3);
open (FILE4, ">$directory/.htpasswd");
foreach $password(@password){
chomp($password);
print FILE4 "$password\n" unless ($password =~ /\b$user\b/);
}
}
&form2;
}
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Patrick Texier
Le Thu, 11 Sep 2003 20:46:03 +0200, Paul Sellis
a écrit :

comment décrypter un mot de passe quand on connait le résultat crypté et
la clé ?


Cela ne sert à rien. De mémoire le codage MD5 en Perl est géré par le
module Digest::MD5. On ne teste que le résultat du codage.
--
Patrick Texier

Avatar
Franck Guillaud
Patrick Texier wrote:
Le Thu, 11 Sep 2003 20:46:03 +0200, Paul Sellis

comment décrypter un mot de passe quand on connait le résultat
crypté et la clé ?


Cela ne sert à rien. De mémoire le codage MD5 en Perl est géré par le
module Digest::MD5. On ne teste que le résultat du codage.


Et surtout, on ne peut pas remonter au mot de passe en clair à partir
du mot de passe crypté, même avec la clef qui d'ailleurs n'en est pas une.

Le seul moyen de comparaison possible consiste à comparer les données
cryptées....

Franck.


Avatar
Paul Sellis
In article ,
Patrick Texier wrote:

comment décrypter un mot de passe quand on connait le résultat crypté et
la clé ?


Cela ne sert à rien. De mémoire le codage MD5 en Perl est géré par le
module Digest::MD5. On ne teste que le résultat du codage.


OK.
Mais comment redonner le mot de passe à quelqu'un qui l'aurait oublié ?


Avatar
Emmanuel Florac
Dans article ,
disait...

OK.
Mais comment redonner le mot de passe à quelqu'un qui l'aurait oublié ?



Tu ne peux pas. Tu le changes, c'est la seule méthode sûre.

--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?

Avatar
Paul GABORIT
À (at) Thu, 11 Sep 2003 20:28:16 +0200,
Paul Sellis écrivait (wrote):
In article ,
Paul GABORIT wrote:

hum... c'est très possible que ce soit du gruyère.
C'est sûr !!! On peut exécuter, grâce à ce script, n'importe quelle

commande !


Ceci dit il est situé dans un répertoire cgi-bin qui n'est pas
normalement pas lisible directement à partir de serveur web. C'est un
répertoire en parallèle de www.


Certes (tous les CGI sont habituellement dans des répertoires spéciaux hors
des documents statiques). Mais il faut bien que l'utilisateur puisse lui
envoyer une requête à ce script. Or une requête forgée correctement (par
exemple, en envoyant un commande comme nom de 'directory') permet de faire
exécuter n'importe quelle commande au serveur web. Ce n'est pas un petit
trou... C'est une porte béante !!!!

(*) Si c'est un serveur Unix, essayez de lui passez comme valeur du champ
directory '|cat /etc/passwd' (avec comme valeur de submit 'Submit'). Ça doit
fonctionner au poil.

--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Perl en français - <http://www.enstimac.fr/Perl/>
Remove '.OOO' from e-mail address - Supprimez '.OOO' de l'adresse e-mail



Avatar
Michel Rodriguez
Paul Sellis wrote:

J'utilise le script password.cgi.
Pour faciliter l'administration, je souhaiterais que sur la page où l'on
présente des utilisateurs déjà inscripts (Current Users), en plus de
leur nom on ait aussi leur Password non crypté.
Mais évidemment je n'y connais rien en Perl... comment faire ça ?


Ne le prends pas mal, mais vu ce message et le reste de l'enfilade, non
seulement tu ne "connais rien en Perl", mais apparemment la securite n'est
pas ton fort non plus.

Dans ces conditions administrer un script qui gere des mots de passe me
semble extremement dangereux.

Bien sur tu ne seras pas le premier a faire ca, le Web est plein de site mal
administres, mais quand meme, reflechis a ce a quoi tu t'exposes avant de
te lancer la dedans: le site que tu administres peut etre pirate tres
facilement, la machine usilisee comme relais pour des attaques de sites
plus sensibles, les mots de passes de tes utilisateurs recuperes, puis
utilises pour attaquer d'autres comptes...

Au moins lis un peu de doc, histoire de comprendre les principes de base de
la securite, sans meme parler du script que tu utilises. perldoc perlsec
donne quelques indications, mais vraiment il me semble qu'il faudrait que
tu commence par des bouquins d'introduction.

J'ai pas lu beaucoup dans le domaine, donc j'ai pas vraiment de
recommendation, mais je suis sur que d'autres en auront.

A partir du moment ou on s'occupe de machines accessibles depuis
l'exterieur, la securite c'est serieux, ca ne doit pas etre traite "a peu
pres", ou on s'expose a de graves consequences (surtout.

Voila, j'espere que ca ne te demoralisera pas trop, mais je crois qu'il vaut
mieux te prevenir, plutot que tu aies des surprises desagreables plus tard.

__
Michel Rodriguez
Perl &amp; XML
http://xmltwig.com

Avatar
Paul Sellis
In article <bjs9qn$g64$,
Michel Rodriguez wrote:

Ne le prends pas mal, mais vu ce message et le reste de l'enfilade, non
seulement tu ne "connais rien en Perl", mais apparemment la securite n'est
pas ton fort non plus.


Je ne le prends pas mal : j'ai dit que je n'y connaissais rien.
Oui mais bon...
après une recherche Google "relativement" sérieuse je suis arrivé à ce
script référencé dans des sites Perl. Je l'ai installé et il fonctionne
sur un site hébergé chez OVH, hébergeur profesionnel. Les éventuels
trous de sécu ne sont pas de mon fait, mais révèlent les limites dudit
script.

Ceci dit (bien qu'ayant reçu de beaucoup conseils ici... et merci), tout
le monde crie au mauvais script mais personne ne m'en a proposé d'autre
(à part Mickëy qui a participé à son évolution -> et Merci à lui).


Dans ces conditions administrer un script qui gere des mots de passe me
semble extremement dangereux.


Je ne cherche pas à administrer un script qui gere des mots de passe.
Je cherche à administrer les mots de passe avec un script.
A priori, moi seul. Pas d'autres administrateurs. Sauf script "safe".

Bien sur tu ne seras pas le premier a faire ca, le Web est plein de site mal
administres, mais quand meme, reflechis a ce a quoi tu t'exposes avant de
te lancer la dedans: le site que tu administres peut etre pirate tres
facilement, la machine usilisee comme relais pour des attaques de sites
plus sensibles, les mots de passes de tes utilisateurs recuperes, puis
utilises pour attaquer d'autres comptes...

Au moins lis un peu de doc, histoire de comprendre les principes de base de
la securite, sans meme parler du script que tu utilises. perldoc perlsec
donne quelques indications, mais vraiment il me semble qu'il faudrait que
tu commence par des bouquins d'introduction.

J'ai pas lu beaucoup dans le domaine, donc j'ai pas vraiment de
recommendation, mais je suis sur que d'autres en auront.


C'est un peu ça le problème, on dit à peut près ici :
"Fait gaffe, t'y connais rien (et ne le prend pas mal...), c'est une
histoire sérieuse là". Et plop... rien de plus.


A partir du moment ou on s'occupe de machines accessibles depuis
l'exterieur, la securite c'est serieux, ca ne doit pas etre traite "a peu
pres", ou on s'expose a de graves consequences


tu vois...


Voila, j'espere que ca ne te demoralisera pas trop, mais je crois qu'il vaut
mieux te prevenir, plutot que tu aies des surprises desagreables plus tard.


non, non, mais ça ne fait pas avancer le schmilblick tout ça...
Ce script ne semble pas bon, mais personne ne m'en signale de fiable.
Même payant...

Avatar
Michel Rodriguez
Paul Sellis wrote:

après une recherche Google "relativement" sérieuse je suis arrivé à ce
script référencé dans des sites Perl. Je l'ai installé et il fonctionne
sur un site hébergé chez OVH, hébergeur profesionnel. Les éventuels
trous de sécu ne sont pas de mon fait, mais révèlent les limites dudit
script.


Les trous de secus sont de ton fait: c'est toi qui installe le script. Si ta
machine est hackee et/ou des donnees sensibles sont crackees, c'est pas la
faute de l'auteur du script, c'est entierement la tienne. Tu vas vraiment
dire a tes utilisateurs ou a ton chef "c'est pas ma faute c'est la faute
d'un script que j'ai installe"? Tu crois que ca va les interesser comme
explication?

Dans ces conditions administrer un script qui gere des mots de passe me
semble extremement dangereux.


Je ne cherche pas à administrer un script qui gere des mots de passe.
Je cherche à administrer les mots de passe avec un script.
A priori, moi seul. Pas d'autres administrateurs. Sauf script "safe".


Quand je dis "administrer un script qui gere des mots de passe" ca veut dire
le faire tourner. Ce que je veux dire c'est que tes problemes me semblent
depasser de loin la recherche d'un script sans trous de securite. Quand tu
installe un script qui gere des mots de passe, tu administres la securite
de ton site.

C'est un peu ça le problème, on dit à peut près ici :
"Fait gaffe, t'y connais rien (et ne le prend pas mal...), c'est une
histoire sérieuse là". Et plop... rien de plus.


Rien de plus parce que je fais pas de formation a la securite informatique.
Et que je gere les mots de passe avec du code que j'ai ecrit moi-meme.

Voila, j'espere que ca ne te demoralisera pas trop, mais je crois qu'il
vaut mieux te prevenir, plutot que tu aies des surprises desagreables
plus tard.


non, non, mais ça ne fait pas avancer le schmilblick tout ça...
Ce script ne semble pas bon, mais personne ne m'en signale de fiable.
Même payant...


Le probleme c'est que ton schmilblick il a beaucoup de chemin a faire. Tu
nous demande ou trouver une capsule Apollo, meme payante, et on te dit que
ca va pas t'emmener sur la Lune, qu'il y a des trucs a faire avant le
decollage... C'est sur ca repond pas a ta question. Mais repondre a ta
question ne t'enverrait pas sur la Lune pour autant.

Dans ton cas, meme si par hasard on te trouvait un script plus sur, dans la
mesure ou tu te propose de diffuser les mots de passe en clair sur le
reseau, ca avancerait pas beaucoup tes utilisateurs.

Ton probleme de fond, c'est que, pour des raisons surement excellentes, tu
te retrouves a gerer la securite de compte utilisateurs sans avoir la
competence pour ca. Alors tu auras peut etre de la chance et tu n'auras pas
de probleme, mais pour te donner une idee, le dernier site que j'ai
installe, a ete attaque 15 minutes apres avoir lance le httpd pour la
premiere fois, alors qu'il n'etait meme pas encore accessible par une URL,
juste par une adresse IP. J'essaye juste de te faire prendre conscience de
ce a quoi tu t'exposes.

Et si tu fais ca pour ton boulot, il faudrait peut etre qu'il te paye un
formation a la securite.

__
Michel Rodriguez
Perl &amp; XML
http://xmltwig.com


Avatar
Paul Sellis
In article <bk4fi4$am2$,
Michel Rodriguez wrote:

Dans ton cas, meme si par hasard on te trouvait un script plus sur, dans la
mesure ou tu te propose de diffuser les mots de passe en clair sur le
reseau, ca avancerait pas beaucoup tes utilisateurs.


Bon OK, soit.

Mais en dehors des mots de passe en clair sur le reseau, auxquels je
renonce maintenant vu le danger que ça fait courrir à la sécurité,
est-ce que :

€ les fichiers .htaccess et .htpasswd dans les répertoires que l'on veut
protéger sont suffisants, ou faut-il mettre une sécu supplémentaire ?
Laquelle alors ?

(tiens au passage, j'ai mis un AuthType Digest, plutôt que Basic dans
.htaccess, c'est mieux non ? Suffisant ?)

€ et comment faire pour que le script CGI qui me permet de gérer pour
mes clients leurs login/password ne soit vraiment pas accessible depuis
l'extérieur ?
http://www.mon_nom_de_domaine.com/cgi-bin/password_ou_tartenpion.cgi

Je suis hébergé chez OVH. Et il existe les sécurités suivantes pour ce
répertoire (je cite OVH) :
- les fichiers mis dans le répertoire cgi-bin ne peuvent être lus. Ils
peuvent uniquement être executés. Vous ne pouvez pas y placer par
exemple les images gif ou jpeg. Leur lecture provoquera l'erreur.
- puisque aucun fichier ne peut être lus dans cgi-bin, vous pouvez y
placer les fichiers de bases de données en texte par exemple que vous
souhaitez protéger.
- l'execution des scripts cgi à partir de cgi-bin se fait via un alias
de votre site. Vous ne pouvez pas executer les scripts autrement qu'avec
votre domaine.


Merci.

Avatar
Michel Rodriguez
Paul Sellis wrote:

€ les fichiers .htaccess et .htpasswd dans les répertoires que l'on veut
protéger sont suffisants, ou faut-il mettre une sécu supplémentaire ?
Laquelle alors ?


En general je mets pas les fichiers avec des mots de passe dans l'arbre
html. Si ils sont ailleurs, il y a moins de chance que quelqu'un y accede.

(tiens au passage, j'ai mis un AuthType Digest, plutôt que Basic dans
.htaccess, c'est mieux non ? Suffisant )


Ca depend du degre de securite que tu veux. Si tu veux vraiment sur, ya pas
de secret, utilise SSL, sinon effectivement Digest semble mieux que Basic,
mais j'ai pas d'experience avec.

http://httpd.apache.org/docs/howto/auth.html donne quelques infos.

€ et comment faire pour que le script CGI qui me permet de gérer pour
mes clients leurs login/password ne soit vraiment pas accessible depuis
l'extérieur ?
http://www.mon_nom_de_domaine.com/cgi-bin/password_ou_tartenpion.cgi


Je comprends pas la question

Je suis hébergé chez OVH. Et il existe les sécurités suivantes pour ce
répertoire (je cite OVH) :
- les fichiers mis dans le répertoire cgi-bin ne peuvent être lus. Ils
peuvent uniquement être executés. Vous ne pouvez pas y placer par
exemple les images gif ou jpeg. Leur lecture provoquera l'erreur.
- puisque aucun fichier ne peut être lus dans cgi-bin, vous pouvez y
placer les fichiers de bases de données en texte par exemple que vous
souhaitez protéger.
- l'execution des scripts cgi à partir de cgi-bin se fait via un alias
de votre site. Vous ne pouvez pas executer les scripts autrement qu'avec
votre domaine.


Ca limite les risques, mais comme le montrait Paul dans un de ses posts, le
script tels qu'il est laisse l'utilisateur executer n'importe qu'elle
commande (tu as essaye?). Certes avec des droits reduits, mais d'une part
il est probable que ca peut permettre a un cracker de recuperer les
fichiers de donnees qui trainent (ils ne peuvent pas etre servis par le
serveur web, mais ils peuvent probablement etre lus par les cgis), et
d'autre part ca peut etre le debut de la chaine de cracks qui finissent par
donner les droits roots a un intrus.

__
Michel Rodriguez
Perl &amp; XML
http://xmltwig.com

1 2 3