Schaden, der übergeben session-id als url-parameter

So, ich habe gerade festgestellt, dass einer der internet-Banken-websites ist vorbei session-id als url-parameter. ( Siehe Bild unten )

Schaden, der übergeben session-id als url-parameter

Ich zuvor nicht überall sehen, dass ';' in der url, in diesem Fall ist es nach 'private,'.

1) Was ist der nutzen dieser ';'?

2) Und warum internet-bank, die sicherste Ort im internet, übermittlung von session-id als url-parameter?

Zuerst dachte ich, Sie tun es, weil einige der Benutzer verbieten die Verwendung von cookies, aber dann wieder, wenn Sie es erlauben, cookies verwenden, wenn nicht - url, aber ich weiß erlaubt die Verwendung von cookies, so offensichtlich das ist nicht der Fall.

3) ich denke, dann sollten Sie einige andere Sicherheitsmaßnahmen? Was Sie sein könnten?

4) Und was kann man eventuell tun, wenn er weiß, andere gültige session-id?
Soweit ich weiß, können Sie sich ganz einfach anmelden, in anderen Völkern-Sitzung, wenn Sie wissen, dass die id, weil die nicht schwer zu Bearbeiten und es ist viel leichter passieren, dass die session-id als url-parameter, vor allem, wenn Sie so etwas wie:

session_id($_GET[sessionid]);

Dank!

