Cookies sind aus den heutigen Webanwendungen nicht mehr wegzudenken. Wenn es allerdings einem Angreifer gelingt, ein Session-Cookie eines Benutzers zu stehlen, beispielsweise durch Ausnutzen einer XSS (Cross-Site-Scripting)-Schwachstelle oder Abhören einer unverschlüsselten HTTP-Verbindung, kann er die gültige Benutzersitzung potenziell übernehmen. In dieser Position könnte der Angreifer sensible Anwendungsdaten in seinen Besitz bringen oder andere Aktionen ausführen, die dem Unternehmen und seinen Benutzern Schaden zufügen.
Die Lösung Qualys-Web-Application-Scanning meldet, wenn sie ein Cookie findet, das über einen HTTPS-Kanal ausgeliefert wird, ohne dass der Parameter „secure“ gesetzt ist. Diese Funktion hilft zu überprüfen, ob die Programmierverfahren korrekt sind – bei einzelnen Webanwendungen und Entwicklern wie auch im gesamten Unternehmen. Cookies, die mit dem Attribut „secure“ markiert sind, werden niemals über eine unverschlüsselte Verbindung (also ohne HTTPS) gesendet. Dies trägt dazu bei, die Cookies vor dem Zugriff eines eventuellen Angreifers zu schützen, der den Netzwerkverkehr ausspäht.
Qualys-WAS unterstützt bei Cookies ohne „secure“-Flag die folgenden Erkennungsarten (QIDs):
QID 150122: Diese QID wird gemeldet, wenn ein Standard-Cookie via HTTPS übertragen wird, ohne dass das Attribut „secure“ gesetzt ist.
QID 150161: Wenn ein Session-Cookie via HTTPS übertragen wird, ohne dass das Attribut „secure“ gesetzt ist, wird QID 150161 gemeldet. Hier einige gebräuchliche Bezeichnungen von Session-Cookies, die zur Sitzungsverwaltung dienen:
JSESSIONID bei Java-basierten Webanwendungen.
ASP.NET_SessionId bei Microsoft ASP.NET-Webanwendungen.
PHPSESSID bei PHP-basierten Webanwendungen.
QID 150120: Diese QID wird gemeldet, wenn ein Session-Cookie mit der Authentifizierung im Zusammenhang steht und via HTTPS übertragen wird, ohne dass das Attribut „secure“ gesetzt ist. Die Session-Cookies, die mit dieser QID gemeldet werden, unterscheiden sich deutlich von normalen Session-Cookies, da sie dazu dienen, die authentifizierte Sitzung eines Benutzers bei einer Webanwendung zu validieren. Wenn im authentifizierten Zustand auf eine Webressource zugegriffen wird, dient das Cookie „PHPSESSID“ dazu, die authentifizierte Sitzung zu validieren. Wird das Cookie ohne „secure“-Flag via HTTPS gesendet, wird für das Cookie die QID 150120 gemeldet. Beim Zugriff auf Web-Ressourcen im nicht authentifizierten Zustand wird das Cookie „PHPSESSID“ dagegen lediglich eingesetzt, um eine Sitzung über mehrere Anfragen hinweg aufrechtzuerhalten (in diesem Fall würde die QID 150161 gemeldet werden).
Nicht-sensible Cookies
Einige Cookies, die eine Webanwendung setzt, sind möglicherweise nicht sensibel und stellen somit kein Risiko dar, wenn sie kompromittiert werden. Qualys-WAS wird jedoch eventuell auch bei solchen Cookies auf ein fehlendes „secure“-Flag hinweisen und dazu eine der oben aufgeführten QIDs melden.
Ein Beispiel für ein nicht-sensibles Cookie wäre ein „Sprache“-Cookie, das dafür sorgt, dass die vom Benutzer gewünschte Displaysprache beibehalten wird (z. B. Englisch oder Deutsch). Wenn eine Webanwendung dieses Cookie ohne das Attribut „secure“ setzt, ist das kein Problem, da es keine Auswirkungen auf die Sicherheit hat. Solche Ergebnisse können mithilfe der Option „Ignorieren“ in Qualys WAS leicht übersprungen werden. Weitere Einzelheiten zum Ignorieren einer Schwachstelle finden Sie in der WAS-Online-Hilfe.
Hintergrund: Was sind eigentlich Cookies?
Ein Cookie ist ein kleines Datenpaket, das eine Webanwendung an Ihren Webbrowser sendet. Der Browser kann es speichern und bei der nächsten HTTP-Anfrage an dieselbe Webanwendung zurücksenden.
Cookies werden als Name=Wert-Paare gesetzt und gespeichert. Je nach Art der Verbindung zum Server kann der Browser die Cookies bei späteren Anfragen an den Webserver senden oder auch nicht. Die Cookies werden von der serverseitigen Webanwendung verwendet, um den Benutzer zu identifizieren und seinen Status und seine Einstellungen zu bestimmen. Eine Webanwendung kann in einer HTTP-Antwort auch mehrere, durch Strichpunkte getrennte Cookies setzen.
Überwiegend werden Cookies als Authentifizierungstoken, zur Sitzungsvalidierung und als temporärer Datencontainer für Webanwendungen eingesetzt. Wenn eine Webanwendung bei der Kommunikation mit den Clients ein zustandsloses Protokoll wie HTTP nutzt, muss sie dennoch eine Möglichkeit haben, einen Zustand über mehrere Zugriffe hinweg beizubehalten. Cookies ermöglichen es, eine Interaktion zwischen Client und Webserver aufrechtzuerhalten, die aus zahlreichen Anfragen und Antworten bestehen kann.
Wie können Cookies zum Angriffsvektor werden?
Cookies dienen zur Authentifizierung von Webanwendungen und zur Sitzungsverwaltung. Wenn Angreifer Session-Cookies in ihren Besitz bringen können, indem sie zum Beispiel eine Cross-Site-Scripting-Schwachstelle ausnutzen oder eine unverschlüsselte Sitzung (d. h. HTTP) ausspähen, dann können sie diese Cookies missbrauchen, um eine legitime Sitzung des betroffenen Benutzers zu übernehmen.
Ferner dienen Cookies dazu, den Status über mehrere Anfragen desselben Benutzers hinweg aufrechtzuerhalten. Wenn ein Angreifer auf die Cookies zugreifen und deren Werte manipulieren kann, ist es möglich, dass dies zu einer schlechten Performance der Webanwendung führt.
Da viele Cookies sensibel sind, müssen sie zum Schutz der enthaltenen Informationen über eine verschlüsselte Verbindung übertragen werden.
Wie kann dafür gesorgt werden, dass Cookies sicher sind?
Um zu gewährleisten, dass alle Cookies über geschützte Verbindungen gesendet werden, sollte für jedes Cookie das Attribut „secure“ gesetzt werden.
Dieses Attribut zwingt die Browser, das Cookie nur dann zu senden, wenn die Anfrage via HTTPS übertragen wird.
Beispiele
Nachfolgend sehen Sie einen PHP-Codeschnipsel und die entsprechende HTTP-Anfrage und -Antwort. Dieses Beispiel zeigt, wie eine Webanwendung ein Cookie unsachgemäß setzen kann – das Attribut „secure“ fehlt.
setcookie(„LamCookie“, „123“, time()+3600, „/“, „example.com“, 0, 1);
Im folgenden PHP-Code-Ausschnitt ist das Attribut „secure“ dagegen ordnungsgemäß gesetzt. Beachten Sie bitte, dass das sechste Argument, das an setcookie() übergeben wird, eine „1“ ist, wodurch das Cookie „TestCookie“ auf „secure“ gesetzt wird.
setcookie(„TestCookie“, „DummyValue“, time()+3600, „/“, „example.com“, 1, 1);
So setzen Sie ein Cookie auf „secure“
Nachfolgend finden Sie einige Beispiele aus verschiedenen Programmiersprachen, die zeigen, wie ein Cookie in der Antwort auf „secure“ gesetzt werden kann:
In JSP
final Cookie cookie=new Cookie(„TestCookie“, „12345678“);cookie.setMaxAge(0);cookie.setPath(„/“);cookie.setSecure(true);
In ASP.Net
public HttpResponseMessage Get( ){ var resp = new HttpResponseMessage(); var cookie = new CookieHeaderValue(„TestCookie“, „12345“); cookie.Expires = DateTimeOffset.Now.AddDays(1); cookie.Domain = Request.RequestUri.Host; cookie.Path = „/“; cookie.secure = true; resp.Headers.AddCookies(new CookieHeaderValue[] { cookie }); return resp;}
Von Bala Salunke, Senior Software Engineer bei Qualys
#Netzpalaver #Qualys
