Sessions vs htaccess / sicherheit? was meint ihr?

[speedy]

hallo liebes forum,

ich würde gern von euch eure meinung zu passwortgeschützten seiten mittels sessions vs htaccess (beides ssl verschlüsselt natürlich) hören.

vielen dank.

[dedlfix]

echo $begrüßung;

ich würde gern von euch eure meinung zu passwortgeschützten seiten mittels sessions vs htaccess (beides ssl verschlüsselt natürlich) hören.

Ja.

Für welche Aufgabenstellung möchtest du die Antwort präzisiert haben?

echo "$verabschiedung $name";

[speedy]

hallo,

für einen passwortgeschützen bereich einer homepage...ich habe beides bereits erfolgreich probiert, jedoch stellt sich mir die frage was sicherer ist im bezug auf das hacken. (mir ist bekant das beides icht 100% sicher ist, nur stellt sich mir die frage, mit welcher variante ich mit dem geringsten aufwand eine halbwegs sichere umgebung schaffe.)

Oder ist sogar der doppelte einsatz (htaccess und session) sinvoll?

Es werden nicht viele Benutzer sein, somit ist das Problem bezüglich der htaccess und der etwas umständlicheren textdatenbank i.o.

=> mein Webspace ist von tecserver.at, somit gehe ich davon aus, dass der server selbst von dieser firma geschützt wird.

vielen dank für weitere anregungen

[dedlfix]

echo $begrüßung;

für einen passwortgeschützen bereich einer homepage...ich habe beides bereits erfolgreich probiert, jedoch stellt sich mir die frage was sicherer ist im bezug auf das hacken. (mir ist bekant das beides icht 100% sicher ist, nur stellt sich mir die frage, mit welcher variante ich mit dem geringsten aufwand eine halbwegs sichere umgebung schaffe.)

Sie ist nicht nur nicht zu 100% sondern gar nicht beantwortbar, wenn man nur diese beiden Teilaspakte einer generellen Absicherung betrachtet. Außerdem ist zu definieren, was du in dem Fall unter Sicherheit verstehst. Brauchst du die Sicherheit von Fort Knox oder geht es nur um (Entschuldigung) Popelkram? Oder anders gefragt: Was genau soll verhindert werden?

Oft ist es auch die Kombination aus mehreren Unachtsamkeiten und Unterlassungen, die eine Sicherheitslücke ergeben, wie man jüngst sehr anschaulich sehen konnte: http://www.heise.de/security/Hacker-manipulieren-Schalke-Seite--/news/meldung/132404 und http://www.heise.de/security/Website-von-Wolfgang-Schaeuble-ueber-Typo3-Luecke-gehackt--/news/meldung/132315.

=> mein Webspace ist von tecserver.at, somit gehe ich davon aus, dass der server selbst von dieser firma geschützt wird.

Man muss immer davon ausgehen, dass der Hoster und seine Technik auch nicht unfehlbar ist und dass seine Kunden beispielsweise aus Unachtsamkeit seine Bemühungen torpedieren können.

echo "$verabschiedung $name";

[Auge]

Hallo

Server-Authentifizierung und Sessions haben erstmal unterschiedliche primäre Anwendungszwecke. Sie lassen sich aber zum jeweils anderen Zweck benutzen.

Server-Authentifizierung:
Ein Client (Robot, anderer Server, aber auch ein Benutzer an seinem Browser) muss sich für den Zugriff auf bestimmte Verzeichnisse/Dateien dem Webserver gegenüber als berechtigt ausweisen. Schlägt dies fehl, wird dem Clienten mitgeteilt, dass er auf den entsprechenden Bereich keinen Zugriff bekommt (Statuscode 403), gelingt die Authentifizierung erlangt der Client Zugriff auf den Bereich. Alle unter die Authentifizierung fallenden Dateien/Ressourcen erfordern beim Zugriff die Legitimation gegenüber dem Server.
Bei jeder weiteren Anfrage an den Server wird der Benutzername mitgeschickt, sodass der Client/Benutzer weiterhin identifizierbar bleibt.

Session:
Der Zweck der Session ist es primär, einen Clienten/Benutzer während der Laufzeit der Session zu identifizieren, also bei jedem Zugriff wiederzuerkennen. Man kann dies natürlich auch mit einem Login verbinden, so dass ein Benutzer z.B. gegenüber einer Liste von berechtigten Benutzern in einer Datenbank abgeglichen werden kann.

