Login

Hallo,

ich mochte auf meiner Webseite einen kleinen Admin Bereich einrichten, die Seite soll passwortgeschützt sein. Wie kann man das Problem lösen? gibts irgendwo ein Beispiel ?

Hi!

Denke mal du meinst für ASP.NET. Dazu findet man doch sicher einiges bei google:
http://www.google.de/search?q=login+%2Basp.net
Du wärst mit deiner Frage sicher im Forum "Web- und Netzwerktechnologien" besser aufgehoben.

Ansonsten ist es kein Problem einen Login zu programmieren. Das Senden der Daten aus dem Login-Formular machst du per POST-Methode. Das eingegebene Passwort verschlüsselst du mit dem Algorithmus mit dem du auch das Passwort in der Datenbank verschlüsselt hast. Danach musst du dir nur noch überlegen ob du einen sessionbasierten oder einen cookiebasierten Login haben möchtest. Bei Cookies ist natürlich der Vorteil die User können so angemeldet bleiben. Bei einem sessionbasierten Login legt man normalerweise ein Timeout fest, wie lange ein User eingeloggt bleibt.

Wenn du nur eine Hand voll Personen hast, die auf den Bereich zugreifen dürfen, würde ich mir doch einen htaccess geschützten Bereich anlegen. Aber bei google (s. oben) wirst du sicher einiges dazu finden.

Vielen dank für die ausführliche Info ! Jetzt hab ich schon einige Anhaltspunkte.

Ich habe das Login jetzt mal mit Hilfe von Session Variablen umgesetzt. Sollte sicher genug sein oder ?

Original von jan223
Ich habe das Login jetzt mal mit Hilfe von Session Variablen umgesetzt. Sollte sicher genug sein oder ?

Wenn du die Session-ID nicht in der URL mitschleifst, ja.

Ansonsten: warum hast du nicht die Möglichkeiten genutzt, die dir ASP.NET 2.0 von Haus aus bietet? Da hättest du quasi gar nix mehr programmieren müssen ...

Gruß

Weil mein Provider (noch) kein ASP.net 2.0 anbietet 🙂
Die Session ID lasse ich nicht anzeigen:
Siehe hier:

Jan

Na dann passt das schon - musst nur schauen, dass du in jeder Seite auch überprüfst ob die Session Variable existiert oder nicht 😉

Wenn Du Form Authentication verwendest, bindest Du doch einen User an die Session.

FormsAuthentication.SetAuthCookie("DeinUserName", false);

Prüfen kannst Du das ganze über

Request.IsAuthenticated

Wenn Du nun noch in der Web.Config den entsprechenden Wert cookieless nach Deinen Wünschen setzt, kannst Du das Cookie-Verhalten auch noch steuern.

Warum also eigene Session-Variablen Verwenden?

Na dann passt das schon - musst nur schauen, dass du in jeder Seite auch überprüfst ob die Session Variable existiert oder nicht

Ja mache ich im Form Load, wenn die die Session Variable auf false gesetzt ist, dann wird das Login Formular aufgerufen.

Jan

Z.B. - hier nicht der Fall - wenn auf Cookies verzichtet werden soll. Dann geht in 1.1 keine Forms Authentication.

Klar, war ja aber hier nicht gefordert...

Hallo zusammen,

prinzipiell habe ich eine Frage zu dem Thema:

Zitat: Original von jan223
Ich habe das Login jetzt mal mit Hilfe von Session Variablen umgesetzt. Sollte sicher genug sein oder ?

Wenn du die Session-ID nicht in der URL mitschleifst, ja.

Wieso ist das jetzt gefährlich, wenn die Session-ID mit der URL versendet wird?

Ich bin der Meinung, dass ein Speichern der Daten in dem Session Objekt sicherer als in Cookies ist, denn Cookies können vom Benutzer on-the-fly manipuliert werden, während das Session Objekt beim Server gehalten wird.

Auch eine Behauptung, dass URL's von Sniffern mitgelesen werden können, kann ich nicht nachvollziehen, denn das geht auch mit Cookies, diese werden im HTTP-Transfer auch mit übertragen.

Also warum ist das nun negativ?

Ciao
Norman-Timo

