Ein paar dumme Fragen zu "XSS" und zur Sicherheit von Datenbanken

[Onkel Schnitzel]

Nabend,

ich habe gerade darüber nachgedacht, was eigentlich ist, wenn die Sicherheitsvorkehrungen in meinem Gästebuch-Script nicht genügen und ein Hacker über "Cross-Side-Scripting" meine Datenbank angreift. Die Frage stellt sich, weil ich mein GB mit MySQL realisieren will. Dort hätte ich eine Datenbank mit mehreren Tabellen, u.a. auch jene fürs Gästebuch.

Nehmen wir mal an, dem Hacker gelänge es, meine Datenbank anzugreifen- was ist darunter eigentlich genau zu verstehen? Könnte er nur meine Gästebuch-Tabelle manipulieren oder die gesamte Datenbank? Und kann er darüber hinaus sogar auf dem Server Schaden anrichten?

Viele Grüße,
Onkel Schnitzel

[Sebastian Salzgeber]

Wenn er es geschickt anstellt kann er die Admin-Rechte deiner DB bekommen und ab da steht ihm praktisch alles frei.

Schaden muss man da wohl defnieren: Verlust aller Einträge der DB sind möglich.

[Mike©]

Moin Onkel Schnitzel,

Nehmen wir mal an, dem Hacker gelänge es, meine Datenbank anzugreifen- was ist darunter eigentlich genau zu verstehen? Könnte er nur meine Gästebuch-Tabelle manipulieren oder die gesamte Datenbank? Und kann er darüber hinaus sogar auf dem Server Schaden anrichten?

zunächst mal ganz Grundsätzlich; Es gibt keine dummen Fragen. Bestensfalls dumme Antworten.

Zu deiner Frage. Ich kann dazu keine fachmännische Aussage treffen, aber wann immer eine solch Frage auftaucht, frage ich mich, welche hoch sensiblen Daten haben die Leute eigentlich in ihren Datenbanken.

Wenn ich mir über solche Sicherheitsaspekte Gedanken machen muss, dann habe ich ein entsprechend sicheres System, oder ich habe in der DB Daten, welche sich durch ein einfaches Backuo zurück spielen lassen, und durch deren Verlust nicht jahrelange Arbeit dahin ist.

Also, wie hoch sensibel oder arbeitsintensiv sind deine Daten?

regds
Mike©

[Onkel Schnitzel]

Also, wie hoch sensibel oder arbeitsintensiv sind deine Daten?

Ach, bis auf die Baupläne für meine Atombombe is nix sensibles drauf. :-) Neenee, es ist eine Fußballseite und somit sinds ohnehin öffentliche Sachen, also News, Tabellen, Ergebnisse usw. und halt das Gästebuch.

Ich würde natürlich regelmäßig eine Datensicherung machen (sag ich mal), wobei ich glaube, daß mein Web-Hoster das auch macht. Ich werde die Seite wahrscheinlich, bis auf die News (dafür finde ich hoffentlich Redakteure) alleine pflegen und da ich natürlich nicht permanent am Computer sitzen und alles kontrollieren kann, wäre es mir lieb, wenn ich mir bei längerer Abwesenheit keine Gedanken machen muß, ob irgendwer eventuell was versauen könnte- Z.B durch irgendwelche geschickten Eingaben mein ganzes Layout zerreißen, schweinische Sachen einfügen oder sonstiges.

Gruß,
Onkel Schnitzel

[Mike©]

Moin Onkel Schnitzel,

Ich würde natürlich regelmäßig eine Datensicherung machen (sag ich mal), wobei ich glaube, daß mein Web-Hoster das auch macht. Ich

das würde ich zunächst bezweifeln. Frage einfach mal nach.

Durch geringe Sicherheitsabfragen lassen sich deine Zweifel bzgl. der Layout Manipulationen beseitigen.

Eint Tip: Kümmere Dich selbst um die Datensicherung, und verlasse dich nicht auf deinen Hoster ;-)

regds
Mike©

[Christoph Zurnieden]

Hi,

Zuerst einmal: es gibt einige Verfahren, die mit einfachen Mitteln einen Großteil der Gefahr abwehren können. Grundprinzip: laß niemanden an Deine Datenbank _direkt_ ran.

Nehmen wir mal an, dem Hacker gelänge es, meine Datenbank anzugreifen- was ist darunter eigentlich genau zu verstehen? Könnte er nur meine Gästebuch-Tabelle manipulieren oder die gesamte Datenbank? Und kann er darüber hinaus sogar auf dem Server Schaden anrichten?