Beide Techniken ermöglichen das von dir gewollte. Bei der Session musst du aber selbst dafür sorgen, dass ein unberechtigter Zugriff abgewiesen wird. Die in dem entsprechenden Bereich liegenden Seiten/Dateien liegen quasi öffentlich auf dem Server, nur dein Login, bzw. die Folgefunktionen, stellt, wenn es wie gesollt funktioniert, sicher, dass nicht berechtigte Zugriffe abgewiesen werden. Bei der Server-Authentifizierung erledigt das der Server selbst.

für einen passwortgeschützen bereich einer homepage...ich habe beides bereits erfolgreich probiert, jedoch stellt sich mir die frage was sicherer ist im bezug auf das hacken.

Absolut sicher ist nichts. Der Server kann gehackt werden und so Zugriff sowohl auf eine Datenbank als auch auf irgendwelche Dateien (auch die mit den Passwörtern) erlangt werden. Allerdings halte *ich* eine serverseitige Authentifizierung, mit einer außerhalb des per HTTP erreichbaren Bereichs gelagerten Passwortdatei, für sicherer.

Es werden nicht viele Benutzer sein, somit ist das Problem bezüglich der htaccess und der etwas umständlicheren textdatenbank i.o.

Wie an anderer Stelle erwähnt, muss es keine Textdatenbank (typischerweise: .htpass) sein. Die benutzername-Passwort-Kombination kann z.B. auch in einer Datenbank gespeichert werden. Der Server muss dann aber auch wissen, dass er dort suchen muss.

Tschö, Auge

[speedy]

ah danke für den ausführlichen beitrag!

eine ergänzende Frage dazu:

über welche weise schützt du deine veranstaltungsdatenbank?

grüße

[Auge]

Hallo

ah danke für den ausführlichen beitrag!

eine ergänzende Frage dazu:

über welche weise schützt du deine veranstaltungsdatenbank?

Server-Auth, das Skript hat keinen eigenen Login-Mechanismus. Wenn ein Anwender einen Sessionbasierten Login benutzt, kann er natürlich die Funktionen zur Prüfung der Berechtigung in das Skript einbinden. Eine Prüfung, ob der aktuelle Besucher des Administrationsskripts berechtigt ist, da zu sein, erfolgt innerhalb des Skripts nicht, das überlasse ich dem Server. Da alle Administrationsaufgaben in dieser einen Datei abgewickelt werden, sollte die Einbindung des Session-Login aber nicht allzu schwierig sein.

// ermittle Benutzername (Datenbank etc. ...)  
if (Benutzername nicht korrekt) {  
header("http://example.com/schmeiss/ihn/raus");  
}  
// mache weiter

Tschö, Auge

[Jörg Peschke]

Moin,

ich würde gern von euch eure meinung zu passwortgeschützten seiten mittels sessions vs htaccess (beides ssl verschlüsselt natürlich) hören.

Ein paar random thoughts dazu:

Pauschal würde ich erstmal sagen, dass eine Verwaltung von Passwörtern über Datenbanken u.ä. in Verbindung mit Sessions flexibler ist.
Man kann Passwörter, Benutzergruppen, Berechtigungen usw. einfach besser handhaben, wenn sie nicht in irgendwelchen flachen Textdateien herumliegen.

Einen Nachteil bei Sessions ohne Cookies sehe ich darin, dass URLs, in denen die Session-ID auftaucht, benutzt werden können, um die Session zu "hijacken".

Beispiel:
 - User A ruft Webseite auf, bekommt eine Session zugeteilt, loggt sich ein -> Session gilt am Server als authenifziziert

- User A postet eine URL mit Session-ID im Selfhtml-Forum

- User B kopiert die URL und ruft sie auch

-> User B hat die (authentifizierte) Session von User A übernommen!

Dem kann man natürlich entgegenwirken, z.b. dadurch, dass besonders sicherheitskritische Funktionalitäten eben nochmal eine erneute Authentifzierung erfordern oder die Session nach ner Zeit abläuft (ist ja glaube ich sogar Standard). Trotzdem, das ist nicht ganz unproblematisch, und kann bei .htaccess-Schutz nicht passieren.

Ein Nachteil widerrum bei .htaccess:
Es reicht eine kleine Unachtsamkeit bei der Serverkonfiguration (dass z.b. die .htaccess-Datei ungewollt beschreibbar durch einen Prozess wird), und das wars mit der Sicherheit.

-> Mein pers. Fazit: Wenn der Server-Administrator weiß was er tut, nehmen sich .htaccess-Schutz und Authentifizierung über Sessions nicht so viel.
Für komplexere Systeme (viele Benutzer, viele Rollen, viele Benutzergruppen) wird die Wartung über .htaccess jedoch sehr umständlich. Für kleinere Anwendungen dagegen ists ok.

