zurück zum Artikel

Die Entwicklung der OWASP Top 10, einer Liste von Sicherheitsrisiken, fand Ende 2017 erstmals öffentlich statt. Die Neuerungen können sich sehen lassen, boten aber auch Stoff für Diskussionen.

Ende November 2017 sind nach einigen anfänglichen Widrigkeiten die vom OWASP benannten Top-10- Sicherheitsrisiken in ihrer sechsten Auflage erschienen.

OWASP ist das "Open Web Application Security Project" – eine nach amerikanischem Recht gemeinnützige Organisation, die Softwaresicherheit sichtbarer machen will. Dazu dienen Tools und zahlreiche Dokumente, die alle unter einer FOSS-Lizenz stehen. Jeder kann Beiträge leisten.

Erstmals hatte die Entwicklung an dem Awareness-Dokument wirklich öffentlich stattgefunden. Mit etwas Abstand betrachtet stellt sich die Frage, wie die Top 10 zu bewerten sind und wie die Öffentlichkeit sie aufgenommen hat.

Die 2017er Ausgabe [1] hat eine längere Geschichte – mit gutem Ende. Obwohl die Top 10 ein sogenanntes Flaggschiffprojekt vom OWASP sind, lud sie durch die Open-Source-Brille betrachtet bisher nicht gerade zur Zusammenarbeit ein. Die vorigen Autoren schrieben üblicherweise eine Nachricht

mit einem Inhalt wie "hier ist der RC1 als PDF, schaut mal drüber" an die entsprechende Mailing-Liste und klebten ihr Firmenlogo drauf. Die Top 10 für 2017 hatten dieselben Anfänge und sollten planmäßig im Juli oder August 2017 erscheinen.

Die Rechnung ohne die Community gemacht

Allerdings hatten die beiden Autoren zwei Punkte in ihren Release-Kandidaten 1 [2] hineingeschrieben, bei denen sie die Rechnung ohne den Wirt OWASP gemacht haben: Zumindest der siebte Eintrag (A7) "Insufficient Attack Protection" war ein Reibungspunkt. Zum einen in technischer Hinsicht – viele Leute haben sich beschwert [3], dass der Punkt als Anreiz geeignet sei, defekte Software weniger zu fixen und stattdessen durch andere Maßnahmen Löcher mehr oder weniger gut zu kaschieren. Zum anderen lag ein Interessenkonflikt vor: Die Ankündigung des RC1 und ein Eintrag im Firmenblog [4] waren nicht nur beide am 10. April erschienen, sondern in A7 war namentlich das recht seltene Produkt RASP (Runtime Application Self-Protection) im Release-Kandidaten referenziert ("You can use technologies like WAFs, RASP, and OWASP AppSensor to detect or block attacks, and/or virtually patch vulnerabilities."). Die Empörung außerhalb und innerhalb vom OWASP war schließlich dermaßen groß, dass zwei Monate später die Teilnehmer des OWASP Summit, einer Arbeitskonferenz, die langjährige Leitung des Projektes abgelöst und den RC1 zurückgezogen haben.

Das neue vierköpfige Team hatte Mitte Oktober den neuen Release-Kandidaten 2 auf der GitHub-Plattform veröffentlicht, die zur echten Zusammenarbeit einlädt. Diskussionen fanden auf dem Weg zum RC2 und zum Release nur dort statt – in zeitgemäßer, transparenter Weise. Das bewirkte, dass viele die Chance zum Mitdiskutieren genutzt haben – der Anhang zur Top 10 erwähnt schließlich die aktiven Beteiligten mit ihrem Handle oder sogar namentlich.

Angesichts der dadurch resultierenden Mehrarbeit für das Team war es umso erfreulicher, dass es den Zeitplan dennoch einhalten konnte und am 21.11.2017 die finale Version der Top 10 erschienen ist.

Blick auf die Grundlage