Dreimal ja. Und noch schlimmeres. Das ist dann aber extrem unwahrscheinlicher Worst-Case, da muß schon viel zusammenkommen. Mehr oder weniger in dieser Reihenfolge:

1. Du hast Mist programmiert und jeder kann einfach Abfragen an Deine DB direkt schicken -> Datenleck
   1a) Die DB-Konfiguration ist Mist und erlaubt Schreibzugriffe von jedem -> Daten können geändert werden, allerdings nachvollziehbar, wenn geloggt wird.
2. Die DB hat eine Sicherheitslücke -> Daten koruppt
3. Diese Sicherheitslücke und/oder die Konfiguration des Servers erlaubt auch noch Privilege-Escalation -> System korrupt
4. Du hast _schweren_ Ärger mit jemandem.
5. Dieser Jemand hat keinerlei Skrupel, bricht auf Deinem Server ein, sorgt dafür das sich mit der Zeit Material ansammelt, das Dir schaden könnte (z.B. Kinderporno) und meldet's dem Staatsanwalt/dem Partner.
   5a) Du wirst vom Mob gelyncht.

Ich und eine blühende Phantasie? Wie kommt ihr denn darauf? ;-)

so short

Christoph Zurnieden

[Onkel Schnitzel]

Grundprinzip: laß niemanden an Deine Datenbank _direkt_ ran.

Das heißt?

5a) Du wirst vom Mob gelyncht.

Egal, hauptsache die lassen meine Datenbank heil ;-)

Grüße,
Onkel Schnitzel

[Robert Bienert]

Moin!

ich habe gerade darüber nachgedacht, was eigentlich ist, wenn die Sicherheitsvorkehrungen in meinem Gästebuch-Script nicht genügen und ein Hacker über "Cross-Side-Scripting" meine Datenbank angreift.

Das freut mich, denn leider machen sich immer noch viel zu wenig Leute Gedanken über die Sicherheit _ihrer_ Homepage. Das Szenario, was du indirekt ansprichst ist natürlich schon ganz schön heavy, denn die Injektion von ausführbarem Code ist schon recht "unpraktisch".

Die Frage stellt sich, weil ich mein GB mit MySQL realisieren will. Dort hätte ich eine Datenbank mit mehreren Tabellen, u.a. auch jene fürs Gästebuch.

Standard-Bedingung auf den meisten (?) privaten Webseiten der Welt. Wenn du die Datenbankzugriffe kapselst, so dass von außen, z.B. per URI-Parameter oder Eingabeformular nur bestimmte Werte hereingelangen können, fährst du schon recht gut damit. Schau dir mal ein Referat von mir dazu an, es heißt PHPMySQLSicherheit.

Nehmen wir mal an, dem Hacker gelänge es, meine Datenbank anzugreifen- was ist darunter eigentlich genau zu verstehen? Könnte er nur meine Gästebuch-Tabelle manipulieren oder die gesamte Datenbank?

Das hängt, wie bereits angesprochen, von den Berechtigungen der anderen Datenbanken und Tabellen ab, aber in den meisten Fällen kann er wohl sämtliche Tabellen manipulieren. Wenn der Angreifer ein Sicherheitsloch in deinem Gästebuch nutzt, wird er wohl Zugriff auf alle Tabellen haben, auf die auch die zugreifst.

Und kann er darüber hinaus sogar auf dem Server Schaden anrichten?

Das hängt AFAIK auch ein wenig von der SQL-Konfiguration ab, evtl. bietet der verwendete SQL-Dialekt Schnittstellen nach außen hin an, z.B. kann man Shared Libraries (DLLs) laden oder teilweise sogar system calls/API calls absetzen. Normalerweise ist der Systemzugriff über ungeprüftes Lesen von Dateien oder Ausführen ungeprüfter Befehle ein anderes, ebenso spannendes Thema.

Onkel Schnitzel

Lass es dir Schmecken!
Robert

[Robert Bienert]

Die richtige URL ist natürlich

PHPMySQLSicherheit.

Sorry, Robert

[Onkel Schnitzel]

PHPMySQLSicherheit.

Sehr interessant. Ist ja genau das ,was ich gesucht habe.

Gruß und Dank,
Onkel Schnitzel

[Andreas Korthaus]

Hallo!

PHPMySQLSicherheit.

Netter Text! Ich hätte da aber noch zwei Anmerkungen:

Zum Thema "SQL-Injektion":

Erstmal halte ich nicht viel von magic_quotes_gpc = On, weil addaslashes() nicht mit der Quote-Funktionen der Datenbank übereinstimmt, und damit nutzlos ist. Man sollte im Fall von MySQL z.B. mysql_real_escape_string() verwenden, oder die mysqli-Extension mit BindParam.