Greetings,
Jörg

[dedlfix]

echo $begrüßung;

Pauschal würde ich erstmal sagen, dass eine Verwaltung von Passwörtern über Datenbanken u.ä. in Verbindung mit Sessions flexibler ist.
Man kann Passwörter, Benutzergruppen, Berechtigungen usw. einfach besser handhaben, wenn sie nicht in irgendwelchen flachen Textdateien herumliegen.

HTTP-Authentification ist keineswegs an Textdateien gebunden. Das mag vielleicht der bekannteste Weg für Hosterkunden sein, aber selbst da kann man andere Lösungen implementieren, beispielsweise HTTP authentication with PHP. Auch direkt im Apachen kann man HTTP authentication gegen Datenbanken implementieren.

echo "$verabschiedung $name";

[Beat]

Pauschal würde ich erstmal sagen, dass eine Verwaltung von Passwörtern über Datenbanken u.ä. in Verbindung mit Sessions flexibler ist.

Ja, aber...

Man kann Passwörter, Benutzergruppen, Berechtigungen usw. einfach besser handhaben, wenn sie nicht in irgendwelchen flachen Textdateien herumliegen.

Nein das hat primär mal nix mit dem Speicherformat zu tun. Und im Gegenteil. ein Flatfile ist unabhängiger als eine Datenbank.
Für mich ist das auch nicht das Thema den die Frage ist ja nicht, was weniger Programming Skill bedarf.

Der Vorteil eigener Sessions liegt darin, dass du nicht auf bestimmte Parameter Werte festgelegt bist, sondern diese selber definieren kannst.
Alle Komplexizität steht dir offen.

Einen Nachteil bei Sessions ohne Cookies sehe ich darin, dass URLs, in denen die Session-ID auftaucht, benutzt werden können, um die Session zu "hijacken".

Gilt auch bei Cookies. Das hat nichts damit zu tun.

Zudem: Poste hier doch mal, was dir Live Headers anzeigt? Das kam hier kürzlich vor. Der Betroffene wurde darauf hin aufgefordert sein passwort möglichst schnell zu ändern...

Der essentielle Unterschied zwischen einer URL Deponierten ID und einer Cookie ID ist:

Eine Cookie ID ist vollkommen Browser-orientiert.
Eine URL-ID ist Aktivitätsorientiert.

bei URL Sessions kann ich parallel mehrere Sessions haben. Das bekommst du mit Cookies nur in einer höchst blödsinnigen Weise hin.

Beispiel:

...

Dem kann man natürlich entgegenwirken, z.b. dadurch, dass besonders sicherheitskritische Funktionalitäten eben nochmal eine erneute Authentifzierung erfordern oder die Session nach ner Zeit abläuft (ist ja glaube ich sogar Standard). Trotzdem, das ist nicht ganz unproblematisch, und kann bei .htaccess-Schutz nicht passieren.

Du kannst eine Kombination verwenden.
BrowserID = deine Cookie ID
RequestID = einen vorherigen Zustand identifizierenden ID via URL/Formular.

In der Kombination kannst du daraus OneTime IDs basteln und somit im Zusammenhang mit einer "used" marke schon beinahe sichere IDs erzeugen, die bei Doppelverwendung die ganze Browser-ID Geschichte killen, also Schadensbegrenzend wirken.

Ein Nachteil widerrum bei .htaccess:
Es reicht eine kleine Unachtsamkeit bei der Serverkonfiguration (dass z.b. die .htaccess-Datei ungewollt beschreibbar durch einen Prozess wird), und das wars mit der Sicherheit.

Das ist ein Punkt. Aber .htaccess braucht nicht via ein gleichnamiges File implementiert zu sein.

mfg Beat

[Jörg Peschke]

Hallo,

Nein das hat primär mal nix mit dem Speicherformat zu tun.

Ack, point taken.

ein Flatfile ist unabhängiger als eine Datenbank.

Richtig, das habe ich aber nicht gemeint. Die Verwaltung komplexer Datenstrukturen ist in einer Datenbank IMO besser aufgehoben. Denn dafür sind die Dinger. Anfragen wie "Suche mit alle Benutzer, die auf Bereich X aber nicht auf bereich Y Zugriff haben und seit dem XX.XX.2009 nicht mehr eingeloggt waren" möchte ich nicht über grep,awk und sed in ner .htaccess-Datei suchen müssen.
Freilich hast Du recht, dass die Grenze schwimmend ist - DBMS lagern ja den Teil, den sie nicht im Hauptspeicher halten können, auch in Dateien aus, und auch für Textdateien gibts ja SQL-APIs und wie in einem anderen Post in diesem Thread ja richtig angemerkt wurde, das Basic Authentication-Scheme kann man ja auch gegen eine Datenbank laufen lassen.

