Session ID in URL rewrite

Was ist Session ID in URL rewrite?

Bei dem Session ID in URL rewrite verwendet die Webanwendung die GET-Methode zur Verarbeitung von Anfragen, die vertrauliche Informationen enthalten. Diese Informationen können durch den Verlauf des Browsers, über Referrer, Webprotokolle und andere Quellen verfügbar gemacht werden.

Beschreibung

Sitzungen können mit zwei zugrunde liegenden Mechanismen implementiert werden:

• Cookies
• URL-Umschreiben

Beim Umschreiben von URLs wird eine Sitzungs-ID in die URL eingefügt.

Laut OWASP birgt das Umschreiben von URLs erhebliche Sicherheitsrisiken. Die allgemeine Idee ist, dass die Sitzungs-ID in der URL angezeigt wird und von Dritten leicht gesehen werden kann:

Endnutzer kopieren und fügen solche Links häufig ein, ohne zu wissen, dass die angefügte Sitzungs-ID ihre Sicherheit gefährdet. Server-Protokolldateien zeichnen normalerweise den ‘Referrer’-Header auf, der Sitzungs-IDs im Protokoll aufzeichnet.

Dieser Scanner sucht nach der Existenz von Sitzungs-Token-Typ-Parametern, die in die URL umgeschrieben wurden. Um flachen Meldungen vorzubeugen, überprüft der Scanner die Länge der Token-Werte. Wenn der Wert des Parameters 8 Zeichen nicht überschreitet, dann wird der Parameter ignoriert (z.B.: survey?sld=5 würde nicht als gefährdet gekennzeichnet werden).

Haben Dritte Zugriff auf Sitzungs-IDs, bedeutet dies, dass private Benutzerinformationen für Angriffe weit offen sind. URL Rewrite gilt als eine gefährliche Praxis und sollte vermieden werden. Werden stattdessen Cookies verwendet, wird die Sitzungs-ID nicht in der URL angezeigt.

Lösung

Wenn sensible Informationen gesendet werden, wird die Verwendung der POST-Methode empfohlen (z. B. Anmeldeformular).

Optionen zum Verwalten des URL Rewrite sind:

• Auf Serverebene deaktivieren
• Deaktivierung auf Anwendungsebene. Eine attraktive Option ist ein Servlet-Filter. Der Filter umschließt das Antwortobjekt mit einer alternativen Version, wodurch response.encodeURL (String) und verwandte Methoden in “no-operations” geändert werden. (Das WEB4J-Tool enthält einen solchen Filter.)
• Für öffentliche Websites muss entscheiden werden, ob es in jedem Fall akzeptabel ist, dass Browser Cookies aktiviert lassen müssen.
  Andere Informationen

Häufig werden Website Cookies von Benutzern deaktiviert, um ihre Privatsphäre zu schützen. In Anbetracht der Ernsthaftigkeit des Sicherheitsproblems, kann das Deaktivieren von Cookies für den Datenschutz der Nutzer in der Tat viel schlimmer sein. Das Risiko der Gefährdung persönlicher Daten durch Session-Hijacking scheint die Bedenken hinsichtlich der Verfolgung persönlicher Browsing-Verlauf bei weitem zu überwiegen.

Allgemeiner Schwachstellen-Datenbanklink

https://cwe.mitre.org/data/definitions/598.html

https://cwe.mitre.org/data/definitions/200.html