php-resource



Zurück   PHP-Scripte PHP-Tutorials PHP-Jobs und vieles mehr > Entwicklung > PHP Developer Forum
 

Login

 
eingeloggt bleiben
star Jetzt registrieren   star Passwort vergessen
 

 

 


PHP Developer Forum Hier habt ihr die Möglichkeit, eure Skriptprobleme mit anderen Anwendern zu diskutieren. Seid so fair und beantwortet auch Fragen von anderen Anwendern. Dieses Forum ist sowohl für ANFÄNGER als auch für PHP-Profis! Fragen zu Laravel, YII oder anderen PHP-Frameworks.

Antwort
 
LinkBack Themen-Optionen Thema bewerten
  #1 (permalink)  
Alt 07-10-2019, 21:13
Takeshi
 Registrierter Benutzer
Links : Onlinestatus : Takeshi ist offline
Registriert seit: Oct 2018
Beiträge: 4
Takeshi befindet sich auf einem aufstrebenden Ast
Standard Session absichern

Ich möchte mir für ein Projekt eine Nutzerverwaltung neu aufbauen und beschäftige mich nun erst einmal damit, was man da alles beachten kann und/oder soll. Wird natürlich keine Hochsicherheitsanwendung, aber wenn man es schon anfängt, sollte es schon so gut sein, wie es mit gerechtfertigtem Aufwand implementierbar ist.

Grob sehe ich zwei Gefahren. Jemand ...
- loggt sich bei einem falschen Account ein
- übernimmt eine Session

Das wird jetzt eine etwas größere Liste, einfach damit mir keiner Ansätze erklären muss, die ich schon kenne, das wäre ja unnötige Arbeit

Der erste Fall ist für mich recht klar. Brute-Force-Angriffe durch begrenzte Login-Versuche verhindern und Passwort vernünftig gehasht mit Salt in der Datenbank speichern, da gibt es mit password_hash() inzwischen schon alles fertig.

Mich beschäftigt vorallem nun der zweite Punkt. Habe mir dafür "Session Management Basics - Session Security" auf php.net und noch die Beschreibung einiger Funktionen durchgelesen. Dabei habe ich mitgenommen, dass man vorallem session.use_strict_mode und session.use_only_cookies verwenden soll, um zu vermeiden, dass jemand seine Session-ID mit einem Link mitschickt und die Session-ID nicht nicht in den Metadaten irgendwo auftaucht. Außerdem kann dem Anwender keiner einen Link mit einer Session-ID darin schicken, die er dann verwende, womit der Angreifer dann die ID des Anwenders kennen würde. session.use_strict_mode schützen zudem davor, dass der Angreifer selbst die Session-ID bestimmen kann, also eine verwendet, die der Server selbst gar nicht kennt.

Weiter steht da, man sollte die Session nicht zu lange laufen lassen und nach einer gewissen Zeit durch eine neue Session ersetzen, wovon der Anwender natürlich nichts mitbekommt. In der Session sollte ein Ablaufdatum hinterlegt sein, damit die alte Session nicht ewig weiter verwendet werden kann.

Bei Erhöhung der Berechtigungen soll die Session-ID erneuert werden, damit ein Angreifer, der die alte Session-ID kennt, nicht plötzlich auch eine höhere Berechtigung hat.

Ferner wird im Kapitel "Session and Auto-login" empfohlen eine große Pseudozufallszahl als Cookie zu hinterlegen, die sich am besten mit jedem Seitenaufruf ändert und der Server immer mit der Datenbank abgleichen kann. Und generell sollte ich alle aktiven Sessions in der Datenbank mit Zusatzinformationen nachhalten.

Unter anderem Wikipedia empfiehlt noch die Session an eine IP oder einen Fingerprint des Clienten binden. Die Bindung an die IP bringt mit sich, dass der Anwender sich jeden Tag neu einloggen muss, nicht zielführend. Wäre höchstens sinnvoll IPs zu speichern, von denen aus zugegriffen wird und wenn die IP wechselt und die alte danach wieder auftaucht, dann wird es verdächtig.
__________________________________________

