Datenklau leicht gemacht: Unsichere Objektreferenzen

Diese Woche wurde bekannt, dass tausende Kundendatensätze im Geschäftskundenbereich der Deutschen Bahn abgegriffen werden konnten. Grund sind unsichere direkte Objektreferenzen.

Was ist passiert?

An Kunden wurde eine URL mit einer Firmen-ID gesendet. Auf der Seite waren Kundendaten zu sehen. Diese Firmen-IDs konnte man durchiterieren und erhielt die Daten anderer Kunden zu sehen. Die Journalisten von CORRECTIV.RUHR schieben ein kleines Script, welches diesen Prozess automatisiert. So war es ihnen möglich in 45 Minuten etwa 10.000 Datensätze abzugreifen.

Es war also möglich unauthentifiziert, direkten Zugang zu fremden Daten zu erhalten. Dies war in diesem Fall auch mehr oder weniger erwünscht, denn der Mail-Empfänger sollte mit einem Klick in der Lage sein seine Daten einzusehen.

Weiterlesen


XSS erfolgreich verhindern

XSS, kurz für Cross Site Scripting, ermöglicht es einem Angreifer Browser-Code in die Seite einzubauen. Dadurch kann z.B. auf anderen Clients Javascript ausgeführt werden, die Same-Origin-Policy umgangen werden und Daten abgegriffen werden.

Wie funktioniert XSS?

Stellen wir uns beispielsweise eine Kommentier-Seite vor: Es werden Kommentare von Nutzern angezeigt. Nicht eingeloggte Nutzer können durch Eingabe ihrer Zugangsdaten auch einen Kommentar hinterlassen. Unser Angreifer möchte die Zugangsdaten der User gerne mitlesen. Dazu könnte unser Angreifer ein Kommentar mit einem Javascript posten, welches Formulardaten per AJAX an seinen Server sendet.

XSS kann aber auch ganz einfach genutzt werden um COOKIE-Inhalte abzugreifen. Dadurch kann eine Session übernommen werden.

Weiterlesen


Sicher mit Sessions umgehen

Wie Session Fixation verhindert werden kann, habe ich bereits gezeigt. In diesem Beitrag möchte ich mich um grundsätzliches im Umgang mit Sessions beschäftigen.

1. Session-IDs sind in der URL offengelegt

Die Session-ID sollte ein Geheimnis zwischen dem User und der Applikation sein. Diese in der URL mitzuschliefen ist sehr gefährlich. Der User muss den Link nur mit jemanden Teilen, schon int ein Dritter ein eingeloggter User. Zum Glück ist die Übergabe per Cookie der Standardfall in PHP, die Übergabe per URL erfordert einiges an Arbeit. Die PHP-Konfigruation use_trans_sid sollte den Wert 0 haben.

2. Sessions werden nicht richtig geschlossen

Weiterlesen


Session Fixation verstehen und beheben

Session Fixation ist auch Teil des „Broken Authentication & Session Management“-Punktes in den OWASP Top 10. Der Hintergrund ist eigentlich ganz einfach: Wenn wir die Session-ID eines eingeloggten Users kennen, können wir selbst eingelogged sein.

Wie funktioniert Session Fixation?

Die Frage die sich stellt ist natürlich: Woher kennen wir die Session-ID? Bei Session Fixation ist die Antwort ganz simpel: Wir setzen Sie selbst.

Weiterlesen


Authentifizierung die kein Vertrauen weckt

Authentifizierung richtig gemacht

Bildnachweis: (c) Annie Spratt

Das Thema Authentifizierung und Session-Management hat viele Aspekte, und es gibt viele potentielle Fehler, die gemacht werden können. Ich möchte mich hier deshalb zunächst nur auf die Authentifizierung beschränken.

1. Passworte sind nicht sicher gespeichert

Leider sehen wir das immer wieder: In einer Datenbanktabelle existiert ein Feld „password“, mit lesbarem Inhalt. Das darf natürlich gar nicht sein. Häufiger sehen wir Passworte, die mit md5 oder sha1 gehashed wurden. Das ist auch nicht sehr sicher. Denn oft reicht eine Google-Suche nach einem Hash, und am Ende findet man in irgendeiner Rainbowtable das gesuchte Passwort.

Weiterlesen


SQL-Injection

SQL-Injection-Lücken erkennen und beheben

