Im Laufe des Kurses haben wir eine Reihe von Methoden gelernt, um
Fehler und Schwachstellen in verschiedenen Arten von Software und Infrastruktur zu entdecken. Normalerweise müssen Sie am Ende des Tests den
Kunden über alle gefundenen Schwachstellen oder mit allen Ergebnisse.
Dies erfolgt über einen Prüfbericht.
Was wir unter einem Testbericht verstehen, ist also im Grunde nur ein Dokument, das alles
enthält, was Sie durch Ihr Engagement gefunden haben, damit der Kunde oder der Administrator alle Schwachstellen und Schwächen beheben kann,
die Sie gefunden haben.
Diese Berichte werden auch häufig von Führungskräften gelesen.
Daher müssten Sie dies berücksichtigen.
Ein guter Bericht sollte also einfach sein.
Aber es ist jetzt auch leicht zu verstehen, wenn Sie als Tester arbeiten, dann hat das Unternehmen, für
das Sie arbeiten, wahrscheinlich eine eigene Vorlage und eigene Standards, die Sie beim Schreiben eines Berichts befolgen
müssen.
Und in vielen Fällen werden Sie das nicht einmal tun.
Sie leiten Ihre Ergebnisse einfach an ein anderes Mitglied Ihres eigenen Teams weiter und diese werden die
Lücken im Bericht ordnungsgemäß ausfüllen.
Daher müssen Sie wahrscheinlich keine von Grund auf neu schreiben.
Und in vielen Fällen schreiben Sie nicht einmal den eigentlichen Bericht, den der Kunde sieht.
Trotzdem möchte ich Ihnen noch zeigen, wie das geht, nur um Ihnen eine Vorstellung davon zu
geben, wie ein Testbericht aussieht.
Bevor ich Ihnen nun das Beispiel zeige, das ich habe, werde ich dieses
Repository einschließen, das im Grunde eine große Anzahl von Pantazis-Berichten enthält.
Sie können diese also tatsächlich durchsehen, um sich inspirieren zu lassen und einfach die verschiedenen Stile zu sehen, denen
verschiedene Unternehmen bei der Erstellung eines Testberichts folgen.
Sie können also auf eines davon klicken und Sie finden den Bericht und können ihn tatsächlich durchgehen, um
zu erfahren, wie dieses bestimmte Unternehmen berichtet, Sie schreiben ihre Berichte und vielleicht finden Sie etwas, das Ihnen gefällt und
das Sie in Ihren eigenen Bericht aufnehmen würden .
Ich werde dies also in die Ressourcen des Vortrags aufnehmen, damit Sie zur Inspiration darauf zurückkommen können.
Aber was ich wirklich tun möchte, ist, Sie durch eine Auswahl von Berichten zu führen, die wir hier in der Sicherheit verwenden.
Nur um Ihnen eine Vorstellung von den Hauptabschnitten zu geben, die die meisten Berichte enthalten.
Ich werde dies auch in die Ressourcen aufnehmen.
Fühlen Sie sich also frei, es zu ändern und zu verwenden oder einige Elemente davon zu übernehmen, wenn Sie möchten.
Sie werden also aus dem Repository hier merken, dass jedes Unternehmen seinen eigenen Stil hat, Berichte zu schreiben,
aber im Allgemeinen gibt es immer ein paar Hauptabschnitte, die Sie in jedem Bericht finden.
Also beginnend mit der ersten Seite hier haben wir das Deckblatt.
Sie können dies also wieder verkaufen, wie Sie möchten.
Sie haben normalerweise das Firmenlogo, Sie haben den Titel und dann das Datum des Berichts und
die Version.
Dies ist sehr wichtig.
Und dann haben wir die Firma, unsere Firmeninformationen.
Dieser Bericht wird also von uns geschrieben.
Dies sind unsere Firmeninformationen.
Und dann haben Sie im Kraftfeld die Firma, für die Sie diesen Bericht schreiben.
Sie hätten also den Firmennamen und eine spezifische ID für diese Firma.
Dies ist die Idee, dass Sie dieses Unternehmen in Ihren eigenen Aufzeichnungen identifiziert haben.
Auch dies ist wahrscheinlich nicht etwas, was Sie selbst tun werden.
Diese Idee bekommen Sie von Ihrem eigenen Unternehmen.
Und dann haben wir Kontaktinformationen für beide Unternehmen.
Sie können also in dieser Firma sehen, dass wir diese dort haben und dann Tester zwei mit ihren E-Mail-Adressen.
Dies könnte natürlich eine größere Liste mit dem gesamten Team sein, das den Test durchführt, und ähnlich der Firma,
für die Sie den Test durchführen.
Auch hier haben Sie ihre Namen, ihre Position im Unternehmen und ihre Kontaktdaten.
Denken Sie auch daran, dass Sie die erste Seite nicht immer so gestalten müssen, sondern mehr oder
weniger normalerweise auf der ersten Seite der Titel, das Datum, die Version und die Kontaktinformationen stehen.
So machen wir es.
Aber auch hier können Sie es so machen, wie Sie es möchten, und Sie können sich von der Ressource inspirieren lassen, die ich
hier aufnehmen werde.
Als nächstes haben wir normalerweise wieder das Inhaltsverzeichnis, wie Sie sehen können, dass einfache Dinge normalerweise
in jedem Dokument enthalten sind.
Dies wird Ihnen die Navigation durch das gesamte Dokument erleichtern.
Und wie ich hier sagte, können wir die Hauptabschnitte jedes Protestberichts sehen.
Daher ist es sehr wichtig, eine Zusammenfassung zu haben.
Dies ist eine Zusammenfassung des gesamten Engagements, das für weniger technische Personen konzipiert ist.
Es soll ihnen also eine Vorstellung von Ihren Erkenntnissen geben, ohne zu tief in die technischen Details einzutauchen.
Dann haben wir eine Zusammenfassung des Engagements, in der wir den Umfang detailliert beschreiben.
Dies ist also, was Sie getestet haben, welche Teile ihres Systems Sie getestet haben, welche Risikobewertungen Sie
verwendet haben und eine Übersicht über alles, was Sie gefunden haben.
Auch hier tauchen wir bisher noch nicht tief ein oder dies ist einfach nur eine Zusammenfassung des gesamten Engagements.
Sie werden eine bessere Vorstellung von all dem bekommen, wenn ich den Bericht durchgehe.
Und dann im Abschnitt "Technische Details" tauchen Sie hier wirklich tief in alles ein, was Sie gefunden
haben.
Wir haben also im Grunde für jeden Fund eine Rubrik.
Wie Sie sehen können, ist dies nur ein Beispiel.
Also habe ich nur drei Feststellungen gemacht.
Wir haben eine anfängliche Injektion, eine standortübergreifende Anforderungsfälschung.
Ja.
SRF und eine Informationsoffenlegung.
Wie Sie im ersten Abschnitt sehen können, hatten wir im Grunde nur eine Zusammenfassung von allem,
was wir gefunden haben, während in den technischen Details im Grunde genommen jeder einzelne Befund aufgeschlüsselt wurde.
Und wir werden darüber sprechen, wie wir es im Detail gefunden haben, wie wir es replizieren können.
Wenn möglich, fügen Sie Screenshots bei, damit das technische Team den Schweregrad dieser
Sicherheitsanfälligkeit genau erkennen und beheben kann.
Sie werden feststellen, dass andere Unternehmen am Ende einen Anhang hinzufügen werden, sie werden Empfehlungen enthalten, in denen
Sie genau sagen, wie Sie Schwachstellen beheben können.
Wie gesagt, es kommt wirklich auf die Firma an.
Jedes einzelne Unternehmen hat seinen eigenen Stil und jedes einzelne Unternehmen hat sein eigenes Format.
Was ich Ihnen hier zeige, ist nur ein Beispiel dafür, wie wir es machen.
Sie können sich von den Ressourcen inspirieren lassen und müssen in vielen Fällen nur der Vorlage Ihres Unternehmens
folgen, weil es nicht möchte, dass Sie es auf Ihre Weise tun.
Gehen wir also zur nächsten Seite und Sie werden sehen, dass wir auf dieser Seite die rechtlichen Informationen haben.
Und deshalb habe ich eigentlich gesagt, dass du das wahrscheinlich nicht selbst machen wirst.
Sie müssen dies nie selbst tun, da Sie Teile des Berichts wie diesen haben.
Sie müssen sie nie ändern und werden tatsächlich von der Rechtsabteilung Ihres Unternehmens geschrieben.
Sie werden also für alles verantwortlich sein, was außer Kontrolle geraten könnte, um sicherzustellen, dass Sie nicht verklagt werden.
Wenn etwas schief geht, enthält es Dinge wie Haftungsausschlüsse, BIP, unsere Privatsphäre, rechtliche Dinge und all das,
was wir nicht wirklich gut kennen.
Normalerweise schreibe ich Tester und Juristen, und dann haben wir das Änderungsprotokoll des Dokuments.
Jedes Mal, wenn eine Änderung am Dokument vorgenommen wird, können Sie sehen, dass wir das Datum, die Version
und einen Kommentar haben.
Warum haben wir diese Änderung vorgenommen oder was ist an dieser Änderung so bedeutsam?
Dies war also der erste Bericht, als wir ihn am 1. Januar erstellten, und dann am 10. Januar eine zweite Version,
in der wir mit der zweiten Phase fertig sind.
Auch dies sind nur Beispiele.
Aber nur um Ihnen eine Vorstellung davon zu geben, dass es sehr, sehr wichtig ist, ein Änderungsprotokoll aller Änderungen
zu führen, die dieses Dokument durchläuft.
Das machen nicht alle Unternehmen.
Aber auch das ist nur unsere eigene Entscheidung, es in unseren Bericht aufzunehmen.
Ich sage dies immer wieder, um Ihnen eine Vorstellung davon zu geben, dass es keine festen Regeln für die Erstellung dieser Art von Dokumenten gibt.
Sie können alles hinzufügen oder entfernen, was Sie möchten, aber die Hauptteile sind der rechtliche Teil, die Zusammenfassung
und dann der technische Teil.
Dies werden die Hauptteile des Berichts sein.
Jetzt haben wir also die Zusammenfassung und Sie können diese durchlesen.
Das soll nicht lange dauern.
Also meiner Meinung nach muss es eine Seite sein, maximal zwei Seiten, wenn Sie wirklich müssen.
Und es heißt im Grunde nur, dass wir angewiesen wurden, ein System zu testen.
Es wird erklärt, wie dieses Dokument aufgebaut ist, wobei der erste Abschnitt weniger detailliert ist, nur um Ihnen eine
Vorstellung vom Risiko zu geben.
Und die zweite ist detailliert, damit die Techniker diese Risiken verstehen und beheben können und dann
die Risikobewertung erhalten.
Wir gehen daher davon aus, dass dies aufgrund der von uns gefundenen Schwachstellen mit einem hohen Risiko verbunden ist.
Es wird die von uns verfolgte Methodik detailliert beschreiben.
Und dann haben wir hier ein paar Charts.
Denken Sie daran, dieser Teil wird von den Führungskräften gelesen.
Das sind Leute, die meistens nicht sehr technisch sind und auch nicht viel Zeit haben.
Daher fügen wir hier Grafiken hinzu, um ihnen die Anzahl der gefundenen Schwachstellen zu zeigen.
Wir können also sehen, dass wir fünf Schwachstellen haben, die hoch sind.
Wir haben 10, die mittel und 8 niedrig sind.
Auf diese Weise erhalten sie ein wirklich gutes Verständnis für die Bedrohungen, denen sie ausgesetzt sind.
Und dann gehen wir noch einmal in die Zusammenfassung.
Dies wird immer noch von den weniger technisch versierten Leuten gelesen.
Daher beschreiben wir zunächst den Anwendungsbereich, um sicherzustellen, dass wir ihnen sagen, was wir getestet haben, obwohl sie uns
bereits gesagt haben, was wir testen sollen, nur damit für den Fall, dass in Zukunft etwas außerhalb unseres Anwendungsbereichs
entdeckt wird, und Sie kommen zu uns zurück, wir können sagen, das war außerhalb des Rahmens.
Das haben wir nächstes Jahr nicht getestet, auch nicht die Risikoeinstufung.
Sie werden dies also in jedem Dokument haben.
Sie möchten, dass ich es ändere.
Wir sagen im Grunde nur, wie wir eine bestimmte Schwachstelle als niedrig, mittel, hoch oder kritisch einstufen
würden.
Und wir sagen unserer Meinung nach, wie Sie mit den niedrigen, mittleren, hohen und kritischen Schwachstellen umgehen sollten, die Sie für die
kritischen Schwachstellen sehen, die Sie unserer Meinung nach sofort beheben müssen, während Sie für das Gesetz in der
nächsten Zeit behoben werden müssen Zyklus aktualisieren.
Auch dies ist nur unsere eigene Meinung.
Als nächstes haben wir die Ergebnisse der Überprüfung.
Wir sind also immer noch in Abschnitt eins.
Das ist nach wie vor für die Führungskräfte.
Wir müssen nicht zu tief tauchen.
Wir haben also nur die Schwachstellen-Idee erhalten.
Und Sie können an der ersten Schwachstelle erkennen, dass sie kritisch ist.
Es ist eine Ezekial-Injektion.
Und in vielen Fällen, in vielen Berichten, werden sie es tatsächlich stoppen und sagen, es sei nur eine ESKIL-Injektion.
Wir zeigen gerne die Auswirkungen in diesem Abschnitt, denn wie ich schon sagte, diese Jungs sind nicht technisch.
Wenn es sich also um eine Injektion handelt, wissen sie möglicherweise nicht, was eine ESKIL-Injektion ist.
Was sie interessiert, sind die Auswirkungen dieser Schwachstelle.
Auch hier haben sie nicht viel Zeit, also müssen Sie direkt auf den Punkt kommen.
Wir sagen also, dass es sich um eine natürliche Injektion handelt, die zu einem autorisierten Datenbankzugriff führen
könnte.
Jetzt wissen sie also, dass ein Hacker mit dieser Schwachstelle auf ihre Datenbank zugreifen kann.
Das ist wahrscheinlich ziemlich schlimm.
Eine weitere Schwachstelle, die wir gefunden haben, ist mittel und übertrieben.
SRF wieder, viele Berichte werden hier aufhören, erklärt Nicht-Technikern wirklich nichts.
Wir sagen also, dass Clients gezwungen werden können, bestimmte nicht kritische Anforderungen zu senden.
Deshalb ist es eine mediale, keine unkritische Anfrage.
Aber sie können gezwungen werden, Dinge einzureichen.
Und dann haben wir eine Schwachstelle, bei der die HP-Version offengelegt wird.
Dies ist also nicht sehr kritisch, da es sich nicht um eine tatsächliche Schwachstelle handelt, die ausgenutzt
werden kann, um Zugang zu erhalten oder Benutzerdaten offenzulegen.
Diese Informationen könnten jedoch für Hacker nützlich sein, um sich mit anderen Angriffen zu verketten oder Schwachstellen für
diese spezielle Version zu entdecken.
Und deshalb ist es ein Tief.
Deshalb muss man sich nicht so dringend um die kritischen kümmern, wie wir oben und
hier erwähnt haben.
Und lesen Sie den Text gerne hier, Sie werden sehen, dass vieles davon im Grunde nur dazu dient, uns den
Rücken freizumachen und sicherzustellen, dass sie alles verstehen, was in dem Bericht steht.
Und das wäre das Ende des Sommers.
Und jetzt sind wir bei den technischen Details.
In diesem Abschnitt haben wir also im Grunde, wie ich bereits sagte, einen Unterabschnitt für jeden einzelnen Befund, den wir
haben.
Und wir tauchen wirklich tief in die Details dieser Entdeckung ein.
Sie können also sehen, dass dies die eigentliche Injektion ist, die wir zuvor in der Zusammenfassung erwähnt haben.
Aber dieses Mal geben wir ihnen tatsächlich die URL, die anfällig ist.
Wir geben ihnen den verwundbaren Parameter.
Wir geben ihnen Referenzen, um zu verstehen, was Eskil-Injektion ist.
Falls sie es nicht verstehen, geben wir ihnen die genaue Anfrage und die genaue Antwort, die wir
erhalten haben, wodurch wir festgestellt haben, dass diese spezielle Seite anfällig für eine Injektion ist.
Dann geben wir ihnen die Auswirkungen hier im Detail und sagen nicht nur, dass sie auf die Datenbank zugreifen können.
Wir sagen also, dass sie auf die Datenbank zugreifen können.
Sie können Daten abrufen, auf die wir Zugriff auf die Tabelle des Benutzers haben.
Sie werden also in Details eintauchen und sollten hier sogar Screenshots einfügen.
Wenn Sie denken, dass sie im Abschnitt zur Risikominderung nützlich sein werden
Wir geben ihnen nur eine kurze Empfehlung.
Wie gesagt, einige Unternehmen geben detaillierte Empfehlungen.
Dies hängt auch stark vom Engagement ab.
In diesem Beispiel sagen wir also im Grunde nur, verwenden Sie Prepare-Anweisungen mit parametrisierten Abfragen, und wir geben ihnen eine
Referenz, um zu lernen, wie das geht oder um zu verstehen, wie es funktioniert.
Und das ist es so ziemlich.
Also werden Sie das für jede einzelne Schwachstelle wiederholen, die Sie gefunden haben?
Ich lasse den Rest leer, da dies nur ein Beispiel ist, aber Sie bekommen die Idee.
Sie haben also einen Unterabschnitt für jedes Ergebnis, in dem Sie alles im Detail erklärt haben, damit
sie die Schwachstelle verstehen und sie dann beheben können.
Am Ende hätten viele Unternehmen einen Anhang und sie könnten einen größeren Empfehlungsbereich haben, wie gesagt,
dies ist unser Stil, Berichte zu schreiben, wobei jedes Unternehmen seinen eigenen Stil hat, wenn Sie möchten.
Dies kann einige Zeit damit verbringen, die Beispielberichte durchzugehen, die wir in diesem Repository haben.
Natürlich füge ich sowohl Links zu meinem Beispiel als auch zu den anderen Beispielen und Ressourcen hinzu, damit
Sie sie selbst durchgehen und sich ein Bild davon machen können, wie Pennhurst-Berichte aussehen.
Aber wie gesagt, in vielen Fällen füllst du einfach eine Probe aus, ähnlich der, die wir hier haben.
Sie werden also nie aufgefordert, eine von Grund auf neu zu entwickeln.