Das Deckblatt der OWASP Top 10 2017 trägt den Untertitel "The Ten Most Critical Web Application Security Risks". Das führt zu der Frage, wie die Beteiligten die kritischsten zehn Risiken ermittelt haben.

Wie zuvor dienten als Grundlage Daten, die aus dem sogenannten "Data Call" stammen. Dabei bat das Team Hersteller und Institutionen, ihre Scan-Ergebnisse einzusenden. Die Rückläufe hat es ausgewertet [5] und einem sogenannten Risk Rating unterzogen (s. Abb. 1).

Grundsätzlich ist ein Risiko das mathematische Produkt aus Schadeneintrittswahrscheinlichkeit und dem Schadenausmaß. In ersteren Faktor sind Daten der Data Calls eingeflossen (Weakness Prevalence). Wie man dem Risk Rating entnehmen kann, hat das Team die Daten ähnlich wie bei CVSS noch gewichtet, je nachdem

• wie leicht die Lücke auszunutzen ist (Exploitability) und
• wie einfach sie zu entdecken ist (Weakness Detectability).

Beispielsweise ist das Schadensausmaß bei SQL Injection immer der GAU, auch wenn die Häufigkeit des Auftretens geringer ist als bei Cross-Site Scripting (XSS). Mehr zu den Risiken ist den Seiten 5, 21 und 22 des Reports zu entnehmen.

Die OWASP Top 10 können nur technische Risiken beurteilen – das Businessrisiko mag im Einzelfall anders sein und lässt sich über die technische Betrachtung nicht ermitteln: Eine SQL Injection auf einem längst vergessenen Server in einem ungepatchen CMS, das außer Webseiten keine Informationssicherheitswerte bietet, hat sicherlich eine andere wirtschaftliche Konsequenz für die betroffene Organisation als ein gehacktes Finanzportal.

Dem Data Call sind jedoch nur acht der zehn Punkte entnommen. Die restlichen beiden kamen aus einer Firmenumfrage und sind nach vorne gerichtete Punkte, also solche, die für die nächsten drei bis vier Jahre relevant sein sollen.

Wichtige Extras hinter den Top 10

Was viele vergessen: Neben den ersten zehn gibt es eine Reihe lesenswerter einleitender sowie abschließender Seiten, auf denen die Macher erklären, was ein Risiko ist und wie es die zehn Plätze besetzt hat.

Die zusätzlichen Seiten verdeutlichen, was die OWASP Top 10 darstellen: ein Awareness-Dokument, bei dem Application Security anfängt. Nach den zehn Punkten nimmt das Dokument die unterschiedlichen Zielgruppen wie Entwickler, Security Tester, Organisationen und neuerdings Application-Manager unter dem Titel "What's next" an die Hand. In den weiterführenden Tipps sind auf jeweils einer Seite fünf oder sechs grundlegende Punkte für die einzelnen Zielgruppen zu finden. Aus Security-Managementsicht sind es somit die wirklich wichtigen Seiten.

Leider fokussieren sich viele nur auf die eigentlichen Top 10. Besonders das Marketing vieler Hersteller und Dienstleister ist regelmäßig ein falsch verstandener Anlass zum Phrasendreschen.

Dabei sind sie explizit nicht

• ein heiliger Gral der Websicherheit,
• die Abdeckung aller Risiken,
• eine Darstellung des SDLC (Software Development Lifecycle Project),
• eine Schablone für Pentests,
• eine Richtlinie, nach der sich WAF-Hersteller (Web Application Framework) oder DAST-Scanner-Anbieter (Dynamic Application Security Testing) ab sofort und ausschließlich richten müssen.

OWASP weiß von den fachlichen Fehlinterpretationen, die es jedoch auch mit einem lachenden Auge betrachtet, da die OWASP Top 10 der am häufigsten zitierte Standard der Applikationssicherheit sind. Die Ausreißer nimmt man dabei in Kauf – frei nach dem Sprichwort "There is no such thing as bad publicity": Auch eine schlechte Werbung ist hilfreich.