Die Hauptgefahr liegt wohl im "Stehlen" der Session....

Grundsätzlich kannst dir das hier mal zu Gemühte führen:

http://www.c-sharpcorner.com/Code/2004/Sept/securewebappl.asp

Hallo trinkjoghurt,

kannst Du mir das ein Wenig ausführlicher erklären?

Wie gesagt, wenn jemand mitsnifft, dann kann er das auch bei Cookies. Da kann er auch mittendrin einsteigen und sich für den anderen ausgeben.

Ciao
Norman-Timo

Wenn Du beide Methoden gegenüberstellst, hast Du absolut recht. Jede der beiden Möglichkeiten lassen es zu, den Besitzer zu wechseln.
Einen 100% Schutz bietet weder das eine, noch das andere.

Aber:

ASP.NET Sessions sind schon seeeehr sicher:

Einige Features:*random session ID with a hash of the client's user agent *secure sockets layer (SSL) should be used to prevent network-level sniffing of session IDs *session ID regeneration feature, which forces expired session IDs that are not found on the server to be replaced with a newly generated ID *ASP.NET 2.0 session state has been hardened to help guard against session ID spoofing and injection. It takes advantage of the HTTP-only cookie feature (currently supported by Internet Explorer 6.0 with Microsoft® Internet Explorer 6.0 SP1 or Windows® XP

Vor allem mit ASP.NET 2.0 hat MS nochmal einiges für die Sicherheit implementiert...

Hallo trinkjoghurt,

danke, das ist das was ich hören wollte 😁

Nein, ich bin sehr wohl vertraut was Security angeht, auch wenn ich nicht immer auf dem "höchsten Level" meine Applikationen sichere (Das ist immer eine Kosten-Nutzen-Rechnung).

Da ich schon mal in den Genuss eines mehrtägigen Hacking-Kurses gekommen bin, weiß ich, dass es verdammt schwierig ist, sich einer fremden Session zu bedienen.

Nichtsdestotrotz, habe ich noch zusätzliche "einfache" Sicherheitsaspekte mit eingebaut. So kann man z.B. über 'Request.UserHostName' sich immer die IP-Adresse holen, und wenn man diese dann neben der Session-ID noch überprüft, dann hat man schon wieder eine Hürde mehr eingebaut.

Komplett sicher bekommt man keine Anwendung, sobald man im Internet angeschlossen ist, ist man unsicher 😉

Aber für jan223 reicht es aus, wenn er für das Thema Security sensibilisiert wird.

Ich mag nur nicht, wenn man eine technologie als unsicher darstellt, ohne genauer darauf einzugehen, oder es zumindest zu begründen...

Ciao
Norman-Timo

Hab eure Posts jetzt nur überflogen. Aber, ganz einfaches Szenario:

Die SessionID wird in der URL mitgeschliffen, also http://mysite.com/(SID)/Default.aspx. Der User loggt sich ein, und klickt anschließend auf einen ausgehenden Link innerhalb des geschützten Bereiches.

Und schon hat man den Salat.

Warum? Einfach: sofern der Client des Users etwa durch Dreck wie Norton Internet Security nicht die Info "Referer" blockt, taucht diese in den Logfiles, oder noch schlimmer, der Livestatistik der aufgerufenen Seite auf. Wenn diese nun vom Admin der anderen Seite zeitnah gelesen wird, kann er einfach auf den Link klicken und schon ist er "drin" ...

Klingt unwahrscheinlich, ist mir aber tatsächlich mal passiert. Damals war aber ich "der andere" und befand mich plötzlich in einer schlecht in PHP programmierten Linksammlung wieder.

Auch sonst ist die Verwendung prinzipiell unsicher - denn es reicht schon, wenn der User im geschlossenen Bereich etwas tolles entdeckt hat, und das einfach per Mail oder Messenger weiter verbreitet. Jeder der dann vor Ablauf der Session den Link aufruft, befindet sich dann "drin" ...

Hoffe es ist etwas klarer - wenn ich irgendwas wiederholt hab, was hier schon geschrieben wurde, sorry dafür.

Gruß

👍 Das war jetzt aber sehr ausführlich 🙂
Danke, ich denke ich lasse den Login jetzt so.
Mein Adminbereich ist nur um mein Weblog zu schreiben und um ne Links zu verwalten.

