Neuigkeiten

Autor Thema: KORREKTUR: Sicherheitspatch für alle Shopversionen (security_fix_2019_05_03.zip)  (Gelesen 4597 mal)

Online Tomcraft

  • modified Team
  • *****
  • Gravatar
  • Beiträge: 43.861
  • Geschlecht: Männlich
    • Teile Beitrag
Liebe Community,

leider ist uns gestern im Sicherheitspatch für die Shopversionen 1.00 bis 1.06 SP4 ein Fehler unterlaufen, der dazu führte, dass keine Artikel mit Optionen mehr in den Warenkorb gelegt werden können (Der Sicherheitspatch für die Shopversionen 2.x ist davon nicht betroffen!). Wir haben daher das Download-Paket von gestern nochmal aktualisiert und bitten um erneuten Austausch der Datei "/includes/classes/shopping_cart.php".

Download des Fixes: Klick mich

Gemeldet wurde uns die Lücke von Jens Justen von (web-looks).

Wir wünschen euch weiterhin gute Geschäfte und viel Spass mit unserer Shopsoftware.

Euer modified eCommerce Shopsoftware Team

Linkback: https://www.modified-shop.org/forum/index.php?topic=40211.0

Offline karsta.de

  • Experte
  • *****
  • Beiträge: 1.681
    • Teile Beitrag
Danke, dass das Sicherheitspatch bereitgestellt wurde.
Schade nur, dass für Version 2.0.4.2 rev 11374 nicht gleich die wichtige Korrektur aus Ticket #1511 mit eingeflossen ist.

BG kgd

Online Tomcraft

  • modified Team
  • *****
  • Gravatar
  • Beiträge: 43.861
  • Geschlecht: Männlich
    • Teile Beitrag
[...]
Schade nur, dass für Version 2.0.4.2 rev 11374 nicht gleich die wichtige Korrektur aus Ticket #1511 mit eingeflossen ist.
[...]

Ein Sicherheitspatch hat nichts mit dem Nachreichen von Funktionen zu tun! :!:

Grüße

Torsten

Offline FräuleinGarn

  • Fördermitglied
  • *****
  • Beiträge: 3.338
    • Teile Beitrag
Die mögliche Gefahr durch SQL Injection wurde geschlossen mit:

Code: PHP  [Auswählen]
WHERE products_id = '".xtc_get_prid($products_id)."'

Sind alle weiteren Änderungen bzgl des casten mit int denn wirklich notwendig? Bzw. warum wurde dabei nicht an Shops mit Dezimalzahlen gedacht? Wäre es nicht auch mit (double) gegangen und hätte dann sowohl bei Shops mit ganzen Mengen als auch mit Dezimalmengen funktioniert? So ist das im weiteren Verlauf für Shops mit Dezimalmengen nicht updatesicher.

Gruß Timm

Offline GTB

  • modified Team
  • *****
  • Gravatar
  • Beiträge: 5.352
  • Geschlecht: Männlich
    • Teile Beitrag
Auch hier gilt, dass wir keine neuen Funktionen mit einem Sicherheitspatch bringen.
Aktuell unterstützen wir keine Kommawerte für die Menge.

Gruss Gerhard

Offline FräuleinGarn

  • Fördermitglied
  • *****
  • Beiträge: 3.338
    • Teile Beitrag
Es wäre ja keine neue Funktion, da dadurch noch lange keine Dezimalzahlen im Shop funktionieren. Dazu bedarf es ja wesentlich mehr Änderungen.

Double statt int hätte vermutlich für normale Shopnutzer keine Nachteile und die "Sicherheitslücke" (wenn es denn eine ist), wäre dennoch geschlossen und für Shops mit Dezimalzahlen hätte es den Vorteil der Updatesicherheit.

Gruß Timm

Offline noRiddle

  • Experte
  • *****
  • Beiträge: 10.188
  • Geschlecht: Männlich
    • Teile Beitrag
