PHP Webanwendung absichern

[FreeCastle]

Hallo,
ich möchte demnächst auf unserer Internetseite eine Art Mitgliederverwaltung mittels PHP entwickeln..Soll heißen: Es gibt eine zentrale Stelle, an welcher eine authorisierte Person alle möglichen Daten zu Mitgliedern von uns eintragen/editieren usw. kann (Name, Adresse, Alter,... aber auch Bankverbindungsdaten). Also durchaus sehr sensible Daten, die natürlich best möglichst vor unbefugtem Zugriff geschützt sein sollen.
Jetzt eben meine Frage: Wie sicher ich das am besten wirklich richtig zuverlässig ab? Ich will dabei jetzt auch nicht total ins paranoide gehen, aber wll wie gesagt schon eine gute Absicherung haben.

Um den Zugang zur Web-App zu sichern tendiere ich derzeit sehr stark zu einem einfachen .htacess-Schutz. Begründung: Es wird wohl eh nur 1 Person geben, die hier Zugriff haben soll und htaccess braucht quasi 0 Aufwand und ist IMHO immer noch sicherer als irgendwelche in PHP entwickelten Login-Skripte.
D.h. um hierüber unberechtigen Zugriff zu erlangen, müsste man quasi schon Zugriff auf den kompletten Webspace haben (klar kann es immer neue Exploits usw. geben, aber das sollte schon ausreichen).
Damit bin ich auch schon beim nächsten Punkt: Mir wäre es am liebsten, wenn ich die Bankverbindungs-Daten zusätzlich noch irgendwie verschlüsseln könnte, so dass selbst bei einem Hack des kompletten Servers, der Angreifer nicht die Klartext-Daten hat. Aber wie würde man das realisieren? Man müsste wohl ein (a)symmetrisches Verschlüsselungsverfahren einsetzen, und nur die berechtigte Person hätte den Schlüssel. Aber wie würde man das am besten in PHP realisieren, so dass die ganze Applikation (also Verwaltung) auch noch anwendbar bleibt?
Allgemeine Meinungen dazu würden mich interessieren...
Btw. falls es hier noch andere Ideen/Ansätze gibt, immer her damit... Oder auch irgendwelche Frameworks/Tools die einem hier hilfreich sein könnten

Achja und nochwas: Um diese Mitgliedsverwaltung herum will ich dann auch noch einige zusätzliche Web-Anwendungen bauen, die hierauf aufbauen (z.B. EMail-Versand an alle Mitglieder). Allerdings werden hierzu die sensiblen Bank-Daten nicht benötigt, und deswegen würde ich hierfür eigene Bereiche schaffen, die auch mittels PHP-Login-Skripte gesichert werden (hier sollen auch mehrere Leute Zugang haben). Das sehe ich durchaus als akzeptabel an, da eben in diesen Anwendungen nur auf einen bestimmten Teil der Daten in der Datenbank zugegriffen wird, und wenn die jemand ausspioniert, wäre das nicht sooo tragisch (es ist ja trotzdem noch alles eigentlich gut gesichert, bei entsprechender PHP Programmierung). Und mal davon abgesehen ist unsere Internet-Seite auch keine bekannte, und es gab noch nie einen Hackversuch seit es die Seite gibt (2 Jahre)

 

[weau]

Https | php.ini absichern | Passwörter in der Datenbank verschlüsseln z.b. md5 | neuen mysql user anlegen der dann zugreift - nicht root

$bankverbindung = 122144324234324324;
$bnverschluesselt = md5($bankverbindung);

 

[Harry Boeck]

Wir können jede Menge Tips geben, allerdings muß ich dazu sagen, daß die Energie, die man nach 10 Jahren ständig anwachsenden Predigens aufbringt, mit der Zeit verebben kann...

So, jetzt wider im Ernst:

Und mal davon abgesehen ist unsere Internet-Seite auch keine bekannte, und es gab noch nie einen Hackversuch seit es die Seite gibt (2 Jahre)

Dafür gibt es (spätestens seit Anfang der 2000er Jahre) exakt drei mögliche Erklärungen:

a) Eure Seite ist überhaupt NICHT im Internet vertreten (über keine IP erreichbar)
b) Du erkennst die Angriffe nicht als solche.
c) Angriffe sind nicht mehr nötig... ;-D

...Oh Mist, ich wollte doch ernst bleiben!

Mal abgesehen davon: Sowas wie Bankdaten (Ihr wollt die Mitgliedsbeiträge automatisiert einziehen, ja?) darf weder offen rumliegen noch nur verschleiert sein. Ich würde für sämtliche sensitiven Dinge (wozu AUCH irgendwelche beliebigen persönlichen Daten der Mitglieder gehören, für die man sich verantwortlich macht, wenn man sie sammelt) eine mindestens zweistufige Sicherung anbringen, wo ich von jeder einzelnen Stufe nach bestem Gewissen behaupten kann, daß sie nicht knackbar sein dürfte. UNABHÄNGIG voneinander! Das heißt, WENN DOCH ein Hindernis überwunden wurde, MUSS ZWINGEND ein weiteres, sehr ANDERSARTIGES vorhanden sein, das immer noch den Zugang blockiert.

Und öfter als einmal pro Monat werdet Ihr doch die Mitgliedsbeiträge nicht einziehen müssen, oder? Da werden ja wohl ZWEI Passworteingaben (einmal pro Monat) nicht zuviel der Sicherung verlangt sein?

Ich würde sogar noch viel weiter gehen: NICHTS von den Bankdaten hat IRGENDETWAS auf einem WEBSERVER verloren! NICHTS davon muß aus IRGENDEINEM Grunde an irgendjemanden AUSGELIEFERT werden!
Die Bankverbindung wird MIT SICHERHEIT von Eurer Seite aus ein CLIENT sein, kein Server. Die Bank, die letzteres bei ihren Kunden voraussetzt, dürfte erst noch gegründet werden müssen.

Auch von den Mitgliedsdaten wird das wenigste auf dem Webserver notwendig sein. Bestenfalls die Namen oder irgendwelche freiwillig von den Mitgliedern in die Öffentlichkeit gestellten Dinge. Der Rest gehört einfach nicht auf den Rechner, der den Webserver enthält. Basta!