Das wäre glaube ich alles, was ich so an Methoden kenne bzw. gelesen habe. Einige Fragen stellen sich mir aber noch.

- Was bringt es einen Hash als weiteres Geheimnis in den Cookies zu speichern? Wenn ein Angreifer die Session-ID auslesen kann, dann doch auch das andere beliebig lange Geheimnis, egal ob er meine Cookies ausliest oder den Datenstrom mitliest. Macht für mich daher keinen großen Unterschied. Das bringt erst dann irgendetwas, wenn sich das geheimnis wirklich ständig ändert. Nur dann muss er lediglich einmal schneller den Server ansprechen als ich, schon wandert die Session zum Angreifer. Der Anwender merkt das nur, weil er plötzlich ausgeloggt ist. Ich könnte dann implementieren, dass mit einem falschen Geheimnis die Session gleich geschlossen wird. Nur dann befürchte ich, dass es ständig Probleme gibt, obwohl es keinen Angriff gab.

- Als "Fingerprint" fällt mir als erstes der User Agent ein, aber gleiches Problem wie oben, wer die Session-ID auslesen kann, bekommt ohne Mehraufwand auch meinen User Agent. Ich weiß, dass es da noch mehr als Fingerprint gibt, kenne mich da aber noch nicht so aus. Gibt es da noch etwas, was per PHP (also ohne JS) zu realisieren wäre, um den Clienten wiederzuerkennen?

- Und natürlich, habe ich was Wichtiges vergessen oder falsch verstanden?

Schon mal vielen Dank fürs Lesen!
Mit Zitat antworten
  #2 (permalink)  
Alt 07-10-2019, 21:50
h3ll
 Registrierter Benutzer
Links : Onlinestatus : h3ll ist offline
Registriert seit: Mar 2008
Beiträge: 3.655
h3ll befindet sich auf einem aufstrebenden Ast
Standard

Zitat:
Zitat von Takeshi Beitrag anzeigen
Unter anderem Wikipedia empfiehlt noch die Session an eine IP oder einen Fingerprint des Clienten binden. Die Bindung an die IP bringt mit sich, dass der Anwender sich jeden Tag neu einloggen muss, nicht zielführend. Wäre höchstens sinnvoll IPs zu speichern, von denen aus zugegriffen wird und wenn die IP wechselt und die alte danach wieder auftaucht, dann wird es verdächtig.
Ein permanenter Login hat nichts mit der Session zu tun. Eine Session hat in der Regel eine recht kurze Lebenszeit und nicht über Tage hinweg.

Desweiteren kann eine Einschränkung auf eine IP zu Problemen führen. Es gibt auch Internetanschlüsse, bei denen die IP häufig wechselt. Zum Beispiel wenn mehrere Proxies dazwischen hängen die sich abwechseln, oder bei instabilen mobilen Verbindungen mit vielen Reconnects.

Ich würde das ganze Thema nicht zu komplex sehen. Wenn ein Angreifer eine Session-ID abfangen kann, dann oft auch die Eingabe von Username und Passwort beim Login. Das ist halt ein Problem, dass beim Client und nicht beim Server besteht. Somit muss das Problem auch beim Client angegangen werden und nicht beim Server. Man kann noch so eine gute Sicherheitstür mit unknackbarem Schloss bauen, hilft das alles nichts, wenn dem Benutzer selber der Schlüssel gestohlen wird. Aber darauf hat der Hersteller der Tür keinen Einfluss.

Eine Session-ID ist an sich als sicher anzusehen, da mit heutigem Stand der Technik nicht ermittelbar, außer die Netzwerkverbindung oder der Client/Server ist manipuliert. Aber in solchen Fällen ist der Diebstahl der Session-ID das kleinste Problem.

