schutz gegen hacker
-
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.
-
Benutze PreparedStatements und die meisten Probleme was Code-Injection anbelangt sind behoben...
-
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.
-
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...
-
in dem Zusammenhang vll interessant:
http://blog.oncode.info/2008/05/07/php_self-ist-boese-potentielles-cross-site-scripting-xss/