Hallo,
wie kann ich folgendes sicher in EINEM Script erreichen:
1. ich generiere eine Zufallszahl
2. ich rufe ein Formular auf
3. Durch "submit" im Formular wird das Script wieder aufgerufen
und vergleicht eine dort eingegebene Zahl mit der zuvor generierten?
Cookies scheiden aus, da diese durch den Nutzer deaktiv sein können.
MfG
Heiko
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6F44A654D0AB9532736D0967
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hallo,
Heiko Rompel wrote:
> wie kann ich folgendes sicher in EINEM Script erreichen:
>=20
> 1. ich generiere eine Zufallszahl
> 2. ich rufe ein Formular auf
> 3. Durch "submit" im Formular wird das Script wieder aufgerufen
> und vergleicht eine dort eingegebene Zahl mit der zuvor generierten?=
>=20
> Cookies scheiden aus, da diese durch den Nutzer deaktiv sein können.
Dann musst du das ganze serverseitig speichern. Ich empfehle
CGI::Session zu benutzen.
Grüße,
Moritz
--=20
Moritz Lenz
http://perl-6.de/ http://moritz.faui2k3.org/
--------------enig6F44A654D0AB9532736D0967
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGK2VsAAkekJBI0yIRApCnAJ0Qj5Z3V0GjXp441IpO45RzgM6Z5gCf W74t
wOV/ahf9wpHVyYeV8vHLzWY=
=MEgJ
-----END PGP SIGNATURE-----
--------------enig6F44A654D0AB9532736D0967--
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigEEC77BE9026CCE9C5C991CA1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hallo,
Moritz Lenz wrote:
> Heiko Rompel wrote:
>> wie kann ich folgendes sicher in EINEM Script erreichen:
>>
>> 1. ich generiere eine Zufallszahl
>> 2. ich rufe ein Formular auf
>> 3. Durch "submit" im Formular wird das Script wieder aufgerufen
>> und vergleicht eine dort eingegebene Zahl mit der zuvor generierten=
?
>>
>> Cookies scheiden aus, da diese durch den Nutzer deaktiv sein können.=
>=20
> Dann musst du das ganze serverseitig speichern. Ich empfehle
> CGI::Session zu benutzen.
Hm, ich glaube CGI::Session funktioniert mit Cookies, ich weiß gerade
nicht, ob man das auch mit anderen IDs betreiben kann.
Anyway, die Zufallszahl solltest du entweder in temporären Dateien oder=
in einer Datenbank speichern.
Grüße,
Moritz
--=20
Moritz Lenz
http://perl-6.de/ http://moritz.faui2k3.org/
--------------enigEEC77BE9026CCE9C5C991CA1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGK3KQAAkekJBI0yIRAifuAKDTsy7EIAYO+B6sGNklNkNWGQ7iAgCg pf37
nHa5/AmFJBhEs+jKQwtg7nc=
=3EHL
-----END PGP SIGNATURE-----
--------------enigEEC77BE9026CCE9C5C991CA1--
Heiko Rompel:
> wie kann ich folgendes sicher in EINEM Script erreichen:
>
> 1. ich generiere eine Zufallszahl
> 2. ich rufe ein Formular auf
> 3. Durch "submit" im Formular wird das Script wieder aufgerufen
> und vergleicht eine dort eingegebene Zahl mit der zuvor generierten?
>
> Cookies scheiden aus, da diese durch den Nutzer deaktiv sein können.
Dann generiere eine Session ID, der du die Zufallszahl zuordnest, und
schick' die beim Formularaufruf wieder mit. Im Skript kannst du sie dann
als "path_info" abrufen und kommst so wieder zu deiner Zufallszahl.
Übrigens: natürlich kannst du nicht verhindern, dass jemand Cookies
deaktiviert, aber du kannst den Benutzer vorher darüber informieren,
dass deine Seite mit deaktivierten Cookies nicht funktionieren wird.
Dann kann er entscheiden, ob er sie nicht doch aktivieren möchte
oder auf die Benutzung deiner Seite verzichtet. Ich mache das bei
meinen Seiten auch so (auch, wenn es um JavaScript geht), weil ich
nicht einsehe, dass ich in Zeiten eines IE 7 bzw. FF 6 (um jetzt nur
zwei zu nennen), mit viel Aufwand technische Voraussetzungen
schaffen soll, um einen IE 3/4 oder Netscape 1/2 zu unterstützen.
Ein gewisses Mindestmaß an Entgegenkommen und Bereitschaft,
die durch moderne SW bereitsgestellten Möglichkeiten zu verwenden,
kann auch ich von meinen Benutzern erwarten. Und das wird auch
allgemein akzeptiert.
LG, Ferry
--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at
Heiko Rompel wrote:
>
> wie kann ich folgendes sicher in EINEM Script erreichen:
>
> 1. ich generiere eine Zufallszahl
> 2. ich rufe ein Formular auf
> 3. Durch "submit" im Formular wird das Script wieder aufgerufen
> und vergleicht eine dort eingegebene Zahl mit der zuvor generierten?
>
> Cookies scheiden aus, da diese durch den Nutzer deaktiv sein können.
Drei Möglichkeiten neben Cookies:
o PATH_INFO (wurde schon genannt)
o URL-Parameter
o Hidden-Feld
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Hallo,
"Frank Seitz" schrieb:
> o PATH_INFO (wurde schon genannt)
> o URL-Parameter
> o Hidden-Feld
Danke Dir und den anderen Antwortern.
Ich habe das jetzt so gelöst:
Ich schreibe die Zahl in eine Temporärer Datei außerhalb des
Homeverzeichnisses und frage diese dann an entsprechender Stelle ab.
MfG
Heiko
Heiko Rompel wrote:
> "Frank Seitz" schrieb:
>>
>>o PATH_INFO (wurde schon genannt)
>>o URL-Parameter
>>o Hidden-Feld
>
> Danke Dir und den anderen Antwortern.
>
> Ich habe das jetzt so gelöst:
>
> Ich schreibe die Zahl in eine Temporärer Datei außerhalb des
> Homeverzeichnisses und frage diese dann an entsprechender Stelle ab.
Die Datei hat einen festen Namen?
Das ist keine Lösung, wenn mehrere Benutzer mit der Anwendung
arbeiten können.
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Hallo,
> Die Datei hat einen festen Namen?
Ja.
> Das ist keine Lösung, wenn mehrere Benutzer mit der Anwendung
> arbeiten können.
Ups, an sowas habe ich nicht gedacht.
Also muß ich Serverseitig doch eine andere Lösung suchen.
MfG
Heiko
Hallo,
Wie war das noch?
CGI::Session ==> arbeite mit Cookies
o PATH_INFO (wurde schon genannt)
o URL-Parameter
o Hidden-Feld
Das sind doch alles Weg, wo jemand der Ahnung hat, die Zufallszahl doch
auslesen kann
und mich nicht weiterbringt.
Ich dachte auch ein Hiddenfeld wäre gut, aber da hat man mich eines besseren
belehrt.
Wie kann man sich eigentlich den Quelltext eines Perlscriptes vom Server
anzeigen lassen
und wie verhindert man das?
MfG
Heiko
Heiko Rompel wrote:
>
> Wie war das noch?
>
> CGI::Session ==> arbeite mit Cookies
>
> o PATH_INFO (wurde schon genannt)
> o URL-Parameter
> o Hidden-Feld
>
> Das sind doch alles Weg, wo jemand der Ahnung hat, die Zufallszahl doch
> auslesen kann
> und mich nicht weiterbringt.
Wenn die Zufallszahl geheim ist, musst Du sie serverseitig
unter einem Schlüssel speichern (Datenbank oder Datei). Statt der
Information kommunizierst Du den Schlüssel. Mit diesem greifst
Du serverseitig auf die Information zu. Der Client kann das nicht.
> Ich dachte auch ein Hiddenfeld wäre gut, aber da hat man mich eines besseren
> belehrt.
>
> Wie kann man sich eigentlich den Quelltext eines Perlscriptes vom Server
> anzeigen lassen
> und wie verhindert man das?
Du kannst nicht verhindern, dass der HTML-Quelltext eingesehen
werden kann. Alles, was zum Client geht, kann eingesehen werden.
Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Heiko Rompel wrote:
> CGI::Session ==> arbeite mit Cookies
>
> o PATH_INFO (wurde schon genannt)
> o URL-Parameter
> o Hidden-Feld
>
> Das sind doch alles Weg, wo jemand der Ahnung hat, die Zufallszahl doch
> auslesen kann
> und mich nicht weiterbringt.
Es ist mir nicht ganz klar, was du eigentlich genau haben willst. Du willst
Information zu einer HTTP-Session irgendwie zwischenspeichern, so dass du
später wieder darauf zugreifen kannst. Gleichzeitig soll der Benutzer aber
diese Information nicht sehen können. Sehe ich das richtig?
Grundsätzlich sehe ich da zwei Möglichkeiten:
1. Du speicherst die Information serverseitig und übergibst dem Benutzer
einen zufällig generierten Schlüssel, unter dem du die Information wieder
abrufen kannst. Das geht sehr elegant mit einer Datenbank.
2. Wenn du serverseitig nichts zwischenspeichern möchtest, könntest du die
Daten auch verschlüsseln und dann via Hidden-Field, URL-Parameter o.ä. beim
Benutzer zwischenspeichern. Wenn du das möchtest, müsste man das eventuell
noch genauer anschauen, damit die Angelegenheit wirklich kryptografisch
sicher ist.
Gruss
Roman°
--
IRC-Freenode: #usenet-friends
http://www.usenet-friends.ch.vu/
Hallo,
> Es ist mir nicht ganz klar, was du eigentlich genau haben willst.
Mein Gäästebuch sicher machen. :-)
Erst hatte ich ein "CATCHA" so eingebaut, das die Kontrollzahl mittels
"Hidden-Field"
mit lief. Leider hat man das geknackt.
So wie man sowieso an den Klartext des Scriptes rangekommen ist und
dann die Variablen durch ein eigenes Formular manipuliert.
> Du willst
> Information zu einer HTTP-Session irgendwie zwischenspeichern, so dass du
> später wieder darauf zugreifen kannst.
Ja.
> Gleichzeitig soll der Benutzer aber
> diese Information nicht sehen können. Sehe ich das richtig?
Jein, der Benutzer bekommt ja die Zahl angezeigt, die er eingeben soll.
Eigentlich muß ich dafür sorgen, das das Script sicher wird.
Nachdem was ich jetzt gelesen habe, wäre das
a) das Script im "Taint"-Modus laufen lassen
b) keine Passwörter im Script in Klartext hinterlegen
c) den Vergleichswert für das "CATCHA" mittels Session-ID hinterlegen und
Abfragen.
> 1. Du speicherst die Information serverseitig und übergibst dem Benutzer
> einen zufällig generierten Schlüssel, unter dem du die Information wieder
> abrufen kannst. Das geht sehr elegant mit einer Datenbank.
Mit Datenbanken habe ich Nullahnung und würde mir wahrscheinlich
neue Löcher in die Sicherheit bohren.
> 2. Wenn du serverseitig nichts zwischenspeichern möchtest, könntest du die
> Daten auch verschlüsseln und dann via Hidden-Field, URL-Parameter o.ä.
> beim
> Benutzer zwischenspeichern. Wenn du das möchtest, müsste man das eventuell
> noch genauer anschauen, damit die Angelegenheit wirklich kryptografisch
> sicher ist.
Würde ein MD5-Hash ausreichen?
MfG
Heiko
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig8E44CAEF62524FF1983572BB
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hallo,
Heiko Rompel wrote:
>> Es ist mir nicht ganz klar, was du eigentlich genau haben willst.
>=20
> Mein Gäästebuch sicher machen. :-)
> Erst hatte ich ein "CATCHA" so eingebaut, das die Kontrollzahl mittels=
> "Hidden-Field"
> mit lief. Leider hat man das geknackt.
das ist ja auch recht einfach herauszufinden.
>> Du willst
>> Information zu einer HTTP-Session irgendwie zwischenspeichern, so dass=
du
>> später wieder darauf zugreifen kannst.
>=20
> Ja.
>=20
>> Gleichzeitig soll der Benutzer aber
>> diese Information nicht sehen können. Sehe ich das richtig?
>=20
> Jein, der Benutzer bekommt ja die Zahl angezeigt, die er eingeben soll.=
Aber nur in Bild-Form, richtig?
> Eigentlich muß ich dafür sorgen, das das Script sicher wird.
>=20
> Nachdem was ich jetzt gelesen habe, wäre das
> a) das Script im "Taint"-Modus laufen lassen
> b) keine Passwörter im Script in Klartext hinterlegen
> c) den Vergleichswert für das "CATCHA" mittels Session-ID hinterlegen=
> und Abfragen.
Richtig.
>> 1. Du speicherst die Information serverseitig und übergibst dem Benu=
tzer
>> einen zufällig generierten Schlüssel, unter dem du die Information=
wieder
>> abrufen kannst. Das geht sehr elegant mit einer Datenbank.
>=20
> Mit Datenbanken habe ich Nullahnung und würde mir wahrscheinlich
> neue Löcher in die Sicherheit bohren.
Letztendlich lohnt es sich mit Datenbanken zu beschäftigen, weil das ei=
nem
viel Arbeit abnehmen kann, und wenn man sich an die Tipps in der
perldoc-Seite
von DBI hält, muss man auch keine Angst vor SQL injection haben.
>> 2. Wenn du serverseitig nichts zwischenspeichern möchtest, könntes=
t du
>> die
>> Daten auch verschlüsseln und dann via Hidden-Field, URL-Parameter o.=
ä.
>> beim
>> Benutzer zwischenspeichern. Wenn du das möchtest, müsste man das
>> eventuell
>> noch genauer anschauen, damit die Angelegenheit wirklich kryptografisc=
h
>> sicher ist.
>=20
> Würde ein MD5-Hash ausreichen?
Ein einfacher md5-Hash nicht, weil dann könnte der Angreifer ja einfach=
einen zufälligen Text zusammen mit dessen MD5-Hash schicken.
Aber was du machen kannst, ist auf dem Server einen zufälligen String
als Passwort zu nehmen, und diesen String an den Captch-String anhängen=
und die MD5-Summe des ganzen Strings mitschicken.
Also
my $secret =3D "meeNoo4air;
my $captcha =3D generate_captacha();
my $hidden_field =3D md5hex($captcha . $secrect);
Demenstprechend überprüfst du dann, ob md5_hex($eingabe . $secret) eq=
$hidden_field ist.
HTH,
Moritz
--=20
Moritz Lenz
http://perl-6.de/ http://moritz.faui2k3.org/
--------------enig8E44CAEF62524FF1983572BB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGLMdpAAkekJBI0yIRAjpzAJ9nL0ugHz7JwRzC0BofAe4cvGFnOACf YEOV
1+otouw/IlJmHCb8v1rSaXA=
=Nqpp
-----END PGP SIGNATURE-----
--------------enig8E44CAEF62524FF1983572BB--
Heiko Rompel wrote:
>> Gleichzeitig soll der Benutzer aber
>> diese Information nicht sehen können. Sehe ich das richtig?
>
> Jein, der Benutzer bekommt ja die Zahl angezeigt, die er eingeben soll.
>
> Eigentlich muß ich dafür sorgen, das das Script sicher wird.
>
> Nachdem was ich jetzt gelesen habe, wäre das
> a) das Script im "Taint"-Modus laufen lassen
> b) keine Passwörter im Script in Klartext hinterlegen
> c) den Vergleichswert für das "CATCHA" mittels Session-ID hinterlegen und
> Abfragen.
Der Inhalt des Scripts sollte bei einem gut konfigurierten Webserver für den
Benutzer nicht sichtbar sein. Nur dessen Ausgabe, d.h. alles, was du an den
User schickst.
>> 2. Wenn du serverseitig nichts zwischenspeichern möchtest, könntest du
>> die Daten auch verschlüsseln und dann via Hidden-Field, URL-Parameter
>> o.ä. beim
>> Benutzer zwischenspeichern. Wenn du das möchtest, müsste man das
>> eventuell noch genauer anschauen, damit die Angelegenheit wirklich
>> kryptografisch sicher ist.
>
> Würde ein MD5-Hash ausreichen?
Kommt drauf an. Wenn du dein Captcha aus einem fünfstelligen Randomstring
generierst, ist es recht einfach, die MD5-Hashes aller möglichen
fünfstelligen Randomstrings zu generieren und in einer Datenbank
vorzuhalten, um Seiten wie die deinige zu knacken.
Ausserdem ist es für einen Angreifer möglich, ein bestimmtes Captcha zu
lösen und dann immer die Lösung zusammen mit der (codierten) Frage für
genau dieses Captcha zu versenden. Dazu muss der Angreifer nicht die
Verschlüsselung brechen, sondern einfach merken, dass du die Frage beim
Benutzer codiert hinterlegst und einsehen, dass er die wirklich gestellte
Frage durch eine Frage, auf die er die Antwort kennt, ersetzen kann.
Sofern dein Skript sicherstellt, dass mehrfache identische Formulareingaben
nur einmal eine Zustandsveränderung bewirken, könnte dein Hidden-String für
das Captcha z.B. aus MD5(festgelegter, im Skript hinterlegter geheimer
Wert||Datum||Formulareingabe||Captcha-Klartext)||Datum bestehen. Dadurch
wird sichergestellt, dass ein gelöstes Captcha sich nicht auf eine andere
Formulareingabe übertragen lässt.
Durch die Prüfung des Datums kannst du auch verhindern, dass uralte Daten
wieder eingespielt werden können, nachdem sie in deiner Datenbank evtl.
nach einer gewissen Weile irgendwann wieder gelöscht werden. Dazu entnimmt
dein Skript zur Prüfung das Datum, welches ja im Klartext im Hidden-String
steht, prüft, ob das noch nicht zu lange her ist, und bildet dann zusammen
mit der bekannten Formulareingabe und dem geheimen Wert (welcher
verhindert, dass Angreifer sich Datenbanken anlegen können) sowie der vom
User eingegebenen Lösung für das Captcha den MD5-Wert.
Gruss
Roman°
--
IRC-Freenode: #usenet-friends
http://www.usenet-friends.ch.vu/
Moritz Lenz wrote:
> my $secret = "meeNoo4air;
> my $captcha = generate_captacha();
> my $hidden_field = md5hex($captcha . $secrect);
>
> Demenstprechend überprüfst du dann, ob md5_hex($eingabe . $secret) eq
> $hidden_field ist.
Das ist ungenügend. Nachdem ein Angreifer einmal das Captcha einmal gelöst
hat, ersetzt er das vom Skript erzeugte Hidden Field einfach immer durch
das, von dem er die richtige Lösung kennt. Dazu muss er das Secret nicht
kennen.
Gruss
Roman°
--
IRC-Freenode: #usenet-friends
http://www.usenet-friends.ch.vu/
Hallo,
> Der Inhalt des Scripts sollte bei einem gut konfigurierten Webserver für
> den
> Benutzer nicht sichtbar sein. Nur dessen Ausgabe, d.h. alles, was du an
> den
> User schickst.
Hmm, was müßte den bei einem Apache wie eingestellt sein,
damit der Benutzer nicht an das Script kommt?
Oder ist das eine Sache der Attribute?
> Kommt drauf an. Wenn du dein Captcha aus einem fünfstelligen Randomstring
> generierst, ist es recht einfach, die MD5-Hashes aller möglichen
> fünfstelligen Randomstrings zu generieren und in einer Datenbank
> vorzuhalten, um Seiten wie die deinige zu knacken.
Aha.
> Ausserdem ist es für einen Angreifer möglich, ein bestimmtes Captcha zu
> lösen und dann immer die Lösung zusammen mit der (codierten) Frage für
> genau dieses Captcha zu versenden. Dazu muss der Angreifer nicht die
> Verschlüsselung brechen, sondern einfach merken, dass du die Frage beim
> Benutzer codiert hinterlegst und einsehen, dass er die wirklich gestellte
> Frage durch eine Frage, auf die er die Antwort kennt, ersetzen kann.
Hmm...
> Sofern dein Skript sicherstellt, dass mehrfache identische
> Formulareingaben
> nur einmal eine Zustandsveränderung bewirken, könnte dein Hidden-String
> für
> das Captcha z.B. aus MD5(festgelegter, im Skript hinterlegter geheimer
> Wert||Datum||Formulareingabe||Captcha-Klartext)||Datum bestehen. Dadurch
> wird sichergestellt, dass ein gelöstes Captcha sich nicht auf eine andere
> Formulareingabe übertragen lässt.
Du meinst mit "dass mehrfache identische Formulareingaben" das das
CAPTCHA nicht vom Usernamen etc. abhängig sein soll - oder wie?
> Durch die Prüfung des Datums kannst du auch verhindern, dass uralte Daten
> wieder eingespielt werden können, nachdem sie in deiner Datenbank evtl.
> nach einer gewissen Weile irgendwann wieder gelöscht werden. Dazu entnimmt
> dein Skript zur Prüfung das Datum, welches ja im Klartext im Hidden-String
> steht, prüft, ob das noch nicht zu lange her ist, und bildet dann zusammen
> mit der bekannten Formulareingabe und dem geheimen Wert (welcher
> verhindert, dass Angreifer sich Datenbanken anlegen können) sowie der vom
> User eingegebenen Lösung für das Captcha den MD5-Wert.
Bahnhof ??? - Muß die Sonne sein...
MfG
Heiko
Heiko Rompel wrote:
>> Sofern dein Skript sicherstellt, dass mehrfache identische
>> Formulareingaben
>> nur einmal eine Zustandsveränderung bewirken, könnte dein Hidden-String
>> für
>> das Captcha z.B. aus MD5(festgelegter, im Skript hinterlegter geheimer
>> Wert||Datum||Formulareingabe||Captcha-Klartext)||Datum bestehen. Dadurch
>> wird sichergestellt, dass ein gelöstes Captcha sich nicht auf eine andere
>> Formulareingabe übertragen lässt.
>
> Du meinst mit "dass mehrfache identische Formulareingaben" das das
> CAPTCHA nicht vom Usernamen etc. abhängig sein soll - oder wie?
Nein. Ich meinte damit, dass dein Skript es merkt, wenn jemand mehrfach die
gleichen Angaben macht (z.B. auf den Reload-Button drückt oder ein Skript
spammen lässt).
>> Durch die Prüfung des Datums kannst du auch verhindern, dass uralte Daten
>> wieder eingespielt werden können, nachdem sie in deiner Datenbank evtl.
>> nach einer gewissen Weile irgendwann wieder gelöscht werden. Dazu
>> entnimmt dein Skript zur Prüfung das Datum, welches ja im Klartext im
>> Hidden-String steht, prüft, ob das noch nicht zu lange her ist, und
>> bildet dann zusammen mit der bekannten Formulareingabe und dem geheimen
>> Wert (welcher verhindert, dass Angreifer sich Datenbanken anlegen können)
>> sowie der vom User eingegebenen Lösung für das Captcha den MD5-Wert.
>
> Bahnhof ??? - Muß die Sonne sein...
Nun, der Einsatz von Kryptografie ist halt nicht immer so einfach, wie er
zunächst scheint. :-)
Gruss
Roman°
--
IRC-Freenode: #usenet-friends
http://www.usenet-friends.ch.vu/
Hallo,
Roman Racine wrote:
> Moritz Lenz wrote:
>=20
>> my $secret =3D "meeNoo4air;
>> my $captcha =3D generate_captacha();
>> my $hidden_field =3D md5hex($captcha . $secrect);
>>
>> Demenstprechend überprüfst du dann, ob md5_hex($eingabe . $secret)=
eq
>> $hidden_field ist.
>=20
> Das ist ungenügend. Nachdem ein Angreifer einmal das Captcha einmal g=
elöst
> hat, ersetzt er das vom Skript erzeugte Hidden Field einfach immer durc=
h
> das, von dem er die richtige Lösung kennt. Dazu muss er das Secret ni=
cht
> kennen.=20
Richtig, Asche auf mein Haupt. Es hatte doch einen guten Grund, dass ich
die Captchas damals[tm] in einer Datenbank gespeichert habe ;-)
Grüße,
Moritz
--=20
Moritz Lenz
http://perl-6.de/ http://moritz.faui2k3.org/
Frank Seitz:
> Du kannst nicht verhindern, dass der HTML-Quelltext eingesehen
> werden kann. Alles, was zum Client geht, kann eingesehen werden.
Echt? Auch JavaScript-Code, der aus externen Datein geladen wird?
Mach' mich nicht schwach... ;-)
LG, Ferry
--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at
Danke an Euch für die vielen Tips.
Ich habe daraus jetzt meine Lösung gebaut und hoffe das die sicher genug
ist.
Ich erzeuge für das Captcha-Passwort eine temporäre Datei außerhalb des
Homepageverzeichnisses deren Dateiname sich aus festen Zeichen und dem
aktuellem
Datum und der Uhrzeit incl. Sekunden zusammensetzt.
Diesen Dateinamen übergebe ich mittels "Hidden"-Field.
Nach dem auslesen des Captcha-Passwortes lösche ich die Datei wieder.
Was meint Ihr ist die Sache sicher genug?
MfG
Heiko
Heiko Rompel wrote:
> Danke an Euch für die vielen Tips.
>
> Ich habe daraus jetzt meine Lösung gebaut und hoffe das die sicher genug
> ist.
>
> Ich erzeuge für das Captcha-Passwort eine temporäre Datei außerhalb des
> Homepageverzeichnisses deren Dateiname sich aus festen Zeichen und dem
> aktuellem
> Datum und der Uhrzeit incl. Sekunden zusammensetzt.
Nunja, und wenn zwei Prozesse in der gleichen Sekunde zugreifen?
> Diesen Dateinamen übergebe ich mittels "Hidden"-Field.
> Nach dem auslesen des Captcha-Passwortes lösche ich die Datei wieder.
D.h., wenn man im Hidden-Field was anderes reinschreibt, als dein Skript
vorschlägt, kann man irgendwelche Dateien löschen? Oder fängst du das
irgendwie ab?
Was passiert, wenn jemand die Seite mehrfach aufruft oder das Captcha nicht
löst? Wird da jedes Mal eine Datei angelegt, die dann nicht mehr gelöscht
wird?
Gruss
Roman°
--
IRC-Freenode: #usenet-friends
http://www.usenet-friends.ch.vu/
Hallo,
"Roman Racine" schrieb:
> Nunja, und wenn zwei Prozesse in der gleichen Sekunde zugreifen?
Okay, das wäre ein Argument, aber bei diesem Gästebuch eher
unwahrscheinlich.
> D.h., wenn man im Hidden-Field was anderes reinschreibt, als dein Skript
> vorschlägt, kann man irgendwelche Dateien löschen? Oder fängst du das
> irgendwie ab?
Die Datei liegt in einem Verzeichnis außerhalb des eigentlichen
Homepageverzeichnisses
und der Pfad ist im Script fest.
Ich übergebe nur den Dateinamen. Das bedeutet doch, das nur Dateien in
diesem
Verzeichnis gelscht werden können oder kommt man da durch ./ oder ../ raus?
> Was passiert, wenn jemand die Seite mehrfach aufruft
Meinst Du mittel "Zurück"-Button des Browsers?
Das ist noch ein Problem, in diesem Fall gibt es keine Datei und das System
hängt. Das muß ich noch irgendwie abfangen.
> oder das Captcha nicht löst?
> Wird da jedes Mal eine Datei angelegt, die dann nicht mehr gelöscht wird?
Nein, auch wenn das Captcha nicht gelöst wird, wird die Temp-Datei gelöscht.
Sollte man da alternativ eine Meldung ausgeben und zum Zurückgehen
auffordern?
MfG
Heiko
Heiko Rompel wrote:
> Hallo,
>
> "Roman Racine" schrieb:
>
>> Nunja, und wenn zwei Prozesse in der gleichen Sekunde zugreifen?
>
> Okay, das wäre ein Argument, aber bei diesem Gästebuch eher
> unwahrscheinlich.
Wenn jemand dein System aushebeln will, was ja anscheinend schon mal
geschehen ist, ist es sehr wahrscheinlich, dass er versucht, durch
massenhafte gleichzeitige Zugriffe genau solche Fehler zu verursachen.
>> D.h., wenn man im Hidden-Field was anderes reinschreibt, als dein Skript
>> vorschlägt, kann man irgendwelche Dateien löschen? Oder fängst du das
>> irgendwie ab?
>
> Die Datei liegt in einem Verzeichnis außerhalb des eigentlichen
> Homepageverzeichnisses
> und der Pfad ist im Script fest.
> Ich übergebe nur den Dateinamen. Das bedeutet doch, das nur Dateien in
> diesem
> Verzeichnis gelscht werden können oder kommt man da durch ./ oder ../
> raus?
Ich weiss nicht, wie du das programmiert hast, grundsätzlich kommt man
über ../ schon raus, ja.
>> Was passiert, wenn jemand die Seite mehrfach aufruft
>
> Meinst Du mittel "Zurück"-Button des Browsers?
Oder durch ein Skript, das die ganzen Requests absetzt.
>> oder das Captcha nicht löst?
>> Wird da jedes Mal eine Datei angelegt, die dann nicht mehr gelöscht wird?
>
> Nein, auch wenn das Captcha nicht gelöst wird, wird die Temp-Datei
> gelöscht. Sollte man da alternativ eine Meldung ausgeben und zum
> Zurückgehen auffordern?
Na, und wenn einfach jemand ein Captcha anfordert, ohne dann was weiteres zu
unternehmen? Gibt das jedes Mal eine neue Datei, die dann liegen bleibt?
Gruss
Roman°
--
IRC-Freenode: #usenet-friends
http://www.usenet-friends.ch.vu/
Hallo,
"Roman Racine" schrieb:
> Wenn jemand dein System aushebeln will, was ja anscheinend schon mal
> geschehen ist, ist es sehr wahrscheinlich, dass er versucht, durch
> massenhafte gleichzeitige Zugriffe genau solche Fehler zu verursachen.
Also brauche ich jemanden, der mir zeigt wo ich noch Fehler habe und
wie man sie beseitigt oder einen kostenlosen Gästebuch-Dienstleister der
das
Gästebuch dann mit Bannern vollmüllt.
> Ich weiss nicht, wie du das programmiert hast, grundsätzlich kommt man
> über ../ schon raus, ja.
$festerpfad: /home/usr/temp/
$Datei = $festerpfad.$dateiname;
Würde man da rauskommen wenn man ein ./ oder ../ übergibt?
Dann würde der Zielpfad doch so aussehen: /home/usr/temp/./ bzw.
/home/usr/temp/../ .
> Oder durch ein Skript, das die ganzen Requests absetzt.
Hmm, solange er ein Submit auslöst und mein Script zu dem Teil kommt, an dem
es die richitgkeit des Captcha prüft, werden alle Temp-Dateien gelöscht.
> Na, und wenn einfach jemand ein Captcha anfordert, ohne dann was weiteres
> zu
> unternehmen? Gibt das jedes Mal eine neue Datei, die dann liegen bleibt?
Ja. Also muß ich noch irgendwas zeitmäßiges einbauen oder einen Cronjob der
für das regelmäßige löschen sorgt.
Wobei, wenn jemand viel Text schreibt, könnte eine Zeit ihn aussperren und
wenn die Zeit zu lang ist, dann köntte man mittels Script sehr viele Dateien
erzeugen.
Man ist das knifflig und das bei der Hitze 34Grad in der Sonne.
MfG
Heiko
Heiko Rompel schrieb:
> Ich erzeuge für das Captcha-Passwort eine temporäre Datei außerhalb des
> Homepageverzeichnisses deren Dateiname sich aus festen Zeichen und dem
> aktuellem
> Datum und der Uhrzeit incl. Sekunden zusammensetzt.
> Diesen Dateinamen übergebe ich mittels "Hidden"-Field.
> Nach dem auslesen des Captcha-Passwortes lösche ich die Datei wieder.
>
> Was meint Ihr ist die Sache sicher genug?
Gibt es irgendeinen bestimmten Grund, keine Datenbank zu
verwenden? Wenn ja, würde ich trotzdem den Dateinamen nicht
direkt übergeben, sondern eine Funktion wie md5_hex aus
Digest::MD5 auf den key anwenden und so den Dateinamen
generieren. Dann hast Du auch keine Probleme mit Path
Traversals oder Shellcodes.
-Christian
Hallo,
"Christian Winter" schrieb:
> Gibt es irgendeinen bestimmten Grund, keine Datenbank zu
> verwenden?
Ich habe keinen Plan von Datenbanken und würde mir wahrscheinlich nur neue
Löcher schaffen.
>Wenn ja, würde ich trotzdem den Dateinamen nicht
> direkt übergeben, sondern eine Funktion wie md5_hex aus
> Digest::MD5 auf den key anwenden und so den Dateinamen
> generieren.
Hmm, das wäre eine Überlegung wert.
> Dann hast Du auch keine Probleme mit Path Traversals
Was ist das? Google zeigt zwar mehrere Hunderttreffen aber aus dem werde ich
nicht schlau.
> oder Shellcodes.
und welche Gefahr bedeuteten diese?
MfG
Heiko
On 2007-04-23 15:11, Heiko Rompel
>> Der Inhalt des Scripts sollte bei einem gut konfigurierten Webserver
>> für den Benutzer nicht sichtbar sein. Nur dessen Ausgabe, d.h. alles,
>> was du an den User schickst.
>
> Hmm, was müÃte den bei einem Apache wie eingestellt sein,
> damit der Benutzer nicht an das Script kommt?
Die Frage ist eher, was muss man beim Apache verbocken, damit der
Benutzer an das Script kommt? Mir fällt da momentan keine Methode ein,
die einem einfach so "passieren" könnte: Entweder der Apache ruft das
Script auf (dann kommt der Benutzer nicht an den Source-Code), oder er
liefert seinen Inhalt (aber dann funktioniert es nicht und das fällt
eigentlich sofort auf). Damit beides geht, muss man schon aktiv etwas
tun.
Bist Du sicher, dass der Benutzer an den Source-Code des Scripts
gekommen ist und nicht einfach nur aus seinem Output geschlossen hat,
was es tut?
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
On 2007-04-27 12:46, Heiko Rompel
> "Roman Racine" schrieb:
>> Wenn jemand dein System aushebeln will, was ja anscheinend schon mal
>> geschehen ist, ist es sehr wahrscheinlich, dass er versucht, durch
>> massenhafte gleichzeitige Zugriffe genau solche Fehler zu verursachen.
>
> Also brauche ich jemanden, der mir zeigt wo ich noch Fehler habe
Das wird Dir keiner zeigen können, solange Du das Script nicht
veröffentlichst. Und selbst dann ist fraglich, ob das wirklich wer
auditen will.
Vielleicht hilft ein Blick auf http://nms-cgi.sourceforge.net/
>> Ich weiss nicht, wie du das programmiert hast, grundsätzlich kommt man
>> über ../ schon raus, ja.
>
> $festerpfad: /home/usr/temp/
> $Datei = $festerpfad.$dateiname;
>
> Würde man da rauskommen wenn man ein ./ oder ../ übergibt?
> Dann würde der Zielpfad doch so aussehen: /home/usr/temp/./ bzw.
> /home/usr/temp/../ .
$dateiname = "../../../etc/passwd";
Dann kommt heraus "/home/usr/temp/../../../etc/passwd".
Dein Script hat hoffentlich nicht die notwendigen Permissions, um
/etc/passwd zu löschen, aber es könnte ja andere empfindliche Dateien
geben, die es löschen kann (z.B. die bisherigen Gästebucheintragungen,
die kann es fast sicher löschen, weil es sie ja auch angelegt hat).
>> Oder durch ein Skript, das die ganzen Requests absetzt.
>
> Hmm, solange er ein Submit auslöst
Und wenn er das eben nicht tut?
> und mein Script zu dem Teil kommt, an dem
> es die richitgkeit des Captcha prüft, werden alle Temp-Dateien gelöscht.
Alle? Auch die anderer User? Wenn ich also jede Sekunde eine Submit
auslöse, kann ich sicher verhindern, dass keiner mehr was eintragen
kann, es sei denn, er schafft es, einen Eintrag in weniger als einer
Sekunde zu machen?
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Hallo,
"Peter J. Holzer" schrieb:
> Bist Du sicher, dass der Benutzer an den Source-Code des Scripts
> gekommen ist
Nein.
> und nicht einfach nur aus seinem Output geschlossen hat,
> was es tut?
Wohl eher das.
MfG
Heiko
Hallo,
"Peter J. Holzer" schrieb:
> Das wird Dir keiner zeigen können, solange Du das Script nicht
> veröffentlichst.
Wenn ich das Script öffentlich mache, wird es doch noch anfälliger,
wenn mir dann nicht jemand sofort meine Lücken aufzeigt.
> Und selbst dann ist fraglich, ob das wirklich wer
> auditen will.
Also, warum veröffentlichen ....
> Vielleicht hilft ein Blick auf http://nms-cgi.sourceforge.net/
Habe mir mal deren Gästebuch runtergeladen, mal sehen was ich da so an Infos
rausziehen kann.
> $dateiname = "../../../etc/passwd";
>
> Dann kommt heraus "/home/usr/temp/../../../etc/passwd".
Aber wenn es unterhalb von temp kein Verzeichnis gibt,
wo würde der Wert in $dateiname dann landen?
(Bin kein Linux-User)
> Dein Script hat hoffentlich nicht die notwendigen Permissions, um
> /etc/passwd zu löschen,
Ist nur read only.
> aber es könnte ja andere empfindliche Dateien
> geben, die es löschen kann (z.B. die bisherigen Gästebucheintragungen,
> die kann es fast sicher löschen, weil es sie ja auch angelegt hat).
Oh mann, wie verhindert man das denn ...
> Und wenn er das eben nicht tut?
Daten eines Formulares schicken ohne Submit?
Och man, was gibt es denn noch an Schweinereien auf die man achten muÃ.
> Alle?
Nein.
> Auch die anderer User?
Nein. Nur das grade zuvor erstellte.
MfG
Heiko
Post removed (X-No-Archive: yes)
Peter J. Holzer:
> Damit beides geht, muss man schon aktiv etwas tun.
Ja, z.B. einen symbolischen Link auf das Skript legen, der
innerhalb von DocumentRoot liegt und kein ScriptAlias ist.
Und wenn dann noch Options FollowSymLinks gesetzt ist
(das hatten wir mal vor vielen Jahren)... ;-)
LG, Ferry
--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at
On 2007-04-30 07:19, Ferry Bolhar
> Peter J. Holzer:
>> Damit beides geht, muss man schon aktiv etwas tun.
>
> Ja, z.B. einen symbolischen Link auf das Skript legen, der
> innerhalb von DocumentRoot liegt und kein ScriptAlias ist.
Ja, das war auch mein erster Gedanke.
> Und wenn dann noch Options FollowSymLinks gesetzt ist
> (das hatten wir mal vor vielen Jahren)... ;-)
Ich habe das ziemlich sicher ein paar mal absichtlich:
script.cgi
script.txt -> script.cgi
und dann ein index.html mit
oder so ähnlich.
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"