안전한 코드에 대한 통찰

Shrewd 조직은 인프라 개념을 코드로 받아들이고 있으며 응용 프로그램을 빌드하는 외부에서도 보안 코드를 만드는 데 상당한 기여를 할 수있는 개발자입니다. 처음에는 여행하기에 긴 길로 보일 수 있지만, 여행은 동료들 사이에서 눈에 띄는 가치가 있습니다.

최신 코더 정복 보안 시리즈의 다음 장에서 시작하기 전에 중요한 데이터 저장소 취약점에 대한 게임화된 과제를 해결하도록 초대하고 싶습니다. 지금 플레이하고 Kubernetes, 테라폼, Ansible, Docker 또는 CloudFormation 중에서 선택합니다.

어땠나요? 지식에 몇 가지 작업이 필요한 경우 다음을 읽으십시오.

요즘에는 암호, 개인 정보 및 재무 기록과 같은 중요한 데이터가 쉬어지는 동안 사이버 보안 방어의 초석입니다. 여러 면에서 마지막 방어선이자 최고의 보호 수단 중 하나로 작용합니다. 공격자가 다른 방어를 뚫고 중요한 파일을 얻을 수 있더라도 제대로 해시되고 저장되는 한 그다지 좋은 것은 되지 않기 때문입니다.

또한 암호화된 파일에 네트워크의 나머지 부분과 별도의 키 또는 암호를 가질 수 있으므로 악의적인 내부자에 대한 견고한 보조 보호 역할을 합니다. 이 경우 시스템 관리자 나 관리자의 자격 증명을 손상 한 해커와 같은 사람이 보호 된 디렉터리로 탐색 할 수 있지만 암호화 키가 다른 곳에서 유지되는 경우 암호화 된 파일의 잠금을 해제 할 수 없습니다.

물론 모든 암호화 보호 방법은 가장 강력한 컴퓨터로도 손상될 수 없는 강력한 암호화 표준을 갖는 데 의존합니다.

안전하지 않은 암호화가 위험한 이유는 무엇입니까?

컴퓨터 기술에 관해서, 강력한 암호화 알고리즘을 만들 수 있는 능력과 그들을 깰 수 있는 능력은 오랜 시간 동안 경쟁 에 왔다. 1977년, 미국 연방 정부는 컴퓨터의 상대적인 힘을 감안할 때 당시 안전하다고 여겨졌던 56비트 알고리즘인 데이터 암호화 표준(DES)을 개발했습니다.

그러나 컴퓨터는 진화했고, 사람들은 힘을 더욱 높이기 위해 협력적으로 네트워크를 구성할 방법을 찾았습니다. 1999년, 전자 프론티어 재단은 Distributed.net 함께 협력하여 단 22시간 만에 DES 보호 문서에 대한 암호화를 공개적으로 깨도록 했습니다. 갑자기 DES 암호화로 보호되는 모든 문서가 더 이상 안전하지 않습니다.

믿거나 말거나, 일부 조직은 여전히 DES 알고리즘또는 유사하게 약한 암호화 보호로 중요한 파일을 보호합니다. 그리고 1999년에 56비트 암호화를 중단하는 데 분산 네트워크가 걸렸지만, 오늘날 거의 모든 충분히 강력한 독립 실행형 컴퓨터가 시간의 수정을 감안할 때 이를 수행할 수 있습니다. 해커는 또한 그래픽 프로세서 단위 (GPU)의 은행에서 만든 전용 크래킹 기계를 만들었습니다. 이러한 GPU는 해당 작업에 매우 능숙하며, 현지에서 네트워크를 획득하고 네트워크하는 데 상대적으로 저렴합니다.

오늘 안전하지 않거나 약한 암호화 알고리즘으로 중요한 파일을 보호하기로 선택한 경우 대부분의 해커가 해당 파일을 분해하고 읽을 수 있도록 하기까지 는 오래 걸리지 않습니다. 데이터 유출로 인해 발생하는 경우 파일이 충분히 보호되지 않으면 결국 파일이 손상될 것이라고 가정해야 합니다.

예를 들어, 다음 Kubernetes 코드 스니펫은 NGINX ingress 컨트롤러 수준에서 정보를 보호하기 위해 약한 암호 알고리즘을 사용하고 있습니다.

api버전: v1
종류: 컨피맵
메타데이터:
이름: 응인스 로드 밸러블러-conf
네임스페이스: 쿠베 시스템
데이터:
ssl-암호: DES-CBC3-SHA
ssl 프로토콜: "TLSv1.2"

이 예제에서는 DES 암호 제품군이 정보를 보호하는 데 사용되었습니다. 그러나 공격자는 쉽게 해독하고 중요한 정보에 액세스할 수 있습니다.

강력한 암호 알고리즘을 사용하는 것이 좋습니다. 다음 Kubernetes 예제에서는 NGINX ingress 컨트롤러 수준에서 정보를 보호하기 위해 강력한 암호 제품군을 사용했습니다.

api버전: v1
종류: 컨피맵
메타데이터:
이름: 응인스 로드 밸러블러-conf
네임스페이스: 쿠베 시스템
데이터:
ssl-암호: |
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:
ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:
ECDHE-RSA-AES128-SHA256
ssl 프로토콜: "TLSv1.2"

이 예제에서는 공격자가 중요한 정보에 잠재적으로 액세스하지 않도록 강력한 암호 제품군이 사용되었습니다.

강력한 암호화로 중요한 정보 보호

강력한 암호화는 거의 깨지지 않는 오늘날 사용할 수 있습니다. 2001년, 국립 표준 기술 연구소(NIST)는 DES를 대체할 새로운 암호화 기술을 만들었습니다. 고급 암호화 표준(AES)이라고 불리는 이 표준은 128비트, 192비트 또는 256비트의 세 가지 키 길이를 사용합니다. 256 비트 AES 암호화는 가장 안전하지만, 세 가지 모두 오늘날의 기술을 감안할 때 거의 완전히 깨지지 않는 것으로 간주됩니다. 슈퍼컴퓨터 로 테스트결과 대부분의 AES 보호 문서를 깨기 위해서는 수천 년의 지속적인 작업이 소요될 것으로 나타났습니다.

중요한 파일을 적절하게 보호하려면 개발자가 먼저 파일을 식별해야 합니다. 지속적인 암호화 및 해독 프로세스로 인해 작업이 느려질 수 있기 때문에 네트워크의 모든 것을 암호화할 필요가 없습니다. 그러나 인사 기록, 고객 데이터 및 재무 정보와 같은 중요한 파일은 적절한 보호가 필요합니다. 본질적으로 보안과 실행 가능한 시스템 간의 균형 잡힌 행동입니다.

그리고 그 데이터는 AES 표준 중 하나에 암호화되어야하며, 심지어 잘못된 손에 착륙해서는 안되는 진정으로 중요한 정보에 대해 256 비트 암호화까지 가야합니다.

고려해야 할 또 다른 한 가지는 암호화를 추가하는 것이 사이트에 암호를 더 추가하는 것과 같다는 사실입니다. 즉, 권한이 있는 사용자는 암호화 키를 추적해야 합니다. 워크플로병목 현상이 발생하지 않도록 하려면 키 관리 플랫폼을 구현하여 해당 키를 추적하고 안전하게 유지하는 것이 좋습니다. 또한 중앙 집중식 키 관리를 사용하지 않더라도 권한이 없는 사용자가 가장 안전한 데이터 볼트에서 제외되도록 모든 키와 암호를 보호해야 합니다.

체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. IaC 챌린지 데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.

Der unzureichende Protokollierungs- und Überwachungsfehler ist hauptsächlich auf einen gescheiterten Cybersicherheitsplan zurückzuführen, der alle fehlgeschlagenen Authentifizierungsversuche, Zugriffsverweigerungen und Eingabevalidierungsfehler protokolliert. Sie kann auch an anderen Stellen in der Produktionsumgebung auftreten, ist aber meistens darauf zurückzuführen, dass ungültige Anmeldeversuche nicht gestoppt werden konnten.

