schutz gegen hacker
-
Nein warum ?
Wenn ich wirklich eine WebSeite hacken will, dann würde ich es doch wohl nicht hier öffentlich bekanntgeben oder ?Nein wirklich nicht. ICh habe eine Seite und will mal versuchen sie zu knacken
-
Normalerweise werden sog. Exploits von Crackern (nicht Hackern -) ausgenutzt, d.h. Schwachstellen in der verwendeten Server-Software (z.B. Apache, IIS, ...)
SQL-Injection und Brute-Force sind nur oberflächliche Angriffe (d.h. es wird sich kurzfristig Zugang zum System geholt - normalerweise kann man damit aber nicht fremden Code nativ auf den Server einschleusen).
-
Aber ist SQL-Injection eigentlich nicht harmlos , denn man muss ja den Aufbau der Datenbank kenn. Oder täusche ich mich
-
Fischkopf2009 schrieb:
Aber ist SQL-Injection eigentlich nicht harmlos , denn man muss ja den Aufbau der Datenbank kenn. Oder täusche ich mich
Den Aufbau der DB kannst du dir ja holen, wenn/falls du die Antwort der SQL-Abfragen kriegst.
-
Der Aufbau der Datenbank ist nicht unbedingt notwendig zu wissen. Bei schlechter Programmierung reicht schon ein einfaches "OR 1=1" ... dahinter was zum auskommentieren und davor das Stringabschlusszeichen.
Jedes Eingabefeld, was ungeprüft in / aus der Datenbank kommt, kann man ausnutzen.
-
Okay also ich habe meine Seite jetzt so gestaltet, dass ich den Benutzer namen bereits vorgebe. Soll ein Froum für Studenten einer UNI werden. Mit der Matrikelnummer kommt man dann gleich in seinen fahcbereich.
Wenn ich im Passwort Feld nun OR'1'='1' hinzufüge bekomme ich vom Webserver :
Database error: Invalid SQL: Select studentenid, kurs FROM studenten WHERE matrikelnr='OR'1'='1''
MySQL Error: 1064 ( You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '1'='1''' at line 1)Kann ein Hacker damit etwas anfangen =
-
dann gib mal folgendes als nummer ein:
' OR 1 = 1 LIMIT 1 --und ja, er kann damit was anfangen
-
Was macht der Befehl.
Es gibt ja keine leere Matrikel nummer in der Datenbank
-
setz es doch einfach mal in deinen query ein
dafür gibts mysql_real_escape
-
Bei eigenen PHP-Scripts musst du sämtliche Daten vom Benutzer sichern (z.B. durch das hier genannte mysql_real_escape). Das umfasst POST, GET und COOKIE, denn diese Daten kann der Benutzer manipulieren.
Wenn du irgendeinen Inhalt aus $_POST, $_GET oder $_COOKIE ungesichert in einer Datenbank-Query nutzt, dann hast du definitiv eine Sicherheitslücke.
Wenn Benutzer durch irgendwelche Eingaben MySQL-Syntaxfehler produzieren können, dann hast du auch definitiv eine Sicherheitslücke.
-
zwutz schrieb:
dann gib mal folgendes als nummer ein:
' OR 1 = 1 LIMIT 1 --und ja, er kann damit was anfangen
Was kann man damit machen
-
Fischkopf2009 schrieb:
Okay also ich habe meine Seite jetzt so gestaltet, dass ich den Benutzer namen bereits vorgebe. Soll ein Froum für Studenten einer UNI werden. Mit der Matrikelnummer kommt man dann gleich in seinen fahcbereich.
Wenn ich im Passwort Feld nun OR'1'='1' hinzufüge bekomme ich vom Webserver :
Database error: Invalid SQL: Select studentenid, kurs FROM studenten WHERE matrikelnr='OR'1'='1''
MySQL Error: 1064 ( You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '1'='1''' at line 1)Kann ein Hacker damit etwas anfangen =
Cool, das sieht ja vielversprechend aus.
Poste doch mal die URL.
-
Was würdest du als nächstes machen und wie
-
Fischkopf2009 schrieb:
Was würdest du als nächstes machen und wie
-
Ich habe jetz tdas Textfeld (eingabe für nutzernamen und passwort) auf 8 zeichen begerenzt und die ddaten werden als post aus einem formular übertragen. so jetzt ist es doch schon sehr schwer fremenden code in den server zu hacken oder ?
-
Fischkopf2009 schrieb:
Ich habe jetz tdas Textfeld (eingabe für nutzernamen und passwort) auf 8 zeichen begerenzt und die ddaten werden als post aus einem formular übertragen. so jetzt ist es doch schon sehr schwer fremenden code in den server zu hacken oder ?
Nein!
Du hast gerade statt deine Wohnungstür abzusperren einfach nur einen Tisch vor die Tür gestellt. Natürlich ist ein Tisch vor der Tür besser als eine offene Tür - aber ist eine zugesperrte Tür nicht immernoch das beste?
Usereingaben müssen Escaped werden. Punkt. Keine Diskussion bitte.
-
Okay aber wie solld er Angreifer denn seinen Code einschluesen. Das Textfeld ist doch 8 Zeichen lang. Also ein "Select * from table" geht ja schon mal nicht
-
Man muss die Daten ja nicht über deine Website an der Server schicken.
Die musst die Daten, die an den Server geschickt werden, prüfen.
Der Server muss prüfen, nicht der Client, den der ist manipulierbar oder ersetzbar.
-
Vielleicht damit es verständlicher ist:
Wenn du dein Textfeld NUR Client-Seitig auf 8 Zeichen begrenzt kann der Angreifer ganz einfach über z.B. Firebug(Firefox AddOn) die Maximale Länge wieder erweitern.
Sicherheit ist hierbei 0 gegeben.
Würdest du über PHP noch einmal die Länge prüfen (wie gesagt: Serverseitig) bist du eher auf dem richtigen weg.
Für die usability würde ich dann aber die client-seitige "prüfung" drinnen lassen
-
Bitte gebe uns dann die URL, ich denke die Seite wird eine wahre Freude für Scriptkiddies und Hobbyhacker. Für richtige Hacker gibt es eh keine großen Hürden da jedes OS seine 0-Day-Exploits hat und auch weiterhin haben wird. Schön sind immer die Leute die glauben nur weil sie eine Linuxwebserver haben sind sie sicherer als wenn sie das mit einem Windows Server mit IIS gemacht hätten.