Blick auf die Charts

Fachlich haben die Top 10 einen recht großen Schritt getan, auch wenn einiges nicht unumstritten war.

Wie (leider) nicht anders zu erwarten, hat SQL Injection erneut den ersten Platz eingenommen – in Top-10-Terminilogie A1. Noch immer können Angreifer viel zu häufig mit SQL-Befehlen in Webformularen Daten stehlen. Auf der zugehörigen Seite dazu warnen die Macher der Top 10 zusätzlich vor Injections in NoSQL-Datenbanken sowie in LDAP oder durch EL (Expression Language), wenngleich Letzteres nach Meinung des Autors seltener geworden ist.

Der zweite Platz (A2) ist mit "Broken Authentication" recht ähnlich zu 2013. Dem Titel nach ist das Session-Management weggefallen, was aber nicht dem Inhalt entspricht. Wenn man die Diskussionen auf GitHub verfolgt, an denen der Autor mitgewirkt hat, sollte das defekte Session-Management tatsächlich aus Platzgründen zunächst entfallen, da viele neue Erkenntnisse vorlagen, die mit Gefahren für die Authentifizierung zusammen hingen – eine davon sind die neuen Passwortempfehlungen des NIST [6] (National Institute of Standards and Technology), die dem Unsinn der unbedingten Passwortrotation und der Passwortkomplexität Einhalt gebieten:

• Das Verifizieren gegen eine Mischung aus unterschiedlichen Zeichenklassen soll nicht mehr Zwang sein,
• die Passwortlänge ist der primäre Faktor zur Charakterisierung der Passwortstärke,
• eine Länge von mindestens 64 Zeichen soll erlaubt sein,
• Passwörter können ein Verfallsdatum haben und
• die Applikation soll gegen Wörterbücher, Passwörter aus "Breaches" und gegen bekannt schlechte Passwörter testen.

Neben dem Aspekt der Bedienbarkeit bei schlecht zu merkenden Passwörtern ist der Hintergrund, dass seit 2013 viele Accounts durch sogenanntes "Credential Stuffing" [7] abhanden gekommen sind, die zweite große Gefahr für die Authentifizierungsmechanismen. Daher ist es wichtig, dass man zumindest beim Passwortcheck unbedingt gegen Wörterbücher aus Breaches prüft.

Der Punkt A3 "Sensitive Data Exposure" war 2013 als A6 zu finden. Eine passende deutsche Übersetzung wäre "ungenügende Kryptografie gespeicherter und transportierter, wichtiger Daten" – wie Kreditkarten, Passwörter und beispielsweise Session Identifier.