Außerdem hilft das beste Escaping nichts gegen sowas:

  
$sql = "  
UPDATE users  
SET (passwd=".mysql_real_escape_string($_GET['pass']).")  
WHERE (name=".mysql_real_escape_string($_GET['user']).")  
";  

Wenn man jetzt folgendes aufruft:

file.php?pass=geheim&user=ich OR 1=1

werden die Passwörter für _alle_ User verändert.

Man muss also die Parameter _immer_ in '' einschließen, also so:

  
$sql = "  
UPDATE users  
SET (passwd='".mysql_real_escape_string($_GET['pass'])."')  
WHERE (name='".mysql_real_escape_string($_GET['user'])."')  
";  

Dein Beispiel hat das auch so gemacht, aber ich finde es wichtig das auch rauszustellen, weil viele das eben nicht so machen.

Zum Thema "Dateihandling":

  
$filename = sprintf('%sdir/%s.ext', $_GET['category'], $_GET['name']);  

Wenn ich das wie folgt aufrufe:

file.php?category=sub&name=../../../etc/hosts

ist es ausgehebelt. Du gehst zwar auf ../ ein, aber es gibt keine Alternative wenn Du die GET-Werte selbst verwenden willst. Ich würde es wenn nur irgendwie möglich vermeiden Daten vom User direkt an solche Funktionen zu übergeben (z.B. durch eine "whitelist"). Wenn Du es denn doch direkt verwenden willst, würde ich basename($_GET['name']) ... verwenden (für _jeden_ Parameter!).

Allgemein kann ich noch folgende Links zum Thema empfehlen:

http://de.php.net/manual/de/security.php
http://de.php.net/security-note.php
http://phpsec.org/projects/
http://talks.php.net/index.php/Security
http://www.owasp.org/
http://www.sklar.com/page/article/owasp-top-ten

Grüße
Andreas

[Robert Bienert]

Nabend!

PHPMySQLSicherheit.

Netter Text!

Danke!

Ich hätte da aber noch zwei Anmerkungen:

Vielen Dank für deine Hinweise! Wie gesagt, das Dokument ist ein Referat für die Schule, mittlerweile bin ich am Studieren. Ich wollte die Seite eh in nächster Zeit überarbeiten, ich hoffe, du hast nichts dagegen, wenn ich deine Anmerkungen miteinbeziehe, du wirst auch bei den Credits erwähnt (natürlich nur, wenn du möchstest ;-) ).

Viele Grüße, Robert

[Andreas Korthaus]

Hi!

Vielen Dank für deine Hinweise! Wie gesagt, das Dokument ist ein Referat für die Schule, mittlerweile bin ich am Studieren. Ich wollte die Seite eh in nächster Zeit überarbeiten,

Wenn Du Lust hast kannst Du ja auch direkt einen Feature Artikel draus machen, der auf SELFHTML veröffentlicht wird! Wäre Dir gerne behilflich wenn Du Fragen hast. Meine Mail-Adresse steht oben.

ich hoffe, du hast nichts dagegen, wenn ich deine Anmerkungen miteinbeziehe, du wirst auch bei den Credits erwähnt (natürlich nur, wenn du möchstest ;-) ).

natürlich nicht ;-)

Noch eine Anmerkung, Du verwendest sowas wie

header("Location: /");

Damit verstößt Du gegen das HTTP-Protokoll, gemäß RFC 2616 muss Du bei Location eine absolute URI angeben. Wie man das lösen kann findest Du im Manual: http://de3.php.net/header#AEN42293

Grüße
Andreas

[Robert Bienert]

Gute Tag!

Wenn Du Lust hast kannst Du ja auch direkt einen Feature Artikel draus machen, der auf SELFHTML veröffentlicht wird! Wäre Dir gerne behilflich wenn Du Fragen hast. Meine Mail-Adresse steht oben.

Interessante Idee. Ein Freund von mir hat mir auch schon angeboten, den (dann überarbeiteten) Artikel in der Datenschleuder (des CCC zu veröffentlichen. Ich hätte nie gedacht, dass eine harmlose Spielerei während einer Unterrichtsvorführung mal solche "Auswirkungen" haben könnte. Aber wieso nicht.

ich hoffe, du hast nichts dagegen, wenn ich deine Anmerkungen miteinbeziehe, du wirst auch bei den Credits erwähnt (natürlich nur, wenn du möchstest ;-) ).
natürlich nicht ;-)

Das freut mich.

Noch eine Anmerkung, Du verwendest sowas wie

header("Location: /");

Damit verstößt Du gegen das HTTP-Protokoll, gemäß RFC 2616 muss Du bei Location eine absolute URI angeben.

