Zurückgewiesene CSRF Lücke auf facebook.com

Letztens entdeckten wir eine CSRF Lücke in den Hilfeseiten von Facebook. Da die Lücke nicht wirklich kritisch war, wurde diese von Facebooks Security Team zurückgewiesen. Wir wurden von einigen Twitterern gebeten trotzdem darüber zu bloggen.

Die “Sicherheitslücke” war wirklich unkritisch, da kaum bzw. keine Veränderung von Benutzerdaten möglich war, sodass wir Facebooks Entscheidung gelassen aufnehmen. Von daher erwartet keinen außergewöhnlichen Fund :)

Facebook betreibt eigene FAQ/Hilfeseiten, welche man hier finden kann: Facebook FAQ/Hilfe.

Dort gibt es ein Suchfeld im oberen Bereich der Seite. Gibt man dort ein Stichwort ein, so werden einem verschiedene Themenvorschläge in einem Dropdown aufgelistet.

Screenshot des Dropdowns mit Themenvorschlägen

Klickt man nun auf einen dieser Vorschläge, so wird der folgende Request an die Facebookserver geschickt:

1
2
3
4
5
6
7
8
9
10
11
12
13

POST /help/typeahead.php?helpPlatformPath=%2Fhelp%2F HTTP/1.1
Host: www.facebook.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://www.facebook.com/help/
Cookie: [COOKIES]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 216

faq_id=224562897555674&user_query=delete+my+account&normalized_query=delete+my+account+site%3awww.facebook.com%2fhelp%2f+meta%3asearch.helptype%28%22faq%22%29+meta%3asearch.searchable%28%22true%22%29&fb_dtsg=AQCQwq0n

Zurück kommt die folgende Antwort, welche einen auf den entsprechenden FAQ Eintrag (faq_id) weiterleitet.

1
2
3
4
5
6
7
8
9
10

HTTP/1.1 302 forced.302
Location: https://www.facebook.com/help/224562897555674
P3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"
Set-Cookie: _e_0Kyy_2=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.facebook.com; httponly
Set-Cookie: wd=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.facebook.com; httponly
Content-Type: text/html; charset=utf-8
X-FB-Debug: IHqg1vyS/5YzFfEDeZpDtVseUBvVhyrORUnqYjWmfLk=
Date: Mon, 10 Feb 2014 21:53:33 GMT
Connection: keep-alive
Content-Length: 0

Der Parameter namens ”fb_dtsg” ist eines der von Facebook genutzten CSRF Token. Das Token bzw. der Parameter wurde serverseitig nicht überprüft, sodass CSRF Angriffe möglich waren.

Man konnte sogar den Request Body auf einen Parameter reduzieren:

1

faq_id=224562897555674

Da wir leider nicht wissen, ob bzw. wie der Parameter “user_query” in Verbindung mit dem angemeldeten Benutzer gebracht wird, können wir mit der Lücke erstmal nicht viel anfangen. Generell sind Vermutungen aber keine praktikable Lösung.

Wir können zusammenfassen: Wir haben zwar eine CSRF Lücke - mit dieser lässt sich aber kaum Schaden anrichten, da keine direkte Verbindung zu Benutzerdaten besteht. Wir haben trotzdem unser Glück versucht und die Lücke gemeldet. Wie zu erwarten war, kam die folgende Antwort von “Arya”:

1

The token is part of the default CSRF framework that we have for POST requests. It is not present for any particular reason. So it's not a big deal if it's not validated.

Interessant: Warum validiert ein CSRF-Framework die Tokens nicht korrekt? ;)

Timeline:

  • 06.02.2014: Lücke an Facebook gemeldet

  • 06.02.2014: Antwort, das es nicht wirklich kritisch bzw. ein Problem ist

  • 10.02.2014: Veröffentlichung des Blogposts

Das Team der Internetwache.org