Skip to main content

Diese Version von GitHub Enterprise Server wird eingestellt am 2023-12-20. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise Server. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Bewährte Methoden für die Verwendung von Webhooks

Wende diese bewährten Methoden an, um die Sicherheit und Leistung bei der Verwendung von Webhooks zu verbessern.

Abonnieren der Mindestanzahl von Ereignissen

Abonniere nur die Webhookereignisse, die deine App benötigt. Dadurch wird die Belastung deines Servers reduziert. Weitere Informationen zum Abonnieren von Ereignissen finden Sie unter „Erstellen von Webhooks“ und „Bearbeiten von Webhooks“.

Verwenden eines Webhookgeheimnisses

Du solltest ein Webhook-Geheimnis für deinen Webhook festlegen und überprüfen, ob die Signatur der einzelnen Webhook-Übermittlungen mit dem Geheimnis übereinstimmt. Dadurch wird sichergestellt, dass die Webhook-Übermittlung aus GitHub stammt. Weitere Informationen findest du unter Validierung von Webhook-Zustellung.

Das Webhook-Geheimnis sollte aus einer zufälligen Textzeichenfolge mit hoher Entropie bestehen. Du solltest dein Webhook-Geheimnis sicher und so speichern, dass dein Server darauf zugreifen kann.

Verwenden der HTTPS- und SSL-Überprüfung

Du solltest sicherstellen, dass dein Server eine HTTPS-Verbindung verwendet. Standardmäßig überprüft GitHub SSL-Zertifikate beim Bereitstellen von Webhooks. GitHub empfiehlt, die SSL-Überprüfung aktiviert zu lassen.

Antworte innerhalb von 30 Sekunden

Dein Server sollte mit einer 2XX-Antwort innerhalb von 30 Sekunden nach Erhalt einer Webhook-Übermittlung antworten. Wenn die Serverantwort länger dauert, beendet GitHub die Verbindung und kategorisiert die Zustellung als Fehler.

Um zeitnah zu antworten, solltest du eine Warteschlange einrichten, um Webhook-Nutzlasten asynchron zu verarbeiten. Dein Server kann antworten, wenn er den Webhook empfängt, und dann die Nutzlast im Hintergrund verarbeiten, ohne zukünftige Webhook-Zustellungen zu blockieren. Beispielsweise kannst du Dienste wie Hookdeck oder Bibliotheken wie Resque (Ruby), RQ (Python) oder RabbitMQ (Java) verwenden.

Überprüfen von Ereignistyp und Aktion vor der Verarbeitung des Ereignisses

Es gibt mehrere Webhook-Ereignistypen, von denen viele mehrere Aktionsarten haben können. GitHub fügt kontinuierlich neue Ereignistypen und neue Aktionen zu vorhandenen Ereignistypen hinzu. Deine Anwendung sollte den Ereignistyp und die Aktion von Webhook-Nutzdaten überprüfen, bevor die Nutzdaten verarbeitet werden. Zur Ermittlung des Ereignistyps kannst du den Anforderungsheader X-GitHub-Event verwenden. Um den Aktionstyp zu ermitteln, kannst du den Schlüssel der obersten Ebene action in den Ereignisnutzdaten verwenden.

Erneute Zustellung bei Fehlschlagen der vorherigen Zustellung

Wenn dein Server ausfällt, solltest du verpasste Webhooks erneut senden, sobald der Server gesichert ist. Weitere Informationen findest du unter Erneutes Zustellen von Webhooks.

Verwenden Sie den X-GitHub-Delivery-Header.

Bei einem Replay-Angriff fängt ein schlechter Angreifer eine Webhook-Zustellung ab und sendet die Zustellung erneut. Um vor Replay-Angriffen zu schützen, können Sie den X-GitHub-Delivery-Header verwenden, um sicherzustellen, dass jede Zustellung eindeutig ist.

Hinweis: Wenn Sie eine Neuzustellung anfordern, ist der X-GitHub-Delivery-Header mit dem der ursprünglichen Zustellung identisch.

Weiterführende Themen