InformationsquelleAutor user3722573 | 2014-12-16

  1. 6

    1) Sie sollten sich Fragen, wer entwickelt die Anwendung der red-box-Abdeckung. URL kann sein, was Sie wollen; die Konvention von key=value&key2=value2 ist einfach nur eine Konvention. In diesem Fall, es ist Java, und es allgemein verwendet die Konvention von ;jsessionid=.... für seine SID.

    2) Es ist nicht , dass große deal ist. Normale Benutzer können keine kopieren-einfügen-cookies, wie Sie können kopieren und fügen Sie GET-parameter, aber power-user können machen was Sie wollen (mit Mechanisieren, wget, curl und anderen nicht-browser-Mittel, oder auch browser-Erweiterungen). Und wenn Sie zulassen, dass es für einige Benutzer und zu verhindern, dass für einige, es ist nicht wirklich viel von einer Vorsichtsmaßnahme, ist es? Im Grunde cookie SID wird der Angriff ein wenig schwerer, aber es ist, wie wenn man die Haustür Schlüssel unter der Matte - auf jeden Fall nicht halten Sie Ihre Tür sicher. Cookies sind geteilt zwischen den tabs: wenn eine Website möchte, dass Sie angemeldet sein mit zwei Konten auf einmal, können Sie es nicht mit cookies.

    3) Server-Side-Sicherheit, ja. Eine wirksame Gegenmaßnahme ist die one-time-SIDs (jedes mal, wenn Sie eine Seite besuchen, liest der server die session ab der aktuellen SID, dann startet eine neue Sitzung mit einer neuen SID für den nächsten request). Weniger wirksam aber immer noch eine gute Methode ist die Validierung von anderen Informationen, die für die Konsistenz (z.B. - immer noch die gleiche IP? Immer noch die gleiche browser?)

    4) ja, wenn Sie jemanden kennen, der gültige SID und der server nicht ausreichend Schutz vor session fixation, können Sie "sich" , person. Dies könnte ermöglichen, den Angreifer zu, sagen, zahlen seine Rechnungen mit dem Geld, zum Beispiel.

    Vielen Dank für Eure Antworten. Sie haben wirklich geholfen, das zu verstehen 🙂 kennt Ihr nützliche links über session-Sicherheit und-vor allem - einer-Zeit-SIDs ( wie ich noch nie davon gehört )?
    Sorry, im moment nicht. Google nach "session fixation" und "one-time-cookies".

    InformationsquelleAutor Amadan

  2. 5

    So, @Amadan richtig bedeckt #1 und #4. Aber es ist ein bisschen mehr, braucht Wachstum.

    Verwendung von Session-IDS in einer URL kann ein großes problem sein. Es gibt ein paar Fälle, in denen es kritisch schlecht:

    1. Session Hijacking:

      Wenn ein Benutzer kopieren-fügt eine URL in eine E-Mail.

      In diesem Fall kann der Angreifer einfach die E-Mails Lesen, und stehlen der session-id (und damit die Wiederaufnahme der Sitzung).

      Konnte man teilweise wehren Sie dies, indem Sie session-Lebensdauer kurze und validieren Dinge wie IP-Adressen oder User-Agents in der Sitzung. Beachten Sie, dass keine absolute Sicherheit, Sie machen es "etwas" schwieriger anzugreifen.

    2. Wenn die Verbindung ist immer herabgestuft HTTP.

      Wenn Sie sich nicht mit Http-Strict-Transport-Security (HSTS), dann kann ein Angreifer in der Lage, erfolgreich ein downgrade der Sitzung nur HTTP (via MITM-Angriffs). Wenn der server ist nicht setup perfekt, dies kann dazu führen, die URL zu lecken, an den Angreifer, und daher die Sitzungs-id.

    3. Session-Fixation-Angriffe

      Kann ein Angreifer das Handwerk eine session-id und senden Sie dem Benutzer eine gefälschte link mit session-id. Der Benutzer meldet sich dann in der Seite, und die Sitzung ist nun mit Ihrem Konto.

      Können Sie mildern, indem Sie konsequent die rotierenden session-IDS jedes mal, wenn die Sitzung änderungen (log-in, log-out, privilege upgrade oder downgrade, etc). Aber viele Server die dies nicht tun, und sind daher anfällig für die Fixierung Stil Angriffe.

    Dem Grund, dass die cookie-sessions werden als sicherer, ist nicht, weil Sie schwerer zu Bearbeiten. Es ist, weil Sie mehr gegen-fixation-Attacken (Sie können nicht erstellen Sie eine URL oder link oder Formular oder js oder alles, dass sendet eine betrügerische cookie im Namen des Benutzers).

    Warum die bank nutzt einen URL-parameter? Ich habe zwei Vermutungen:

    1. Weil Sie wollen diejenigen unterstützen, die keine cookies zulassen.

      Ist Seufzer würdig.

    2. Sie es nicht besser wissen.

      Ernst. Wenn es nicht in einem compliance-doc-oder NIST-Empfehlung, dann werden Sie wahrscheinlich tun Sie es nicht. Die Hölle, die dort umgesetzt werden, NIST-Empfehlungen, die als unsicher bekannt sind, aber dennoch gefolgt, weil es in dem schreiben.

    InformationsquelleAutor ircmaxell

  3. 3

    Was ist der nutzen dieser ;?

    Dies ist nur ein query-string-Trennzeichen. & ist nicht der einzige sub-delim in der URL angegebenen Spezifikation (RFC 3986).

    2) Und warum internet-bank, die sicherste Ort im internet, übermittlung von session-id als url-parameter?

    Könnte es sein, dass diese session-ID wird nie verwendet, und dem tatsächlichen Sitzungs-id-Benutzer übergeben wird, in cookies oder POST-Daten zwischen jeder Seite navigiert. Der einzige Weg, um dies zu überprüfen, ist zu versuchen, kopieren Sie die URL in einem anderen browser zu sehen, wenn die Sitzung wieder aufgenommen wird, aber dann wieder Sie können überprüfen werden, Dinge wie User-Agent - nicht wirkliche Sicherheit würde aber abraten, casual-Attacken. Nicht versuchen, diese zu auf ein live-system, Sie haben nicht die Berechtigung, so zu tun als wäre es illegal. Wenn Sie möchten, erfahren Sie mehr über security herunterladen, so etwas wie Hacme Bank und versuchen Sie es auf.

    3) ich denke, dann sollten Sie einige andere Sicherheitsmaßnahmen? Was Sie sein könnten?

    Kein Zweifel, Sie werden, sonst wäre dies eine große Bedrohung für die Sicherheit. Die URL könnte durchgesickert sein in der referer header, wenn es irgendwelche externen links auf der Seite. Die Typen von der Sicherheit einer bank verwendet für Ihre website ist zu groß, um Sie hier aufzulisten, aber Sie sollten die Einhaltung bestimmter Industriestandards wie ISO/IEC 27001, dass die Deckung der Arten von Bedrohungen, dass Ihre Website benötigen würde, um sicher zu sein gegen.

    4) Und was kann man eventuell tun, wenn er weiß, andere gültige session-id? Soweit ich weiß, können Sie sich ganz einfach anmelden, in anderen Völkern-Sitzung, wenn Sie wissen, dass die id, weil die nicht schwer zu Bearbeiten und es ist viel leichter passieren, dass die session-id als url-parameter, vor allem, wenn Sie so etwas wie:

    Als die ID auf dem Bildschirm angezeigt wird es möglich sein könnte, es zu Lesen (obwohl-IDs sind in der Regel lang). Ein realistischer Angriff Session Fixation. Dies ist, wo ein Angreifer kann das Session-ID Ihrer Opfer. Zum Beispiel, senden Sie einen link, der enthält die Angreifer die Session-ID. Wenn das Opfer folgt es und meldet sich dann, als der Angreifer hat in der gleichen Sitzung, Sie angemeldet sind, zu.

    InformationsquelleAutor SilverlightFox

  4. 1

    Speicherung der Session-Informationen in einem cookie oder in der URL sind praktikable Methoden. Eine Kombination kann verwendet werden als
    Sicherheits-session-management und (Server) Session-management sind separate Aspekte:

    Der grundlegende Unterschied ist, dass cookies geteilt werden zwischen browser-Fenstern/tabs, die url nicht.

    Wenn Sie möchten, dass Ihre Benutzer angemeldet sein, wenn die Navigation auf die gleiche Seite in der anderen Registerkarte Freigabe des Sicherheits-session (=ohne ein neues logon-Prozedur), dann cookies sind ein guter Weg.

    Unterscheiden "sessions" pro Registerkarte, und ordnen Sie unterschiedliche server-Sitzungen mit verschiedenen tabs (man Denke an die user laufen zwei "stateful" - Transaktionen in zwei verschiedenen tabs parallel), die Verwaltung einer sessionId auf dem client unterschiedlich sein kann pro Tablette erforderlich ist. Cookies funktioniert hier nicht.

    Indem Sie in der URL ist ein Weg, um sicherzustellen, diese Informationen regelmäßig Hinzugefügt, Anfragen, gefeuert von der Seite (referrer-header). Alternative Methoden erfordern würde, die spezifischen code, fügen Sie diese Informationen ausdrücklich auf jede Anfrage, die mehr arbeiten.

    Sehen Wie unterscheiden sich die Sitzungen in browser-tabs?

    InformationsquelleAutor user6649841

Schreibe einen Kommentar