Wie soll das "den Vorteil der Updatesicherheit" haben wenn es noch zig andere Stellen im System gibt wo Produkt-Qty. auf Int gecastet wird ?
Mit Verlaub, FräuleinGarn, du übertreibst es hier ein bisschen.
Ich verstehe überhaupt nicht wieso du unbedingt in einem Sicherheits-Patch eine Teillösung möchtest.

Es ist doch ohnehin besser, sollte das modified-Team sich dazu entscheiden die Möglichkeit Kommazahlen bei Produkt-Quantity verwenden zu können fest einzubauen, das alles in einem Schwung zu machen. Man muß da sehr genau sein und den Code durchforsten wo überall Int-Casts auf Produkt-Qty. gemacht werden (z.B. auch in der /includes/cart_actions.php und ich meine sogar in einigen Versandmodulen) und dabei gleichzeitig jede S.-Lücke ausschließen.; vom Anpassen der Types in DB-Feldern mal ganz zu schweigen.
Das ist nichts für mal eben machen, oder für teilweise machen.

Gruß,
noRiddle

Offline FräuleinGarn

  • Fördermitglied
  • *****
  • Beiträge: 3.338
    • Teile Beitrag
@noRiddle
die quasi-Updatesicherheit war nur auf diese eine Datei bezogen. Ich kann mit meinen Dezimalzahlen nicht die (int) vor qty setzen - muss mich also um eine eigene Lösung kümmern und hab dann weitere geänderte Stellen in Shopcore Dateien, was mir logischerweise nicht so gefällt. Ich hätte gedacht, wenn man dort einfach so das (int) einsetzen kann, dass man stattdessen auch (double) einsetzen könnte, ohne Nachteile für normale Shops und gleichzeitig keine Änderungen an diesen Stellen für Shops mit Dezimalzahlen bei Updates.

Die zig anderen Stellen im Shop mit (int)qty habe ich nicht für wichtig gehalten, weil sie ja bei mir auch weiterhin da sind und mein Meterwarenmodul dennoch funktioniert, ohne dass ich direkt in den Shopcore-Dateien was ändern musste, sondern fast alles updatesicher gelöst ist bis auf zwei hookpoints in der shopping_cart.php (um die es hier geht und deshalb quasi updatesicher) und einer kleinen Änderung in einer anderen Datei. Vielleicht stell ich mir das auch zu einfach vor.

Es geht mir nicht um eine Teillösung. Das alleine bringt doch nichts auf dem Weg zu einem Shop mit Dezimalzahlen. Aber da der Shop in absehbarer Zeit nicht vom Team auf Dezimalzahlen umgerüstet wird, sollte man doch denjenigen die diese nutzen nicht unnötig mehr Steine in den Weg legen, wenn man es auch anders lösen könnte. Betonung liegt auf könnte, da ich das ja nur annehme.

BTW: Wenn ich deine Ausführungen im zugehörigen Ticket #1622 richtig deute, dann bist du doch der Meinung, dass es sich bei den auf int gecasteten Stellen nicht um Sicherheitslücken handelt, oder? Das wäre ein zweiter Kritikpunkt, weil ich mich um eine Änderung kümmern muss, die eventuell nicht sicherheitsrelevant ist.

Gruß Timm

Online Tomcraft

  • modified Team
  • *****
  • Gravatar
  • Beiträge: 43.861
  • Geschlecht: Männlich
    • Teile Beitrag
[...]
BTW: Wenn ich deine Ausführungen im zugehörigen Ticket #1622 richtig deute, dann bist du doch der Meinung, dass es sich bei den auf int gecasteten Stellen nicht um Sicherheitslücken handelt, oder? Das wäre ein zweiter Kritikpunkt, weil ich mich um eine Änderung kümmern muss, die eventuell nicht sicherheitsrelevant ist.
[...]

Bitte hab Verständnis, dass wir hier nicht öffentlich auf Details der Korrektur eingehen. Wir wollen mögliche Angreifer ja nicht noch mit der Nase drauf stoßen! Es gibt Stellen, die dringend korrigiert werden mussten!

Grüße

Torsten

Shop Hosting

Teile per facebook Teile per linkedin Teile per twitter