IP Adressen sperren

[StefanRHRO]

Cookies werden meistens zugelassen, sonst würden Logins ja auch nicht funktionieren.

Aber Cookies kann man löschen und das ist einfacher als seinen Router neu einwählen zu lassen ...

Ich bin auch eher von automatisierten Angriffen ausgegangen, mit so Tools wie CUrl zum Beispiel, da kann ich frei wählen ob ich Cookies zulasse oder nicht, könnte sogar im Zweifel das Cookie beschneiden, ist ja ne normale Textdatei, wie auf nem "normalen" Klienten auch. Und warum sollten Logins ohne Cookies nicht funktionieren

[lstegelitz]

Und warum sollten Logins ohne Cookies nicht funktionieren

Es geht, aber dann sind andere Maßnahmen notwendig, um den Status des Clients zu speichern/übertragen. HTTP ist zustandslos, alle Informationen eines vorhergehenden Requests sind beim nächsten Request verloren...

[StefanRHRO]

Es geht, aber dann sind andere Maßnahmen notwendig, um den Status des Clients zu speichern/übertragen. HTTP ist zustandslos, alle Informationen eines vorhergehenden Requests sind beim nächsten Request verloren...

Und die anderen Maßnahmen, würden Programmierer überfordern? Oder geht ihr alle allgemein davon aus, dass der User Cookies aktiviert hat? Finde diesen Ansatz schon fragwürdig... Aber danke für die Leerstunde...

[Flor1an]

Zumindest ohne Session Cookies kommt kein Client mehr aus ... von daher kann man meiner Meinung nach Cookies schon als Voraussetzung sehen. Allerdings bringt das nur recht wenig als Sperre ... brauchen wir denke ich auch nicht weiter diskutieren, ich kann mich gut an einen anderen Thread erinnern wo es auch ausführlichst besprochen wurde, wenn der Threadersteller sich dafür interessiert kann er den Thread ja mal durchlesen ...

[lstegelitz]

Cookies haben sich eingebürgert... das Handling ist Bestandteil des Browsers.
Andere Alternativen sind z.B. die Übertragung der Session-ID in der URL bzw. als hidden-Field in einem Formular.

Wenn du dein eigenes System umsetzen willst, wirst du nicht drum herum kommen, einen Browser zu programmieren, der dein Handling implementiert. Wie wäre denn dein Ansatz, wenns nicht Cookies (bzw. das Prinzip der Cookies) sein sollen?

Das Problem bleibt: Aufgrund der Zustandslosigkeit von HTTP muss der Client aktiv mitarbeiten, um sich zu identifzieren - da aber alle Clientinformationen potentiell manipuliert sein können, ist von dieser Seite keine Sicherheit zu erwarten.

[StefanRHRO]

Cookies haben sich eingebürgert... das Handling ist Bestandteil des Browsers.

Bei rot über die Ampel gehen hat sich auch eingebürgert, aber gut ist das trotzdem noch lange nicht!

Andere Alternativen sind z.B. die Übertragung der Session-ID in der URL bzw. als hidden-Field in einem Formular.

Das wär doch mal ein alternativer Ansatz. Ich habe schon Applikationen (oder Module dafür besser gesagt) in Umgebungen umgesetzt, wo Cookies halt vom Proxy nicht zugelassen wurden.

[...]da aber alle Clientinformationen potentiell manipuliert sein können, ist von dieser Seite keine Sicherheit zu erwarten.

Darauf verlassen sich aber viele "Entwickler" einfach, dass die Header, die vom Klient kommen schon alle "sauber" sind. Deswegen meinte ich auch hier zum Beitragseröffner, dass er mal lieber seine App sicher programmieren sollte, als irgendwelche Leute oder IPs (im schlimmsten Fall noch über Cookies )auszusperren.

[Dark Guardian]

Das wär doch mal ein alternativer Ansatz. Ich habe schon Applikationen (oder Module dafür besser gesagt) in Umgebungen umgesetzt, wo Cookies halt vom Proxy nicht zugelassen wurden.

