Secure Code Review: Ein praktischer Ansatz

In diesem Artikel geht es um verschiedene Code-Review-Techniken und deren Anwendung in der realen Welt

Was Sie lernen werden:

Was ist Secure Code Review und wie geht man in realen Szenarien damit um?

Was Sie wissen sollten:

Grundlegende Sicherheitskonzepte

Überprüfung des sicheren Codes:

Secure Code Review ist ein Prozess, der den unsicheren Code identifiziert, der in einer späteren Phase des Softwareentwicklungsprozesses eine potenzielle Sicherheitsanfälligkeit verursachen und letztendlich zu einer unsicheren Anwendung führen kann. Wenn eine Sicherheitsanfälligkeit in früheren Phasen von SDLC erkannt wird, hat sie weniger Auswirkungen als in späteren Phasen von SDLC – wenn der unsichere Code in die Produktionsumgebung verschoben wird. Im SDLC-Prozess (Software Development Life Cycle) fällt der Secure Code Review-Prozess in die Entwicklungsphase, dh wenn die Anwendung von den Entwicklern codiert wird, können sie eine Selbstüberprüfung des Codes durchführen, oder ein Sicherheitsanalyst kann die Codeüberprüfung durchführen oder beides. Die Entwickler können automatisierte Tools verwenden, die in ihre IDE integriert werden können (Eclipse, MS VS usw.) und gleichzeitig Codierung und Codeüberprüfung durchführen können. Danach können sie die Hilfe eines Sicherheitsexperten in Anspruch nehmen, um weitere Fehler im Code zu identifizieren, da die Sicherheitsexperten eine intrinsischere Sicht auf Sicherheitsprobleme haben, die von den Entwicklern übersehen werden könnten.

Verschiedene Studien und Umfragen zeigen, dass ungefähr 75% der Angriffe auf eine unsichere Anwendung zurückzuführen sind, in der unsicherer Code enthalten ist. Auf diese Weise wird es zu einem sehr wesentlichen Bestandteil von SDLC, der rigoros durchgeführt werden sollte. Entwickler konzentrieren sich meist auf die Funktionalität der Anwendung und ignorieren den sicheren Codierungsansatz. Heutzutage sind sie sich jedoch aufgrund der zunehmenden Vorfälle von Hacking- und Serverangriffen der Codeüberprüfung bewusster geworden.

Abbildung – 1

Techniken zur sicheren Codeüberprüfung:

Im Allgemeinen können wir den Secure Code Review-Prozess in zwei verschiedene Techniken unterteilen:

  1. Automatisiertes Tool Based / Black Box: Bei diesem Ansatz wird die sichere Codeüberprüfung mit verschiedenen Open Source / kommerziellen Tools durchgeführt. Meistens verwenden Entwickler sie während der Codierung, aber ein Sicherheitsanalyst kann auch Hilfe von ihnen nehmen. Tools sind sehr nützlich bei der Codeüberprüfung, wenn wir den sicheren SDLC-Prozess in der Organisation implementieren und das Tool den Entwicklern selbst zur Verfügung stellen, um während der Codierung eine “Selbstcode” -Überprüfung durchzuführen. Die Tools sind auch nützlich bei der Analyse großer Codebasen (Millionen von Zeilen). Sie können potenzielle unsichere Codeteile in der Codebasis schnell identifizieren, die vom Entwickler oder einem Sicherheitsanalysten analysiert werden können.
  2. Manuell / White Box: Bei dieser Technik wird eine gründliche Codeüberprüfung über den gesamten Code durchgeführt, was zu einem sehr langwierigen und ermüdenden Prozess werden kann. In diesem Prozess können jedoch logische Fehler identifiziert werden, die mit automatisierten Tools möglicherweise nicht möglich sind, z. B. Probleme mit der Geschäftslogik. Automatisierte Tools sind meist in der Lage, technische Fehler wie Injection-Angriffe zu finden, können jedoch Fehler wie Autorisierungsprobleme übersehen. In diesem Prozess können wir uns, anstatt Zeile für Zeile durch die gesamte Codebasis zu gehen, auf mögliche Probleme im Code konzentrieren. Diesen potenziellen Schwachstellen kann eine hohe Priorität eingeräumt werden. Wenn wir beispielsweise in C / C ++ versuchen, eine Kopierfunktion im Code zu finden und zu überprüfen, ob Funktionen wie strcpy() zum Ausführen der Kopierfunktion verwendet werden. Wie wir wissen, ist strcpy () bekanntermaßen anfällig für Pufferüberlaufangriffe. Möglicherweise möchten wir auch überprüfen, ob in der Anwendung eine benutzerdefinierte Verschlüsselung verwendet wird, die automatisierten Tools möglicherweise fehlt, da sie nur Standardalgorithmen identifizieren können.

    Der beste Ansatz ist also eine Mischung aus beidem, abhängig vom Volumen und der Kritikalität der Daten. In der heutigen Welt, in der viele komplexe Anwendungen entwickelt werden, können wir keine der oben genannten Techniken ignorieren.