Es handelt sich um eine gefährliche Sicherheitslücke, da sie bedeutet, dass Cybersicherheitsteams nicht auf Angriffe reagieren, weil sie nichts über sie wissen. Dies verschafft Angreifern einen großen Vorteil, da sie unbemerkt bleiben, während sie versuchen, weiter in ein System einzudringen oder ihre Anmeldeinformationen zu aktualisieren. Tatsächlich wird es ohne angemessene Protokollierung und Überwachung sehr schwierig oder sogar unmöglich, Angriffe zu erkennen und zu stoppen, bevor sie erheblichen Schaden anrichten können.

Bist du bereit, deine Fähigkeiten jetzt mit einer Herausforderung zu testen? Schau dir das an:

Wie nutzen Angreifer unzureichende Protokollierung und Überwachung aus?

Jede API ist anfällig für unzureichende Protokollierung und Überwachung, wenn die Protokollierungsstufe nicht richtig eingestellt ist, wenn sie zu niedrig eingestellt ist, wenn Fehlermeldungen nicht genügend Details enthalten oder wenn überhaupt keine Protokollierungsfunktion vorhanden ist.

Ein interessantes Beispiel wäre, wenn ein Hacker eine große Liste kompromittierter Benutzernamen für eine Website oder einen Dienst erhalten würde. Durch Experimente könnten sie herausfinden, dass drei fehlgeschlagene Anmeldeversuche erforderlich sind, bis sie vom System ausgeschlossen werden und bevor das Cybersicherheitspersonal benachrichtigt wird.

Mit diesen Informationen bewaffnet, könnten sie, anstatt zu versuchen, einzelne Konten mit Brute-Force-Angriffen zu bekämpfen, stattdessen ein Skript schreiben, das versucht, sich mit jedem Namen auf ihrer kompromittierten Liste mit gängigen Passwörtern wie „123456“ oder „Passwort“ anzumelden. Der Trick dabei ist, dass sie jeden Benutzernamen nur einmal oder vielleicht zweimal ausprobieren und dabei den Schwellenwert für Sperren und Warnmeldungen nicht überschreiten. Wenn sie Glück haben, werden sie auf Anhieb mindestens ein paar Passwörter kompromittieren. Danach warten sie einfach einen Tag, bis der Anmeldezähler zurückgesetzt ist, und führen den Vorgang erneut mit verschiedenen Passwörtern wie „qwerty“ oder „god“ aus. Wenn Administratoren nie herausfinden, was sie tun, können Angreifer die Liste viele Male durchgehen und schließlich die meisten Konten mit schwachen Passwörtern kompromittieren.

Dies geschah in dem von OWASP bereitgestellten Beispiel, bei dem eine Video-Sharing-Plattform mithilfe eines Credential-Stuffing-Angriffs angegriffen wurde, der die Sicherheitslücke in Bezug auf unzureichende Protokollierung und Überwachung ausnutzte. Bis das Unternehmen Beschwerden von Nutzern erhielt, hatte es keine Ahnung, dass der Angriff stattfand. Schließlich fanden sie Beweise in den API-Protokollen und mussten alle ihre Benutzer über eine erzwungene Passwortänderung informieren und den Angriff den Aufsichtsbehörden melden.

Beseitigung der Sicherheitslücke in Bezug auf unzureichende Protokollierung und Überwachung

Automatisierung und ständige Überwachung können dazu beitragen, dieser Sicherheitslücke ein Ende zu setzen. Zunächst sollten alle fehlgeschlagenen Authentifizierungsversuche protokolliert werden. Und dieses Protokoll sollte in ein maschinenlesbares Format wie STIX und TAXII gebracht werden, sodass es in ein SIEM-System (Security Information and Event Management) aufgenommen werden kann, das darauf trainiert ist, unabhängig von den verwendeten Schwellenwerten nach Angriffen zu suchen.

Sie sollten auch Ihre Logdateien schützen. Behandeln Sie sie als vertrauliche Informationen und schützen Sie sie vor dem Löschen oder Ändern durch Angreifer. Eine gute Richtlinie besteht darin, die Protokolldateien sowohl zu sichern als auch zu verschlüsseln.

Erstellen Sie schließlich benutzerdefinierte Dashboards und Benachrichtigungen, damit verdächtige Aktivitäten erkannt und so schnell wie möglich beantwortet werden können. Wenn Sie einem Angreifer die Zeit nehmen, die er mit dem System verbringt, nehmen Sie ihm die Möglichkeit, langsame und langsame Angriffstechniken einzusetzen, um unentdeckt zu bleiben.

Schauen Sie sich das an Sicherer Codekrieger Blogseiten mit weiteren Informationen zu dieser Sicherheitslücke und dazu, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch probiere eine Demo der Secure Code Warrior-Schulungsplattform, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.

Die Sicherheitslücke wegen übermäßiger Datenexposition unterscheidet sich von anderen API-Problemen auf der OWASP-Liste dadurch, dass es sich um eine ganz bestimmte Art von Daten handelt. Die eigentliche Mechanik hinter der Sicherheitslücke ist ähnlich wie bei anderen, aber eine übermäßige Datenexposition wird in diesem Fall so definiert, dass rechtlich geschützte oder hochsensible Daten betroffen sind. Dies kann alle persönlich identifizierbaren Informationen beinhalten, die oft als PII bezeichnet werden. Oder es könnte Informationen aus der Zahlungskartenbranche oder PCI beinhalten. Schließlich kann ein übermäßiger Datenverlust alle Informationen umfassen, die Datenschutzgesetzen unterliegen, wie z. B. der Allgemeinen Datenschutzverordnung (DSGVO) in Europa oder dem Health Insurance Portability and Accountability Act (HIPAA) in den Vereinigten Staaten.

Wie Sie sich vorstellen können, gibt dies Anlass zu großer Besorgnis, und es ist unerlässlich, dass versierte Entwickler lernen, diese Fehler zu beheben, wo immer dies möglich ist. Wenn du bereits bereit bist, es mit einem Drachen aufzunehmen, der das Risiko von Daten gefährdet, dann nimm an unserer spielerischen Herausforderung teil:

Was war dein Ergebnis? Lesen Sie weiter und erfahren Sie mehr:

Was sind einige Beispiele für übermäßiges Datenrisiko?

Einer der Hauptgründe für ein übermäßiges Datenrisiko ist, dass Entwickler und Programmierer nicht genügend Einblick in die Art der Daten haben, die ihre Anwendungen verwenden werden. Aus diesem Grund neigen Entwickler dazu, generische Prozesse zu verwenden, bei denen alle Objekteigenschaften den Endbenutzern zugänglich gemacht werden.

Entwickler gehen manchmal auch davon aus, dass Frontend-Komponenten eine Datenfilterung durchführen, bevor sie Benutzern Informationen anzeigen. Bei den meisten generischen Daten ist dies selten ein Problem. Die Offenlegung rechtlich geschützter oder sensibler Daten für Benutzer beispielsweise als Teil einer Sitzungs-ID kann jedoch sowohl aus sicherheitstechnischer als auch aus rechtlicher Sicht zu großen Problemen führen.

Als Beispiel dafür, wie leicht vertrauliche Daten versehentlich weitergegeben werden können, stellt sich der OWASP-Bericht ein Szenario vor, in dem ein Wachmann Zugriff auf bestimmte IoT-basierte Kameras in einer Einrichtung erhält. Vielleicht überwachen diese Kameras versiegelte und sichere Bereiche, während andere Kameras, die Personen beobachten, angeblich nur Wachpersonal oder Aufsichtspersonen mit höheren Berechtigungen zur Verfügung stehen sollen.

Um dem Wachmann Zugriff auf autorisierte Kameras zu gewähren, können Entwickler einen API-Aufruf wie den folgenden verwenden.

/api/사이트/111/카메라

Als Antwort würde die App Details zu den Kameras, die der Wachmann sehen kann, im folgenden Format senden:

{„id“ :"xxx“, "live_access_token“ :"xxxxbbbbb“, "building_id“ :"yyy "}

Oberflächlich betrachtet scheint das gut zu funktionieren. Der Wachmann, der die grafische Benutzeroberfläche der App verwendet, würde nur die Kamera-Feeds sehen, zu deren Anzeige er berechtigt ist. Das Problem ist, dass aufgrund des verwendeten generischen Codes die eigentliche API-Antwort eine vollständige Liste aller Kameras in der gesamten Einrichtung enthalten würde. Jeder, der das Netzwerk ausspioniert und diese Daten erfasst oder das Konto des Wachmanns kompromittiert, könnte die Standorte und die Nomenklatur für jede Kamera im Netzwerk herausfinden. Sie könnten dann uneingeschränkt auf diese Daten zugreifen.

Beseitigung übermäßiger Datenrisiken

Der wichtigste Schlüssel zur Vermeidung übermäßiger Datenexposition ist ein Verständnis der Daten und der Schutzmaßnahmen, die sie umgeben. Generische APIs zu erstellen und es dem Kunden zu überlassen, Daten zu sortieren, bevor sie den Benutzern angezeigt werden, ist eine gefährliche Wahl, die zu vielen vermeidbaren Sicherheitsverletzungen führt.

Neben dem Verständnis der relevanten Datenschutzmaßnahmen ist es auch wichtig, den Prozess zu beenden, bei dem alles mit generischen APIs an einen Benutzer gesendet wird. Beispielsweise muss Code wie to_json () und to_string () vermieden werden. Stattdessen sollte der Code speziell die Eigenschaften auswählen, die an autorisierte Benutzer zurückgegeben werden müssen, und diese Informationen ausschließlich senden.

Um sicherzustellen, dass keine geschützten Daten versehentlich zu oft geteilt werden, sollten Unternehmen die Implementierung eines schemabasierten Antwortvalidierungsmechanismus als zusätzliche Sicherheitsebene in Betracht ziehen. Er sollte definieren und durchsetzen, dass Daten über alle API-Methoden zurückgegeben werden, einschließlich Regeln für die Fehlerberichterstattung.

Schließlich sollten alle Daten, die als PII- oder PCI-Daten eingestuft werden, oder Informationen, die durch Vorschriften wie die DSGVO oder HIPAA geschützt sind, mit einer starken Verschlüsselung geschützt werden. Auf diese Weise gibt es eine gute zweite Verteidigungslinie, die die Daten auch dann schützen sollte, wenn der Speicherort dieser Daten als Teil einer Sicherheitslücke wegen übermäßiger Datensicherheit herauskommt, selbst wenn sie in die Hände eines böswilligen Benutzers oder Bedrohungsakteurs gelangen.

Schauen Sie sich das an Sicherer Codekrieger Blogseiten mit weiteren Informationen zu dieser Sicherheitslücke und dazu, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch probiere eine Demo der Secure Code Warrior-Schulungsplattform, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.

Es ist Zeit für den nächsten Teil unserer Reihe „Infrastructure as Code“, die Blogs, die Entwickler wie Sie bei der Bereitstellung sicherer Infrastrukturen in Ihrem eigenen Unternehmen auf ein völlig neues Niveau des Sicherheitsbewusstseins heben werden.

Oh, übrigens... wie ist es Ihnen mit der Sicherheitsfehlkonfiguration im vorherigen Blog ergangen? Wenn Sie sofort eine Sicherheitslücke in der Zugriffskontrolle auf Funktionsebene beheben möchten, besuchen Sie die Plattform:

(Der obige Link führt Sie zur Kubernetes-Herausforderung, aber sobald Sie auf der Plattform sind, verwenden Sie das Drop-down-Menü, um auch zwischen Ansible, CloudFormation, Terraform oder Docker auszuwählen. Deine Wahl.)

Fast jede heute eingesetzte Anwendung verfügt über eine Art Zugriffskontrollmechanismus, der überprüft, ob ein Benutzer die Berechtigung hat, die angeforderten Funktionen auszuführen oder nicht. Dies ist so ziemlich der Eckpfeiler guter Sicherheit und Funktionalität bei der Erstellung einer Anwendung. Tatsächlich benötigen alle Webanwendungen Zugriffskontrollen, damit Benutzer mit unterschiedlichen Rechten das Programm verwenden können.

Probleme können jedoch auftreten, wenn dieselben Überprüfungsfunktionen für die Zugriffskontrolle nicht auf Infrastrukturebene ausgeführt werden oder falsch konfiguriert sind. Wenn die Zugriffskontrolle auf Infrastrukturebene nicht in einwandfreiem Zustand ist, ist ein ganzes Unternehmen Hackern ausgesetzt, die diese Sicherheitslücke als Einfallstor für unbefugtes Ausspionieren oder für einen vollständigen Angriff nutzen können.

Tatsächlich ist es extrem einfach, fehlende oder falsch konfigurierte Sicherheitslücken bei der Funktionskontrolle auszunutzen. Angreifer müssen nicht einmal übermäßig geschult sein. Sie müssen nur wissen, welche Befehle Funktionen innerhalb des Frameworks ausführen, das die Anwendung unterstützt. Wenn sie das tun, ist es nur eine Frage von Versuch und Irrtum. Sie können kontinuierlich Anfragen stellen, die nicht zugelassen werden sollten, und sobald eine solche Anfrage erfolgreich ist, könnte die Zielwebsite, die Anwendung, der Server oder sogar das gesamte Netzwerk gefährdet sein.

Wie funktionieren fehlende Zugriffskontroll-Exploits auf Funktionsebene?

Es gibt verschiedene Möglichkeiten, wie sich Zugriffskontrollen auf Funktionsebene in ein Unternehmen einschleichen können. Beispielsweise kann der Zugriff auf Funktionsebene einer Anwendung überlassen werden und nicht von der zugrunde liegenden Infrastruktur verifiziert werden. Oder die Zugriffskontrolle auf Infrastrukturebene kann falsch konfiguriert werden. In einigen Fällen gehen Administratoren davon aus, dass nicht autorisierte Benutzer nicht wissen, wie sie zu Infrastrukturressourcen gelangen, die nur für Benutzer auf höherer Ebene sichtbar sein sollten, und verwenden ein „Security by Obscurity“ -Modell, das selten funktioniert.

Ein Beispiel für Security by Obscurity: Die folgende URL ist wahrscheinlich anfällig für Angriffe:

http://companywebsite.com/app/NormalUserHomepage

Wenn ein authentifizierter Benutzer eine Technik namens Forced URL Browsing verwendet, könnte er versuchen, eine Seite zu erreichen, die nur Administratoren angezeigt wird. Ein Beispiel könnte sein:

http://companywebsite.com/app/AdminPages

Wenn keine serverseitige Überprüfung existiert, werden ihnen einfach die Admin-Seiten angezeigt (falls ihr Name mit der Anfrage übereinstimmt) und haben dann Zugriff auf alle zusätzlichen Funktionen, die Administratoren von der neuen Seite aus ausführen. Wenn der Server den Fehler „Seite nicht gefunden“ an den Angreifer zurückgibt, kann er es einfach so lange versuchen, bis er herausgefunden hat, welchen Namen die Admin-Seite erhalten hat.

Für Angreifer, Ausnutzen fehlende Zugriffskontrollen auf Funktionsebene ist ein ähnlicher Prozess. Anstatt zu versuchen, unautorisierte Seiten zu durchsuchen, senden sie stattdessen Funktionsanfragen ein. Beispielsweise könnten sie versuchen, einen neuen Benutzer mit Administratorrechten zu erstellen. Ihre Anfrage würde also je nach Framework ungefähr so aussehen:

Beitrag/Aktion/CreateUsername=Hacker&pw=password&role=admin

