3. schutz gegen hacker

schutz gegen hacker

  • F

    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 =

    0
  • Z

    dann gib mal folgendes als nummer ein:

    ' OR 1 = 1 LIMIT 1 --

    und ja, er kann damit was anfangen

    0
  • F

    Was macht der Befehl.

    Es gibt ja keine leere Matrikel nummer in der Datenbank

    0
  • Z

    setz es doch einfach mal in deinen query ein

    dafür gibts mysql_real_escape

    0
  • R

    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.

    0
  • F

    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

    0
  • E

    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.

    0
  • F

    Was würdest du als nächstes machen und wie

    0
  • E

    Fischkopf2009 schrieb:

    Was würdest du als nächstes machen und wie

    http://www.google.de/search?q=sqlinjection+tutorial

    0
  • F

    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 ?

    0
  • S

    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.

    0
  • F

    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

    0
  • W

    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.

    0
  • ?

    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 😉

    0
  • ?

    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.

    0
  • A

    Benutze PreparedStatements und die meisten Probleme was Code-Injection anbelangt sind behoben...

    0
  • S

    Antoras schrieb:

    Benutze PreparedStatements und die meisten Probleme was Code-Injection anbelangt sind behoben...

    SQL Injections sind nur ein kleiner Teil.
    Ein größeres Problem sind XSS Angriffe, Session Riding, CSRF,...

    Prepared Statements sind natürlich ein muss, keine Frage - aber sicher ist man damit noch lange nicht.

    0
  • A

    Deshalb hab ich ja Code-Injections geschrieben. Meinte damit alle Injections, die man "normal" über den Browser absenden kann.
    Dass das natürlich nur die spitze des Eisberges ist, ist klar. Eine sichere Webapplikation zu entwickeln ist ein langer Weg.

    @TO aber das kann dir am Anfang eigentlich alles egal sein. Prepared Statements reichen für den Anfang vollkommen aus. Irgendwann arbeitest dich dann schon noch in die weiterführenden Themen hinein...

    0
  • Z

    in dem Zusammenhang vll interessant:

    http://blog.oncode.info/2008/05/07/php_self-ist-boese-potentielles-cross-site-scripting-xss/

    0
Anmelden zum Antworten