Vorteile von Secure Code Review:

Es gibt einige Faktoren, die bei der Entwicklung eines robusten Zugriffskontrollmechanismus in der Webanwendung berücksichtigt werden sollten:

  1. Aufwandsvorteil: Der Aufwand zur Behebung der Sicherheitsanfälligkeiten in der früheren Phase des SDLC-Prozesses ist viel geringer als in der späteren Phase des Prozesses. Sobald der Code vollständig ist und der Fehler nicht identifiziert wurde, ist es ein sehr mühsamer und zeitaufwändiger Prozess, Probleme zu finden, sobald die Anwendung bereit ist, in die Produktion zu gehen. Außerdem kann die Last-Minute-Reparatur die gesamte Funktionalität des Programms beeinträchtigen und die für die Produktfreigabe festgelegten Fristen behindern. Wer weiß, es kann eine weitere Sicherheitslücke schaffen, die mit einem großen und komplexen Code leicht möglich sein kann.
  2. Kostenvorteil: Die Kosten sind direkt proportional zum Aufwand. Nicht nur Entwicklungskosten, sondern auch eine in der Produktionsumgebung identifizierte Sicherheitsanfälligkeit kann mehr Kosten verursachen. Auch hier lohnt es sich, da die mit einem Angriff verbundenen Kosten viel steiler sein können.
  3. Compliance: Einige Compliance-Anforderungen, wie z. B. PCI, machen es erforderlich, vor der Einführung des Produkts eine sichere Codeüberprüfung durchzuführen. So hat eine Organisation, die dem SDLC folgt, bessere Chancen, zertifiziert zu werden.
  4. Reputation: Secure Code Review beseitigt die meisten Sicherheitslücken in der früheren Phase und macht es sicherer als nur Black-Box-Assessments. Es besteht also eine geringere Chance, dass das Produkt kompromittiert wird, daher eine geringere Chance auf Reputationsschäden.

Ansatz:

Diese basieren auf einer Mischung aus Standardprozess und meinem eigenen Ansatz. Es kann von Person zu Person unterschiedlich sein.

Standardverfahren :

Abbildung-2

Umfang definieren: Zunächst müssen Sie den Umfang der Codeüberprüfung und den damit verbundenen Aufwand verstehen und grob abschätzen. Außerdem können Budgetbeschränkungen definiert werden. Welche Art von Code Review kann durchgeführt werden? Black Box oder White Box? Versuchen Sie, die Geschäftslogik der Anwendung zu verstehen. Denken Sie daran, welche Schwachstellen Sie suchen müssen, wie OWASP Top 10, SANS, etc … Man kann versuchen, sie so viel wie möglich zu überprüfen, wenn nicht alle von ihnen. Dann können Sie ableiten, wie viele davon mit Tools erkannt werden können und welche für die manuelle Überprüfung am besten geeignet sind.