Wenn keine Zugriffskontrolle auf Funktionsebene vorhanden ist, wäre das obige Beispiel erfolgreich und ein neues Administratorkonto würde erstellt. Sobald sich der Angreifer wieder als neuer Administrator anmeldet, hätte er denselben Zugriff und dieselben Berechtigungen wie jeder andere Administrator in diesem Netzwerk oder Server.

Die Lösung für fehlende Zugriffskontrollen auf Funktionsebene

Da es für Angreifer so einfach ist, fehlende Sicherheitslücken bei der Zugriffskontrolle auf Funktionsebene auszunutzen, ist es wichtig, dass sie gefunden, behoben und verhindert werden. Zum Glück ist das mit etwas Fachwissen und einer grundlegenden Infrastruktur nicht allzu schwierig Schulung zur Codesicherheit.

Der Hauptschutz wird durch die Implementierung einer rollenbasierten Autorisierung auf Infrastrukturebene gewährleistet. Vertrauen Sie niemals darauf, dass Anwendungen diese Funktion ausführen. Selbst wenn dies der Fall ist, stellt eine infrastrukturseitige Autorisierung sicher, dass nichts übersehen wird. Idealerweise sollte die Autorisierung von einer zentralen Stelle aus erfolgen (z. B. AWS IAM, Azure IAM usw.), die in die Routine Ihres Unternehmens integriert ist und auf jede neue Anwendung angewendet wird. Diese Autorisierungsprozesse können vom Framework selbst oder aus einer beliebigen Anzahl benutzerfreundlicher externer Module stammen.

Schließlich sollte sich Ihr Unternehmen das Konzept der geringsten Privilegien zu eigen machen. Alle Aktionen und Funktionen sollten standardmäßig verweigert werden, wobei der Autorisierungsprozess verwendet wird, um gültigen Benutzern die Erlaubnis zu geben, alles zu tun, was sie benötigen. Sie sollten nur genügend Berechtigungen erhalten, um die erforderliche Funktion auszuführen, und zwar nur so lange wie erforderlich.

Fehlende Zugriffskontrollen auf Funktionsebene können verheerend sein. Aber glücklicherweise können Sie dieses Problem ganz einfach verhindern, indem Sie in Ihrem Unternehmen gute Autorisierungspraktiken auf Infrastrukturebene integrieren.

Denken Sie, Sie sind bereit, einen Zugangskontrollfehler in freier Wildbahn zu entdecken? Vergleichen Sie diese Docker-Codefragmente; einer ist verwundbar, einer sicher:

Verwundbar:

VON quay.io/prometheus/busybox:latest
ARG-VERSION = 0.12.1
ARG-Dateiname=mysqld_exporter-$ {VERSION} .linux-amd64
ARG URL= https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$filename.tar.gz &&\
tar -xf $dateiname.tar.gz &&\
mv $Dateiname/mysqld_exporter /bin/mysqld_exporter
KOPIERE .my.cnf /home/.my.cnf
KOPIEREN. /scripts/entrypoint.sh ~/entrypoint.sh
BENUTZER root
AUSSETZEN 9104
EINSTIEGSPUNKT ["sh“, "~/entrypoint.sh"]
CMD [„/bin/mysqld_exporter“]

Sicher:

VON quay.io/prometheus/busybox:latest
ARG-VERSION = 0.12.1
ARG-Dateiname=mysqld_exporter-$ {VERSION} .linux-amd64
ARG URL= https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$filename.tar.gz &&\
tar -xf $dateiname.tar.gz &&\
mv $Dateiname/mysqld_exporter /bin/mysqld_exporter
KOPIERE .my.cnf /home/.my.cnf
KOPIEREN. /scripts/entrypoint.sh ~/entrypoint.sh
BENUTZER niemand
AUSSETZEN 9104
EINSTIEGSPUNKT ["sh“, "~/entrypoint.sh"]
CMD [„/bin/mysqld_exporter“]

Erfahre mehr, fordere dich selbst heraus

Schauen Sie sich das an Sicherer Codekrieger Blogseiten mit weiteren Informationen zu dieser Sicherheitslücke und dazu, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken und Sicherheitslücken schützen können.

Und wenn du es früher verpasst hast, kannst du probieren Sie eine IaC Gamified Security Challenge aus auf der Secure Code Warrior-Plattform, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.

Seien Sie gespannt auf das nächste Kapitel!

리소스와 속도 제한이 부족하면 API 취약점이 제목에 의해 설명되는 방식과 거의 정확히 일치합니다. 모든 API에는 환경에 따라 리소스와 컴퓨팅 전력이 제한되어 있습니다. 대부분은 원하는 기능을 수행하도록 요청하는 사용자 또는 기타 프로그램의 요청을 필드로 수행해야 합니다. 이 취약점은 너무 많은 요청이 동시에 들어올 때 발생하며 API에는 이러한 요청을 처리할 수 있는 컴퓨팅 리소스가 충분하지 않습니다. 그런 다음 API를 사용할 수 없거나 새 요청에 응답하지 못할 수 있습니다.

API는 속도 또는 리소스 제한이 올바르게 설정되지 않았거나 코드에 제한이 정의되지 않은 상태로 남아 있는 경우 이 문제에 취약해집니다. 예를 들어 비즈니스에서 특히 바쁜 기간을 경험하는 경우 API를 오버로드할 수 있습니다. 그러나 위협 행위자는 DDoS(서비스 거부) 공격을 수행하기 위해 요청으로 보호되지 않은 API를 의도적으로 과부하시킬 수 있기 때문에 보안 취약점이기도 합니다.  

그런데 지금까지 API 게임화 챌린지로 어떻게 하고 있습니까? 지금 당장 취약점을 제한하는 속도 처리 기술을 시도하려면 경기장에 들어갑니다.

이제 좀 더 깊이 살펴보겠습니다.

리소스가 부족하고 API 취약점을 제한하는 속도의 예로는 어떤 예가 있습니까?

이 취약점이 API에 몰래 들어갈 수 있는 방법에는 두 가지가 있습니다. 첫 번째는 코더가 API에 대한 스로틀 속도를 정의하지 않는 경우입니다. 인프라 어딘가에 스로틀 속도에 대한 기본 설정이 있을 수 있지만 이에 의존하는 것은 좋은 정책이 아닙니다. 대신 각 API의 요금은 개별적으로 설정되어야 합니다. API는 사용 가능한 리소스뿐만 아니라 매우 다른 기능을 가질 수 있기 때문에 특히 그렇습니다.

예를 들어 소수의 사용자에게만 제공하도록 설계된 내부 API는 매우 낮은 스로틀 속도를 가질 수 있으며 잘 작동할 수 있습니다. 그러나 실시간 전자 상거래 사이트의 일부인 공용 API는 동시 사용자의 급증 가능성을 보상하기 위해 매우 높은 비율이 정의될 가능성이 큽습니다. 두 경우 모두 제한 속도는 예상 요구 사항, 잠재적 사용자 수 및 사용 가능한 컴퓨팅 성능에 따라 정의되어야 합니다.

특히 매우 바쁠 가능성이 높은 API를 사용하면 성능을 극대화하기 위해 요금을 무제한으로 설정하는 것이 유혹적일 수 있습니다. 이것은 코드의 간단한 비트로 수행 할 수 있습니다 (예를 들어, 우리는 파이썬 장고 REST 프레임 워크를사용합니다):

"DEFAULT_THROTTLE_RATES: {
       "anon: None,
       "user: None

이 예제에서는 익명 사용자와 시스템에 알려진 사용자 모두 시간이 지남에 따라 요청 수와 관계없이 무제한 으로 API에 연락할 수 있습니다. API가 사용할 수 있는 컴퓨팅 리소스의 양에 관계없이 공격자는 봇넷과 같은 리소스를 배포하여 결국 크롤링 속도를 늦추거나 오프라인으로 완전히 노크할 수 있기 때문에 이는 잘못된 생각입니다. 이 경우 유효한 사용자가 액세스가 거부되고 공격이 성공합니다.

자원 부족 및 속도 제한 문제 제거

조직에서 배포하는 모든 API에는 스로틀 요금이 코드에 정의되어야 합니다. 여기에는 실행 시간 시간, 최대 허용 메모리, 사용자에게 반환할 수 있는 페이지당 레코드 수 또는 정의된 기간 내에 허용되는 프로세스 수 등이 포함될 수 있습니다.

위의 예에서 제한 요금을 크게 열어 두는 대신 익명 및 알려진 사용자에 대해 서로 다른 비율로 엄격하게 정의할 수 있습니다.

"DEFAULT_THROTTLE_RATES: {
       "anon: config("THROTTLE_ANON, default=200/hour),
       "user: config("THROTTLE_USER, default=5000/hour)

