Sicherheitsl?cken im xtc 2?

[tmj]

Hallo!

Ich habe gerade folgende Meldung im Internet gefunden:

http://www.shopanbieter.de/news/archives/2...lattformen.html

Einen Punkt aus der Meldung habe ich bereits ausprobiert.

Ich habe ein Produkt aufgerufen und bei Artikelanzahl ein ? eingetragen und dann auf Jetzt kaufen geklickt. Nun m?sste eine Meldung erscheinen, dass nur Zahlen erlaubt sin. Also dass die Eingabe gepr?ft wurde.

Nach dem Klick auf Jetzt Kaufen wurde der Artikel mit einer Menge von 1000 in den Warenkorb gelegt.

Wie kann ich diese Sicherheitsl?cke beheben? Reicht es, wenn ich die entsrpechenden Felder in der Datenbank ?ndere?

Gibt es noch andere Sicherheitsl?cken?

[Buggyboy]

Hallo!

Das kann ich nicht best?tigen.
Zumindest wenn ich mit meinem Admin-Account bei einem Produkt einen Buchstaben oder eine Buchstabenkombination (z.B.: lol) eingebe, passiert rein garnichts. XTC springt einfach wieder auf die Produktseite ohne etwas in den Warenkorb eingetragen zu haben.

Mit verspielten Gr??en
Peter

[bmg4ever]

Jo der Fehler ist in Verson zwei tats?chlich vorhanden und hier liegt das Kind begraben:

application_top.php:

 if ($_POST['products_qty']>MAX_PRODUCTS_QTY) $_POST['products_qty']=MAX_PRODUCTS_QTY;

? oder irgendein anderer Buchstabe ist anscheinend gr??er als MAX_PRODUCTS_QTY.

Ich wei? zwar nicht in was php das beim Vergleich umwandelt aber logischweise baut dieser Vergleich mist und setzt die Menge auf die in der Admin-Oberfl?che eingestellte maximale Bestellmenge.

Richtig m?sste es lauten:

 if (($_POST['products_qty']>MAX_PRODUCTS_QTY) && is_numeric($_POST['products_qty'])) $_POST['products_qty']=MAX_PRODUCTS_QTY;

wie es in der Zeile davor bei der products_id v?llig richtig gemacht wurde, wobei die doch nichtmal eine Benutzereingabe ist, sondern ?ber ein hidden-field ?bergeben wird. Aber naja jeder macht mal Fehler, obwohl man Benutzereingaben immer besonders unter die Lupe nehmen sollten

Ich w?re mal stark davon ausgehen, dass das auch schon l?ngst mal behoben wurde auf dem Weg zur 3er Version.

[xt:mzanier]

was hat das mit einer sicherheitsl?cke zu tun ? hat keinerlei auswirkungen oder sonstiges.


wenn jemand 10000 produkte bestellen will, dann kann er auch 10000 in das feld eingeben.


nicht Int werte werden ignoriert und eben auf einen festen wert gesetzt.

[bmg4ever]

Originally posted by mzanier@Oct 14 2005, 11:47 AM
was hat das mit einer sicherheitsl?cke zu tun ? hat keinerlei auswirkungen oder sonstiges.
wenn jemand 10000 produkte bestellen will, dann kann er auch 10000 in das feld eingeben.
nicht Int werte werden ignoriert und eben auf einen festen wert gesetzt.

naja gut du hast recht, dass es im eigentlichen sinne keine sicherheitsl?cke ist. aber erz?hl mir nicht, dass das so gewollt ist.
nach dem allseits beliebten motto "it's not a bug, it's a feature".

In diesem Fall w?rde ich dann rein aus Kundenfreundlichkeit die Menge nicht auf "MAX_PRODUCTS_QTY", sondern auf 1 setzen.
Am besten ist nat?rlich wenn man irgendwie eine R?ckkopplung f?r den User einbaut, so wie bei einem Anmeldeformular, dass Pflichtfelder nicht ordnungsgem?? ausgef?llt wurden.

[tmj]

was hat das mit einer sicherheitsl?cke zu tun ? hat keinerlei auswirkungen oder sonstiges.

Naja so wie es in dem Artikel steht, soll es dem Hacker dann M?glich sein Komandos in die DB einzutragen:

ein Beispiel: "Fehler in der Verarbeitung von Benutzereingaben werden von Hackern gerne ausgenutzt, um den Web-Shop zu unterwandern. Wird beispielsweise bei der Eingabe einer Bestellmenge nicht vom Web-Shop ?berpr?ft, ob es sich bei der Eingabe tats?chlich um eine Zahl handelt, kann ein Hacker auf diesem Weg eigene Kommandos an die Datenbank des Web-Shops absetzen. In vielen F?llen k?nnen dadurch extrem sensible Daten wie Kreditkarteninformationen in die H?nde der Hacker gelangen und von diesen missbraucht werden"

[xt:mzanier]

Naja so wie es in dem Artikel steht, soll es dem Hacker dann M?glich sein Komandos in die DB einzutragen:

aber nicht bei xtc, denn wie du oben bereits erkennen kannst, wird bei falsch eingabe der maximalwert gesetzt, und nichts anderes.