nicht angemeldet
Problem wg. Sicherheit mit Provider
Hallo!
Mir wurde schriftlich durch meinen Provider mitgeteilt,
dass meine bei ihm gehostete Internetseite
gravierende Sicherheitsprobleme aufweißt und dass es einem Hacker am Wochenende gelungen ist, über diese Webseite auf den Server zu gelangen.
Der Provider behält sich in dieser Nachricht vor, die Webseiten entsprechend zu deaktivieren bzw. mir durch derartige Einbrüche entstehende Kosten entsprechend in Rechnung zu stellen.
Ich bin ja kein Rechtsexperte und habe mit Anfängerwissen ein paar php-Formulare mit Einträgen in eine dem webspace angeschlossene mysql-Datenbank geschrieben.
Frage:
Kann denn wirklich ein Hacker auf dem ganzen Server des Anbieters einbrechen, nur weil ich "schlechten" code produziert habe?
Ist es rechtens, dass die Seite deaktiviert werden kann und mir Kosten in Rechnung gestellt werden?
-
Hello,
Kann denn wirklich ein Hacker auf dem ganzen Server des Anbieters einbrechen, nur weil ich "schlechten" code produziert habe?
MMn kann man PHP schon seit Längerem so einrichten, dass der Schaden auf den jeweiligen Account beschränkt bleibt. Aber das ist keinesfalls trivial. Ein Provider, der Accounts verkauft, sollte das aber können.
Wenn ein Schaden eingetreten ist und aus diesem irgendwelche Rechtsfolgen abgeleitet werden sollen, sollte der Provider diesen erst einmal genau beschreiben und damit auch beweisen.
Welche Rechte der Provider jedoch gegenüber seinem Hostingkunden hat, ist i.d.R. davon unabhängig in den Vertragsbestimmungen (inclusive rechtsgültiger AGB), an die dann beide Seiten gebunden sind, geregelt.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
auf meinem Server wurde ja auch dreimal hintereinander "eingebrochen". Der Provider hat "irgendwas" gemacht, und meine Seiten waren wieder da. Ich war froh, dass er schnell reagiert hat und habe keinen Fernlehrgang verlangt, bin zu diesem Thema also doof geblieben ;-)
Nach dem dritten Mal hat er das System neu installiert, nachdem ich alle Daten gesichert hatte. Anschliessend wieder neu aufgespielt.
Bei einem Sicherheits-Infoabend wurde gezeigt, wie man über phpMyAdmin einbrechen kann. Dem konnte ich ja nun wirklich nicht abhelfen.
Bis heute weiss ich nicht, wo die Schwachstelle war, habe aber meinen Code überarbeitet. Auf jeden Fall dürfen die vom Server automatisch generierten Slashes (") vor den Datenbank- Zugriffen auf keinen Fall entfernt werden.
Danach, vor der Ausgabe auf HTML aber schon:
$string = htmlspecialchars($string, ENT_QUOTES); // wandelt & & " " ' ' < < > >Und bisher habe ich Glück gehabt ...
Kalle
-
Hi!
Bei einem Sicherheits-Infoabend wurde gezeigt, wie man über phpMyAdmin einbrechen kann. Dem konnte ich ja nun wirklich nicht abhelfen.
Grundlegend kann man schon mal einen Zugriffsschutz über HTTP-Authentication davorschalten, da muss man schon erstmal am Apachen vorbeikommen.
Und bisher habe ich Glück gehabt ...
Deine Seite ist aber weiterhin alles andere als sicher. Mit nur einem in die URL eingefügten Zeichen, das du nicht erwartest, bekommt man komplette SQL-Statements angezeigt. Das mag für dich zum Debuggen komfortabel sein, für einen böswilligen Angreifer ist es das aber auch.
Es würde sich wirklich lohnen, wenn du grundlegend lernen würdest, welche Unterlassungssünden zu den gravierendsten Lücken führen, nämlich vor allem die nicht beachteten Kontextwechsel.
Bis heute weiss ich nicht, wo die Schwachstelle war, habe aber meinen Code überarbeitet. Auf jeden Fall dürfen die vom Server automatisch generierten Slashes (") vor den Datenbank- Zugriffen auf keinen Fall entfernt werden.
Diese Aussage ist falsch. Die Slashes werden von PHP eingefügt. Das Feature nennt sich Magic Quotes und ist in der nächsten Version von PHP nicht mehr dabei. Schon in aktuellen Versionen ist es im Auslieferungszustand deaktiviert (zumindest in der empfohlenen Variante der php.ini). Es bereitet gelegentlich und unbemerkt, weil wieder mal vom Programmierer nicht beachtet, mehr Probleme als es löst, weil es an der falschen Stelle ansetzt.
Des weiteren gibt es auch noch Datenbankzugriffe, bei denen die Daten sonstwoher stammen. Auch diese müssen SQL-gerecht behandelt werden, nicht nur Benutzereingaben. Zwei Systeme zu haben, wie man mit den unterschiedlichen Daten umgehen muss, ist auch nicht gerade übersichtsfördernd. Deshalb erst - und das aber konsequent - beim Übergeben in einen anderen Kontext die Daten diesem entsprechend behandeln. Die Verarbeitung erfolgt in Rohform, also ohne irgendwelche Maskierungzeichen für spätere Kontexte und die Eingabedaten müssen von einer eventuell vorhandenen Transportsicherung befreit werden. (Das war jetzt rückwärts aufgezählt. Die EVA findet ja üblicherweise andersrum statt: Eingabe -> Verarbeitung -> Ausgabe).
Lo!
-
Hi!
Deine Seite ist aber weiterhin alles andere als sicher. Mit nur einem in die URL eingefügten Zeichen, das du nicht erwartest, bekommt man komplette SQL-Statements angezeigt.
Stimmt. Das läuft zwar über eine Funktion, in der ich die Ausgabe nach der Testphase abschalten wollte. Aber bei mir ist eben immer Testphase ;-)
Müsste ich wohl besser in eine Datei oder DB-Tabelle umleiten.
... die vom Server automatisch generierten Slashes (") ...
Diese Aussage ist falsch. Die Slashes werden von PHP eingefügt.
OKay, hab mich falsch ausgedrückt.
Das Feature nennt sich Magic Quotes und ist in der nächsten Version von PHP nicht mehr dabei.
Oh hoppla, man kann sich auf gar nichts mehr verlassen.
Kalle
-
Hi!
Deine Seite ist aber weiterhin alles andere als sicher. Mit nur einem in die URL eingefügten Zeichen, das du nicht erwartest, bekommt man komplette SQL-Statements angezeigt.
Stimmt. Das läuft zwar über eine Funktion, in der ich die Ausgabe nach der Testphase abschalten wollte. Aber bei mir ist eben immer Testphase ;-)Vermutlich testest du doch aber hauptsächlich im Labor und nicht in der Produktivumgebung. Also könnte man den Servernamen ($_SERVER["SERVER_NAME"]) befragen und wenn es die Labormaschine ist, die Debug-Information ausgeben, ansonsten eben nicht - oder nur mit einem schwer zu erratenden Zusatzparameter - oder mit einem Parameter in einer Konfigurationsdatei, den man aber nicht wieder zu deaktivieren vergessen darf.
Lo!
-
-
-
-
-
Hallo,
ja zu beiden fragen.
Gruß
jobo
-
Mir erscheint zwar Toms Antwort durchaus plausibler,
aber zum ersten ja: Ist das nicht dann ein selbst sehr schlecht abgesicherter Provider, wenn durch "meine" Seite der ganze Server in Mitleidenschaft gezogen werden kann??-
Hallo,
Mir erscheint zwar Toms Antwort durchaus plausibler,
aber zum ersten ja: Ist das nicht dann ein selbst sehr schlecht abgesicherter Provider, wenn durch "meine" Seite der ganze Server in Mitleidenschaft gezogen werden kann??Naja, nenn ihn doch mal. Toms Antwort ist sicher detaillierter. Aber wenn Dein Account zB. als Spamschleuder neutzbar gemacht werden kann, hat das mit dem Provider nicht viel zu tun, würde ich sagen.
Gruß
jobo
-
-
-
salut
da du anfänger bist, schau dir doch einmal dies hier an, dann wirst du in zukunft weniger solche probleme haben:
Einige Php-Sicherheitsprobleme für Anfänger
mfg
stewe
-
Ojemine, ein Verfechter von magic_quotes_gpc On, das ist ja aber auch schon von 2002.
-
das ist ja aber auch schon von 2002.
jap, stimmt, darauf hätt' ich noch verweisen sollen, aber man kann nich alles haben :)
in jedem fall gibts ihm n'schönen einblick wie man formulare etc missbrauchen kann.
-
-
-
h1,
Mir wurde schriftlich durch meinen Provider mitgeteilt,
dass meine bei ihm gehostete Internetseite
gravierende Sicherheitsprobleme aufweißt und dass es einem Hacker am Wochenende gelungen ist, über diese Webseite auf den Server zu gelangen.Dein Provider möchte Dir das bitte so detailiert mitteilen, dass Du das
'Eindringen eines Hackers auf den Server über Deine Webseite'
nachvollziehen kannst. Ansonsten ist das, was Dein Provider da behauptet, null und nichtig. Detailiert heißt u.a.: Welche Seite/Script.
Hotti