Was übrig bleibt, ist ausschließlich Web-Inhalt und ein paar organisatorische Scripte, die das bequeme Editieren von letzterem per Webbrowser ermöglichen (jedenfalls hört sich die Anfrage danach an, daß sowas erwünscht sein wird).
SOLCHE Scripte sind Angriffsfläche genug für Böslinge, die es auf Euren Webserver abgesehen haben. Und sie sind Bewährungsfeld genug für Webmaster, die ihren Server dicht halten wollen.

Wenn Ihr ein verbreitetes OpenSource-System zum Editieren verwendet, hat das bezüglich der Sicherheit zwei gegenläufige Wirkungen:
Einerseits darf man damit rechnen, daß bei solchen Systemen viele Leute mithelfen, Einbruchstore zu finden und dicht zu machen. Andererseits darf man damit rechnen, daß massenhaft Einbruchstore dadurch neu erschaffen werden, daß solche Systeme auch von unerfahrenen Programmierern kräftig weiterentwickelt werden. Und vor allem stehen solche Systeme naturgemäß auch allen Böslingen zum Ausforschen offen.

Also, meine wichtigste Empfehlung: Überdenke dringend die Pläne, sowas wie Online-Banking automatisiert über einen Webserver (!) abwickeln zu lassen!
Ansonsten beschreibe näher, was Ihr vorhabt...

 

[end4win]

Original von weau
Https | php.ini absichern | Passwörter in der Datenbank verschlüsseln z.b. md5 | neuen mysql user anlegen der dann zugreift - nicht root

$bankverbindung = 122144324234324324;
$bnverschluesselt = md5($bankverbindung);

Wo speicherst du die Rainbowtable, um wieder an die Kontonummer zu kommen
oder gibt es inzwischen Banken die einen Hash akzeptieren?

Ansonsten stimme ich Harry Boeck zu, solche Daten haben auf einem Webserver
nur etwas zu suchen, wenn dies absolut notwendig ist und nicht aus Bequemlichkeit.


Gruss

 

[FreeCastle]

Mh also mit Online-Banking hat das gar nichts zu tun.
Das hat folgende Hintergründe:

- Eine zentrale Mitgliederverwaltung (es stimmt zwar, dass da prinzipiell nur einer was macht, aber ab und zu machen doch noch 2-3 andere da was, und so kommt es immer mal wieder zu Inkonsistenzen, da derzeit jeder seine eigene lokale kleine Datenbank hat).
Das wäre damit synchronisiert, außerdem könnte man so durchaus etwas die Komfortabilität erhöhen

- Mehr wichtig: Diese Mitgliedsverwaltung, soll quasi den Kern für weitere Anwendungen drum herum bilden: Etwa ein zentraler Mail/SMS-verteiler oder aber auch für andere Services, in denen gewisse Mitgliedsdaten benötigt werden.

Dass btw. mein letzter Satz in irgendnem Zitat aufgegriffen werden würde, war mir schon beim Schreiben zu 100% klar Aber ist ja auch durchaus berechtigt...
Ich persönlich sehe es aber dennoch nicht als so kritisch an, dass Bankverbindungsdaten online gespeichert werden, das tun ja auch viele andere (kommerzielle) Seiten, und da finden ja tatsächlich viel mehr Angriffe statt, als bei unserer kleinen Seite, die hierfür eigentlich gänzlich uninteressant ist.
Und wie gesagt, ich will mich ja eben nicht nur auf den .htaccess-Schutz verlassen, sondern eben durchaus die sensiblen Daten noch anderweitig schützen...
Aber wie gesagt für weitere Meinungen/Anregungen bin ich dankbar. Ich will das eigentlich schon so machen...

@weau: Inwiefern soll mir hier ein MD5 Hash weiterhelfen? Es geht nicht darum Passwörter zu sichern, sondern um richtige Daten die wiederhergestellt werden müssen (Verschlüsselung != Hashing).
Aber ich lass mich da auch gern eines besseren belehren...

 

[Harry Boeck]

OK, dann solltest Du mit den Regeln, die schon "weau" zusammengestellt hat, hinreichend sichern können.

...Wobei allerdings die Frage kommt: Ist der Server ein gemieteter oder ein eigener?
Ein gemieteter läßt sich schwerer absichern und ist zusätzlichen Gefahren ausgeliefert, wenn man sich den Rechner mit anderen Nutzern teilt.

Du kannst (und solltest wie gesagt) mehrere Sicherungsebenen (mindestens zwei für sensible Daten) aus Sicht der Benutzer vorsehen.
Du benötigst aber auch in aller Regel mehrere Sicherungsmaßnahmen aus Implementationssicht, um eine einzelne aus Anwendersicht umzusetzen.

Ich versuche mal aufzuzählen, was mir einfällt, um einen Server "anständig" abzusichern:

- Um bei einem Einbruch noch ganz unabhängig von den Webanwendungen nicht alle anderen Sicherungsmaßnahmen unwirksam werden zu lassen, müssen die Prozesse des Webservers und des Datenbankservers auf eigenen, rechtereduzierten Konten laufen. Das ist eine Vorbeugemaßnahme, die noch keine Sicherheit auf der Anwendungsebene bringt, aber dringend anzuraten ist.
Damit einhergehend müssen die Dateisystemrechte auf Ebene des Betriebssystems so eingestellt werden, daß die Server an ein Minimum an Daten mit einem Minimum an Rechten herankommen, so daß die Anwendung gerade laufen kann.

Dazu gehört auch, daß für einen Apache-Webserver Zugriffsregeln weitestgehend in Konfigurationsdateien festgehalten werden, die außerhalb des Bereichs der ausgelieferten Dateien liegen, also nach Möglichkeit NICHT in htaccess-Dateien. Wenn doch mit letzteren gearbeitet werden muß, muß deren Sicherheit gegen Manipulation geprüft werden. Sobald eventuell benutzte CMS oder sonstige serverseitigen Systeme eine gewisse Komplexität überschreiten, würde ich dringend davon abraten, sich auf Regeln in Dateien im Auslieferungsbereich zu verlassen. Der Strom an Hiobsbotschaften über Löcher in CMS reißt einfach nicht ab.