Kategorisieren Sie die Schwachstellen: Was ist Ihre Priorität, dh welche Art von Schwachstellen werden Sie als Priorität betrachten? In Geschäftsanwendungen können Sie sich beispielsweise hauptsächlich auf die Geschäftslogik der Anwendung konzentrieren und tief in diese eintauchen, da die technischen von Tools leicht erkannt werden können. Priorisieren Sie sie.

Im Folgenden finden Sie einige Kategorien, die Sie sich ansehen können:

  • Autorisierung
  • Authentifizierung
  • Injektionsfehler
  • Unsachgemäße Fehlerbehandlung / Ausnahmefehler
  • Verschlüsselung (Kryptographie)
  • Überwachung und Protokollierung
  • Sitzungsbezogene Fehler (Sitzungsverwaltung)
  • Unsichere Konfiguration

Empfehlung: Als Sicherheitsanalyst ist es unsere Pflicht, von Tools generierte Fehlalarme zu filtern und zu validieren, um zu bestätigen, dass es sich um tatsächliche Fehler handelt. Nach einer ordnungsgemäßen Codeüberprüfung sollten Sie die gefundenen Sicherheitsanfälligkeiten in einem umfassenden Bericht über die Kategorie der Sicherheitsanfälligkeit und deren Minderung dokumentieren. Sie können einen Schritt weiter gehen und einen sicheren Beispielcode vorschlagen. Ich persönlich füge die Code-Snippets auch in den Bericht ein, vorzugsweise in eine Excel-Datei, und hänge sie dann an.

So gehe ich persönlich vor. Die folgenden Punkte basieren auf meinen bisherigen Erfahrungen bei der Codeüberprüfung. Ich muss noch viel lernen und die folgenden Punkte können in jedem Zustand zutreffen oder auch nicht:

Führen Sie immer manuelle Überprüfungen durch: Die automatisierte Codeüberprüfung ist ein Prozess, bei dem Sie die Scan-Tools wie Rational, Unze Labs und Parasoft auf der Codebasis ausführen, gefolgt von einer manuellen Überprüfung der Ergebnisse. Der Scanner kennzeichnet den gesamten Code anhand seiner Wahrnehmung mit Schwachstellen. Jetzt ist es die Aufgabe des Auditors, zwischen echten Problemen und Fehlalarmen zu unterscheiden. Hier beginnt der eigentliche Schmerz. Sie beherrschen nicht jede Sprache. Daher ist die Hilfe sprachspezifischer Ressourcen erforderlich. Inzwischen bin ich mit fast allen wichtigen Sprachen vertraut (.NET, Java, PHP) spezifische Schwachstellen. Wenn Sie eine Black-Box-Bewertung durchführen, wissen Sie nie, wo das eigentliche Problem liegt.

Sprechen Sie zuerst mit Entwicklern: Je mehr Sie Entwickler in Ihren Code-Review-Prozess einbeziehen, desto effektiver wird die Analyse. Sie erhalten das Vertrauen, dass alles, was Sie tun, auf dem richtigen Verständnis des Codes basiert. Auf der anderen Seite freuen sich Entwickler auch, dass Sie ihnen Vertrauen entgegenbringen, anstatt sofort etwas Verletzliches zu deklarieren.

Halten Sie ein Notizbuch und einen Stift bereit, um den Ablauf des Programms zu verstehen. Es ist notwendig, die Quelle des Schadens zu verstehen und zu wissen, wo er sich im Code widerspiegelt, um die tatsächlichen Schwachstellen zu erkennen. Nur zu sehen, dass der Makel in das Programm eindringt und sich in einem anderen Teil des Programms widerspiegelt, bedeutet nicht immer, dass es beispielsweise anfällig für Cross Site Scripting ist. Auch hier hilft es, mit Entwicklern zu sprechen, da sie möglicherweise einen zentralisierten Eingabefilter- / Validierungsmechanismus implementieren. Springen Sie also nicht einfach zu Schlussfolgerungen.