Bildnachweis: (c) Heiko Stuckmann / pixelio.de

Die OWASP TOP 10 sieht Injection als größte Gefahr in Webanwendungen. Ein häufiger Sonderfall ist SQL-Injection. Damit können nicht nur Daten geklaut, manipuliert, hinzugefügt oder gelöscht werden. Es kann sogar genutzt werden um Kontrolle über den Server zu übernehmen.

Betrachten wir folgendes Beispiel. Über solchen Code sind wir sicherlicher schon alle gestolpert.

Würde dieses Query ausgeführt, würde funktionieren. Allerdings klafft hier ein großes Sicherheitsloch, denn wir akzeptieren einfach so, was wir per GET an Parametern bekommen, und senden es zur Datenbank. Es gibt eine Maxime, die hier sicherlich öfter genannt werden wird: Traue keinen Daten von fremden Quellen. Egal ob GET, POST, Cookie oder APIs. Wir vertrauen Daten die wir nicht kontrollieren niemals!

Weiterlesen


Sichere Software ist kein Zufall

Meiner Erfahrung nach wird oft nur wenig Wert auf sichere Software im PHP-Umfeld gelegt. Ich habe bei meinen Arbeiten an Fremdcode schon zahllose Sicherheitslücken gefunden. Die Projektmanager waren selten erfreut.

Sicherheit darf kein nachgelagerter Aspekt der Softwareentwicklung sein, sondern muss bei der Entwicklung von der ersten Sekunde mitgedacht werden. Ein Sicherheitsbewusstsein muss bei allen Projektbeteiligten tief verankert sein. Leider passiert das oft erst, wenn es zu spät ist, und eine Applikation Ziel eines erfolgreichen Angriffs wurde.

Sichere Software: So geht’s

1. Machen Sie sich mit den Gefahren vertraut

Die Organisation OWASP (Open Web Application Security Project) veröffentlicht regelmäßig die Top 10 der Sicherheitsrisiken für Webanwendungen. Auf diese werde ich in den folgenden Beiträgen genauer eingehen. Es besteht zum Beispiel die Möglichkeit Daten zu stehlen, zu manipulieren oder zu löschen. Denkbar wäre sogar das erhalten von Rootrechten auf Servern. Dies würde es zum Beispiel ermöglichen heimlich Daten abzugreifen oder die Infrastruktur zu zerstören. Lassen Sie sich regelmäßig schulen.

2. Ermitteln Sie, welche Maßnahmen ergriffen werden können

Oft kann durch die Wahl eines geeigneten Frameworks und das Bedenken einiger Details auf einer globalen Ebene die halbe Miete sein. Wird zum Beispiel eine Datenbankabstraktion (z.B. Doctrine) genutzt, ist SQL-Injection möglicherweise gar kein Problem mehr. Wenn alle Formulare von einem Basis-Formular erben, welches ein One-Time-Token beinhaltet, ist CSRF auch kein Problem mehr.

Auch wenn wir uns hier hauptsächlich mit der sichereren PHP-Entwicklung beschäftigen, sollten auch Infrastrukturmaßnahmen nicht unberücksichtigt bleiben: Das Trennen von Servern nach Aufgabe (Web, Datenbank, Cache, etc) kann z.B. auch sehr sinnvoll sein.

3. Definieren Sie Coding-Regeln und überprüfen Sie diese in Code-Reviews

Jeder Entwickler im Team muss sich an gemeinsam vereinbarte Coding-Regeln halten. Das sollte sich nicht nur auf den Coding-Style beschränken, sondern auch auf Sicherheitsaspekte. Ohne Code-Review durch einen anderen Entwickler sollte kein Zeile in den Betrieb gehen.

4. Regelmäßige Penetrationstests

Auch wenn es teuer klingen mag: es lohnt sich! Sie werden Nachts besser schlafen können! Es gibt spezialisierte Unternehmen, die für Sie Sicherheitslücken auffindig machen, bevor es Kriminelle tun. Diese Penetrationstester testen Ihre Anwendung teils automatisch, teils manuell auf Herz und Nieren. Danach erhalten Sie einen Report der alle gefundenen Probleme auflistet und nach Schweregrad bewertet. In der Regel wird eine kostenfreie Prüfung nach beheben der Probleme angeboten.

Ich kann für Sie gerne ein preiswertes Angebot einholen. Nehmen Sie dazu einfach Kontakt zu mir auf!