1. Die erste Zugriffs-Sicherungsebene für die Anwendung kann durch Zugriffsregeln im Webserver einschließlich Festlegung auf HTTPS erfolgen. WENN Open-Source-CMS verwendet werden, sollten deren Dateien von den Anwendungsdateien getrennt gelagert werden. Nur eine speziell eingeschränkte Auswahl von Dateien (namentlich gewöhnlich eine "index.php" oder ähnliches) sollten vom Webserver frei an die weite Welt ausgeliefert werden. Und darunter sollten Anfrage-Muster, die für das VERÄNDERN von Inhalten und den Zugriff auf sensitive Daten typisch sind, nur an die registrierten Administratoren bzw. Bearbeiter und nur über HTTPS ausgeliefert werden. Und DEREN Verwaltung würde ich NICHT dem CMS überlassen, DAMIT es eine eigene Sicherungsschicht bleibt.

Wie das konkret aussieht, dürfte allerdings sehr individuell sein.

Mittel zum Zweck sind hier z.B. beim Apache:
mod_ssl, mod_setenvif, mod_rewrite,
mod_auth_basic, mod_authn_file, mod_authz_user

2. Die zweite Zugriffs-Sicherungsebene für die Anwendung kann aus der CMS-eigenen Sicherung bestehen.

Soweit ein Datenbankserver verwendet wird (wonach es sich anhört), ist die von "weau" genannte Regel wichtig, nicht das "root"-Konto desselben für den Zugriff vom Webserver bzw. dem darauf laufenden CMS zu vergeben, sondern auch hier verschiedene rechtereduzierte Konten einzurichten, die für verschiedene Zwecke verwendet werden (ein Konto für alle Daten, die frei ins Web gehen dürfen, ein Konto für sensible Daten, die nur zum Austausch unter den Mitgliedern vorgesehen sind, ein Konto für die Administration der Mitglieder einschließlich deren Bankverbindungsdaten).

Wichtig ist dabei, daß eine Trennung der Bereiche sowohl im CMS als auch in der Datenbank vorhanden ist, die von den oben genannten Mitteln der ersten Sicherungsebene ebenfalls "gegriffen" werden können: Die Seiten, über die vom Internet aus von den verschiedenen Personenklassen auf die verschiedenen Inhalte zugegriffen wird, sollten sich eindeutig auf der ersten Sicherungsebene unterscheiden lassen, so daß man eben beim Apachen einstellen kann, daß, selbst WENN jemand eine Einbruchsstelle im CMS gefunden haben sollte, derjenige immer noch nicht die Anfragen an den Webserver abgesetzt kriegt, wenn er nicht mindestens AUCH NOCH das Passwort auf dessen Ebene für den Zugang zu den betreffenden Dateien kennt.

Umgekehrt greift die Doppelsicherung auch: Selbst WENN jemand den Apachen geknackt kriegen sollte, KANN der einfach die Dateien des CMS nicht ÄNDERN, wenn das auf Ebene der Dateisystem-Rechte korrekt eingestellt ist. Und er kommt einfach nicht an die Dateien des Datenbankservers heran. Und er kommt aus dem Bereich der Dateien in seinem Document-Root nicht heraus. Und seine eigene Konfiguration kann er auch nicht ändern.
Und WENN DANN AUCH NOCH eine anständige Arbeitsteilung zwischen Server-Script und Webserver eingerichtet ist (Scripts laufen unter nochmal einem extra Konto, die Scriptdateien des CMS liegen bis auf ein paar Stümpfe außerhalb des Webserver-Servierungsbereichs und der Webserver hat nur Zugriff auf die paar vermittelnden Dateistümpfe), ist die Sache schon recht zuverlässig dicht.
Jedenfalls kommt dann keiner mehr mit einfachen gescripteten Angriffen durch, ohne vor einem Erfolg bemerkt zu werden.

...Regelmäßige Kontrolle des Servers vorausgesetzt...

----

Die Verwendung von solcherart doppelter Sicherung hat naturgemäß einen Nachteil: Jeder Benutzer, der an die sensitiven Daten heran will, muß sich doppelt ausweisen. (Jede Technik zum wieder Verstecken dieses Doppel-Logins dürfte es effektiv wirkungslos machen.)

Dafür bietet es eben eine zuverlässige Sicherung TROTZ am laufenden Band immer wieder bekannt werdenden Löchern in CMS bzw. - falls man seine Scripte weitgehend selbst schreibt - gegen eigene Fehler.

----

Kombinieren kann man das mit einem Einbruchs-Meldesystem, welches im einfachsten Fall alle Zugriffsmuster, die nicht eindeutig auf erwünschte solche abgebildet werden können (whitelisting), als verboten einstuft, die betreffende IP-Adresse sperrt und mindestens einen Logeintrag schreibt oder auch eine Mail sendet (wobei bei der üblichen Menge an Einbruchsversuchen selbst bei vollkommen unbekannten Servern letzteres sinnlos sein dürfte). Script-Kiddies verlieren an solchen Servern leicht die Lust.

----

Sofern die Daten, die auf dem Server liegen, auch zu gewissem Grade vor einem physischen Zugriff oder bei einem gemieteten Server vor einem amoklaufenden parallelen virtuellen System geschützt werden sollen, sollten sie mit einem üblichen Algorithmus verschlüsselt gelagert werden. Da es in diesem Fall nicht darum geht, Daten zwischen Personen auszutauschen, sondern von einer Gruppe von Personen gemeinsam zu benutzen und dabei zentral verschlossen zu lagern, ist eine symmetrische Verschlüsselung zu benutzen. Da gibt es genug zur Auswahl, die von allen Scriptsprachen unterstützt werden.

Das wäre dann eine dritte Sicherungsschicht für die sensitiven Daten.
Auch die hat nur Sinn, wenn der Zugriff NICHT automatisiert wird.
Sonst kann ein gewillter und geübter Einbrecher diese in den Scripten oder Konfigurationsdateien finden - an die er herankommt, WENN das Szenario, weswegen diese Sicherung überhaupt erst als notwendig eingestuft wird, eintrifft.

 

