Webservice Sicherheit

#1

Gleichmal vorweg, das ist bestimmt das falsche Unterforum, mangels fachspezifischem Wissen weiß ich aber auch nicht wo sonst.

Ich bin in ein Unternehmen eingestiegen die einen Webservice aufbauen wollen. Tolle Idee und der Businessplan stimmt auch, die Finanzierung steht aber keiner hat sich auch nur annähernd mit dem Thema “Sicherheit” beschäftigt.
Die Mitglieder haben größtenteils auch keine Erfahrung in der Programmierung, weshalb es auch nicht überrascht dass nach Plan die gesamte Infrastruktur innerhalb von 4 Wochen inklusive Webseite, App und der eigentliche Webservice fertig sein soll.
Dabei sollen die Kunden auf der Webseite sich einloggen, Kontodaten, Kreditkarten als auch persönliche Daten angeben, speichern und damit bezahlen. Von daher stellt sich mir schon die große Frage “Aber was ist mit der Sicherheit?”.

Das Projekt habe ich zwar auf den Boden der Tatsachen zurückgeholt das die gesamte Entwicklung bis zur Erstbenutzung weit weit länger dauert und die Entwicklung meist auch nie aufhört über die Lebensdauer des Produktes.
Dennoch kenne ich mich mit diesen Webservices (Onlineshops) bzw. mit allem was Server angeht überhaupt nicht aus, aber wenn ich Themen höre das wieder irgendein Milliardenschweres Unternehmen geknackt worden ist und all diese Daten in die Öffentlichkeit gelangten was einen erheblichen wirtschaftlichen Schaden verursacht - obwohl der Servertraffic rund um die Uhr bewacht wird - dann mache ich mir schon Gedanken wie “einfach” es ist heutzutage einen Onlineshop/Onlinediesntleistungsunternehmen aufzuziehen?

Sicherlich gibt es fertige Lösungen?
Aber wieviel Arbeit muss denn ein einzelnes kleines Unternehmen leisten, oder ist das eher etwas für die Big Player?

#2

Einige Arbeit wird einem abgenommen, wenn man bspw. Spring Security verwendet. Zumindest der Teil Authentifizierung wird dort elegant zentral gelöst, sodass die Anwendung eine interne “Firewall” bekommt. Auch einige andere Angriffsszenarien wie CSRF werden transparent abgewehrt.
Passworte werden transparent und sicher mit bcrypt gehasht, sodass gestohlene Zugangsdaten kein allzu großes Problem darstellen.
Um die Sicherung von Betriebsgeheimnissen / Kreditkartendaten muss man sich aber selbst kümmern, indem man bspw. eine zweite Datenbank / einen zweiten PersistenceContext mit eigenen Zugangsdaten anlegt und dort diese Informationen speichert.
SQL-Injection sollte, sofern man mit JPA oder grundsätzlich prepared statements arbeitet und Statements niemals von Hand zusammensetzt kein Problem sein.

Darüber hinaus ist es wichtig, die relevantesten Angriffsszenarien zu kennen. Eine gute Anlaufstelle für die sichere Programmierung von Webanwendungen ist der OWASP Development Guide (verfügbar bspw hier, falls du das Worddokument nicht selbst bauen kannst / möchtest).

Meines Erachtens ist Sicherheit ein grundlegender Aspekt, den jedes Unternehmen bieten muss um das Vertrauen seiner Kundschaft nicht zu enttäuschen.
Bei zwei Onlineshops von mittelständischen Unternehmen bin ich über so gravierende Sicherheitslücken gestolpert (ja, die waren so offensichtlich, dass “gestolpert” der passende Ausdruck ist), dass die gesamte Datenbank auslesbar war, beliebige Bestellungen auslösbar waren und in einem Fall sogar die Kennworte der Kunden im Klartext gespeichert waren. (Die Lücken habe ich natürlich an die Betreiber gemeldet, die darüber dankbar waren.)

#3

Danke, ich lese gerade noch etwas in deinem verlinkten Dokument aber eine Frage vorweg, wie hoch würdest du den Aufwand für so etwas schätzen sich darin ein zu arbeiten um möglichst professionell auftreten zu können? Lieber ein externes Unternehmen betrauen oder Hello World?

Viele Server Anbieter stellen bereits ein Account und Shopping Modul bereit, über das man seine Webseite legen kann. Wobei die Anbieter sehr intransparent sind was den technischen Aspekt angeht.

~ ~ ~ ~
Folgebeitrag, durch Forumsoftware nicht wiederherzustellen:

#5

Um eine “Basissicherheit” zu gewähren, bietet wie schon erwähnt Spring Security ein sehr gutes Toolset (ob sich das in den verwendeten Technologiestack integriert, ist eine andere Frage). In der Dokumentation sind die behandelten Angriffsvektoren auch aufgeführt. Eine lehrreiche Lektüre ist darüber hinaus die OWASP Top 10 Auflistung der verbreitetsten Sicherheitslücken in Webanwendungen (ist zwar noch von 2013, aber die Probleme müssen nach wie vor berücksichtigt werden).
Wenn man das alles bei der Entwicklung beherzigt, dazu noch eine Trennung der besonders schützenswerten Daten wie beispielsweise von @ionutbaiu beschrieben, dann hat man schon einen sehr, sehr guten Stand.

Schwierig ist das ganze nicht - man muss die Probleme nur kennen. Und genau an diesem Punkt wäre ein externer Berater besonders hilfreich, von dessen Erfahrung man profitieren kann.

Das ist von außen schwierig zu beurteilen. Ich meine mal etwas über derartige Shopmodule gelesen zu haben, kann mich aber nicht mehr genau erinnern.