Zudem: Poste hier doch mal, was dir Live Headers anzeigt?

Ok...das ist aber ein theoretisches Beispiel (was zugegeben in Technik-basierten Foren wie dem Selfhtml-Forum mal vorkommen kann, aber nicht der Regelfall ist.) Bzw., bei jemand der LiveHTTPHeaders einsetzt, gehe ich i.d.regel davon aus, dass er weiß, was in einer solch mitgeschnittenen Kommunikation alles an persönlichen Daten drinstehen kann (und diese ggf. raus-X-t bgz. anonymisiert).
Das ist so, wie wenn ich sage "Poste mal Dein Passwort".

Aber ab einer gewissen Abstraktionsebene verschmelzen ohnehin beide Ideen zum selben technischen Grundprinzip:

Benutzer bekommt Authentifizierungsanfrage, authentifiziert sich.
Fortan sendet der Browser jedesmal Authentifizierungsinformationen mit
(im Falle von htaccess o.ä. als Authorisation-Header, im Fall von Sessions als Session-ID im Cookie/der URL). Der Server benutzt diese Authentifizierungsinformation, um den Benutzer zu identifizieren und zuordnen zu können.

[Christoph Jeschke]

Guten Tag,

Einen Nachteil bei Sessions ohne Cookies sehe ich darin, dass URLs, in denen
die Session-ID auftaucht, benutzt werden können, um die Session zu "hijacken".

Es ist gar nicht notwendig, dass die Session bereits in der URL angegeben wird, es reicht, wenn die Möglichkeit dazu besteht (session.use_trans_sid = On). Man kann dann nämlich einen User mit einer bereits bekannte Session starten lassen (Session Fixation, session_regenerate_id()).

Zusätzlich gibt es noch das Problem, dass eine bestehende Session zu bösartigen Zwecken benutzt werden kann (Cross Site Request Forgery). Ein nicht völlig unbekanntes CMS hat das Problem, dass es für CSRF verwundbar ist und man einen Eintrag in die interne IP-Blackliste schmuggeln kann, der Zugriffe _jeder_ IP-Adresse (.) verbietet - auch die des Administrators.

Dem kann man natürlich entgegenwirken, z.b. dadurch, dass besonders
sicherheitskritische Funktionalitäten eben nochmal eine erneute
Authentifzierung erfordern oder die Session nach ner Zeit abläuft (ist ja
glaube ich sogar Standard).

Es gibt in PHP einen Mechanismus, er eine ungenutzte(!) Session nach einer bestimmten Zeit und mit einer bestimmten Chance aufräumt.

Trotzdem, das ist nicht ganz unproblematisch, und
kann bei .htaccess-Schutz nicht passieren.

Nahezu alle Authentifizierungsmöglichkeiten sind für CSRF anfällig, egal ob PHP-Session oder Basic Auth.

Ein Nachteil widerrum bei .htaccess:
Es reicht eine kleine Unachtsamkeit bei der Serverkonfiguration (dass z.b.
die .htaccess-Datei ungewollt beschreibbar durch einen Prozess wird), und das
wars mit der Sicherheit.

Das ist kein prinzipielles Problem der Konfiguration über eine .htaccess-Datei. Genauso leicht ist es möglich, einen Programmierfehler in eine Applikation einzubauen, der XSS ermöglicht. Das passiert (vermutlich) sogar viel öfter.

-> Mein pers. Fazit: Wenn der Server-Administrator weiß was er tut, nehmen
sich .htaccess-Schutz und Authentifizierung über Sessions nicht so viel.

Ich persönlich hätte da viel mehr Sorgen um die Qualität der Applikation. Ansonsten bin ich aber der Meinung, dass eine Authentifizierung in eine Applikation gehört und nur in Fällen, wo es keine Applikation gibt, in den Webserver.

Für komplexere Systeme (viele Benutzer, viele Rollen, viele Benutzergruppen)
wird die Wartung über .htaccess jedoch sehr umständlich. Für kleinere
Anwendungen dagegen ists ok.

.htaccess sind nur Steuerdateien für die Serverkonfiguration. Was darin konfiguriert wird, ist eine andere Frage. Es gibt übrigens durchaus auch Apache-Module, welche eine Authentifizierung über LDAP o.ä. anbieten.

Gruß
Christoph Jeschke