[fetzer]

Original von FreeCastle
Ich persönlich sehe es aber dennoch nicht als so kritisch an, dass Bankverbindungsdaten online gespeichert werden, das tun ja auch viele andere (kommerzielle) Seiten, und da finden ja tatsächlich viel mehr Angriffe statt, als bei unserer kleinen Seite, die hierfür eigentlich gänzlich uninteressant ist.

Nein! Bäh! Pfui! Aus! Wieviele Angriffe stattfinden ist unwichtig, Fakt ist, dass sie stattfinden und dass sie auch DICH treffen können. Es geht hierbei auch nicht um "die Anderen", sondern um dich und du musst deinen Server genauso absichern, wie "die Anderen" auch. Und wenn du das eben nicht kannst ( die anderen haben eventl. ausgebildete Spezialisten dafür engangiert ), dann haben die Daten nichts auf deinem Server verloren. Ansonsten kann das schnell in die Hose gehen - für deine Kunden und für dich als Verantwortlichen.

Begründung: Es wird wohl eh nur 1 Person geben, die hier Zugriff haben soll und htaccess braucht quasi 0 Aufwand und ist IMHO immer noch sicherer als irgendwelche in PHP entwickelten Login-Skripte.

0 Aufwand = 0 Sicherheit. D.h. bei sowas auf jeden Fall verschlüsselte Verbindungen verwenden, alles andere ist unfug. Harry Boeck hat es mit mod_ssl ja schon genannt. Wirkliches Vertrauen beim Endbenutzer solltest du aber erst mit einer gescheiten Zertifizierung (http://de.wikipedia.org/wiki/Zertifizierungsstelle) erreichen, was einiges kosten wird.

Desweiteren sprichst du nur von Webanwendungen. Was läuft auf dem Server noch? Liefert der Apache auch andere Seiten aus? Welche Benutzer hat der Server noch? Wie greifen diese auf den Server zu? Welche Rechte haben sie? Vserver ( d.h. Linux Kernel ist nicht veränderbar ), Root-Zugriff oder direkter Zugriff auf den Server? Wer hat noch Zugriff, z.b. bei dedi. Servern die Supporter, andere Admin, Rechenzentrummitarbeiter )? Welche Aufgaben hat der Server noch? Usw... D.h. nur, weil du eine Webapplikation abgesichert hast heisst das nicht, dass du beim SSH Zugriff kein Passwort/Zertifikat verwenden musst ( extrem gesagt ).

 

[Elderan]

Hallo,

Original von Harry Boeck
...Wobei allerdings die Frage kommt: Ist der Server ein gemieteter oder ein eigener?
Ein gemieteter läßt sich schwerer absichern und ist zusätzlichen Gefahren ausgeliefert, wenn man sich den Rechner mit anderen Nutzern teilt.

Jein. Stimmen tut diese Aussage schon, wenn man aber keine Ahnung von Servern hat, ist das größte Problem nicht die Webanwendung sondern die Serverconfig.
Dort ist man immer noch am besten beraten mit guten Webspace bei einem vernünftigem/seriösen Webhoster, evt. nicht einer der den unlimited Webspace für 49 Cent im Monat anbietet.

Persönlich würde ich euch zu Webspace raten, mit einem eigenen root Server wäret ihr total überfordert und würdet diesen auf keinen Fall sicher bekommen.
Damit entfallen aber auch die Tipps von Harry bzgl. Dateirechte etc.

Original von fetzer

Original von FreeCastle
Ich persönlich sehe es aber dennoch nicht als so kritisch an, dass Bankverbindungsdaten online gespeichert werden, das tun ja auch viele andere (kommerzielle) Seiten, und da finden ja tatsächlich viel mehr Angriffe statt, als bei unserer kleinen Seite, die hierfür eigentlich gänzlich uninteressant ist.

Nein! Bäh! Pfui! Aus! Wieviele Angriffe stattfinden ist unwichtig, Fakt ist, dass sie stattfinden und dass sie auch DICH treffen können. Es geht hierbei auch nicht um "die Anderen", sondern um dich und du musst deinen Server genauso absichern, wie "die Anderen" auch. Und wenn du das eben nicht kannst ( die anderen haben eventl. ausgebildete Spezialisten dafür engangiert ),

Naja es gibt sehr viele Webshops, die von kleinen Firmen unterhalten werden und defakto keinen Spezialisten haben.
Die haben irgendwo PHP fähigen Webspace und osCommerce installiert, ohne besondere Sicherung und dort sind die Bankdaten auch so abgespeichert.

Du kannst (und solltest wie gesagt) mehrere Sicherungsebenen (mindestens zwei für sensible Daten) aus Sicht der Benutzer vorsehen.

Ja das sehe ich auch so.

