Tobias Zander
Security im E-Commerce
Absicherung von Shopsystemen wie Magento, Shopware und OXID
schnell+kompakt
ISBN: 978-3-86802-646-7
© 2014 entwickler.press
ein Imprint der Software & Support Media GmbH
http://www.entwickler-press.de
http://www.software-support.biz
Ihr Kontakt zum Verlag und Lektorat: lektorat@entwickler-press.de
Bibliografische Information Der Deutschen Bibliothek
Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.
Lektorat: Theresa Vögle
Korrektorat: Frauke Pesch
Copy-Editor: Nicole Bechtel
Satz: Dominique Kalbassi
Umschlaggestaltung und Titelbild: Maria Rudi
Alle Rechte, auch für Übersetzungen, sind vorbehalten. Reproduktion jeglicher Art (Fotokopie, Nachdruck, Mikrofilm, Erfassung auf elektronischen Datenträgern oder andere Verfahren) nur mit schriftlicher Genehmigung des Verlags. Jegliche Haftung für die Richtigkeit des gesamten Werks, kann, trotz sorgfältiger Prüfung durch Autor und Verlag, nicht übernommen werden. Die im Buch genannten Produkte, Warenzeichen und Firmennamen sind in der Regel durch deren Inhaber geschützt.
Vorwort
Zunächst einmal vielen Dank, dass Sie sich für dieses Buch entschieden haben, das Ihnen helfen soll, Ihr E-Commerce-Projekt sicherer zu machen und sich vor Angriffen zu schützen. Zwar fokussiert sich das Buch auf E-Commerce, um zum einen gute praktische Beispiele zu zeigen und zum anderen auch auf Spezialfälle wie das Handling von Kreditkarten einzugehen. Allerdings ist ein Großteil des Buches auch für jede andere Webanwendung relevant, auch wenn diese nichts mit E-Commerce zu tun hat. So sollten Sie auch für ein CMS, einen Blog oder eine Intranetanwendung sehr wichtige Informationen bekommen.
Das Buch beruht zunächst auf meiner eigenen Erfahrung als Webentwickler und CTO. So habe ich in den letzten Jahren nicht nur zahlreiche Websysteme gesehen, sondern sicherlich auch selbst nicht immer alles richtig gemacht, dadurch aber eine Menge gelernt.
Des Weiteren wird das Buch angereichert durch Recherchen und Feedback, das ich im Zuge einer Reihe von Security Talks erhalten habe.
Sie werden in den Codebeispielen vor allem PHP- oder JavaScript-Code finden, allerdings stehen ähnliche Funktionalitäten in jeder anderen Programmiersprache zur Verfügung.
Ein besonderer Dank geht an meinen Arbeitgeber, die Sitewards GmbH, die sich als E-Commerce-Spezialist einen Namen gemacht und mich stark unterstützt hat, damit ich dieses Buch schreiben konnte. Insbesondere geht mein Dank an Constantin Kammerer, der sich für die Visualisierung einiger Probleme ins Zeug gelegt hat.
Des Weiteren möchte ich mich für die Geduld meiner Frau Nicole bedanken, mit der ich aufgrund der Arbeiten an dem Buch noch weniger Zeit verbringen konnte.
So, nun soll es aber losgehen, ich wünsche Ihnen viel Spaß beim Lesen und beim Entdecken der Aha-Effekte auf den folgenden Seiten.
Sollten Fragen aufkommen, erreichen Sie mich am besten auf Twitter als @airbone42 oder via E-Mail unter tobias.zander@sitewards.com.
1 Sicher, aber wo anfangen?
In diesem Kapitel geht es zunächst um die Definition von Sicherheit. Wer entscheidet eigentlich, was sicher ist? Welche Organisationen und Dokumente gibt es und wo können Sie diese finden und Unterstützung erhalten?
1.1 Die Lage der Nation
1.1.1 NSA
Es ist wohl aktuell kaum möglich, ein Buch über Websecurity zu schreiben, ohne zumindest kurz auf die Vorkommnisse einzugehen, die quasi die ganze Welt aufgeweckt haben. Dass viele Webserver und deren Software heutzutage nicht wirklich sicher sind, ist kein großes Geheimnis, und je mehr Aufwand man betreibt, desto größer wird die Wahrscheinlichkeit, dass man auch Zugriff auf ein System bekommt. Doch was wirklich klar wurde, ist, dass kein System wirklich sicher ist. Je nach Höhe der Mittel, die dem Angreifer zur Verfügung stehen, ist der Kampf nahezu aussichtslos. Das ist aber kein Grund, die Flinte ins Korn zu werfen, denn auch wenn man sich gegenüber mächtigen Institutionen wie der NSA nicht wirklich absichern können wird, so gibt es auch zahlreiche weitere Gefahren, z. B. Scriptkiddies, Trickbetrüger oder die Konkurrenz, die Interesse an meinen Daten hat oder sich einen Vorteil davon erhofft, meinem Ruf zu schaden.
1.1.2 Ponemon Institute
Doch nicht erst seit dem NSA-Skandal ist Security wieder ein Thema. Erst kürzlich wurde vom Ponemon Institute eine Umfrage veröffentlicht, in der 73 Prozent der befragten Unternehmen zugaben, mindestens einmal in den letzten zwei Jahren gehackt worden zu sein.
Dabei ist es auch interessant, dass vielen gar nicht bekannt ist, welcher finanzielle Schaden dadurch entstanden ist bzw. entstehen kann. 47 Prozent der Befragten schätzten die Kosten auf 100 000 bis 500 000 $. Ein Viertel der Befragten konnte gar keine Schätzung dazu abgeben.
Zudem gaben 88 Prozent der Teilnehmer an, dass ihr Kaffeebudget in der Firma (im Schnitt 30 $ pro Mitarbeiter pro Monat) höher ist als das der Web Application Security.
Das komplette Ergebnis der Umfrage können Sie unter https://www.barracuda.com/assets/docs/white_papers/barracuda_web_app_firewall_wp_cenzic_exec_summary.pdf nachlesen.
1.1.3 Forrester
Auch Forrester veröffentlicht regelmäßig Statistiken und Umfragen zum Thema Websecurity. Interessant ist dabei u. a., dass 70 Prozent aller Sicherheitslücken auf dem Web Application Layer zu finden sind, also in der Software, die wir entwickeln und für die wir selbst verantwortlich sind!
Auch geht aus den Ergebnissen der Umfragen immer wieder hervor, dass die größte Herausforderung bei der Entwicklung von sicherer Software das Finden von geschultem Personal in ausreichender Menge ist. Es reicht leider nicht, einen Experten im Team zu haben, sondern bereits bei der Planung der Architektur und später bei der Implementierung jedes einzelnen Moduls muss darauf geachtet werden. Und am Ende, wenn etwas schief geht, interessiert es niemanden, wer den Fehler implementiert hat. Daher ist es an uns, das entsprechende Wissen auch weiterzugeben und ständig auf dem aktuellen Stand zu bleiben.
Sie haben nun erfahren, dass es 100 Prozent Sicherheit nicht geben kann. In den folgenden Kapiteln wollen wir uns anschauen, wie man nun zumindest die wichtigsten Maßnahmen ergreifen kann.
1.2 OWASP
Das Open Web Application Security Project (OWASP) ist eine der wichtigsten Institutionen, die das Thema Web Security stark vorantreibt. Der Grundsatz ist es, Web Security sichtbar zu machen, was dadurch geschieht, dass viele Beiträge zu den Themen geschrieben, und auch entsprechende Videos zu bestimmten Themen produziert oder von Vorträgen aufgezeichnet werden.
Abbildung 1.1: Das Logo der OWASP
Die OWASP ist eine Non-Profit-Vereinigung, es steht keine Firma dahinter, was einerseits die Unabhängigkeit gewährleistet, doch andererseits ist es natürlich nicht immer einfach, die nötigen Gelder aufzutreiben.
Es gibt zudem eine ganze Liste an Projekten, wie z. B. ein XSS-Tool, das Zed Attack Proxy (Kapitel 7.1) oder Webgoat, eine Webanwendung, die absichtlich unsicher programmiert wurde, um so eine praktische Anleitung zu bieten, sichereren Code zu schreiben.
1.2.1 Wiki
Einer der Hauptbestandteile ist sicherlich das Wiki, zu finden unter http://www.owasp.org. Dort sind über 1 000 Mitglieder aktiv und pflegen die Seiten zu den diversen Projekten. Einziger Nachteil ist, dass das Wiki durch die große Menge an Beiträgen ein wenig unübersichtlich geworden ist, doch aufgrund der zahlreichen Verlinkungen findet man selbst mit der Google-Suche relativ schnell den entsprechenden Content.
Besonderes Augenmerkt sollte u. a. auf die Cheat Sheets geworfen werden, die begleitend zu diesem Buch eine sehr gute Hilfe bieten, wie man sich gegen einige Sicherheitsprobleme schützen kann.
1.2.2 Chapters
Die Organisation unterteilt sich in verschiedene Chapters, meist nach Ländern getrennt und über den ganzen Globus verteilt. Zudem hat zum Beispiel der Germany Chapter weitere Unterteilungen in diverse lokale Gruppen, wie z. B. Rhein-Main-Gebiet oder Hamburg. Diese Chapters treffen sich dann in regelmäßigen Abständen und tauschen sich über aktuelle Sicherheitsthemen aus. Die meisten Mitglieder kommen bisher aus der Java-Welt, doch auch PHP- oder Ruby-Entwickler sind herzlich willkommen. Ich als PHP-Entwickler wurde zunächst zwar belächelt, doch ich wurde sehr schnell akzeptiert, nachdem ich gezeigt habe, dass auch uns das Thema ernst ist!
Zudem gibt es auch zahlreiche Mailing-Listen zu diversen Themen, in die man sich einschreiben und an denen man auch aktiv teilnehmen kann.
Zudem werden Events gemeinnützig veranstaltet. Die bekannteste europäische Veranstaltung ist dabei sicherlich die AppSecEU, die 2013 in Hamburg stattfand und im Juni 2014 in Cambridge stattfinden wird. Die Liste der Speaker ist international und hochkarätig besetzt.
1.2.3 Top 10
Doch was sind überhaupt die wichtigsten Sicherheitsprobleme? Dieser Frage hat sich die OWASP mit ihrem wohl bekanntesten Projekt der OWASP Top 10 gewidmet, wo bisher alle drei Jahre eine Liste der riskantesten Sicherheitslücken erstellt wurden. Die aktuelle Version wurde 2013 veröffentlicht, und um nicht nur aufzuzeigen, wie groß der technische Impact ist, wurde eine Einstufung nach Risiken vorgenommen. Hier ist unter anderem auch die wirtschaftliche Sicht berücksichtigt:
Neben der globalen Top-10-Liste gibt es auch noch einen Ableger für Mobile Development, der sich speziell an Produzenten für mobile Apps richtet, und aktuell ist eine OWASP Top 10 für Entwickler in Arbeit, die sich speziell an Entwickler richtet und u. a. auch mit mehr technischem Background und Codebeispielen in möglichst vielen Sprachen aufwarten soll.
Dies sind die Top 10 der Liste von 2013 mit einer Referenz, wo in diesem Buch das jeweilige Problem besprochen wird:
1.3 CWE/SANS Top 25
Analog zur OWASP Top 10 erscheint regelmäßig die „CWE & SANS Institute Top 25 of most dangerous software errors“. Diese fokussiert sich nicht nur auf Webapplikationen, hat aber doch zahlreiche Überschneidungen und sollte entsprechend beachtet werden, wenn man sich mit dem Thema auseinandersetzt.
Die Common Weakness Enumeration (CWE) bezeichnet sich selbst als Wörterbuch, um die verschiedenen Softwareschwachstellen zu beschreiben und arbeitet ähnlich wie die OWASP communitygetrieben, wird aber von Spenden des Cybersecurity and Communications Department der Homeland Security unterstützt.
Die SANS ist eine kommerzielle Firma, die sich auf Trainings und Zertifizierungen rund um das Thema Sicherheit spezialisiert hat.
Lassen Sie uns die Liste der Top-25-Schwachstellen genauer anschauen. Wiederum werden Kapitel entsprechend referenziert, sofern es detaillierte Informationen dazu in diesem Buch gibt:
Interessant ist, dass die OWASP- und die CWE/SANS-Liste zu sehr ähnlichen Ergebnissen kommen. Allerdings gibt es auch hier und da Überscheidungen in den Definitionen, sodass mehrere Schwachstellen oft durch dieselbe Codeänderung gelöst werden können.
1.4 PCI DSS
Soll auf der Website eine Möglichkeit zur Bezahlung via Kreditkarte integriert werden, ist Ihnen eventuell schon einmal die PCI Compliance (http://www.pcicomplianceguide.org) über den Weg gelaufen. Der Payment Card Industry Data Security Standard (PCI DSS) ist ein Set an Regeln, die festgelegt wurden, um sicherzugehen, dass alle Firmen, die Kreditkartendaten verarbeiten, speichern oder übermitteln, eine möglichst sichere Umgebung einsetzen. Dies gilt auch für jeden Händler, der Zahlungen via Kreditkarte empfangen möchte. Die PCI DSS werden festgelegt vom PCI Security Standards Council (PCI SSC, http://www.pcisecuritystandards.org), das von den führenden Kreditkartenherstellern VISA, MasterCard, American Express, Discover und JCB gegründet wurde.
Die Regeln bestehen aus den folgenden zwölf Anforderungen:
Es ist also wichtig, dass nicht nur der Quellcode die Regeln befolgt, sondern auch der Hoster sie kennt und einhält.
Wie oft man sich entsprechend prüfen lassen muss, hängt von der Anzahl der getätigten Kreditkartentransaktionen ab.
Level 1 betrifft alle Händler mit mehr als sechs Millionen Transaktionen pro Jahr. Diese müssen sich viermal im Jahr einem unabhängigen Security Scan unterziehen und zudem einmal pro Jahr ein Security Audit durchführen.
Level 2 betrifft alle Händler mit mehr als einer Millionen Transaktionen pro Jahr. Diese müssen auch den vierteljährlichen Security Scan durchführen und zusätzlich einmal im Jahr den Self-Assessment Questionnaire (SAQ) ausfüllen.
Händler mit mehr als 20 000 Transaktionen pro Jahr fallen in Level 3 und benötigen genauso wie Level 2 den vierteljährlichen Security Scan und den SAQ.
Alle Händler mit weniger Transaktionen befinden sich im Level 4 und müssen nur den SAQ ausfüllen.
Die Einstufung kann bei den verschiedenen Kreditkartenprovidern leicht abweichen, so kann z. B. für Transaktionen bei MasterCard ein höherer Aufwand als bei VISA anfallen.
Die Strafen sind entsprechend hoch angesetzt, wenn gegen diese Regeln verstoßen wird: So können monatlich bis zu 100 000 $ fällig werden. Bei einem entsprechenden Vergehen wird man zudem von Level 2 bis 4 direkt in Level 1 hochgestuft und muss künftig die strengeren Richtlinien erfüllen.
Folgende Informationen dürfen zudem auf gar keinen Fall gespeichert werden: Daten des Magnetstreifens, Kartenprüfnummer und PIN.
Sofern die Kartennummer gespeichert wird, muss sie verschlüsselt werden.
Gültigkeit, Servicecode und Name der Karteninhaber dürfen ohne Verschlüsselung gespeichert werden.