MeinKonto: Linkangabe

[larsUE]

Die Stadt Zürich betreibt MeinKonto einerseits als OIDC Anbindung, andererseits auch als gesamthaftes E-Services-Portal.

Dort ist z.B. «Mitwirken an Zürichs Zukunft» auch verlinkt, allerdings mit einem fehlerhaften Link (Hinterlegt ist: https://mitwirken.stadt-zuerich.ch/users/auth/oidc?locale=de und man landet auf einer Ups-Seite (ohne Redirect auf eine schöne Seite). Es soll auf Decidim so weitergeleitet werden, dass man gleich eingeloggt ist (und weil man bereits bei MeinKonto eingeloggt ist, sollte dies auch funktionieren). Welchen Link müssen sie angeben, um direkt angemeldet zu sein?

[carlobeltrame]

Hm, schwierig. Der Link wird tatsächlich so von Decidim angeboten, aber man kann ihn nicht einfach mit dem Browser besuchen (GET Request) sondern muss via einen Button (eigentlich via das Absenden eines kleinen Formulars, resultiert in einem POST Request) ausgelöst werden.

Grund dafür ist ein Security Feature. Wir könnten GET Requests via OmniAuth.config.allowed_request_methods erlauben, aber dann würde folgende Warnung in den Logs auftauchen:

You are using GET as an allowed request method for OmniAuth. This may leave you open to CSRF attacks. As of v2.0.0, OmniAuth by default allows only POST to its own routes. You should review the following resources to guide your mitigation:
https://github.com/omniauth/omniauth/wiki/Resolving-CVE-2015-9284
omniauth/omniauth#960
https://nvd.nist.gov/vuln/detail/CVE-2015-9284
omniauth/omniauth#809
You can ignore this warning by setting:
OmniAuth.config.silence_get_warning = true

[larsUE]

@carlobeltrame hierzu eine Nachfrage: Wenn die Stadt also im MeinKonto einen POST-Request abschickt, statt nur einen Link zu hinterlegen, würde dies funktionieren?

[larsUE]

Weitere Beobachtung, die ich mir nicht ganz erklären kann:

Wenn ich auf der Sign-In Maske auf "Mit «Mein Konto» anmelden" klicke, führt dies auf folgenden Link: https://mitwirken.stadt-zuerich.ch/users/auth/oidc –> Funktioniert, ich werde weitergeleitet

Auf Mein Konto ist derzeit folgender Link hinterlegt: https://mitwirken.stadt-zuerich.ch/users/auth/oidc –> Dieser führt auf eine 404-Seite. Die Links sind doch identisch, oder?

[carlobeltrame]

Der Button auf der Sign-In Maske ist eben nicht einfach ein Link. Dieser Button macht intern dann eben einen POST Request. Es sieht nur im Browser beim draufzeigen wie ein Link aus, aber der Klick wird abgefangen und ein POST Request wird ausgelöst.

Es wäre auch nicht möglich, von Mein Konto aus einen POST Request abzusetzen. Grund ist auch wieder die CSRF-Protection. Jedes Mal wenn die Decidim-Seite geladen wird, wird ein kleines temporäres "Secret", das sogenannte CSRF Token generiert, und dieses wird dann beim POST Request mitgeschickt. Rails überprüft dann, ob das CSRF Token vor kurzem so ausgestellt wurde.

Dieses CSRF Token ist genau der Grund, warum ein GET Request als vulnerable und ein POST Request (mit dem ein vor kurzem ausgestelltes CSRF Token mitgesendet wird) als sicher angesehen wird.

Im Mail habe ich noch gelesen "es kann doch nicht sein dass ein GET Request nicht möglich ist". Ich kenne es von anderen OAuth Logins auch so dass es einen direkten GET-zugänglichen Link gibt, mit dem man den User direkt einloggen kann. Aber bei Omniauth wurde 2015 exakt das als Security Vulnerability gemeldet, und ist daher seit dann standardmässig nicht mehr aktiviert. Ich würde allen bei der Stadt die daran Zweifel haben sehr empfehlen, den CVE sehr genau durchzulesen und zu begründen, warum das in unserem Fall (Omniauth + Rails + Decidim + Mein Konto) kein Problem sein dürfte. Ich selber habe mich nicht genügend vertieft dass ich mit Zuversicht sagen könnte, der CVE betrifft uns nicht.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-9284

The request phase of the OmniAuth Ruby gem (1.9.1 and earlier) is vulnerable to Cross-Site Request Forgery when used as part of the Ruby on Rails framework, allowing accounts to be connected without user intent, user interaction, or feedback to the user. This permits a secondary account to be able to sign into the web application as the primary account.

Was eine CSRF Attacke genau ist, ist hier beschrieben: https://owasp.org/www-community/attacks/csrf

[larsUE]

@carlobeltrame danke! Wie per Mail erwähnt leite ich das weiter. Wenn wir nun auf eine aktuelle Version des Gems wären (weiss nicht, was derzeit bei uns installiert ist), wäre es dann möglich GET-Requests zu aktivieren? Der CVE gilt ja nur bis zur Gem Version 1.9.1. und früher.

[carlobeltrame]

Wir haben aktuell omniauth in der Version 2.1.1 installiert.

omniauth/omniauth#960 (comment)

The vulnerable by default configuration has been removed in the v2.0.0 release

Die Versionen 2.0.0 und später sind nur nicht mehr vulnerable, weil sie die GET Requests per default ausgeschaltet haben. Der Fix nach 1.9.1 war also nicht, dass GET Requests auf magische Weise sicher gemacht wurden, sondern dass GET Requests standardmässig deaktiviert wurden und eine grosse Warnung ausgespuckt wird, wenn man sie wieder zu aktivieren versucht. Würden wir GET Requests wieder aktivieren, dann wäre es wieder vulnerable (soweit ich verstehe).

[larsUE]

Weitere Rückfrage. @carlobeltrame, was denkst du?

Könnt Ihr nicht eine weitere Seite https://mitwirken.stadt-zuerich.ch/users/sign_in_2 auf Eurer Plattform einrichten, die nichts anderes macht als einen Redirect auf https://mitwirken.stadt-zuerich.ch/users/auth/oidc (das käme einer Simulation des Endbenutzers gleich der auf den Knopf "Mit Mein Konto anmelden" bei Euch gleich käme und die ganze OIDC Geschichte läuft doch dann sicher über die Backchannel ab? Was spricht dagegen?

[carlobeltrame]

Das käme nicht nur vom Verhalten her sondern auch technisch gleich mit einer Umgehung des forcierten POST-Requests und der CSRF Protection. Dagegen spricht wie gesagt, dass der CVE exakt diese Operation als gefährlich gemeldet hat. Bisher habe ich noch nicht genügend Hintergrundwissen, um den CVE so grundlegend zu hinterfragen und zu beurteilen ob der uns nicht betrifft. Soll ich da Zeit investieren um ein fundierteres Wissen in diesem Bereich aufzubauen, und wie viel Zeit habe ich? (Das könnte einige Stunden bis wenige Tage dauern.) Solange ich das nicht mache, ist diese Anfrage gleichzusetzen mit der Anfrage, ganz bewusst eine Sicherheitslücke in die Mitwirken-Plattform einzuführen.

Das Problem ist nicht, dass wir dieses Verhalten von Omniauth nicht anpassen könnten, Omniauth bietet auch eine offizielle Option (siehe hier im Kapitel GET) um wieder zum alten, verwundbaren Verhalten von 1.9.1 zurückzugehen. Es bringt nichts, hier eine separate Seite aufzubauen. Grundsätzlich ist laut CVE verwundbar, wer auf seiner Seite einen OAuth/OIDC Login hat welcher via einen GET Request automatisiert ausgelöst werden kann.

Siehe auch:

If the use of GET requests to /auth/:provider is essential for your application (for example, if you are ever redirecting to /auth/:provider as part of an authentication process), then you will need to put together a more involved solution for your specific needs.

https://github.com/omniauth/omniauth/wiki/Resolving-CVE-2015-9284

Auch OWASP empfiehlt explizit, das nicht zu tun:

Do not use GET requests for state changing operations.
If for any reason you do it, protect those resources against CSRF

https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#cross-site-request-forgery-prevention-cheat-sheet

Eine GET-zugängliche Seite welche automatisiert eine state changing operation (Login mit Mein Konto) auslöst, ist selber eine state changing operation.