GitHub verlangt vor Token- und Webhook-Änderungen eine frische IdP-Prüfung
Victoria Shinder2 Min. LesezeitGitHub hat "Proof of Presence" eingeführt, eine öffentliche Vorschau, mit der Unternehmen vor kritischen Aktionen eine frische interaktive Prüfung verlangen können. Laut Changelog vom 24. September erweitert sie GitHubs bestehenden Sudo-Modus: Will ein Mitglied ein Token erzeugen, Webhooks bearbeiten, Sicherheitseinstellungen der Organisation ändern oder Wiederherstellungscodes ansehen, leitet GitHub es zum Identitätsanbieter um, damit es eine Richtlinie erfüllt, und lässt die Aktion nur zu, wenn es mit dem Nachweis zurückkommt.
Administratoren wählen zwischen zwei Anforderungen: erneute Anmeldung, die je nach IdP-Richtlinie auch ein Passwort erfüllen kann, oder MFA mit einer zusätzlichen Mehrfaktor-Prüfung, etwa per Authenticator-App oder Biometrie. Weil die Prüfung beim Identitätsanbieter läuft, können Unternehmen eigene Richtlinien anwenden, auch zur Gerätekonformität. Nach einer erfolgreichen Prüfung kann das Mitglied in dieser Browsersitzung zwei Stunden lang weitere kritische Aktionen ausführen, wie im Sudo-Modus. Die Pflicht vor dem Zusammenführen von Pull-Requests soll bald folgen.
Der Umfang der Vorschau ist eng. Sie gilt nur für Enterprise-Managed-Users-Unternehmen auf github.com und für GitHub Enterprise Cloud mit Datenresidenz und nur, wenn Microsoft Entra ID der SSO-Identitätsanbieter ist, per SAML oder OIDC.
Als Grund nennt GitHub jüngste Lieferkettenangriffe, bei denen gestohlene Session-Cookies und langlebige Tokens immer wieder auftauchten. Proof of Presence bestätige, dass im Moment der Aktion eine berechtigte Person handelt, nicht nur, dass eine gültige Sitzung oder ein Token benutzt wurde; zudem helfe es regulierten Kunden, Pflichten zur frischen Anmeldung vor sensiblen Vorgängen zu erfüllen.
Was das bedeutet
Ein Session-Cookie beweist, dass sich irgendwann jemand angemeldet hat; es sagt nichts darüber, wer es gerade hält. Für die meisten Aktionen ist das ein vertretbares Risiko. Für das Erzeugen von Tokens oder das Ändern von Webhooks - genau die Schritte, mit denen sich ein Angreifer nach einem Sitzungsdiebstahl festsetzt - ist es das nicht, und eine frische Prüfung beim Identitätsanbieter unterbricht die Kette vom gestohlenen Cookie zum dauerhaften Zugang.
Zu beachten sind das Zwei-Stunden-Fenster und der enge Umfang der Vorschau. Ein Angreifer mit einer Sitzung, die nach einer erfolgreichen Prüfung weniger als zwei Stunden alt ist, kommt weiterhin durch, und Unternehmen mit anderen Identitätsanbietern oder ohne verwaltete Nutzer können die Funktion noch nicht einschalten.