Die Idee, dass Nutzer ihr eigenes Konto in ein Unternehmen mitbringen können, funktioniert auf der Website selbst einigermaßen, verhindert aber nicht, dass beim Login einer App über GitHub die Organisationsmitgliedschaft ausgelesen wird
Eine SAML-Sitzung ist nur dann erforderlich, wenn Daten über ein vom Nutzer erhaltenes Token abgerufen werden
SAST-Tools verwenden fast immer App-Instanz-Tokens und zeigen den Code jedem an, der ein GitHub-Konto hat
Tailscale hat dieses Problem gelöst, Sonarcloud bat jedoch darum, es geheim zu halten, und GitHub antwortete einige Wochen später, dass dieses Verhalten so erwartet gewesen sei
Das Melden von Sicherheitsbugs ist eine undankbare Aufgabe
Ich musste vor Kurzem SAML implementieren, und diese Überschrift überrascht mich überhaupt nicht
Die SAML-Spezifikation selbst ist vernünftig, basiert aber auf XML-Signaturen und XML-Kanonisierung und ist dadurch extrem komplex
Nur ein Komitee kann solche widersprüchlichen Ideen zusammenbringen
SAML, oder allgemeiner XML-DSIG, ist das schlimmste noch allgemein verwendete Sicherheitsprotokoll
Man sollte alles Nötige tun, um auf OAuth umzusteigen
Ich würde mich beim Launch eines neuen Produkts nicht darauf verlassen
Wenn es keinen echten Durchbruch bei formaler Verifikation gibt, werden DSIG-Schwachstellen weder die letzten noch die schlimmsten gewesen sein
Man sollte REXML nicht verwenden
Es parst bereitwillig fehlerhaftes XML und verursacht dadurch endlose Probleme
XML mit regulären Ausdrücken zu parsen, ist ein Anti-Pattern
Projekte haben Nokogiri nicht wegen der Performance verwendet, sondern wegen der Korrektheit
Großartiger Artikel
Danke an ahacker1 für die Sicherheitsarbeit an SAML-Implementierungen
WorkOS hat einen Artikel über die Zusammenarbeit mit ahacker1 veröffentlicht
In GitLab wurde eine Schwachstelle gefunden und dem Security-Team gemeldet
GitLab hat sie behoben
Der Artikel von Latacora aus dem Jahr 2019 über das Signieren von JSON-Objekten
Bäume zu verschachteln und zu signieren ist schwierig
Es ist einfacher, die Nachricht als Rohstring zu behalten und zu signieren
Die Schlussfolgerung, dass man einfacher die Stelle finden sollte, an der eine Signatur sein muss
Man sollte kein allgemeines XPath verwenden, das Signaturen an unerwarteten Stellen findet
Es ist ärgerlich, wenn ein Blogbeitrag eine Schwachstelle erklärt, aber die relevanten Parser-Unterschiede auslässt
Das ist, als würde man den Einstieg einer Geschichte schreiben und den Höhepunkt weglassen
Ich habe gerade zum ersten Mal die technischen Details von XML-Signaturen gelesen, und mir schwirrt der Kopf
Ich frage mich, ob es einen nicht-legacybedingten Grund gibt, statt SAML nicht die Public-Key-authentifizierte Verschlüsselung crypto_box von libsodium zu verwenden
Ich frage mich, ob bei der Verwendung von libsodiums crypto_box und Golangs x/crypto/nacl/box ein nicht nur theoretisches Risiko von Parser-Unterschieden besteht
1 Kommentare
Hacker-News-Kommentare
GitHubs SAML-Implementierung ist nutzlos
Ich musste vor Kurzem SAML implementieren, und diese Überschrift überrascht mich überhaupt nicht
SAML, oder allgemeiner XML-DSIG, ist das schlimmste noch allgemein verwendete Sicherheitsprotokoll
Man sollte REXML nicht verwenden
Großartiger Artikel
In GitLab wurde eine Schwachstelle gefunden und dem Security-Team gemeldet
Der Artikel von Latacora aus dem Jahr 2019 über das Signieren von JSON-Objekten
Die Schlussfolgerung, dass man einfacher die Stelle finden sollte, an der eine Signatur sein muss
Es ist ärgerlich, wenn ein Blogbeitrag eine Schwachstelle erklärt, aber die relevanten Parser-Unterschiede auslässt
Ich habe gerade zum ersten Mal die technischen Details von XML-Signaturen gelesen, und mir schwirrt der Kopf
crypto_boxvon libsodium zu verwendencrypto_boxund Golangsx/crypto/nacl/boxein nicht nur theoretisches Risiko von Parser-Unterschieden besteht