Dieses Problem habe ich bei mir mittlerweile durch eine entsprechende Funktion um den Redirect gelöst; da fällt mir ein, dass ich solche Tools auch mal als OpenSource veröffentlichen wollte. Wird Zeit für den Providerwechsel!

Vielen Dank, Robert

[Andreas Korthaus]

Hallo Robert!

Wenn Du Lust hast kannst Du ja auch direkt einen Feature Artikel draus machen, der auf SELFHTML veröffentlicht wird! Wäre Dir gerne behilflich wenn Du Fragen hast. Meine Mail-Adresse steht oben.

Interessante Idee. Ein Freund von mir hat mir auch schon angeboten, den (dann überarbeiteten) Artikel in der Datenschleuder (des CCC zu veröffentlichen. Ich hätte nie gedacht, dass eine harmlose Spielerei während einer Unterrichtsvorführung mal solche "Auswirkungen" haben könnte. Aber wieso nicht.

Wie gesagt, interessant wäre es auf jeden Fall. Ist ein wichtiges Thema.

Wird Zeit für den Providerwechsel!

Sieht so aus ;-)

Viel Grüße
Andreas

[Andreas Korthaus]

Hallo nochmal!

Zum Thema "Dateihandling":

$filename = sprintf('%sdir/%s.ext', $_GET['category'], $_GET['name']);

>   
> Wenn ich das wie folgt aufrufe:  
>   
> file.php?category=sub&name=../../../etc/hosts  
>   
> ist es ausgehebelt.  
  
Stimmt so nicht ganz - wegen "ext". In älteren PHP-Versionen kann man aber auch das aushebeln.  
  
  
Grüße  
Andreas

-- 
SELFHTML Linkverzeichnis: <http://aktuell.de.selfhtml.org/links/>

[Elderan]

Hallo,
also Cross-Side-Scripting ist noch relativ harmlos, was viel schlimmer ist, wenn er dir PHP-Code unterschiebt, und dieser dann ausgeführt wird.

Dies kann passieren, wenn per URL/Eingabe angegeben wird, welche Datei per include geladen wird.

SQL-Injection sind auch sehr gefährlich, auch wenn PHP schon die besten Sicherheitspackete dort mitbringt.

Aber zurück zu XSS:
Also XSS ist wenn man HTML Code einschleust. Ein Beispiel wäre, wenn du ungefiltert den Benutzernamen ausgibst.
Wenn jmd. z.B. <h1>Name</h1> eingibt, dann wird dieser sehr groß Angezeigt.
Darum sollte man jede Eingabe, egal welche, mit htmlentities() "behandeln".

Was kann passieren, wenn dies nicht passiert:
-Meta-Refresh auf eine fremde Seite
-Leichte Verunstaltung der Seite durch den einen Eintrag

oder, jetzt das gefährliche:
Per JavaScript liest er dir deine Cookies (für die deine Seite) aus und sendet den Inhalt an sich selber.
Sofern du vorher irgendwie im Admin CP warst, ist in dem Cookie normalerweise noch die Session ID gespeichert.
Mit dieser kommt er dann in das Admin CP.

Oder:
Irgendwo auf der Gästebuchseite ist ein Loginformular. Dieses lässt er dann durch sein eigenes "überschreiben", also er lässt ein 2. Fenster über dem Loginfenster anzeigen.
Wenn jmd. sich einloggen möchte, so füllt er das Formular vom Angreifer aus und sendet dann die Daten an den Angreifer.
Damit wäre es auch möglich Loginlinks zu überschreiben, die dann auf die Seite des Angreifers führen.

Oder er baut ein Meta-Refresh ein und sendet dann die Leute auf die eigene Seite, die genau aussieht wie deine, bloß dass er dann die Logindaten sammelt.

Oder:
Er speichert einen JavaScript Virus und dieser Virus installiert dann unerwünschte Software auf den Computern der Gästebuchbetrachter.

Also, wie gesagt eingeschleuster+ausgeführter PHP Code oder SQL Injection sind schlimmer, aber sofern auf der Seite weitere sensible Daten sind, kann man damit auch einigen Schaden anrichten.

Außerdem sollte man auch Werte die per URL übergeben werden nicht einfach so ausgeben.

Und wenn du einen bestimmten Wert erwartest, z.B. eine Zahl, dann solltest du überprüfen ob es eine ist.
Dies geht z.B. per is_numeric().
Sonst kann man soetwas mit regulären Ausdrücken überprüfen.

P.S. PHP Code aus einer DB auszuführen ist recht kompilziert und wird auch nicht empfohlen.
Aber mit echo $row->text; geht dies _nicht_.

Grüße