Verwenden Sie einen erweiterten Texteditor: Der Texteditor sollte in der Lage sein, einen Begriff in der gesamten Codebasis zu suchen. Ein solcher Texteditor ist Notepad ++. Es durchsucht den Begriff und hebt sie hervor, so dass Sie sehen können, wo an allen Stellen der jeweilige Begriff verwendet wird. Es hilft Ihnen, die Teile zu verbinden und das vollständige Bild zu sehen.

Haben Sie genügend Zeit für die Codeüberprüfung, da Sie Ihre Gedanken mehr als einmal anwenden müssen, um echte Schwachstellen zu erkennen. Bitten Sie Ihre Kunden daher immer um ausreichend Zeit, um das Projekt vollständig abzuschließen.

Zum Zeitpunkt der Codeüberprüfung hilft es immer, mit dem Internet verbunden zu sein. Bestimmte Begriffe, Funktionen oder Methoden ärgern Sie immer, wie Sie sie vielleicht noch nicht gesehen haben. Google hilft sehr, sie zu verstehen.

Schwachstellen im Kontext der Anwendung finden: Sie sollten nicht nur reale und anwendbare Schwachstellen im Kontext der Anwendung aufgreifen – da dies die Anzahl der Probleme verringert –, sondern auch die Gegenmaßnahmen im Bericht vorschlagen. Das macht Entwickler glücklich und zuversichtlich. Der Scanner kann jedes Problem als hoch, mittel oder niedrig kennzeichnen. Es liegt in Ihrer Verantwortung, ihnen ein angemessenes Ranking basierend auf dem Anwendungskontext zu geben.

Jeder liebt sein eigenes Programm: Programme sind wie ein Entwickler-Baby. Identifizieren Sie nicht immer die Schwächen des Programms, sondern schätzen Sie sie auch, wenn Sie einen robusten Mechanismus finden, der im Programm verwendet wird. Auf diese Weise können Sie sie freundlich machen und sie werden immer kommen, um ihren Code überprüfen zu lassen. So sind beide dann glücklich.

Trainiere sie: Zu guter Letzt trainiere Entwickler über die Schwachstellen in der realen Welt. Geben Sie ihnen Schulungen, binden Sie sie ein und ermutigen Sie sie, ihre Codes vor der Produktion zu überprüfen. Sagen Sie ihnen, wie es Aufwand und Geld spart. Wenn Sie ein Scan-Tool haben, das Plug-Ins für IDE unterstützt, installieren Sie es auf ihren Computern, damit sie die richtige Entwicklung und eine Hand-für-Hand-Überprüfung durchführen können.

Eine Beispielillustration:

Betrachten Sie dieses Beispiel( Owasp WebGoat-Projekt):

String Benutzername = “”;

String Passwort = “”;

benutzername = s.getParser().getRawParameter(BENUTZERNAME);

Passwort = s.getParser().getRawParameter(PASSWORT);

……………..

………..……

String query = “SELECT * FROM user_system_data WHERE user_name = ‘”

+ benutzername + “‘ und Passwort = ‘” + Passwort + “‘”;

EG.addElement(neues StringElement(Abfrage));

Die Eingaben des Benutzers werden über getRawParameter angefordert und den Variablen ‘username’ und ‘password’ zugewiesen. Auch hier werden sie direkt in der SQL-Abfrage ohne Eingabevalidierung verwendet und auch in die dynamische Abfrage eingebettet. Jeder böswillige Benutzer kann diese Abfrage manipulieren, um seine eigenen beliebigen SQL-Codes auszuführen. Wenn wir also versuchen, alle Einstiegspunkte in die Codebasis zu finden (in diesem Fall getRawParameter ), erkennen wir möglicherweise Injektionsfehler. Selbst wenn wir nach SQL-Abfragen suchen, die im Code verwendet werden, können sie ein Fall einer möglichen SQL-Injektion sein, wenn wir feststellen, dass sie als dynamische Abfragen verwendet werden.

Im Netz: https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

https://www.owasp.org/images/2/2e/OWASP_Code_Review_Guide-V1_1.pdf

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.