A4 "XML External Entities (XXE)" gehört zu den neu aufgenommen Risiken. Eine XXE-Schwachstelle kann bei XML-/SOAP-Applikationen ein defekter XML-Parser verursachen, der die Definition und den Aufruf externer Entitäten zulässt. Vereinfacht gesprochen ist dadurch eine lokale (Handler: file://) oder remote (Handler: http://) Dateieinbindung möglich, unter Umständen in einem Rutsch mit Codeausführung (phar://, jar:// oder express://). Die Auswirkung ist in den meisten Fällen fatal.

"Broken Access Control" (A5) ist konsequenter Weise ein zusammengelegter Punkt aus A4 ("Insecure Direkt Object References") und A7 ("Missing Function Level Access Control") aus 2013. A7 war das, was man unter Forced Browsing/Access bezeichnet, also das Abrufen von Objekten ohne die entsprechenden Rechte. A4 war artverwandt und bezeichnete, dass ein Zugriff auf fremde Objekte über Parametermanipulation möglich war.

Die "Security Misconfiguration" (A6) ist den neuen OWASP Top 10 zufolge immer noch ein Problem. Dabei geht es um Default-/Fehlkonfiguration von Serverkomponenten, Default Credentials und beispielsweise Stack-Traces im Browser. Das Dokument empfiehlt zeitgemäß das Setzen von Security-Headern und weiteren Härtungen in Frameworks wie Spring, Struts und ASP.NET.

Cross-Site Scripting (XSS) ist nur schwer in den Griff zu bekommen und für Pentester meistens ein gefundenes Fressen. Die Häufigkeit ist dem Data Call zufolge immer noch hoch, doch die Auswirkung im Durchschnitt eher weniger gravierend, daher ist der Punkt von A4 auf A7 gefallen.

Insecure Deserializations (A8) ist einer der beiden Punkte, die sich aus der Firmenumfrage ergeben haben. Einigen wird bei den Deserialisierungsangriffen zunächst die 2015 entdeckte Apache-Commons-Verwundbarkeit einfallen. Die Bug-Klasse ist jedoch deutlich älter und flog lange unter dem Radar. Zudem ist nicht nur Java betroffen, sondern alle Sprachen, die Objekte serialisieren – zum Speichern oder zur Kommunikation mit anderen Programmteilen – und diese schließlich wieder in ein Objekt zurückführen. Beim Deserialisieren lässt sich durch zuvor konstruierte Payloads schlimmstenfalls Code einschleusen. Die Bug-Klasse hatte zusätzliche Aufmerksamkeit gewonnen, als auf der BlackHat USA 2017 der Vortrag "Friday the 13th JSON Attacks" [8] zeigte, dass viele .NET-Bibliotheken Probleme bei der Deserialisierung von JSON haben.

Der Punkt A9 – Komponenten mit bekannten Verwundbarkeiten – ist durch die Brille des Sicherheitsforschers betrachtet weniger spannend, aber für den Betrieb nach wie vor wichtig. Das rechtfertigt den Verbleib auf der derselben Position wie 2013. Der Punkt betrifft sowohl Serversoftware als auch Clientanwendungen. Entweder mangelt es an Patches oder es kommt beispielsweise bei Java-Applikation zum Einbinden von Bibliotheken, die bekannte Schwachstellen aufweisen. Ein weiterer Klassiker sind clientseitige Bibliotheken wie jQuery, die Firmen nach dem Installieren nie wieder aktualisieren oder überprüfen. Das gilt ebenso für serverseitige Bibliotheken.

A10 "Insufficient Logging & Monitoring" stammt nicht aus dem Data Call, sondern gehört zu den auf die Zukunft ausgerichteten Punkten. Das Risiko entsteht demnach dadurch, dass erfolgreiche und fehlgeschlagene Log-ins, wichtige Transaktionen und Fehler nicht entsprechend auf einem Log-Server protokolliert werden. Darüber hinaus sollten Systeme Scans und Fehler überwachen und beim Überschreiten von Schwellwerten einen Alarm erzeugen. Der neue Punkt geht über das hinaus, was Entwickler umsetzen können.

Aus den Charts geflogen

Die drei Neuzugänge XXE (A4), Unsichere Deserialisierung (A8) sowie Logging und Monitoring (A10) führten dazu, dass Risiken aus der OWASP Top 10 von 2013 nun ihren Chartplatz verloren haben. Durch das Zusammenlegen der beiden Punkte A4 und A7 aus 2013 zu "Broken Access Control" (A5) 2017 bleiben nur zwei Punkte (s. Abb. 2): "Cross-Site Request Forgery" (vormals A8) sowie "Unvalidated Redirects and Forwards" (vormals A10).

Beim Wegfall der "Unvalidated Redirects and Forwards" aus den ersten zehn Risiken gab es Kritik. Einige Diskussionsteilnehmer waren der Meinung, dass es nach wie vor zu häufig vorkommt, dass eine Applikation URL-Parameter vor dem Weiterverarbeiten nicht überprüft. Zwei prominente Fälle dazu:

• Im Oktober 2016 gab es eine Spear-Phishing-Kampagne [9], die Google benutzte, um an Gmail-Accounts zu gelangen. Das Ziel waren russlandkritische Personen. Den Angriff führte einer Analyse zufolge APT28/Fancy Bear durch – in Deutschland keine Unbekannten, da sie für den Bundestags-Hack verantwortlich sein sollen.
• Der zweite Fall betraf zwei Lücken im UK Tax Office [10] (HMRC), die es ermöglichten, Steuer- und andere Daten von Briten anzusehen oder zu ändern.

Zudem wären nach Ansicht einiger Diskussionsteilnehmer Applikationen gerade an den heiklen Stellen verwundbar, an denen Shops zum Payment-Server-Provider weiterleiten.

Besonders viele bedauerten, dass CSRF (Cross-Site-Request-Forgery) seinen Top-10-Platz verloren hat. Das offizielle Argument ist, dass viele moderne Frameworks von Haus aus dagegen abgesichert seien. Der Autor dieses Artikels kann das nicht nachvollziehen, da selbst bei Verwendung moderner Frameworks der Schutz häufig nicht aktiviert ist. Zudem ist das Problem bei vielen Entwicklern immer noch nicht im Bewusstsein vollständig angekommen. Zur Erinnerung ein Szenario: Ein Benutzer ist bei einer Applikation in einem Reiter seines Browsers angemeldet. In einem anderen Reiter schaut er sich derweil lustige Katzenvideos an. Auf der betreffenden Seite ist allerdings ein Payload hinterlegt, der eine Transaktion Cross-Site durchführt – als GET oder POST. Also im einfachen ersten Fall über

<img src="http://kaputtebank.de/transfer.do?zielkonto=DIEB123&betrag=10000"
 width="0" height="0" border="0">

oder

<body onload="document.formular.submit()">

<form action="http://kaputtebank.de/transfer.do" name="formular"
 method="POST">

<input type="hidden" name="zielkonto" value="DIEB123">

<input type="hidden" name="betrag" value="10000"> </form>

Obwohl CSRF und die Unvalidated Redirects es nicht unter die ersten Zehn geschafft haben, sollten Entwickler und Administratoren nicht vergessen, dass diese Schwachstellen immer noch ein beträchtliches Risiko darstellen, wie die Release Notes mit dem Vermerk "retired but not forgotten" klarstellen wollen.

Kritische Töne

Dagegen, dass XXE es auf den vierten Platz geschafft hat, haben viele protestiert – vor allem Pentester. Einer von ihnen brachte es auf den Punkt: "Ich kann mich letztes Jahr nur an eine Instanz einer XXE-Schwachstelle erinnern, während CSRF beständig gefunden wurde". Das wirft die Frage auf, ob die überprüften Applikationen repräsentativ sind für die Gegebenheiten der realen Welt. Unklar blieb, inwieweit die Häufigkeit der getesteten Content Types, also XML versus HTML und JSON, was mit der Realität im Internet zu tun hat.

Verantwortlich sind laut den Release Notes statische Analysewerkzeuge (SAST). Damit die Daten repräsentativ für die Allgemeinheit sind, wäre eine passende Gewichtung notwendig gewesen.

Hinzu kommt eine weitere Unsicherheit bei der Datenerhebung: Gerade bei SAST-Daten ist zu befürchten, dass die Tools nur von den Firmen eingesetzt werden, deren Applikationen weniger repräsentativ sind, da die jährlichen Kosten durchaus mit dem Preis eines Oberklassewagens vergleichbar sind. Das begrenzt die Auswahl und schließt kleinere Unternehmen aus der Erhebung aus.

Auf der anderen Seite lässt sich nur mit vorhandenen Daten arbeiten. Statt, wie von einigen vorgeschlagen, nicht mit einem spitzen Bleistift den Data Call auszuwerten und ihn wissenschaftlich zu interpretieren, wäre es vielleicht passender gewesen, entweder das Verhältnis zwischen XML, JSON und HTML abzuschätzen oder etwas Bauchgefühl einfließen zu lassen.

In der aktuellen Situation lässt sich nur mutmaßen, ob eventuell überproportional viele XML-Backends in die Überprüfung eingeflossen sind. Bei Applikationen im Internet erscheint XML unterpräsentiert und ist eher auf dem Rückzug. JSON befindet sich dagegen auf dem Vormarsch. Abseits von Backends oder Dokumenten kommt XML vor allem bei Single-Sign-On-Diensten zum Einsatz.

Dem Team zufolge wäre für das Risiko die Auswirkung entscheidender gewesen als die Häufigkeit. Ob das in Multiplikation mit der tatsächlichen Häufigkeit, wie es in der Risikodefinition der Top 10 steht, den vierten Platz rechtfertigt, bleibt zu hinterfragen.

Ein weiterer Kritikpunkt an den Daten: XML-Parser schreiben Entwickler im Regelfall selten selber und verwenden stattdessen Libraries, die wiederum eher in die Kategorie A9 fallen – bekannt verwundbare Komponenten. Zwei Fälle bei libmxl2 sind unter anderem bekannt:

Der erste [11] liegt gut vier Jahre zurück und hatte einige WAF-Hersteller nebst ModSecurity(!) getroffen. Der zweite Fall [12] ist ein Jahr alt und betraf beispielsweise mit Nokogiri ein Ruby Gem, das unter anderem XML parst.

Rückblickend wäre bei den Daten somit eine genauere Betrachtung sinnvoll gewesen, ob vielleicht veraltete XML-Parser mit bekannten Schwachstellen für die Zahlen sorgten.

Reaktives Mittel Log-Dateien

Logging ist fraglos in professionellen Umgebungen wichtig zur Nachvollziehbarkeit von Ereignissen. Die OWASP Top 10 umfassen zwar zehn Risiken, aber keine Best Practices. Bei A10 erschien die Argumentation etwas schwach, dass nicht zu loggen und zu monitoren ein Risiko wäre. OWASP bewegt sich zudem auf dünnem Eis, da sie ähnlich wie beim alten A7 etwas propagiert, was Ursache und Wirkung vermischt. Anders formuliert: Ähnlich wie eine Sicherheitskamera, die einen Einbruch filmt, ist Logging mehr eine reaktive als eine proaktive Maßnahme. Aus fehlender Reaktion ein Risiko abzuleiten ist schwer. Beim Einbruch können Videoaufnahmen der Aufklärung dienen, verhindern jedoch nicht die Tat selbst. Ähnliches gilt für einen Datenbdiebstahl via SQL Injection: Die gestohlenen Daten holt das Logging nicht zurück.

Zudem haben Log-Daten nur teilweise einen aufklärenden Charakter. Meist lässt sich ablesen, wann und wie ein Angriff erfolgte. Wer ihn durchgeführt hat, ist dagegen in der Regel nicht ableitbar – die wenigsten Kriminellen sind dumm genug, von ihrer Einwahlverbindung aus zu agieren.

Im Application Security Verification Standard (ASVS) von OWASP ist zudem beschrieben, dass verünftiges Logging alles andere als trivial ist. Die Tatsache kommt in den Top 10 leider etwas zu kurz. Ein Lied davon singen können Administratoren, die ein zentrales Logging aufgebaut und unterschiedliche Logger als Zulieferer eingesetzt haben. Dabei müssen sie darauf achten, dass beispielsweise ModSecurity keine Passwörter oder Kreditkarteninformationen mitschneidet, die nicht im Klartext gespeichert werden dürfen. Deutsche Datenschutzgesetze begrenzen zudem auch die Sammelwut. Eine Logging-Infrastruktur hat einen hohen Schutzbedarf. Sie erfordert Sorgfalt im Umgang mit Zugriffsrechten und gegebenenfalls Transport- und Datenverschüsselung.

Damit die zentrale Log-Sammlung nicht zum Datengrab verkommt, das höchstens reaktiv hilft, sollte ein proaktiver Mechanismus existieren, der Anomalien aufdeckt und Log-Korrelationen vornimmt. Selbst ein SIEM (Security Information and Event Management) erledigt die Arbeit nicht automatisch, sondern erfordert hochbezahlte Arbeitskräfte, die passende Use Cases konfigurieren und weitere Fachkräfte, die die Ausgabe gewissenhaft inspizieren. Gut aufgestellt ist, wer das hinbekommt und zudem nicht wie in A10 angedeutet bei jedem von einem Scanner verursachten Internetrauschen einen Alarm auslöst, der die Mitarbeiter überflüssig irritiert.

Logging und Monitoring sind also wichtig, aber als sinnvolles Mittel nicht trivial. Zur Risikovermeidung ist der Punkt zweifelhaft. Es wäre besser gewesen, A10 ausnahmsweise als Best Practice zu kennzeichnen, statt das Fehlen als Risiken zu verargumentieren.

Eine vielleicht sinnvollere Option wäre gewesen, Logging und Monitoring eine eigene Seite in "What's next" zu spendieren.

Fazit

Viele Punkte sind lediglich im Vergleich zu 2013 leicht verschoben. Der Punkt A10 ist in der Form der Bezeichnung als Risiko zumindest fragwürdig. Die Aufnahme der unsicheren Deserialisierungen (A8) ist hingegen eine positive Überraschung in der Liste. Der Punkt ragt aus den (leider) erwarteten, üblichen Risiken heraus.

Das größte Lob gebührt den Machern jedoch dafür, dass OWASP die Kurve bekommen und das Dokument öffentlich erstellt hat – passend zum "O" für Open in OWASP. Andere Dokumente wie der ASVS folgen dem Vorbild. Schließlich ist bemerkenswert, dass das OWASP-Top-10-PDF kein Herstellerlogo trägt, was ein weiterer Schritt zur Unabhängigkeit ist.

Die OWASP Top 10 2017 sind bereits ins Spanische, Japanische und Koreanische übersetzt worden. Weitere Sprachen wie Französisch, Hebräisch und Chinesisch sind in Arbeit. Eine deutsche Ausgabe soll ebenfalls bald erscheinen.

Dirk Wetter
ist selbständiger Berater für IT-Sicherheit mit mehr als 20 Jahren Erfahrung und lange bei OWASP aktiv.

(rme [13])

URL dieses Artikels:
https://www.heise.de/-3953648

Links in diesem Artikel:
[1] https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf
[2] http://lists.owasp.org/pipermail/owasp-topten/attachments/20170410/63ee67b4/attachment-0001.pdf
[3] http://lists.owasp.org/pipermail/owasp-topten/2017-April/
[4] https://www.contrastsecurity.com/security-influencers/two-new-vulnerabilites-added-to-the-owasp-top-10
[5] https://github.com/OWASP/Top10/tree/master/2017/datacall/analysis
[6] https://pages.nist.gov/800-63-3/sp800-63b.html
[7] http://michael-coates.blogspot.de/2013/11/how-third-party-password-breaches-put.html
[8] https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf
[9] https://motherboard.vice.com/en_us/article/mbqzq8/russian-hackers-are-using-googles-own-infrastructure-to-hack-gmail-users
[10] http://www.bbc.com/news/technology-41188008
[11] https://www.trustwave.com/Resources/SpiderLabs-Blog/XML-External-Entity-(XXE)-Execution-Disabled-in-ModSecurity-v2-7-3/
[12] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9318
[13] mailto:rme@ix.de

Copyright © 2018 Heise Medien