#6

es ist ein einfaches bekanntes Mittel was viel erreichen kann, klare Sache,
aber die Betonung darauf ist mir in den Medien fast zu viel,

als wäre alles gut wenn nur die Passwörter gehasht sind, dabei heißt das doch, dass da jemand Zugriff auf die DB hat,
wieviele andere Dinge können dann dort meist unverschlüsselt gelesen/ gar geändert werden?

oder kommt es häufiger vor, dass die Passwörter aus toten Backups gelesen werden?
sollten viel weniger öffentlich zugreifbar sein, aber sollte soll viel…

freilich ist der normale Login mit Passwort ganz was anderes als mühsame interne Umwege zu Informationen und Aktionen,
mit Passwort auch zukünftiger Zugriff, Mitlesen usw. denkbar

den Punkt

könnte man doch auch ruhig für die Passwortdaten erwähnen, falls nicht bereits impliziert,

die Passwörter sollten (zumindest in Gedanken ausgemalt, nicht alles immer umsetzbar, schon gar nicht für Mini-Webservice nötig) so schwer wie möglich zu erreichen sein,
vor allem ein konzentriertes Auslesen besser technisch gar nicht möglich im Normalbetrieb, kein SELECT * auf die entsprechene DB-Tabelle, überhaupt kein DB-Zugriff,
genausowenig darf ein einzelner Hash rausgehen,
nur eine separate Anwendung, die einzelne Anfragen bekommt (auch nicht zu viele auf ein Konto je Zeit, Log sowieso usw.) und nur diese Einzelanfragen mit ja/ nein beantwortet

aber so wie auch die Haupt-DB an sich eigentlich ja nicht zugreifbar ist, gelingt es mit Tricks vielleicht letztlich auch bei der versteckten Passwort-DB…,

was sagen Fachkreise zu Ideen, diese Daten überhaupt nicht in einer DB,
auf welche dann doch bestimmte Programme zur Laufzeit technisch Vollzugriff haben, standardisiert abzulegen?

die Gedankenmaschine wirft einige Ideen an,
zum Einen ist die Speicherung der Hashes + Salt irgendwie immer noch Klartext,
jeder Dummy kann zu Hause die Rechnung des wohl bekannten Grundverfahrens nachbauen,
Passwörter testen,
warum nicht nochmal mit einem wichtigen System-Passwort verschlüsseln?,
das bekommen Angreifer hoffentlich nicht so leicht…, etwa nicht aus reinen Backup-Dateien

hübsch finde ich gerade, überhaupt keine dauerhafte Speicherung von der Webanwendung zugreifbar zuzulassen,
es könnten bei Systemstart die Passwörter einmalig einlesen werden, danach Speicherung physisch nicht mehr zugreifbar,
oder die Passwörter werden von außen als Nachricht geschickt,
in der Anwendung bleiben sie nur im Arbeitsspeicher,

neue/ geänderte Passwörter mögen zu speichern sein falls nicht zu verschicken, nur diese wären dann temporär weniger stark gesichert

na, gibt wohl neue mögliche Lücken/ Probleme und zu aufwendig, ‘Security by Obscurity’ :wink:

gut finde ich noch Systeme wie bei GMX und Steam gesehen, die den letzten Login anzeigen (besser längere Historie), Anzahl fehlgeschlagener Login-Versuche,
neue Ausgangsrechner für Login mit Mail zu bespätigen

#7

Der Grund, weshalb das mediale Aufmerksamkeit bedeutet ist, dass die Nutzer, die ihr Passwort auch bei anderen Diensten verwenden (das dürfte fast die Masse sein), auch um die Datensicherheit bei diesen anderen Diensten Angst haben müssen.

Einen Hash + Salt mittels MD5 oder SHA1 oder einem anderen kryptographischen Hash zu bilden ist falsch. Denn diese Algorithmen sind auf hohe Performance ausgelegt, um auch größere Datenmengen in annehmbarer Zeit hashen zu können.
Deshalb hatte ich bcrypt erwähnt. Das ist ein spezieller Passworthash, der im Gegensatz zu den vorher genannten Algorithmen direkt einen Salt integriert und über mehrere Tausend Runden läuft, sodass die Berechnung eines einzelnen Hashwertes bspw. 10ms dauert. Dadurch werden selbst schwache Passworte (sofern sie nicht in einem Wörterbuch stehen) nicht geknackt.

Wenn man noch mehr Sicherheit möchte, kann man auch einen Authentifizierungsdienst wie Kerberos verwenden. Das wäre für eine normale Webanwendung aber ein absoluter Overkill. Das genannte Passworthash-Verfahren ist state of the art.

Grundsätzlich ist Passwortsicherheit aber nur ein einzelner Baustein von sehr vielen. Gerade das Hashen der Passworte ist ja nur eine Maßnahme, um die Nutzerdaten zu schützen, nachdem das Kind schon in den Brunnen gefallen ist.

#8

Achso, interessant, so funktioniert das :smiley:

Das ist in der Tat keine unwichtige Frage. Deshalb stehen wir natürlich im Kontakt mit den Betreibern besonders weil sich halt die Fragen stellen: Wer kümmert sich um die Sicherheit? Überwacht der Betreiber die Server? Und vor allem wer ist verantwortlich?

Ich bedanke mich für euren großartigen Input.
Nehmt es mir nicht übel: Im Moment hat das Thema bei mir (noch) nicht Hauptpriorität und eure Resonanz überflutet mich gerade ungeahnt mit vielen interessanten Informationen die ich jetzt erstmal nur langsam verarbeiten und einarbeiten kann und werde.

Grüße TMII