Dieser Ansatz bietet aber neue Probleme besonders bei der Übertragung über die URL.

Da man diese auch mal gerne verschickt offenbart man seine Session-ID. Das ist soweit nicht shclimm wnen man sich auf andere Informationen vom Client verlassen kann. Als da wären IP-Adresse, HTTP User Agent und andere Informationen die der Browser "manchmal" mit schickt oder manchmal auch eben nicht.

D.h. du hast über eine URL im Prinzip keine Chance trotz SID sicher zu sagen "das ist jetzt der und der Benutzer".

[StefanRHRO]

Dieser Ansatz bietet aber neue Probleme besonders bei der Übertragung über die URL.

Da man diese auch mal gerne verschickt offenbart man seine Session-ID. Das ist soweit nicht shclimm wnen man sich auf andere Informationen vom Client verlassen kann. Als da wären IP-Adresse, HTTP User Agent und andere Informationen die der Browser "manchmal" mit schickt oder manchmal auch eben nicht.

D.h. du hast über eine URL im Prinzip keine Chance trotz SID sicher zu sagen "das ist jetzt der und der Benutzer".

Hmm die Session ID, könnte ich aber auch ohne dass sie in der URL steht oder in nem Hidden Feld herausfinden. Zum Beispiel über XSS oder son Schweinskram. JavaScript kann "leider" auch mit Cookies umgehen...

[Dark Guardian]

Hmm die Session ID, könnte ich aber auch ohne dass sie in der URL steht oder in nem Hidden Feld herausfinden. Zum Beispiel über XSS oder son Schweinskram. JavaScript kann "leider" auch mit Cookies umgehen...

Über Sicherheitslücken in einer Anwendung brauchen wir gar nicht diskutieren. Da kannst auch sagen "wozu brauch ich ein Passwort wnen ein Angreifer über SQL Injections eh die komplette Usertabelle sehen kann und sich Adminrechte geben kann?".

[lstegelitz]

Hmm die Session ID, könnte ich aber auch ohne dass sie in der URL steht oder in nem Hidden Feld herausfinden. Zum Beispiel über XSS oder son Schweinskram. JavaScript kann "leider" auch mit Cookies umgehen...

Wenn die Session ID (serverseitig generiert!) nicht auf dem Client gespeichert ist - wie willst du sie dann herausfinden?
Den Weg musst du mir jetzt mal erklären.

[StefanRHRO]

Wenn die Session ID (serverseitig generiert!) nicht auf dem Client gespeichert ist - wie willst du sie dann herausfinden?
Den Weg musst du mir jetzt mal erklären.

Ich bin in dem Fall von der Cookie Methode ausgegangen... Deshalb auch der Hinweis:

JavaScript kann "leider" auch mit Cookies umgehen...

...

@Dark Guardian: Wieso will eigentlich nie einer mit mir über Sicherheitslücken diskutieren? Und dein Beispiel mit den Passwörtern ist sehr abstrakt, finde ich jetzt persönlich... Was ich eigentlich die ganze Zeit versuche zu sagen ist, dass sich einige "Entwickler" eher mal Gedanken darüber machen sollten, wie es zu Missbräuchen kommt und die Applikation dahingehend anpassen... Das was der Beitragseröffner vor hat hindert den "User" ja nach wie vor nicht daran die Seite/Applikation für irgendwelchen Schund zu missbrauchen, sondern hindert ihn ja "nur" zeitweise daran...

[Dark Guardian]

@Dark Guardian: Wieso will eigentlich nie einer mit mir über Sicherheitslücken diskutieren?

Weil du bei einer potenziel angreifbaren Anwendung immer davon ausgehen kannst das alle Sicherheitsmaßnahmen (über die wir hier reden) nicht greifen und sich die Diskussion somit im Kreis dreht.

Wenn du über wirksame Sicherheitsmaßnahmen reden willst musst du von einer vor Angriffen ausreichend geschützten Anwendung ausgehen. Und da sind für Reidentifikation eines Benutzers Cookies nun einmal der "sicherste" Weg.