Original von Waschbecken
Z.B. - hier nicht der Fall - wenn auf Cookies verzichtet werden soll. Dann geht in 1.1 keine Forms Authentication.

Wie läuft das unter v2.0 - wird die Info in den HTTP-Header geschrieben (wie die sessionId)?

// EDIT:
@ all: bessere Sicherheit bringt es vor allem, wenn man beim erfolgten Login die IP/SessionId des Users speichert und diese bei jeder Anforderung abgleicht. Nun können nur noch Personen die Session stehlen, die über denselben Proxie wie man selbst surfen, denn die IP kann vom User nicht gefälscht werden, da sie fester Bestandteil des Internet-Protokolls ist.

Grüsse
Cord

Original von Cord Worthmann

Original von Waschbecken
Z.B. - hier nicht der Fall - wenn auf Cookies verzichtet werden soll. Dann geht in 1.1 keine Forms Authentication.
Wie läuft das unter v2.0 - wird die Info in den HTTP-Header geschrieben (wie die sessionId)?

Ja, da generiert er eine pervers lange ID und hängt die dynamisch in die URL. Interessant ist übrigens, dass man es in 2.0 auf AutoDetect stellen kann, d.h. er checkt beim ersten Request automatisch, ob der Client Kekse isst, oder nicht, und stellt dann entweder auf cookiebased oder cookieless um.

Gruß

Original von Waschbecken

Original von Cord Worthmann

Original von Waschbecken
Z.B. - hier nicht der Fall - wenn auf Cookies verzichtet werden soll. Dann geht in 1.1 keine Forms Authentication.
Wie läuft das unter v2.0 - wird die Info in den HTTP-Header geschrieben (wie die sessionId)?
Ja, da generiert er eine pervers lange ID und hängt die dynamisch in die URL. Interessant ist übrigens, dass man es in 2.0 auf AutoDetect stellen kann, d.h. er checkt beim ersten Request automatisch, ob der Client Kekse isst, oder nicht, und stellt dann entweder auf cookiebased oder cookieless um.

Gruß

Na ja, das Abgefahrene dabei ist ja, dass die Info nicht wirklich an den URL angehängt wird (siehe HTML output), sondern dass der entsprechende Wert lediglich im HTTP Header steht!
Der Browser hängt den Wert dann an den URL an - wahrscheinlich deswegen, weil es offensichtlich ein (oder mehrere) bedienbare HTTP-Header-Bit(s) gibt, die es ermöglichen, Variablen pauschal an eine Anforderung (und vor allem auch noch an entsprechender Stelle) zu hängen, die dort normalerweise nicht eingeplant sind.
Zu Zeiten von v1.1 war die SessionId ja noch in jedem HTML-Link sichtbar - unter v2.0 ist sie das nicht mehr, wird aber dennoch von jedem Browser problemlos übertragen.
Damit ist quasi eine "CookieLess-Übertragung" möglich, ohne das der entsprechende Wert im sichtbaren Teil des URL verborgen wird (s. v1.1).

Infolgedessen frage ich mich, ob es evtl. Möglichkeiten gibt, eigene Werte im HTTP-Header zu kapseln, die der lokalen Authorisierung (z. B. via Proxy/Firewall) des Users verborgen bleiben, die aber dennoch vom Browser gesendet werden - das wäre ja eine ganz neue fulminante Möglichkeit Daten zu übertragen.

Grüsse
Cord

Hallo Cord Worthmann,

das wäre ja eine ganz neue fulminante Möglichkeit Daten zu übertragen.

Ich gehe aber stark davon aus, dass der Browser nix damit anfangen kann, geschweige auch irgendwie manipuliert.

Also sehe ich jetzt gar keinen Sinn darin, zusätzliche Daten im HTTP-Header zu übertragen, denn die kommen so wieder zurück, wie der Server sie abgeschickt hat.

Und aus dem HTML-Dokument kann ich auch nicht drauf zugreifen, bringt mir also auf Clientseite nix, oder täusche ich mich da?

Ciao
Norman-Timo