Viel wichtiger ist die korrekte Behandlung von Kontextwechseln, damit keine schadhafte Inhalte in die Seite eingeschleust werden. Denn wenn ein Angreifer in die Position kommt im Namen deiner Seite JavaScript beim Client auszuführen, dann ist so gut wie alles möglich.
Mit Zitat antworten
  #3 (permalink)  
Alt 10-10-2019, 19:26
Takeshi
 Registrierter Benutzer
Links : Onlinestatus : Takeshi ist offline
Registriert seit: Oct 2018
Beiträge: 4
Takeshi befindet sich auf einem aufstrebenden Ast
Standard

Vielen Dank für die Antwort!

Ich denke in Wikipedia war allgemein eine "Session" im Sinne der Software-Implementierung gemeint, also das, was ich im PHP-Code schreibe und nicht die Session-Funktion des PHP-Servers, zumindest hatte ich das auch so verstanden.

Wegen der dynamischen IP-Adressen wollte ich auch von einer IP-Bindung absehen, genau.

Natürlich nimmt ein Angreifer das größte Einfallstor und deshalb wollte ich es auch nicht übertreiben, so dass ich Klimzüge verrichten müsste, die meine persönlichen Fähigkeiten übersteigen, aber wollte es doch einmal zumindest ansatzweise vernünftig machen, wenn ich es schon neu mache. Aber da kein großer Gegenwind kam, gehe ich davon aus, dass das schon so passen wird.

Und natürlich gibt es weitere Sicherheitsaspekte, vorallem das Einschleusen von irgendwechem JS-Code, das wird natürlich auch (hoffentlich ausreichend) bedacht. Habe mir das gerade noch mal an kritischen Stellen notiert, dass ich daran denke, danke.
Mit Zitat antworten
Antwort

Lesezeichen


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Usereingaben absichern INC. PHP Developer Forum 7 21-04-2007 22:34
String absichern MaxP0W3R PHP Developer Forum 6 24-03-2006 21:52
Absichern?? BladeTheUndying BRAINSTORMING PHP/SQL/HTML/JS/CSS 2 30-10-2003 16:52
mail(); absichern Thomas PHP Developer Forum 23 07-11-2002 18:47
Input absichern Rookie PHP Developer Forum 3 23-06-2002 12:22

Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist Ihnen nicht erlaubt, neue Themen zu verfassen.
Es ist Ihnen nicht erlaubt, auf Beiträge zu antworten.
Es ist Ihnen nicht erlaubt, Anhänge hochzuladen.
Es ist Ihnen nicht erlaubt, Ihre Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


PHP News

Die RIGID-FLEX-Technologie
Die RIGID-FLEX-TechnologieDie sogenannte "Flexible Elektronik" , oftmals auch als "Flexible Schaltungen" bezeichnet, ist eine zeitgemäße Technologie zum Montieren von elektronischen Schaltungen.

06.12.2018 | Berni

ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlicht
ebiz-trader 7.5.0 mit PHP7 Unterstützung veröffentlichtDie bekannte Marktplatzsoftware ebiz-trader ist in der Version 7.5.0 veröffentlicht worden.

28.05.2018 | Berni


 

Aktuelle PHP Scripte

Newsmanager

Der Newsmanager ist ein Newssystem und Newsletter in einem. Mit WYSIWYG Editor und E-Mail import aus einer bestehenden MySql Datenbank sowie dynamische Kategorien / Themen Filter.

11.09.2019 Stephan_1972 | Kategorie: PHP/ News
Modelmanager

Der Modelmanager ist ein Webtool für Fotografen, kann als komplette Homepage oder als Webtool installiert werden.

11.09.2019 Stephan_1972 | Kategorie: PHP/ Webservice
ContentLion - Open Source CMS ansehen ContentLion - Open Source CMS

ContentLion ist ein in PHP geschriebenes CMS, bei dem man Seiten, Einstellungen usw. in Ordnern lagern kann

22.08.2019 stevieswebsite2 | Kategorie: PHP/ CMS
 Alle PHP Scripte anzeigen

Alle Zeitangaben in WEZ +2. Es ist jetzt 01:20 Uhr.