Secure Coding – Geballte Sicherheit

SQL-Injection

Bernhard Hirschmann — Mon, 27 Jul 2020 16:04:00 +0000

Es ist fast schon etwas beschämend, dass so viele erfolgreiche SQL Injection-Angriffe auftreten, da es eigentlich EXTREM einfach ist, SQL Injection-Schwachstellen zu vermeiden.

SQL Injection-Fehler treten auf, wenn Softwareentwickler dynamische Datenbankabfragen erstellen, die vom Benutzer bereitgestellte Eingaben enthalten. Das Vermeiden von SQL-Injection-Fehlern ist tatsächlich einfach. Entwickler haben dazu 2 Optionen:

1) keine dynamische SQL-Queries schreiben

2) Keinen Input zulassen der Befehle enthält

Wenn die erste Option nicht möglich ist, dann gibt es folgende Möglichkeiten zur Prävention von SQL-Injection:

Verwenden von Prepared Statements (mit Variable-Binding)

Hier wird eine sichere API verwendet, die es einem Angreifer nicht erlaubt, den SQL-Interpreter auszutricksen. Anstatt den Query-String zusammen zu bauen durch Strinkonkatenation, werden die einzelnen Bestandteile sicher an die API übergeben.

Verwenden von Stored Procedures

Hier wird die SQL-Abfrage direkt auf der DB abgelegt und man ruft sie nur noch auf mit den Parametern. Auch hier kann man nicht so leicht den SQL-Interpreter austricksen.

Whitelisting von Eingabeparametern

Das ist ein Filter mit erlaubten Zeichen, bei denen man gefährliche Zeiten wie Anführungszeichen oder Semikolon nicht mit aufnimmt. Dadurch wird es für Angreifer sehr schwer, einen wirksamen Angriffsvektor zu erstellen.

Escaping aller Eingaben

Gefährliche Zeichen können vor dem Übergeben an den SQL-Interpreter escaped werden. Dabei werden sie durch eine harmlose Schreibweise ausgedrückt, so dass sie nicht als Kommando interpretiert werden.

Habt Ihr noch auf dem Schirm, wie man das Ganze am besten anwendet? Falls nicht, dann möchte ich nochmal auf unser Secure Coding Workbook verweisen, wo man das ganz schnell nachschlagen kann.

Neues Video – Unzureichendes Logging und Monitoring

Bernhard Hirschmann — Sun, 07 Jul 2019 21:09:22 +0000

Den meisten Webanwendungen fehlt ein effektives und nachhaltiges Monitoring, über das man Angriffe erkennen kann. Und wenn man Angriffe nicht erkennt, dann kann man auch nicht darauf reagieren.
In meinem 10. Video der Secure Coding Reihe sprechen wir über dieses Thema, und was das in der Folge für Probleme mit sich bringt.

Talk „Hack me if you can“ auf der JAX2019

Bernhard Hirschmann — Fri, 10 May 2019 08:08:59 +0000

Auf der diesjährigen JAX in Mainz (6.-10. Mai 2019), der Konferenz für Java, Architektur- und Software-Innovation, habe ich am 8. Mai den Talk „Hack me if you can – Sicherheit in Webanwendungen“ gehalten. Inhaltlich habe ich dabei herausgearbeitet, wie wichtig die Berücksichtigung von Sicherheitsschwachstellen ist, bzw. dass man diese konsequent und strategisch vermeidet. Die richtige Vorgehensweise ist dabei, zunächst die Angriffe zu verstehen, damit man eine wirksame Verteidigung aufbauen kann.

Es gibt viel zu viele Webanwendungen, die zu einfach zu hacken sind. Der Grund ist fast immer, dass sich die Entwickler während der Implementierung keine Gedanken über die Sicherheit machen – weil sie die Angriffe nicht kennen. Deshalb ist es eine Grundvoraussetzung für sichere Software, dass man die Grundlagen sicherer Software kennt.

Den Vortrag habe ich aus diesem Grund in 4 Teile aufgeteilt:

Einleitung: Warum das Ganze?
Wie man hackt
Wie man sich schützt
Wie man sich wehrt

In der Einleitung geht es darum, zu zeigen, dass man sich aktiv um die Sicherheit kümmern muss. Man muss die Angriffe verstehen, um wirksame Verteidigung aufbauen zu können. Ich erläutere, dass viele Basics nicht berücksichtigt werden können, wenn das Know-How bei der Entwicklung nicht vollständig vorhanden ist.

Im 2. Teil „Wie man hackt“ zeige ich die Vorgehensweise von Hackern, so wie man es auch in Hacker-Kursen lernt. Der Grund dafür ist, damit ein Verständnis aufgebaut wird, wie man eine Anwendung angreift, bzw. von der anderen Perspektive aus gesehen, wie man angegriffen wird. Dadurch kann dann im 3. Teil besser verstanden werden, welche Maßnahmen man treffen muss, damit diese offenen Flanken nicht mehr bestehen.

Der 4. Teil beschäftigt sich dann mit der angemessenen Reaktion auf Angriffe. Denn niemand muss für eine Anwendung hinnehmen, dass sie durch Angriffe lahmgelegt wird. Es gibt hier Verteidigungsmaßnahmen, die das unterbinden können. Dabei stelle ich Tools vor, die eine Schaltzentrale für Sicherheitsmonitoring bieten, damit man Angriffe auf seine Anwendungen in Echtzeit verfolgen kann, und den Abwehrmaßnahmen live bei Ihrer Arbeit zuschauen kann.

Anbei die Folien zum Vortrag als PDF
EXXETA@JAX_Hack-me-if-you-can-lowq Herunterladen

Neues Video: XXE: XML External Entities

Bernhard Hirschmann — Sun, 03 Feb 2019 18:54:00 +0000

Der 4. Teil der Secure Coding Reihe behandelt das Thema XXE – §XML External Entities§. Diese ganz neue Schwachstellen-Kategorie ist erstmals in den OWASP Top-10. Damit können Hacker eine Anwendung angreifen, indem sie manipulierte XML-Dateien hochladen.

Secure Coding – Teil 4: XXE: XML External Entities

Neues YT-Video: Broken Authentication

Bernhard Hirschmann — Thu, 27 Dec 2018 21:47:25 +0000

Gerade eben habe ich mein neues YouTube-Video veröffentlicht. Es ist aus der Secure Coding Reihe zum Platz 2 der OWASP-Top10 „Broken Authentication – Fehler in Authentifizierung und Session-Management.

Mich würde sehr interessieren, was Ihr darüber denkt. Konstruktive Kritik oder auch nur kurzes Feedback ist also willkommen. Entweder hier, oder auch bei YT als Kommentar.