Also eure ganze Problematik nehmt ihr wohl ein bischen zu eng. Normalerweise macht man das ja so das man sich mit cookies autentifiziert. NUR wenn der user auf gar keinen fall cookies will, kann man das lösen indem man die sessid immer weiterreicht!
klar , jetzt sagen einige von euch, ich kann meinen cookie faken oder er kann gesnifft und somit geklaut werden. ABER, wenn du das sessionbasiert machst, und die session nicht immer mti in der url dranhängst, dann liegt auf deinem rechner auch ein cookie in dem einfach nur di essesionid liegt! die kann genau so gesnifft werden wie der cookie mit den userdaten. den einzigen vorteil den man hat ist, daß die user keinen scheiss machen können. die sicherheit des users wird damit nicht erhöht, nur die des servers.
solche cookie manipulationsversuxhe nehme ich doch immer gerne als einladung und logge sie mit. ein cookie kann mal falsche daten haben wenn man sien kennwort ändert und dann von einem anderen rechner (mit dem alten kennwort im cookie) versucht einzu loggen. aber wenn das in kurzen abständen öfters passiert h at da einer was vor! solche ip´s/user gehören gesperrt 😉

zu thema sessionid im httpheader:
cleint seitig brint dir das nix. der webserver friemelt sich den einfach aus dem header raus, fertig. theoretisch kannst du da alles reinschreiben, auch ein pornobillschen, allerdings muss der webserver damit was anzufangen wissen!

Jetzt beginnen wir uns im Kreis zu drehen ...

Hallo Sixpack,

ich wollte das Ganze nur erwähnen, weil ich z.B. IMMER Cookieless programmiere, damit die Daten nicht vom User manipuliert werden können.

Meist sind das Intranetanwendungen, und da ist ein "böses" Mitsniffen wohl auszuschliessen.

Aber auch für Internetanwendungen arbeite ich mit Cookieless, dann aber wie schon erwähnt, mit der Speicherung der dazugehörigen IP-Adresse, das macht es zumindest für Laien-Hacker sicher.

Grundsätzlich kann man keine Internet-Anwendung 100%ig sicher machen, aber da drehen wir uns wirklich im Kreis.

Ich will nur mal betonen, dass die Aussage

ABER, wenn du das sessionbasiert machst, und die session nicht immer mti in der url dranhängst, dann liegt auf deinem rechner auch ein cookie

so nicht richtig ist, wenn die Einstellung 'cookieless=true' in der Web.config vorgenommen wird.

Ciao
Norman-Timo

Original von norman_timo
Ich will nur mal betonen, dass die Aussage

ABER, wenn du das sessionbasiert machst, und die session nicht immer mti in der url dranhängst, dann liegt auf deinem rechner auch ein cookie
so nicht richtig ist, wenn die Einstellung 'cookieless=true' in der Web.config vorgenommen wird.

Ciao
Norman-Timo

Doch ... du musst sie nur richtig lesen - denn cookieless=true bewirkt ja das mitschleifen in der URL 😉

richtig!
die sessionid im http header ist natürlich besser als in der url, dan wie oft sehe ich im internet links auf irgendwelche foren wo die sessionid im link mit drin steht. die gefahr ist ja dann gebannt! ich mag cookies, und benutze sie weiter! wenn du keinen cookie von mir willst, musste halt nicht auf meine seite, so einfach ist das! bei mir kriegt halt jeder nen keks 😉

Original von norman_timo

das wäre ja eine ganz neue fulminante Möglichkeit Daten zu übertragen.

Ich gehe aber stark davon aus, dass der Browser nix damit anfangen kann, geschweige auch irgendwie manipuliert.

Also sehe ich jetzt gar keinen Sinn darin, zusätzliche Daten im HTTP-Header zu übertragen, denn die kommen so wieder zurück, wie der Server sie abgeschickt hat.

Und aus dem HTML-Dokument kann ich auch nicht drauf zugreifen, bringt mir also auf Clientseite nix, oder täusche ich mich da?

Nö, der Client soll ja auch nicht darauf zugreifen können. Es ging mir dabei um eine Möglichkeit, Custom-Authentifizierungs/Authorisierungs-Infos im Header mitzusenden zu können, auch wenn der Client Cookies ablehnt.

Das wäre schon praktisch.

Grüsse