새 예제에서 API는 익명 사용자가 시간당 200개의 요청을 하는 것으로 제한합니다. 이미 시스템에 의해 심사를 받은 알려진 사용자는 시간당 5,000건의 요청으로 더 많은 여유를 받습니다. 그러나 피크 타임에 우발적 인 과부하를 방지하거나 사용자 계정이 손상되어 서비스 거부 공격에 사용되는 경우 보상하도록 제한됩니다.

고려해야 할 마지막 좋은 연습으로, 해당 제한이 재설정될 시기에 대한 설명과 함께 제한 제한에 도달했을 때 사용자에게 알림을 표시하는 것이 좋습니다. 이렇게 하면 유효한 사용자가 응용 프로그램이 요청을 거부하는 이유를 알 수 있습니다. 또한 승인된 작업을 수행하는 유효한 사용자가 제한을 늘려야 한다는 것을 작업 담당자에게 신호를 볼 수 있으므로 API에 대한 액세스가 거부되는 경우에도 도움이 될 수 있습니다.

체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. 데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.

인증이 깨진 경우 API 문제에 대한 OWASP 목록이 올바르게 구현하기 어려운 것으로 악명이 높습니다. 또한 공격자는 본질적으로 대부분의 인증 문제를 사용자에게 노출해야 하므로 공격자가 이를 연구하고 악용할 수 있는 패턴이나 취약점을 찾을 수 있는 기회를 제공해야 하기 때문에 약간의 이점이 있습니다.

마지막으로 인증은 응용 프로그램 과 네트워크의 나머지 부분에 대한 게이트웨이 역할을 하는 경우가 많기 때문에 공격자에 대한 대상을 유혹하고 있습니다. 인증 프로세스가 깨지거나 취약하면 공격자가 약점을 발견하고 악용할 가능성이 높습니다.

그래서, 이 장에서, 우리는 인증 문제에 관해서 나쁜 사람을 종료하는 방법을 배울 거 야. 먼저 기술을 테스트하려면 머리를 숙이고 게임화 된 도전을 플레이하십시오.

점수를 향상시키고 싶으신가요? 우리가 그것을 무너뜨리는 동안 나와 함께 있어.

손상되거나 잘못 구성된 인증의 예로는 어떤 예가 있습니까?

인증 방법이 자격 증명 스터핑에 취약하거나 알려진 사용자 이름과 암호 목록을 사용하여 보안을 끊을 수 있는 경우문제가 명확하지 않을 수 있습니다. 요청이 제한되거나 제한되거나 모니터링되지 않는 경우 다단계 인증과 같은 일반적으로 매우 안전한 권한 부여 방법조차도 취약할 수 있습니다.

예를 들어 공격자는 POST 요청을/api/system/확인 코드로 보내고 요청 본문에 사용자 이름을 제공하여 암호 복구 요청을 트리거할 수 있습니다. 앱이 6자리 코드가 사용자의 휴대폰으로 전송되지만 입력 필드가 제한되지 않는 SMS 문자 메시지 챌린지를 사용하는 경우 응용 프로그램이 단 몇 분 만에 끊어질 수 있습니다. 공격자는 올바른 조합을 칠 때까지 가능한 모든 6자리 조합을 응용 프로그램에 보내야 합니다.

이 시나리오에서는 표면에서 이중 인증을 사용하면 응용 프로그램을 안전하게 유지하는 것처럼 보입니다. 그러나 사용자 입력속도가 제한되지 않으므로 인증이 끊어지고 취약합니다.

또 다른 예에서 응용 프로그램은 인코딩된 사용자 개체를 인증 쿠키로 사용할 수 있습니다. 그러나 수준이 낮은 사용자 액세스가 있는 공격자가 Base64를 사용하여 쿠키를 디코딩하는 경우 쿠키가 세션과 사용자를 응용 프로그램에 정의하는 방법을 발견할 수 있습니다. 예를 들어, 그들은 다음 JSON을 볼 수 있습니다 한 번 디코딩:

{
"username" : "ShadyGuy",
"role" : "user"
{

이 시점에서 악의적인 사용자가 사용자 이름, 역할 또는 둘 다 변경할 수 있습니다. 몇 가지 값을 변경하여 권한 수준이 높은 다른 사용자가 될 수 있습니다.

{
"username" : "GoodGuy",
"role" : "admin"
{

이 시점에서 공격자가 정보를 다시 코딩하고 쿠키 값으로 설정하면 기본적으로 더 높은 권한 수준을 가진 새 사용자가 됩니다. 이러한 변경을 방지하기 위한 방법이 마련되지 않는 한 응용 프로그램이 변환을 수락할 가능성이 높습니다.

잘못되었거나 잘못 구성된 인증 제거

인증에 실패하면 전반적으로 보안이 손상될 가능성이 큽분입니다. 그러나 코딩 응용 프로그램이 모든 것을 안전하게 유지하는 데 도움이 될 수 있지만 몇 가지 중요한 지침을 따르면 모든 것을 안전하게 유지하는 데 도움이 될 수 있습니다.

먼저 사용자가 프로그램 기능에 액세스할 수 있도록 모든 곳에서 인증 검사를 포함해야 합니다. 인증 검사가 전혀 존재하지 않으면 처음부터 전투가 손실됩니다.

모범 사례의 관점에서 볼 때 사용자가 액세스할 수 있는 URL에 세션 ID가 노출되지 않도록 하는 것이 좋습니다. 깨진 인증과 관련하여 위의 두 번째 예에서는 공격자가 세션 쿠키에 노출되지 않으면 세션 쿠키를 디코딩하지 않도록 하는 것이 훨씬 쉽습니다.

다단계 인증을 구현하는 것도 좋습니다. 이 작업은 촉박한 일정에 따라 알고리즘적으로 암호를 생성하는 하드웨어 토큰을 사용하여 안전하게 수행할 수 있습니다. 사용자에게 이러한 장치를 제공할 수 없는 경우 SMS 문자 메시지도 작동할 수 있습니다. 그러나 사용자 요청이 30초 동안 3~4회 시도와 같은 합리적인 것으로 제한되고 코드가 단 몇 분 만에 모두 함께 만료되는지 확인해야 합니다. 거상 코드를 사용하면 잠재적인 암호에 문자와 번호를 추가하여 보안을 향상시킬 수도 있습니다.

마지막으로 가능하면 사용자 이름 또는 세션 ID로 예측 가능한 순차적 값에 따라 달라지 마십시오. 대신 매번 임의의 세션 ID를 생성하는 보안 서버 측 세션 관리자를 사용합니다.

보안 인증 방법을 구현하는 것은 평균 취약점에 대처하는 것보다 조금 더 까다롭습니다. 그러나 권한 부여는 모든 응용 프로그램, 프로그램 및 API에 매우 중요하기 때문에 올바른 것을 얻기 위해 여분의 시간을 할애할 가치가 있습니다.

체크 아웃 Secure Code Warrior 이 취약점에 대한 자세한 정보를 위한 블로그 페이지와 다른 보안 결함의 파괴로부터 조직과 고객을 보호하는 방법. 데모를 시도할 수도 있습니다. Secure Code Warrior 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 교육 플랫폼을 제공합니다.

Bedrohungen der Cybersicherheit sind heutzutage allgegenwärtig und unerbittlich. Es ist so schlimm geworden, dass es fast unmöglich geworden ist, nach der Bereitstellung von Programmen mit ihnen Schritt zu halten. Im Zeitalter von DevSecOps, kontinuierlicher Bereitstellung und mehr Daten als je zuvor helfen kluge Unternehmen ihren Entwicklern jedoch dabei, sich zu sicherheitsbewussten Superstars weiterzubilden, die dabei helfen, häufig auftretende Sicherheitslücken zu beseitigen, bevor sie überhaupt in die Produktion gelangen. Wir haben uns damit befasst Sicherheitslücken im Internet, plus unser eigenes Die 8 wichtigsten Infrastrukturen als Code Bugs, und jetzt ist es an der Zeit, sich mit der nächsten großen Softwaresicherheitsherausforderung vertraut zu machen. Bist du bereit?

Diese nächste Blogserie wird sich auf einige der schlimmsten Sicherheitslücken konzentrieren, die sich auf Anwendungsprogrammierschnittstellen (APIs) beziehen. Diese sind so schlimm, dass sie das Open Web Application Security Project ins Leben gerufen haben (WESPE) Liste der wichtigsten API-Schwachstellen. Angesichts der Bedeutung von APIs für moderne Computerinfrastrukturen handelt es sich um kritische Probleme, die Sie um jeden Preis von Ihren Anwendungen und Programmen fernhalten müssen.

Ein perfektes Beispiel dafür, warum es wichtig ist, Code zur Durchsetzung der Sicherheit zu verwenden, findet sich in einer Untersuchung der Sicherheitsanfälligkeit für eine fehlerhafte Autorisierung auf Objektebene. Dies passiert, wenn Programmierer nicht explizit definieren, welche Benutzer Objekte und Daten anzeigen können, oder wenn sie irgendeine Form der Überprüfung vornehmen, um Objekte anzusehen, zu ändern oder andere Anfragen zu stellen, um sie zu manipulieren oder auf Objekte zuzugreifen, sodass sie Objekte und Daten über API-Endpunkte ändern und darauf zugreifen können. Ein API-Endpunkt ist ein Kontaktpunkt, oft eine URL, der für die Kommunikation zwischen der API selbst und einem anderen System verwendet wird. Die Fähigkeit zur Konnektivität zwischen Apps hat einige der beliebtesten Softwareprogramme der Welt verbessert, aber es besteht das Risiko, dass mehrere Endpunkte offengelegt werden, wenn sie nicht luftdicht sind.

Es kann auch vorkommen, dass Programmierer Eigenschaften von übergeordneten Klassen vergessen oder erben, ohne zu wissen, dass dadurch auch ein kritischer Überprüfungsprozess in ihrem Code ausgelassen wird. Im Allgemeinen sollten Autorisierungsprüfungen auf Objektebene für jede Funktion vorgesehen werden, die mithilfe einer Benutzereingabe auf eine Datenquelle zugreift.

Denken Sie, Sie kennen sich bereits mit diesen aus und können einen Fehler in der Zugriffskontrolle sofort finden, beheben und beheben? Spiele die spielerische Herausforderung:

Wie ist es dir ergangen? Wenn du an deinem Ergebnis arbeiten willst, lies weiter!

Was sind einige Beispiele für Sicherheitslücken bei der Autorisierung auf Objektebene?

Sicherheitslücken bei der Zugriffskontrolle auf Objektebene ermöglichen es Angreifern, Maßnahmen zu ergreifen, zu denen sie nicht zugelassen werden sollten. Dabei kann es sich um eine Aktion handeln, die Administratoren vorbehalten sein sollte, wie etwa der Zugriff auf oder das Anzeigen vertraulicher Daten oder das Löschen von Datensätzen. In einer hochsicheren Umgebung kann dies sogar bedeuten, dass niemand die Aufzeichnungen überhaupt einsehen kann, sofern er nicht ausdrücklich dazu autorisiert ist.
Bei der Definition der Autorisierung auf Objektebene sollten Sie alle möglichen Aktionen berücksichtigen. In der Java Spring API könnte ein Endpunkt mit einem potenziellen Problem beispielsweise so aussehen:

public boolean deleteOrder (Lange ID) {
Bestellung = OrderRepository.getOne (id);
wenn (Reihenfolge == null) {
log.info („Keine Bestellung gefunden“);
gib falsch zurück;
}
Benutzerbenutzer = order.getUser ();
OrderRepository.delete (Bestellung);
log.info („Bestellung für Benutzer {} löschen“, user.getId ());
gib wahr zurück;

Der API-Endpunkt löscht Bestellungen anhand der ID, überprüft jedoch nicht, ob diese Bestellung vom aktuell angemeldeten Benutzer getätigt wurde. Dies bietet einem Angreifer die Möglichkeit, diese Lücke auszunutzen und die Bestellungen anderer Benutzer zu löschen.

Damit sichere Zugriffsbeschränkungen ordnungsgemäß implementiert werden können, würde der Code eher so aussehen:

public boolean deleteOrder (Lange ID) {
Benutzerbenutzer = UserService.getUserByContext ();
boolean orderExist = getUserOrders () .stream ()
.anyMatch (order -> (order.getId () == id));
wenn (OrderExist) {
orderrepository.deleteById (id);
log.info („Bestellung für Benutzer {} löschen“, user.getId ());
gib wahr zurück;
} sonst {
log.info („Keine Bestellung gefunden“);
gib falsch zurück;

Beseitigung von Sicherheitslücken bei der Autorisierung auf Objektebene

Der Zugriffskontrollcode muss nicht übermäßig kompliziert sein. Im Fall unseres Beispiels für eine Java-Spring-API-Umgebung kann dies behoben werden, indem genau definiert wird, wer auf Objekte zugreifen kann.

Zunächst muss ein Überprüfungsprozess implementiert werden, um festzustellen, wer die Anfrage stellt:

Benutzerbenutzer = UserService.getUserByContext ();

Als Nächstes müssen wir sicherstellen, dass die Objekt-ID existiert und dem Benutzer gehört, der die Anfrage stellt:

boolean orderExist = getUserOrders () .stream ()
.anyMatch (order -> (order.getId () == id));

Und schließlich löschen wir das Objekt:

orderrepository.deleteById (id);

Denken Sie daran, dass Sie sicherstellen müssen, dass die Autorisierungsmethode in Ihrem Code den Benutzerrichtlinien und Datenzugriffskontrollen Ihres Unternehmens entspricht. Um sicherzustellen, dass Ihr Code vollständig sicher ist, sollten Sie Prüfungen durchführen, um sicherzustellen, dass Benutzer mit unterschiedlichen Berechtigungsstufen Zugriff auf die Daten haben, die sie für ihre Arbeit benötigen, aber daran gehindert werden, Inhalte einzusehen oder zu ändern, die auf sie beschränkt sein sollten. Dadurch könnten Sicherheitslücken bei der Steuerung fehlender Objekte aufgedeckt werden, die versehentlich übersehen wurden.

Die wichtigsten Erkenntnisse aus diesen Beispielen bestehen darin, zunächst jede Aktion zu definieren, die ein Benutzer mit einem Objekt ausführen könnte, und dann dem Code direkt starke Zugriffskontrollen hinzuzufügen. Und schließlich sollten Sie niemals darauf vertrauen, dass die vererbten übergeordneten Eigenschaften diese Aufgabe erledigen oder diese Autorität an eine andere Stelle delegieren. Definieren Sie stattdessen Benutzerberechtigungen und Aktionen im Code explizit für jeden Objekttyp, den Sie schützen müssen.

Schauen Sie sich das an Sicherer Codekrieger Blogseiten mit weiteren Informationen zu dieser Sicherheitslücke und dazu, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch probiere eine Demo der Secure Code Warrior-Schulungsplattform, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.

최근 장거리 비행에서, 나는 팟 캐스트 에피소드의 아주 솔직히, 미친 볼륨을 삼킬 수있는 기회를 했다. 너무 많은 다른 시리즈와 최신 유지 의미 내가 들을 수 있는 뭔가 부족, 설득력 있는--하지만-대화 그냥 내 전화 화면의 터치.

결국, 나는 진정한 범죄 팟 캐스트, Casefile의에피소드에 도착 . 이 극적인, 무 보류 금지 시리즈 (불길하게 목소리와 이름없는 호스트와 완료) 심지어 가장 지식과 정통한 기술자를 매료 주제로 탐구: 깊은 웹, 그리고 밀수 무역 웹 의 대격변 승천, 실크 로드. 실크로드의 상승과 하락에 익숙한 사람들은 의심 할 여지없이 사건에 대한 뉴스를 따랐을 것이지만, 팟 캐스트는 맛있고 좌석 가장자리 의 이야기로 모든 작은 세부 사항을 공개합니다.

실크로드: 딥 웹 던전의 교훈

실크로드에 대해 잘 모르시는 분들을 위해 간단히 설명하자면, 한 남성이 딥 웹에 일반인의 눈에 띄지 않고 특수 소프트웨어인 Tor 브라우저를 사용하지 않으면 볼 수 없는 거래 웹사이트를 구축했다는 것입니다. 이 사이트는 처음에는 직접 재배한 마법의 버섯만 판매했지만, 하룻밤 사이에 하드코어 마약부터 불법 무기, 도난당한 신용카드 정보까지 모든 것을 제공하는 판매자가 폭발적으로 증가했습니다. 자세한 내용은 여기에서 확인할 수 있습니다. 제작자이자 사이트 관리자는 프린세스 브라이드에서 영감을 받아 공포의 해적 로버츠라는 가명을 사용했습니다. 그는 누구도 아닌 모든 사람이었습니다. 모든 사용자는 엄청난 양의 불법 상품을 거래했으며, 완전히 익명으로 거래했습니다(그 과정에서 비트코인은 마약상들이 선호하는 통화로 명성을 얻었습니다. 이제 막 흔들리기 시작한 오명입니다).

그러나, 공포 해적 로버츠의 설립 실험은 자신의 짐승이었다. 곧, 히트맨은 자신의 서비스를 광고했다. 나쁜 사람들은 나쁜 일을하고 있었다 ... 그리고 그는 새로 발견 된 헤아릴 수없는 재산에 중독되었다. 그는 심지어 전 직원을 처분하기 위해 광고 된 히트맨의 서비스를 활용하려고노력했습니다. 긴 이야기 짧은, 이것은 그의 파멸을 초래 많은 너클 머리 결정 중 하나였다. 그는 로스 울브리히트로 가면을 쓰지 않았고 현재 미국 감옥에서 썩어가며 가석방의 가능성없이 이중 종신형과 40 년을 복역하고 있습니다.

그러나 모든 것이 완전히 비공개이고 익명이라면 어떻게 잡혔습니까?

글쎄, 무딘 넣어 : 그는 꽤 엉터리 코더였다. 실크로드 부지 자체는 바다에 누워 있는 새는 낡은 바지선과 같았습니다. 불법 활동의 허브(그리고 그 활동의 모든 데이터)를 고려하면 전혀 안전하지 않았습니다. 그것은 기회 해커에 의해 악용되기를 기다리는 앉아있는 오리였습니다. 공정하게, 당신은 거 대 한의 지배자 때, 불법 마약 밀매 사업, 그것은 아마 당신의 작업에 참여 하 고 싶은 유능한 직원을 찾기 쉽지 않다. 그는 자신의 기술 격차의 비밀을하지 않았다, 어느 - 그는 심지어 스택 오버 플로우 (예, 즉, 그의 사용자 계정)에 자신의 실명 아래에 게시, 제대로 PHP에서 컬을 사용하여 토르와 연결하는 자신의 사이트 코드를 구성하는 데 도움을 요청. 그는 게시 후 1 분 이내에 핸들 "서리가 내린"핸들에 자신의 실명을 변경하지만, 이것은 분명히 도움이되지 않았다 ... 사실, 실크로드 서버의 암호화 키는 "frosty@frosty"로 끝났기 때문에 FBI가 그의 향기의 바람을 잡으면 더 연루되었습니다.

암호화된 메시지, 통화, 밀수품의 운송 및 배송 시 보안에 대한 명시적인 지침 등 프라이버시를 위한 엄청난 노력에도 불구하고 이 사이트는 울브리히트가 상상했던 자유주의적 판타지의 난공불락의 요새는 아니었습니다. 기술을 가진 사람들(FBI에 고용된 프로그래머)은 천천히, 그러나 확실하게 이 사이트를 풀어내어 사이트에서 거래한 수천 명의 신원을 포함한 모든 것을 밝혀냈습니다. 수년 전에 음란물을 구매했던 사람들도 언젠가는 법의 긴 팔이 문을 두드리게 될 가능성이 있습니다.

FBI는 그들이 실크로드를 관통 할 수있는 방법을 설명하는 문서를 발표, 일반적인 설명은 IP 주소 누출을 활용하는 것입니다. 실크로드 로그인 페이지의 잘못된 구성은 IP 주소와 따라서 언더 핸드 해킹이 필요하지 않고, 서버의 물리적 위치를 공개했다. 신인 오류, 확실히, 그리고 결국 로스 울브리히트에 FBI를 직접 주도 하나.

이 결함이 있었다면 - 이 결함이 이 순간을 오래 전에 발견했을 것이라는 추측이 있습니다. 호주 보안 컨설턴트인 Nik Cubrilovic은 WIRED와의 인터뷰에서단순히 거기에 없었다고 주장합니다.

"Tor 사이트에 연결하고 Tor 노드가 아닌 서버의 주소를 볼 수 있는 방법은 없습니다. 배심원이나 판사가 배심원을 만들려고 하는 방식은 기술적으로 는 의미가 없다고 믿습니다."

그런 다음 Cubrilovic은 불법 해킹 관행에 의해 정보가 입수되었을 수 있음을 암시합니다. 그 관행은 SQL 주입 것 같다, 이후 많은 사이트에서 추출의 그럴듯한 방법으로논의 된 입증되지 않은 소문.

FBI의 전술을 둘러싼 적법성은 완전히 별개의 논의입니다. 이 정보를 전혀 얻을 수 있다는 사실은 사이트가 "비공개"라는 일반적인 사용자 이해에도 불구하고 실크로드의 열악한 보안 관행을 나타냅니다. 개인 정보 보호가 보안과 혼동되면 취약점에 노출 될 가능성이 가장 확실하게 증가합니다.

로스 울브리히트가 개인 정보 보호와 보안을 구별한 경우 사이트가 여전히 실행될 가능성도 있습니다 (원래의 형태로, 어쨌든, 그것은 여러 번 부활하고, 지금 작동하는 것처럼 더 큰 사이트가 있다) 로스 울브리히트는 개인 정보 보호 와 보안을 구별했다면, 적극적으로 거대한 열램프로 성장하기 전에 모두를 보장하기 위해 노력하고 있습니다. , 지구에 약간 평균 이상의 기술 지식으로 모든 불미스러운 도둑을 유치. 대신, 개인 클럽과 모든 비밀은 누군가가 문을 열 수있는 방법을 발견하는 순간을 공개했다.

당신은 마약 주인이 아니에요, 그래서 당신은 왜 걱정해야합니까?

실크로드의 상실과 설립자의 투옥은 슬프고 공감하는 이야기가 아니지만 프라이버시와 진실하고 강력한 사이트 보안 사이의 미묘한 차이에 대한 매혹적인 사례 연구입니다. 디지털화된 의료 기록이나 대형 은행이 보유한 수백만 개의 신용 카드 번호를 생각하거나, 철통을 입은 소프트웨어 개발로 보호되지 않는다면, 그 정보는 공격자가 체리를 골라서 고를 수 있습니다(그리고 아이러니하게도 실크로드와 같은 사이트에 결국)가 거래와 정보를 비공개로 요구하는 많은 합법적 인 작업이 있습니다. 개인 정보 보호는 보안없이 존재하지 않습니다.

여러분과 같은 선량한 기업도 SQL 인젝션 공격 및 기타 OWASP 상위 10가지 취약점에 취약한 소프트웨어를 보유하고 있을 수 있으므로 이러한 취약점에 효율적으로 대비하고 완화하는 것이 중요합니다. 개발자가 프로세스 시작 단계부터 안전하게 코딩하도록 교육을 받는다면 이러한 결함은 빛을 보지 못할 것입니다. 조직은 보안 사고방식에 초점을 맞추고 개발팀이 안전하게 코딩할 수 있도록 역량을 강화하는 것이 필수적입니다. 재미있고 측정 가능하며 게임화된 방식으로 이를 수행하는 방법을 보여드릴 수 있습니다. 준비되셨나요?

Nun, das ist es (vorerst). Wir haben das Ende unserer Infrastructure as Code-Serie erreicht. Wir hoffen, Sie hatten Spaß daran, Sicherheitsprobleme in Docker, Ansible, Kubernetes, Terraform und CloudFormation zu überwinden. Bevor wir uns jedoch abmelden, haben wir noch eine weitere Sicherheitslücke, die Sie beherrschen müssen: Bugs in der Geschäftslogik.

Denken Sie, Sie sind jetzt bereit, Ihre Fähigkeiten zu testen? Probiere die letzte spielerische Herausforderung aus:

Wenn Sie sich in einigen Dingen immer noch nicht sicher sind, lesen Sie weiter:

Die Sicherheitslücken, auf die wir uns heute konzentrieren wollen, sind Geschäftslogik Mängel. Diese können auftreten, wenn Programmierer die Regeln der Geschäftslogik nicht ordnungsgemäß implementieren, wodurch ihre Anwendungen anfällig für verschiedene Arten von Angriffen werden könnten, falls ein böswilliger Benutzer sie ausnutzt. Je nach Zweck und Funktionalität, die in jeder Anwendung implementiert ist, kann ein Fehler in der Geschäftslogik dazu führen, dass Rechte erweitert werden, Ressourcen nicht ordnungsgemäß genutzt werden oder eine beliebige Anzahl unbeabsichtigter Geschäftsprozesse ausgeführt wird.

Im Gegensatz zu vielen Sicherheitslücken kann die falsche Implementierung von Geschäftslogikregeln überraschend subtil sein. Sie erfordern besondere Wachsamkeit, um sicherzustellen, dass sie sich nicht in Anwendungen und Code einschleichen.

Was sind einige Beispiele für Fehler in der Geschäftslogik?

Als Beispiel dafür, wie einfach es sein kann, Fehler in der Geschäftslogik zu induzieren, betrachten Sie das folgende Beispiel aus einer Docker-Umgebung, die mit einer Docker Compose-Datei definiert ist. Um Container auf die Ausführung von Funktionen vorzubereiten, könnte ein Entwickler eine Standard-Ressourcenrichtlinie verwenden, die in der Docker Compose-Datei definiert ist, wie im folgenden Beispiel:

bereitstellen:
Ressourcen:
Grenzwerte:
CPUs: „0,5"
Reservierungen:
CPUs: „0,5"

Oberflächlich betrachtet sieht das gut aus, aber diese Ressourcenrichtlinie für Container schränkt den Ressourcenverbrauch nicht richtig ein. Ein Angreifer könnte den Fehler in der Geschäftslogik ausnutzen, um einen Denial-of-Service (DoS) -Angriff zu implementieren.

Um zu versuchen, Benutzer daran zu hindern, zu viele Ressourcen zu beanspruchen, könnte ein Entwickler versuchen, besser zu definieren, was jeder Container unterstützen kann. Der neue Code könnte also eine Platzierungsbeschränkung enthalten:

bereitstellen:
Ressourcen:
Grenzwerte:
CPUs: „0,5"
Reservierungen:
CPUs: „0,5"
Platzierung:
Einschränkungen:
- „node.labels.limit_cpu == 100 M“
- „node.labels.limit_memory == 0,5"

Auf den ersten Blick sieht das so aus, als würde es das lösen Geschäftslogik Fehler. Die neue Platzierungsbeschränkung wirkt sich jedoch nicht auf das Limit für die Ressourcennutzung für den Docker-Containerdienst aus. Es wird nur verwendet, um einen Knoten für die Planung des Containers auszuwählen. In diesem Fall ist ein DoS-Angriff immer noch möglich. Der Angreifer müsste zuerst einen Docker-Container kompromittieren, wäre danach aber in der Lage, Ressourcen unbegrenzt abzubauen.

Wie Sie sehen, kann es ein kniffliges Unterfangen sein, über Fehler in der Geschäftslogik nachzudenken und zu programmieren, um sie zu beheben.

Beseitigung von Fehlern in der Geschäftslogik

Bei Fehlern in der Geschäftslogik liegt der Schlüssel darin, zu wissen, dass sie existieren. Sie müssen darauf achten, sie von Ihrer Umgebung fernzuhalten, während neuer Code geschrieben wird. Geschäftsregeln und bewährte Verfahren sollten in allen Phasen des Anwendungsentwicklungsprozesses, einschließlich Design, Implementierung und Test, klar definiert und überprüft werden.

Um beispielsweise zu verhindern, dass ein Fehler in der Geschäftslogik einen DoS-Angriff wie im obigen Beispiel ermöglicht, empfiehlt es sich, die Menge an Ressourcen zu begrenzen, die jeder von Ihnen erstellte Docker-Container verwenden kann. Insbesondere müssen im Abschnitt „Limits“ die Anzahl der CPUs und die Menge an Speicher angegeben werden, die ein Docker-Container verwenden kann. Ein Beispiel wäre:

bereitstellen:
Ressourcen:
Grenzwerte:
CPUs: „0,5"
Speicher: 100M
Reservierungen:
CPUs: „0,5"
Speicher: 50M

Die Verwendung von Code wie dem obigen Beispiel als Richtlinie würde einen großen Fehler in der Geschäftslogik aus der Umgebung entfernen und DoS-Angriffe verhindern. Dies würde auch dann funktionieren, wenn ein Angreifer einen der Docker-Container kompromittiert hätte. In diesem Fall wäre der Angreifer immer noch nicht in der Lage, seinen Halt zu nutzen, um Ressourcen zu erschöpfen.

Bedrohungsmodellierung kann hilfreich sein, indem sie definiert, wie verschiedene Angriffe stattfinden, und sicherstellt, dass Geschäftslogikregeln verwendet werden, um sie zu verhindern und einzuschränken. Tests auf der Grundlage von Compliance-Regeln und bekannten Missbrauchsfällen könnten ebenfalls hilfreich sein, um Fehler in der Geschäftslogik zu erkennen, die durch das Raster gleiten.

Fehler in der Geschäftslogik gehören zu den subtilsten Sicherheitslücken, die sich in Anwendungen einschleichen können, aber nicht weniger gefährlich sind als andere, bekanntere Risiken. Wenn Sie wissen, wie sie auftreten können, und bewährte Methoden anwenden, können Sie sie während der Anwendungsentwicklung von Ihrer Umgebung fernhalten. So wird sichergestellt, dass sie niemals in eine Produktionsumgebung gelangen, in der sie von Angreifern missbraucht werden können, die mit ihrer Ausnutzung bestens vertraut sind.

Schauen Sie sich das an Sicherer Codekrieger Blogseiten mit weiteren Informationen zu dieser Sicherheitslücke und dazu, wie Sie Ihr Unternehmen und Ihre Kunden vor den Folgen anderer Sicherheitslücken schützen können. Sie können auch probiere eine Demo Nehmen Sie an dieser IaC-Herausforderung auf der Secure Code Warrior-Schulungsplattform teil, um all Ihre Cybersicherheitsfähigkeiten zu verbessern und auf dem neuesten Stand zu halten.