URL nicht in der Adressleiste sichtbar + Login über htaccess
membran
- cgi
0 membran0 Marc Reichelt0 membran0 Alain0 Matti Maekitalo
Hi,
gerade habe ich den Login für meine Seite sicherer machen können, da fallen mir Funktionen dieses Forums auf, wenn man eingeloggt ist:
Erste Frage:
Das Login erfolgt nicht (wie bei meinem Projekt) über ein Formular mit anschließender CGI-Abfrage, sondern über die .htaccess.
Ist das "sicherer" als meine Methode? Wie könnte man bei diesem und bei meinem Weg ein Passwort "abfangen" - bzw. wie leicht oder wie schwer ist das? Oder nehmen sich beide Wege nichts?
Zweite Frage:
Das Forum hier hat keine "vollständige" URL, der Dateiname des eigentlichen Skripts fehlt. Zuerst dachte ich, das Forum wäre in ein blindes Frameset eingebunden, was jedoch nicht der Fall ist. Query-Paramter werden statt "skript.cgi?foo=1234" mit "?foo=1234" übergeben. Wie realisiert man das?
Dritte Frage:
Bei einem Login über htaccess: wie greife ich da den Usernamen so ab, daß ich damit eine Session starten und ein Cookie schreiben kann?
Ich dachte immer, man hat eine .htpassword und .htaccess im Verzeichnis und gut ist. Daß man die eingebenen Funktionen irgendwie abgreifen kann, wusste ich bislang noch nicht - wie geht das?
Danke!
»»
Daß man die eingebenen Funktionen irgendwie abgreifen kann, wusste ich bislang noch nicht - wie geht das?
Eingegebenen Informationen, nicht Funktionen, sorry.
Hi!
Daß man die eingebenen Funktionen irgendwie abgreifen kann, wusste ich bislang noch nicht - wie geht das?
Eingegebenen Informationen, nicht Funktionen, sorry.
steht in meinem posting, siehe:
https://forum.selfhtml.org/?t=90440&m=542400
cu
Marc Reichelt || http://www.marcreichelt.de/
Hi!
Hi,
gerade habe ich den Login für meine Seite sicherer machen können, da fallen mir Funktionen dieses Forums auf, wenn man eingeloggt ist:
Erste Frage:
Das Login erfolgt nicht (wie bei meinem Projekt) über ein Formular mit anschließender CGI-Abfrage, sondern über die .htaccess.
Ist das "sicherer" als meine Methode? Wie könnte man bei diesem und bei meinem Weg ein Passwort "abfangen" - bzw. wie leicht oder wie schwer ist das? Oder nehmen sich beide Wege nichts?
Sicherheit ist kein Zustand, sondern ein Prozess.
Die Seite ist so sicher wie du sie schreibst.
Zweite Frage:
Das Forum hier hat keine "vollständige" URL, der Dateiname des eigentlichen Skripts fehlt. Zuerst dachte ich, das Forum wäre in ein blindes Frameset eingebunden, was jedoch nicht der Fall ist. Query-Paramter werden statt "skript.cgi?foo=1234" mit "?foo=1234" übergeben. Wie realisiert man das?
Es wird die Standard-Datei (DirectoryIndex beim Apache) aufgerufen mit den entsprechenden Variablen.
Also bei index.php z.B.:
?var=wert
anstatt
index.php?var=wert
Dritte Frage:
Bei einem Login über htaccess: wie greife ich da den Usernamen so ab, daß ich damit eine Session starten und ein Cookie schreiben kann?
Ich dachte immer, man hat eine .htpassword und .htaccess im Verzeichnis und gut ist. Daß man die eingebenen Funktionen irgendwie abgreifen kann, wusste ich bislang noch nicht - wie geht das?
Apache gibt zwei Servervariablen aus, schreib mal eine phpinfo()-Datei und steck sie in ein passwortgeschütztes (.htaccess) Verzeichnis.
Unten steht dann:
PHP_AUTH_USER <USERNAME>
PHP_AUTH_PW <PASSWORT>
sowie
_SERVER["PHP_AUTH_USER"] <USERNAME>
_SERVER["PHP_AUTH_PW"] <PASSWORT>
Einfach das $-Zeichen für eine Variable vorne dransetzen und wohlfühlen... *g*
cu
Marc Reichelt || http://www.marcreichelt.de/
Sicherheit ist kein Zustand, sondern ein Prozess.
Die Seite ist so sicher wie du sie schreibst.
Hm :)
Geht mir jetzt nur um den Login. Ich hab erst seit knapp 2 Wochen einen Vertrag mit einem "richtigen" Anbieter (all-inkl.com), wo ich neben Webspace auch volle Perl, PHP und MySql Unterstützung habe.
Wie sicher die DB ist, weiss ich nicht - ich hab mich mit dem Thema Sicherheit einfach noch nicht richtig beschäftigt.
Derzeit schreibe ich die Userpasswörter nur als Prüfsumme (MD5) in die DB, und der Login erfolgt über 16-stellige Session-IDs (maximale Dauer eine Stunde). Die SID wird in ein Cookie geschrieben, das seine Gültigkeit beim Schließen des Browsers verliert. Der User wird nur über die SID des Cookies und der Sessiondatenbank identifiziert.
Bei jedem Login eines Users wird zudem das SessionTable "aufgeräumt", d.h. alte Sessions entfernt.
Ich denke (hoffe!), das ist schon ziemlich sicher. Selbst wenn jemand die DB von außen einsehen kann, bringt ihm das nichts, weil er nur die MD5-Passwörter sieht...
Der einzige Angriffspunkt ist imo der Moment des Einloggens, wenn
das Passwort per Klarnamen an das Skript geschickt wird.
Die einzige Möglichkeit wäre hier SSL, oder?
Was mich aber interessiert: Wie schwierig ist es, ein Passwort beim Login abzufangen? Vielleicht stell ich mir das ja völlig falsch vor. Naja, eigentlich hab ich als Nicht-Hacker überhaupt keine Vorstellung davon :)
Zweite Frage:
Es wird die Standard-Datei (DirectoryIndex beim Apache) aufgerufen mit den entsprechenden Variablen.
Also bei index.php z.B.:
?var=wert
anstatt
index.php?var=wert
Oh, natürlich, da hätte ich auch drauf kommen können - statt index.html ist halt index.php die Startseite.
Ich hab jetzt nur keine Ahnung, ob ich das bei mir ändern kann... das steht doch normalweise in der httpd.conf? Da lässt mich mein Anbieter doch sicherlich nicht dran... oder gibt es andere einfachere Möglichkeiten, diese Startdateien festzulegen?
Dritte Frage:
Einfach das $-Zeichen für eine Variable vorne dransetzen und wohlfühlen... *g*
Ah, cool, danke. Geht das nur mit PHP oder auch mit einem Perl-Cgi?
Danke!
hi,
Geht mir jetzt nur um den Login. Ich hab erst seit knapp 2 Wochen einen Vertrag mit einem "richtigen" Anbieter (all-inkl.com), wo ich neben Webspace auch volle Perl, PHP und MySql Unterstützung habe.
Wie sicher die DB ist, weiss ich nicht - ich hab mich mit dem Thema Sicherheit einfach noch nicht richtig beschäftigt.
also ich habe beides erst wird über das login.cgi script abgefragt danach wird der link angezeigt vom htaccess geschützen bereich und der user muss nochmal eingeben.
Htaccess alleine find ich nicht so sicher,da man mit diversen hackertools solche htaccess abfragen ausnutzen kann und zwar von den antworten dess jeweiligen server status 401 oder status 200,was bei einem
perl script nicht der fall ist,da weiss der client bzw. hackerprogie ja nicht was das perl auf dem server tut(request ist immer 200),wenn man es gut schreibt :)
Derzeit schreibe ich die Userpasswörter nur als Prüfsumme (MD5) in die DB, und der Login erfolgt über 16-stellige Session-IDs (maximale Dauer eine Stunde). Die SID wird in ein Cookie geschrieben, das seine Gültigkeit beim Schließen des Browsers verliert. Der User wird nur über die SID des Cookies und der Sessiondatenbank identifiziert.
mit cookies und session arbeite ich nicht -> zu kompliziert :)
Bei jedem Login eines Users wird zudem das SessionTable "aufgeräumt", d.h. alte Sessions entfernt.
naja...
Ich denke (hoffe!), das ist schon ziemlich sicher. Selbst wenn jemand die DB von außen einsehen kann, bringt ihm das nichts, weil er nur die MD5-Passwörter sieht...
ja das schon.
Der einzige Angriffspunkt ist imo der Moment des Einloggens, wenn
das Passwort per Klarnamen an das Skript geschickt wird.
genau,aber wer hat schon einen server und snifft die passabfragen?
Die einzige Möglichkeit wäre hier SSL, oder?
ja ,nützt aber nichts denk ich,weil der browser ja bei jedem request klartext schickt,es sei denn der geschützte bereich ist
auch auf ssl basis.
Was mich aber interessiert: Wie schwierig ist es, ein Passwort beim Login abzufangen? Vielleicht stell ich mir das ja völlig falsch vor. Naja, eigentlich hab ich als Nicht-Hacker überhaupt keine Vorstellung davon :)
ich denke ziehmlich schwierig oder teuer.
Gruss
Alain
hi,
Der einzige Angriffspunkt ist imo der Moment des Einloggens, wenn
das Passwort per Klarnamen an das Skript geschickt wird.genau,aber wer hat schon einen server und snifft die passabfragen?
es dürfte im www in den seltensten fällen eine direkte verbindung zwischen client und server bestehen.
Die einzige Möglichkeit wäre hier SSL, oder?
ja ,nützt aber nichts denk ich,weil der browser ja bei jedem request klartext schickt,es sei denn der geschützte bereich ist
auch auf ssl basis.
es reicht doch, wenn die anmeldung SSL-gesichert erfolgt.
danach kann man den user ja ggf. über andere mechnismen (bspw. sessions) identifizieren.
(so lange es sich nicht um äußerst sensible bereiche handelt.)
gruß,
wahsaga
hi,
Der einzige Angriffspunkt ist imo der Moment des Einloggens, wenn
das Passwort per Klarnamen an das Skript geschickt wird.genau,aber wer hat schon einen server und snifft die passabfragen?
es dürfte im www in den seltensten fällen eine direkte verbindung zwischen client und server bestehen.
das mein ich auch,eine zwischenstation(sniff-server) zum eigentlichen ziel-server
Die einzige Möglichkeit wäre hier SSL, oder?
ja ,nützt aber nichts denk ich,weil der browser ja bei jedem request klartext schickt,es sei denn der geschützte bereich ist
auch auf ssl basis.es reicht doch, wenn die anmeldung SSL-gesichert erfolgt.
danach kann man den user ja ggf. über andere mechnismen (bspw. sessions) identifizieren.
(so lange es sich nicht um äußerst sensible bereiche handelt.)
was ist wenn man an die session(oder den link) z.B. herankommt?
Gruss
Alain
Hallo,
was ist wenn man an die session(oder den link) z.B. herankommt?
PP,
das skript kann höchstens noch versuchen den user jedesmal anhand von anderen (auch nicht sicheren) merkmalen zu identifizieren:
browser, referer, remote_addr etc.
wenn man restriktiv genug vorgeht ist a) der user schnell sauer
und b) hat man vielleicht glück und fängt einen spoofing versuch ab.
Bert
use Mosche;
Der einzige Angriffspunkt ist imo der Moment des Einloggens, wenn
das Passwort per Klarnamen an das Skript geschickt wird.Die einzige Möglichkeit wäre hier SSL, oder?
Es ist eine Möglichkeit.
Bitte bedenke, wie der HTTP-Authentifizierungsmechanismus (".htaccess") funktioniert: der Client (Browser) schickt bei jedem Request Username/Passwort an den Server. Dadurch wird die Möglichkeit, diese abzufangen und mitzulesen, deutlich erleichtert.
Ich hab jetzt nur keine Ahnung, ob ich das bei mir ändern kann... das steht doch normalweise in der httpd.conf? Da lässt mich mein Anbieter doch sicherlich nicht dran... oder gibt es andere einfachere Möglichkeiten, diese Startdateien festzulegen?
http://httpd.apache.org/docs-2.0/mod/mod_dir.html.en#directoryindex sagt folgendes:
"Context: server config, virtual host, directory, .htaccess"
Dritte Frage:
Einfach das $-Zeichen für eine Variable vorne dransetzen und wohlfühlen... *g*Ah, cool, danke. Geht das nur mit PHP oder auch mit einem Perl-Cgi?
Das geht zum Glück nur mit PHP. Inzwischen haben aber selbst PHP-Programmierer festgestellt, daß diese Erleichterung sehr große Lücken in ein Skript reißen _kann_. Verzichte lieber auf dieses "Feature" (register_globals off) und benutze die richtigen Variablen ($_POST, $_GET).
Alle PHP-Angaben ohne Gewähr, bin kein PHP-Hacker.
use Tschoe qw(Matti);