Discover millions of ebooks, audiobooks, and so much more with a free trial

Only $11.99/month after trial. Cancel anytime.

Security im E-Commerce: Absicherung von Shopsystemen wie Magento, Shopware und OXID
Security im E-Commerce: Absicherung von Shopsystemen wie Magento, Shopware und OXID
Security im E-Commerce: Absicherung von Shopsystemen wie Magento, Shopware und OXID
Ebook198 pages1 hour

Security im E-Commerce: Absicherung von Shopsystemen wie Magento, Shopware und OXID

Rating: 0 out of 5 stars

()

Read preview

About this ebook

Das Buch richtet sich besonders an Webentwickler und IT-Entscheider, die eine E-Commerce-Seite betreiben wollen oder dies bereits schon tun.

Es werden neben den häufigsten Angriffsszenarien wie XSS, Injection oder CSRF auch Exoten wie Pixel Perfect Timing beschrieben und mögliche Verteidigungsmethoden besprochen. Die Beispiele beruhen dabei auf der langjährigen Erfahrung des Autors und sind zum Großteil auch für Applikationen außerhalb des E-Commerce wie CMS-Projekte, Blogs oder Intranetapplikationen interessant.

Zudem werden Frameworks und Tools analysiert, die helfen, Ihre Applikation mit möglichst geringem Aufwand abzusichern.
LanguageDeutsch
Release dateJul 1, 2014
ISBN9783868026467
Security im E-Commerce: Absicherung von Shopsystemen wie Magento, Shopware und OXID

Read more from Tobias Zander

Related to Security im E-Commerce

Titles in the series (20)

View More

Related ebooks

E-Commerce For You

View More

Related articles

Reviews for Security im E-Commerce

Rating: 0 out of 5 stars
0 ratings

0 ratings0 reviews

What did you think?

Tap to rate

Review must be at least 10 words

    Book preview

    Security im E-Commerce - Tobias Zander

    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:

    Wie hoch ist der finanzielle Schaden?

    Kann das Ausnutzen der Lücke zu einem Reputationsverlust führen?

    Wie viele persönliche/sensitive Daten können veröffentlicht werden?

    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:

    Injection (Kapitel 3.1)

    Broken Authentication and Session Management (Kapitel 4.2 und 4.3)

    Cross-Site Scripting (Kapitel 2)

    Insecure Direct Object References (Kapitel 4.5)

    Security Misconfiguration (Kapitel 4.6)

    Sensitive Data Exposure (Kapitel 5.1)

    Missing Function Level Access Control (Kapitel 4.1)

    Cross-Site Request Forgery (Kapitel 3.3)

    Using Components with known Vulnerabilities (Kapitel 6 und 7)

    Unvalidated Redirect and Forwards (Kapitel 4.5.2)

    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:

    Improper Neutralization of Special Elements used in SQL Command (Kapitel 3.1.1)

    Improper Neutralization of Special Elements used in an

    Enjoying the preview?
    Page 1 of 1