Wirkliches Vertrauen beim Endbenutzer solltest du aber erst mit einer gescheiten Zertifizierung (http://de.wikipedia.org/wiki/Zertifizierungsstelle) erreichen, was einiges kosten wird.

Naja, bischen übertrieben, oder?
Wenn nur 2 oder 3 Personen an den Bankdaten rumspielen und diese evt. aus Anmeldeformularen stammen, ist ein von einer CA ausgestelltes SSl Zerfitikat für mich ein overkill. Hier würde ein selbst unterschriebenes Zert. vollkommen ausreichen und für mich sogar ein SSL Proxy der seitens des Rechenzentrums/Webhosters angeboten wird.



Dann mal hier meine kleine Guide, ohne irgendwelche übertrieben Anforderungen für die man nen root Server braucht:
0. Webspace bei seriösen Anbieter mit zumindest selbstsigniertem SSL Zertifikat oder SSL Proxy. Von einem eigenen root Server ist unbedingt abzuraten

1. Schön wäre es, wenn ihr 2 Datenbankbenutzer hättet mit unterschiedlichen Passwörter selbstverständlich.
Die eine Datenbank ist für die Mitglieder, die andere für euch.
Oft kommt es vor, dass man mittels SQL Injection in der Anwendung die gesamte Datenbank auslesen kann. Wenn man dies einfach Datenbankmäßig trennt, könnte eine SQL Injection im Anwenderbereich nur die Daten aus dem Anwenderbereich auslesen, die sensible Daten in euerer Datenbank aber nicht.

2. Grundsicherung für PHP
Mehr dazu hier und hier

3. .htaccess um den Adminbereich abzusichern.
Dann wäre es schön, wie du es schon erkannt hast, die Daten der User zu verschlüsseln. Es gibt in PHP schon diverse fertige symmetrische Algorithmen (asymmetrische machen hier keinen Sinn) von DES bis hin zu AES, oder selber implementieren, XTEA sollte vermutlich auch in PHP schnell implementiert sein.
Allerdings ist es besser, fertige Implementationen zu verwenden. Da PHP nicht allzuschnell ist, sollten Algorithmen mit aufwendigem Key setup wie Blowfish nicht verwendet werden.

So wie löst man dies nun elegant:
Nachdem man sich mittels .htaccess eingelogt hat und evt. etwas an den Verbindungsdaten machen möchte, wird man aufgefordert ein Passwort (von .htaccess verschiedenen) einzugeben.
Dieses wird dann in einer Session abgespeichert und für die ver/entschlüsselung der Daten benutzen.
Natürlich sollte das Passwort / der Key sicher sein und ihr solltet auch sicher gehen, dass ihr nicht jedes mal einen anderen Key verwenden.
Diese Überprüfung nur mittels eines md5/sha1 Hashes kann etwas riskant sein, sofern das Passwort unsicher ist, eine Key strengthening Methode könnt ihr euch dafür schon gönnen.


4. Eigentlich das wichtigste: Sichere Implementierung der Webapplikation!
Sofern noch nicht vorhanden unbedingt informieren wie SQL und Code-Injections funktionieren und wie man sich dafür schützt.
Ihr müsst dieses Schutzmechanismen konsequent befolgen, denn eine clever ausgenutzte Code-Injection unterwandert jede Sicherungsmaßnahme, selbst die symmetrische Verschlüsselung lässt sich damit leicht austricksen.
Einen intensiv Kurs über Sicherheitslücken (es gibt noch mehr, z.B. XSS) in PHP Applikationen und Stolperfallen in PHP solltet ihr unbedingt machen.


So das wärs dann auch soweit:
Mögliche Angriffszenarien:
SQL Injection im Anwenderbereich:
Sofern verschiedene Datenbankbenutzer verwendet werden + symmetrische Verschlüsselung im Einsatz ist, ist dies eher unproblematisch.

SQL Injection im Adminbereich (also euer Bereich):
Kann durch .htaccess nur mittels Kentnisses des Adminpasswortes ausgenutzt werden. Symmetrische Verschlüsselung liefert den restlichen Schutz der sensitiven Daten

Code Injection:
Dann ist alles vorbei, ist leider so.
Davor schützen kann man sich z.B., indem man regelmäßig, z.B. täglich, die md5 Summen der PHP Dateien bildet und auf Veränderung überprüft.
Dies erfordert aber weitergehende Rechte auf dem Server, was nicht empfehlenswert ist.
Ansonsten kann man auch einen lokalen Client schreiben, der täglich die Dateien mittels FTP runterlädt, md5 Summe bildet und abgleicht.

Einbruch in den Server (Apache):
Für die Sicherheit des Servers ist der Webhoster zuständig, und bei seriösen Anbietern sollte dieses eigentlich gegeben sein.
Ansonsten schützt die symmetrischese Verschlüsselung vor dem bloßen Auslesen.
Dennoch könnte noch viel Schaden anrichten, angefangen bei der manipulation der PHP Dateien (code injection) bis hin zur Manipulation des Webservers, um so alle Daten, und somit auch den Key, zu protokollieren.
Halte ich aber für unrealistisch.

Dummheit der Admins:
Ist nicht zu unterschätzen! Ein Admin von Woltlab hat sein Adminpasswort auch woanders verwendet, so dass jmd. dort ins Admin-CP sich einloggen konnte und über das Datenbankbackup an knapp 40 000 Benutzerdaten gelangt ist.

Also unbedingt sicher gehen, dass ihr sichere Passwörter habt (für den Adminbereich, Key für Bankdaten, FTP Passwort, MySQL Passwort, PW beim Webhoster) und diese auf keinen Fall bei anderen Diensten verwenden.
Auch sollten sich die einzelnen Passwörter unterscheiden, so dass jmd. der an das Adminpw gelangt nicht mittels FTP alle Dateien runterladen bzw. manipulieren kann.



So ich glaub ich bin nun fertig, wobei ich nochmal betonen möchte, dass Punkt 4 in meiner kleinen Liste der wichtigste ist.
Denn Bankdaten sind keine hoch sensitiven Daten, viele Firmen verschicken Rechnungen per Email (keine Verschlüsselung, gar nichts!) auf denen die Bankdaten angegeben sind.
Ein Beispiel dafür ist Fonic
Deswegen braucht ihr für eure Anwendung keinen super ausgebildeten Sicherheitsspezialisten und auch keinen managed Server.
Wenn ihr die oben gegeben Tipps befolgt und richtig umsetzt (vorallem Punkt 4) seit ihr deutlich besser gerüstet als viele größere Webshops u.ä.
Denn viele Anbieter verschlüsseln solche Daten gar nicht, womit es dann zu solchen Pannen kommen kann: Zehntausende Kartenhaus-Kunden von Kreditkartendaten-Diebstahl betroffen, wobei ich deren Sicherungsvorkehrungen nicht kenne, aber Kreditkartendaten sind deutlich sensibler als Kontonummer+Name.

Edit;

@fetzer :

0 Aufwand = 0 Sicherheit.

Dies stimmt auch nicht, vorallem kleine Sachen können die Sicherheits beträchtlich erhöhen.
Das Mitgliederpasswort als md5-Hash abzuspeichern ist 0 Aufwand, der Sicherheitsgewinn ist enorm.
Seine php.ini entsprechend dem obigen Artikel zu konfigurieren, z.B. register globals auf off, magic_quotes_gpc auf on etc. ist auch 0 Aufwand, erhöht aber die Sicherheit auch extrem.

Andere Sachen, wie z.B. Bankdaten zu verschlüssel ist mit viel Aufwand verbunden, der Sicherheitsgewinn ist aber nicht allzugroß, da soetwas nur zum tragen kommt, wenn schon etwas schief gegangen ist.
Man sollte also lieber erstmal die kleinen Dinge beachten, statt Stunden daran zu verbringen irgendwelche ausgefeilten Sicherheitsachen zu entwickeln.
Lieber evt. ein Code audit mehr durchführen, überprüfen ob alle SQL Abfragen gegen Injections gesichert sind etc., als Stunden um irgendwelche ausgefuchsten Verschlüsselungen oder Authenfizierungen zu invenstieren wo der endgültige Sicherheitsgewinn nur marginal ist.

 

[Harry Boeck]

Wieder mal eine sehr interessante Diskussion...

Was mich daran noch interessieren würde, sind die konkreten Voraussetzungen, um Bankeinzüge machen zu können. Möglicherweise sollte man, um da die richtigen Vorstellungen von Sicherungsnöten zu bekommen, sich mit dem dahinterstehenden Verfahren beschäftigen...

...Ich hoffe, der Themenstarter toleriert diese Neugier oder geht gar mit...

Bisher hatte ich mich nur mit der Sicherung solcher Daten gegen einen Fremdzugriff befaßt und bin noch vollkommen ahnungslos, was die tatsächlichen Abläufe bei automatisierten Bankeinzügen betrifft.

Normalerweise gebe ich ja nirgendwo Bankdaten heraus, sondern erledige Überweisungen an online-Händler von meinem online-Konto aus. Wenn man irgendwo eine Einzugsermächtigung rausgibt, muß die - soweit ich weiß - von einer Unterschrift begleitet werden.

Wie wird nun aber mit dieser Unterschrift gegenüber den Banken umgegangen?

Wird tatsächlich jeder Versuch, einen Bankeinzug zu tätigen, von einer Unterschriftenkontrolle durch einen Handschrift-Spezialisten begleitet? Oder wird da eventuell nur automatisiert geprüft und es würde eine einfache Bildkopie einer Unterschrift reichen? Oder wird da vielleicht GAR NICHTS an Kundenunterschriften geprüft? Reicht es eventuell, sich einmalig als Einzugs-berechtigter Kunde zu "registrieren"?

Wie gesagt - ich bin da vollkommen unbeleckt...

Was ich zunächst per Google finde, ist nicht sehr aufschlußreich und untermauert nur sämtliche Bedenken GEGEN das Herausgeben von bloßen Bankverbindungsdaten...

http://www.google.de/search?hl=en&q=bankeinzug+automatisiert&btnG=Google+Search&meta= ...->

http://www.wer-weiss-was.de/theme220/article3128784.html
http://www.webmasterpark.net/forum/archive/index.php?t-80446.html
http://forums.oscommerce.de/index.php?showtopic=4691

-> Letztlich habe ich den Eindruck, daß dieses Verfahren bei normalen Händlern wegen der für deren Seite erheblichen Mängel von kaum jemandem angewandt wird. Ohne daß es deshalb unmöglich wäre. Aber es ist offenbar nichts außer allgemeinem Blahblah zu erfahren, ehe man es konkret selbst probiert...

Ach ja: Mit der Vermutung, daß eine einmalige "Registrierung" als "einzugsberechtigter Kunde" ausreicht, liege ich offenbar richtig. Es sei denn, etwas wäre total anders gemeint... -> Leute, laßt Eure Bankdaten NICHT öffentlich liegen!

----

Das hier scheint etwas Code zu sein, der immerhin auf ein übliches "Bankeinzugsmodul" aufsetzt: http://forums.oscommerce.de/lofiversion/index.php?t47334.html
Damit kann man immerhin schon eine konkretere Phrasensuche (nach den dort definierten Konstanten) starten...

-> Ach, das gehört zu osCommerce... Ist ja niedlich. In dem osCommerce ist also offenbar eine solche Zahlungsart mit abgehandelt. Man sollte sich also nur den dortigen PHP-Code ansehen müssen, um zu lernen, wie es funktioniert...

http://www.oscommerce.com/about/about

 

[Elderan]

Hallo,
es ist so gehandhabt, dass jeder der deine Kontonummer + BLZ/Institut hat dich mit einer Lastschrift belasten kann. Selbst Namen werden manchmal nicht mal überprüft von der Bank (denke mal die werden auch bei Lastschriften mit angegeben), so dass es passieren kann (nichts außergewöhnliches), dass du mit einer falschen Lastschrift belastet wirst.

Ich denke mal beim automatischen Einzug wird dies nicht anders sein, sie stellen dir dann monatlich eine Lastschrift und bekommen das Geld. Die Treffer die man dazu findet, unter Anderm der bezüglich der Integration in osCommerce, bei denen geht es um die Frage, wie der Webshop automatisch eine Lastschrift ausstellen kann.

Bei einer Einzugsermächtigung ist es ähnlich, ggf. sind dort Fristen anders und der Anbieter kann sich besser vor zurückgeholten Beträgen seitens Kunden schützen.
Dennoch ist auch hier das Geld nicht verloren (beim Kunden), wenn sein Konto belastet wird. Wenn eine Einzugsermächtigung vorliegt, kann er innerhalb einer gewissen Frist, sofern in den AGBs vorhanden, das Geld anstandslos zurückbuchen lassen.

Diese Unterschrift auf dem Vertrag wird aber, soweit ich weiß, nur benötigt, wenn es zu einem Rechtsstreit kommt. Der Anbieter kann dann bequem nachweisen, dass du ihm diese Ermächtigung erteilt hat und er muss nich fürchten, dass der Kunde das eingezogene Geld zu unrecht einfach zurück buchen lässt.

Normalerweise gebe ich ja nirgendwo Bankdaten heraus, sondern erledige Überweisungen an online-Händler von meinem online-Konto aus.

Naja der Online-Händler sieht ja deine Konto-Nummer, BLZ, Name und könnte darauf auch eine Lastschrift ausstellen, die ohne Probleme dann von deinem Konto abgebucht wird.
Allerdings kannst du dir diese problemlos zurückerstatten lassen, eine Email an die Bank reicht. Also ist es relativ egal, ob der Shop es per Lastschrift abrechnet oder du es überweist.

Aber wie so oft schon gesagt, eine Kontonummer + BLZ sind keine streng geheimen Daten, sobald du eine Rechnung bekommst findest du darauf ja auch Name, Konto-Nr, BLZ.
Natürlich wäre es ärgerlich, wenn die Usertabelle mit Kontonummer gestohlen wird und würde das Image doch schon etwas schädigen, aber ein Beinbruch wäre es nicht.

 

[fetzer]

Original von Elderan
Naja es gibt sehr viele Webshops, die von kleinen Firmen unterhalten werden und defakto keinen Spezialisten haben.
Die haben irgendwo PHP fähigen Webspace und osCommerce installiert, ohne besondere Sicherung und dort sind die Bankdaten auch so abgespeichert.

Ich versteht nicht, warum das für euch ein Grund ist, es auch zu machen? Ich als möglicher Endbenutzer würde solche Shops nicht nutzen, schon garnicht würde ich irgendwo im Internet meine Daten zur automatischen Abbuchung eingeben.

Dies stimmt auch nicht, vorallem kleine Sachen können die Sicherheits beträchtlich erhöhen.
Das Mitgliederpasswort als md5-Hash abzuspeichern ist 0 Aufwand, der Sicherheitsgewinn ist enorm.
Seine php.ini entsprechend dem obigen Artikel zu konfigurieren, z.B. register globals auf off, magic_quotes_gpc auf on etc. ist auch 0 Aufwand, erhöht aber die Sicherheit auch extrem.

Das mag für dich so sein, da du dich ( nehm ich jetzt mal an ) täglich damit auseinandersetzen musst und dich auch privat dafür interessierst. Für einen Laien, der dazu auch noch die Homepage selbst schreiben und auch sonst alles selbst regeln muss ist das einfach zu viel. Der wird nicht jede Bedeutung der Einträge in den versch. Config-Dateien kennen und wissen, welchen Inhalt in Sich auf sein Projekt diese haben müssen. Genauso ist ersteres zwar ("einfaches" md5(STRING)) nur eine Zeile (hmac wäre schon etwas mehr Aufwand!), jedoch ist es immernoch Aufwand und es gibt immernoch viele Seiten, die ihre Passwörter aus Bequemlichkeit einfach nicht speichern, z.b. weil sie keine entsprechenden Passwort-Vergessen-Funktionen implementieren wollen, usw.

 

[FreeCastle]

Also erst mal nochmal was: Es geht hier nicht um irgendwelche Geschäftskunden oder sowas, wobei das doch eigentlich klar geworden sein sollte durch meine Beiträge. Das ist letztlich alles privat und ich mach das auch nicht für Geld...

Weiterhin: Wir haben keinen eigenen Server, sondern einen normalen Webspace-Anbieter, allerdings schon einen seriösen (naja wenn mans so nennen kann). Zumindest halt keinen 0815-Billig-Anbieter. Aber deswegen entfallen einige Dinge halt schon einmal perse.

@Elderan + Harry: Vielen Dank erst mal, ihr habt meine Beiträge wirklich durchgelesen und auch verstanden, im Gegensatz zu einigen anderen.

Das mit verschiedenen mysql-Usern ist natürlich prinzipiell gut, wobei ich mir ehrlich gesagt im Moment gar nicht sicher bin, ob das geht (Webspace-Provider mäßig). Wie schon von dir, Elderan, gemeint: Das wichtigste ist eine saubere+sichere Implementierung. Da ich doch von mir behaupten würde, in der Lage zu sein sauber zu programmieren, sehe ich hier SQL-Injections nicht als großes Risiko an. Und seien wir doch mal ehrlich: Die meisten SQL-Injections resultieren nur aus der großen Schlampigkeit einiger Entwickler.

Die Angriffsszenarien sehe ich genauso. Klar, gegen Dummheit der Admin-Person kann man da wenig ausrichten, aber das wird wohl bei jedem noch so perfekten Sicherheitssystem immer das größte Risiko sein, wobei hier eben der Vorteil ist, dass das alles privat ist, und ich z.B. von der Person die das nachher benutzen wird auch genau weiß, dass diese da sehr verantwortungsbewusst ist.


@fetzer:

Original von fetzer

Original von FreeCastle
Begründung: Es wird wohl eh nur 1 Person geben, die hier Zugriff haben soll und htaccess braucht quasi 0 Aufwand und ist IMHO immer noch sicherer als irgendwelche in PHP entwickelten Login-Skripte.

0 Aufwand = 0 Sicherheit.

Da hast du aber etwas grundlegendes nicht verstanden. Je mehr ich selbst implementiere desto größer ist auch das Riskilo Fehler einzubauen die nachher ausgenutzt werden können. htaccess bietet mir bereits fertig implementierten und bewährten Schutz auf Server-Ebene. Wäre doch Schwachsinn diesen Schutzmechanismus nicht auszunutzen, da für diesen schützenswerten Bereich eh nicht viele User vorgesehen sind.
Und das ist ja genau der Punkt: Ich will mich eben nicht nur auf diesen Mechanismus verlassen, sondern die sensiblen Daten noch zusätzlich schützen, in dem ich sie verschlüssele, dass selbst wenn jemand den ganzen Server hacken sollte (was ja eigentlich das worst-case Szenario ist), er nachher trotzdem nur irgendwelchen verschlüsselten Mist in der DB stehen hat, den er nicht entschlüsseln kann.

Und dazu noch eine Frage zur Umsetzung der Verschlüsselung: Ich hatte da sogar eher an so etwas gedacht, dass ich einen Key für einen bestimmten Verschlüsselungsalgorithmus generiere, und diesen nur derjenigen Person gebe, die auch nur wirklich Zugriff auf die Bank-Daten hat. D.h. bevor er dann irgendwas tun kann, muss er evtl. sogar die Datei mit dem Key hochladen, oder einfach erst den Key irgendwo eingben. Zwar nicht besonders komfortabel, aber wär IMHO dafür relativ sicher. Ok, mir ist klar, dass das natürlich irgendwie abgehört werden könnte, oder sogar auch mitgeloggt werden könnte, falls der Server schon gehackt sein sollte. Aber, dass dieser worst-case Fall Auftritt ist ja schon sehr unwahrscheinlich.
Ich persönlich finde das durchaus akzeptabel für den Einsatz dieser Web-Anwendung (man muss ja auch immer sehen wo und wie das eingesetzt wird...). 100%ige Sicherheit gibt es ohnehin nicht, und wie bei fast jedem Sicherheitssystem, ist das größte Problem meist der Faktor Mensch.
Was ist von diesem Ansatz zu halten? Hab ich da irgendwas übersehen?

Mal davon abgesehen: Nein, ich bin kein Sicherheitsspezialist, aber etwas Ahnung von der Materie habe ich dann doch... zumindest weiß ich auch was es an Technologien/Mechanismen gibt und wie diese funktionieren bzw, wie man sie einsetzt...im Gegensatz zu manch anderem hier, wo ich eher den Eindruck hab, dass hier einfach nur mit irgendwelchen Begriffen rumgeschmissen wird ohne überhaupt genau zu wissen was sich dahinter verbirgt.
Und im Übrigen: Ich bin mir ziemlich sicher, dass es viele kommerzielle Web-Dienstleistungen gibt, die auch mit sensiblen Daten hantieren, wo nicht mal so viel Aufwand in die Sicherheit gesteckt wird wie hier in meinem Szenario. Da herrschen knallharte Rahmenbedingungen (Zeit, Geld) und dann wird doch so einiges bei der Entwicklung vernachlässigt.

 

[Elderan]

Hallo,

Original von FreeCastle
Das wichtigste ist eine saubere+sichere Implementierung. Da ich doch von mir behaupten würde, in der Lage zu sein sauber zu programmieren,

Naja sauber programmieren und sicher programmieren ist nicht unbedingt das selbe. Aber wenn du ausreichend Know-How darin hast, ist das wichtigste erledigt.

sehe ich hier SQL-Injections nicht als großes Risiko an. Und seien wir doch mal ehrlich: Die meisten SQL-Injections resultieren nur aus der großen Schlampigkeit einiger Entwickler.

Jein, jmd. der nicht weiß was SQL Injections sind, wird vermutlich welche drin haben.
Aber im phpBB gabs mal eine SQL Injection, und der fix bestand darin, aus einen '==' ein '===' in einer if-Anweisung zu machen.
Solche Fehler zu entdecken ist nicht leicht.

Aber ansonsten, klar, wenn man sich an Grundprinzipien hält, z.B. alles escapen, wenn eine Zahl erwartet wird auch überprüfen ob es eine Zahl ist (z.B. per is_numeric oder per intval) usw.


Die Angriffsszenarien sehe ich genauso. Klar, gegen Dummheit der Admin-Person kann man da wenig ausrichten, aber das wird wohl bei jedem noch so perfekten Sicherheitssystem immer das größte Risiko sein, wobei hier eben der Vorteil ist, dass das alles privat ist, und ich z.B. von der Person die das nachher benutzen wird auch genau weiß, dass diese da sehr verantwortungsbewusst ist.

wenn jemand den ganzen Server hacken sollte (was ja eigentlich das worst-case Szenario ist), er nachher trotzdem nur irgendwelchen verschlüsselten Mist in der DB stehen hat, den er nicht entschlüsseln kann.

Also wenn jmd. den ganzen Server hackt und sich halbwegs vernünftig anstellt, schafft er es auch den Key für die Verschlüsselung abzufangen.
Aber ansonsten hast du schon recht, die meisten würden scheitern, bzw. realistischer ist ja nur ein begrenzter Zugang.


Persönlich würde ich das mit der Verschlüsselung so handhaben:
Wenn die Person an die Daten möchte, also diese bearbeiten möchte etc., erscheint ein normales Login-Formular wo er ein Passwort/Key eingeben muss.
Dieser wird dann in einer Session abgespeichert und entsprechend zum Ver/Entschlüsseln verwendet.

Intern lässt sich dieses relativ leicht regeln:

<?php
session_start();
if(!isset($_SESSION['bankdaten_login'])) 
  die("Bitte erst einloggen...");

//XTEA, AES oder was auch immer
$algo = new Algo($_SESSION['key']);

//...
$sql = mysql_query("UPDATE usertable SET kontonummer = '".$algo->encrypt($_POST['kontonummer'])."' WHERE userid = '$userid'");
?>

Ich glaub das wäre hier die bequemste Variante, erfordert gar nicht soviel aufwand wenn man eine halbwegs vernünftige Klasse zum Ver/Entschlüsseln besitzt etc.

Was evt. noch anzumerken ist:
Wenn er sich auslogt, dann $_SESSION['key'] erst überschreiben und danach die Session löschen (session_destroy).
Evt. die Session-Lifetime runtersetzen auf 15 Minuten oder so.

Denn auf dem Webserver liegt, immer wenn er sich einlogt, in der entsprechende Sessiondatei der Key im Klartext vor.

 

[FreeCastle]

Hi,
danke nochmal

also klar gerade solche "Flüchtigkeitsfehler" wie == und === können natürlich schon passieren, insbesondere dann wenn man gleichzeitig immer noch mit anderen ProgSprachen am rumhantieren ist und auch nicht immer sofort jedes Sprachdetail parat hat. Wobei ich hier dennoch den "Vorteil" habe, dass mein Code doch weitaus kleiner und wartbarer als der von phpBB sein wird
Gut, man könnte z.B. im Hinblick auf SQL Injections auch noch an den Einsatz von Stored Procedures denken, wodurch diese Problematik auch nochmal deutlich entschärft wird.

Das mit den sessions sieht gut aus, werd ich dann so wohl auch umsetzen.