Was freut dieses geheime Feld (゜ ∀ ゜)

Ich habe kürzlich das Gefühl, dass dies eingegeben wurde. Ich werde den Prozess aufschreiben, den ich grob versucht habe. Bitte weisen Sie auf Fehler hin.

Was für eine Funktion

Kurz gesagt, GitHub sendet Ihnen die Signatur der Nutzdaten.

Das Ergebnis der Anwendung der JSON-Nutzdaten, die mit diesem Schlüssel an HMAC (Keyed Hash) gesendet werden sollen Es ist ein Mechanismus, der in den HTTP-Header von WebHook eingefügt wird. Das Geheimnis wird nach der Eingabe nicht auf dem GitHub-Bildschirm angezeigt und erscheint danach in den HTTP-Daten nicht mehr roh, so dass dies auch ein wenig sicher ist.

Sie können erneut eingeben

Ich denke, dieser Mechanismus gab es in der Vergangenheit nicht. Wahrscheinlich nicht direkt nach der Erneuerung des WebHook. Wann bist du reingekommen?

Referenz: http://blog.manaten.net/entry/573

Wenn ich mir die obige Seite anschaue, spüre ich die Bedeutung der Aufbewahrung von Informationen. Es gibt kein Passwortfeld, ich habe es selbst in die Abfragezeichenfolge eingefügt. Es war vor einem Jahr.

Was mich glücklich macht

Sie können das Sicherheitsniveau leicht erhöhen.

Sie können grundsätzlich POST an die WebHook-URL senden und keine CSRF-Token einbetten. Jedes Mal, wenn ich in Django `` @ csrf_exempt``` schreibe, sinkt der SAN-Wert, aber es kann nicht geholfen werden.

Derzeit scheint WebHooks Mund in der Lage zu sein, IP-Beschränkungen lose anzuwenden, daher werde ich sie verwenden. Dennoch gibt es Bedenken, dass etwas aus dem bösartigen GitHub-Projekt kommen könnte. Es scheint, dass alle oder eine beträchtliche Menge der gesendeten Informationen getarnt werden können (obwohl ich sie nicht untersucht habe).

Also wollte ich eigentlich einen anderen Schlüssel als die URL. Aber ich möchte die Implementierung nicht selbst schreiben (die Leute auf der obigen Seite schreiben sie selbst, nicht wahr?)

Was für ein Verhalten

Wenn GitHub einen WebHook sendet, konvertiert es die Zeichenfolge in seiner JSON-Nutzlast mit HMAC + sha1 unter Verwendung des Schlüssels in einen 40-stelligen Hash. Wenn Sie also einen HTTP-POST senden, wird eine Zeichenfolge wie `` `sha1 = dd671d65f5aee8c8aba748fd8f0143c10c5ba875``` in den Header eingefügt. Der Server (Sie selbst) erhält die Nutzdaten und ihre "Signatur".

Der Empfänger oder Ihr eigener Server kann die Signatur überprüfen, indem er die mit dem gemeinsamen Schlüssel gesendete JSON-Zeichenfolge in einen Hash mit demselben Algorithmus konvertiert. Wenn die Signatur falsch ist, können Sie eine Warnung an den Administrator senden, da dies in Ordnung ist.

Vielleicht ist es nicht allzu schwierig, wenn es sich um eine Skriptsprache mit einem OpenSSL-Wrapper handelt, und da die Algorithmen selbst für HMAC und sha1 normal sind, können Sie sie wahrscheinlich mit der Shell überprüfen (was bedeutet, dass Sie kein "sha1sum" verwenden. Ich werde es nicht versuchen, ich werde es nie versuchen).

Es scheint, dass die Bibliothek genauso verwendet wird wie in der (anscheinend) Ruby-Implementierung, die von GitHub selbst verwendet wird.

https://github.com/github/github-services/blob/f3bb3dd780feb6318c42b2db064ed6d481b70a1f/lib/service/http_helper.rb#L77
http://ruby-doc.org/stdlib-2.1.0/libdoc/openssl/rdoc/OpenSSL/HMAC.html

Es ist auch in Python. Ein bewusster Python-Geschmack.

http://docs.python.jp/2.7/library/hmac.html
http://docs.python.jp/2.7/library/hashlib.html

Verwenden wir es mit Python (+ Django)

Um die JSON-Nutzdaten zu empfangen, bereiten Sie zwei Arten von Untertassen entsprechend dem Inhaltstyp auf der Serverseite vor. Dies an sich ist unabhängig von dieser Geschichte etwas zu implementieren.

Außerdem wird die gesendete Zeichenfolge über "request.META.get (" HTTP_X_HUB_SIGNATURE ") abgerufen.

Wenn es leer ist, gibt es kein Passwort. Wenn es nicht leer ist, fügen Sie die unformatierte Nutzlastzeichenfolge in hmac / hashlib.sha1 ein und generieren Sie selbst einen verschlüsselten Hash, um festzustellen, ob er identisch ist.

import hashlib
import hmac

...

    if content_type == 'application/json':
        payload = request.body
    else:
        payload = request.POST.get('payload')
    signature = request.META.get('HTTP_X_HUB_SIGNATURE')
    if signature:
        hasher = hmac.new(secret, payload, hashlib.sha1)
        logger.debug('Signature : {}'.format(signature))
        logger.debug('Calculated: sha1={}'.format(hasher.hexdigest()))

Ich finde das gut, weil die Berechnungsergebnisse korrekt sind.

Ich bin mir jedoch nicht sicher, ob die Codierung und der Zeilenvorschubcode jedes Mal übereinstimmen. Wenn Sie Details haben, kommentieren Sie bitte.

Referenz
- https://github.com/github/github-services/blob/f3bb3dd780feb6318c42b2db064ed6d481b70a1f/lib/service/http_helper.rb#L77

Bonus

Ich möchte mich nicht an den Rohschlüssel auf der Serverseite erinnern, aber wenn Sie einen einfachen und guten Weg kennen, lassen Sie es mich bitte wissen. Ich frage mich, ob es einfach ist, die mit Django serialisierten zu speichern ...

Nachtrag: Beim Testen mit django.test.Client

Wenn die Nutzlast selbst als Zeichenfolge bereit ist, müssen Sie nur das oben generierte Ergebnis in das Header-Äquivalent schrauben. In Django 1.6.5 kann es wie folgt integriert werden.

        hasher = hmac.new('TestSecret', payload_str, hashlib.sha1)
        response = self.client.post(
            url, data={'payload': payload_str},
            HTTP_X_HUB_SIGNATURE='sha1={}'.format(hasher.hexdigest()))

Es ist Django 1.6.5, aber wenn Sie "application / x-www-form-urlencoded" festlegen, das auf GitHub als content_type to Client ausgewählt werden kann, können Sie keine POST-Daten mit response.POST.get ('...') empfangen. Es scheint ein Problem zu geben. Über content_type Ermöglichen wir den Empfang von mehrteiligen / Formulardaten auch auf der Serverseite. GitHub kann sich bald sehr ändern.

[GO] Spielen Sie mit dem Passwortmechanismus von GitHub Webhook und Python