Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with Batch-Upload #66

Closed
MrMusic opened this issue Nov 9, 2015 · 22 comments

Comments

@MrMusic
Copy link
Contributor

commented Nov 9, 2015

DE: In der aktuellen Joomla!-Version gibt es Probleme beim Upload von zip-Dateien. Sobald ein "verdächtiger" Dateiname enthalten ist (z.B. "screenshot upload.php.jpg"), wird der ZIP-Upload verhindert. Mit dem Problem haben viele Joomla!-Erweiterungen zu tun (JCE, Kunena,...). Mögliche Lösung: den Upload auch verdächtiger Dateien explizit zu erlauben. Mit folgender Änderung in der administrator/components/com_joomgallery/helpers/upload.php Zeile 568 sollte der upload auf jeden Fall funktionieren: JFile::upload($zippack['tmp_name'], $zipfile, false, true);
Siehe auch: http://forum.joomla.org/viewtopic.php?f=715&p=3342270

EN: In the latest Joomla! version you are having problems uploading zip files. Once containing a "suspicious" file name (eg "screenshot upload.php.jpg"), the ZIP upload is prevented.
The problem have many Joomla! Extensions too (JCE, Kunena, ...). Possible solution: to allow the upload and suspicious files explicitly. With the following change in the administrator/components/com_joomgallery/helpers/upload.php line 568 the upload should definitely work: JFile::upload($zippack['tmp_name'], $zipfile, false, true);
See also: http://forum.joomla.org/viewtopic.php?f=715&p=3342270

@Erftralle

This comment has been minimized.

Copy link
Contributor

commented Nov 11, 2015

Das Problem kann ich bestätigen.

Vielleicht wäre eine Änderung nach

      JFile::upload($zippack['tmp_name'], $zipfile, false, false, array('php_tag_in_content' => false, 'shorttag_in_content' => false, 'fobidden_ext_in_content'  => false));

sinnvoller, da so nicht alle Sicherheitsüberprüfungen deaktiviert werden?

Zusätzlich sollten auch entsprechende Änderungen an allen anderen Stellen im JoomGallery Code vorgenommen werden, an denen JFile::upload() verwendet wird.

Edit: Code korrigiert!

@MrMusic

This comment has been minimized.

Copy link
Contributor Author

commented Nov 12, 2015

Vielleicht wäre eine Änderung nach
JFile::upload($zippack['tmp_name'], $zipfile, false, false, array('php_tag_in_content' => false, 'shorttag_in_content' => false, 'fobidden_ext_in_content' => false));
sinnvoller, da so nicht alle Sicherheitsüberprüfungen deaktiviert werden?

Danke!
Nach Möglichkeit sollten natürlich die Sicherheitspüfungen erhalten bleiben. Allerdings habe ich auf Joomla.org keine Doku zu den Parametern gefunden.

PS: Ich habe in meinen Github Account ein paar Branches mit neuen Features angelegt.
Ich wäre froh deine fachkundige Meinung dazu zu erhalten. 😄

@Erftralle

This comment has been minimized.

Copy link
Contributor

commented Nov 12, 2015

Nach Möglichkeit sollten natürlich die Sicherheitspüfungen erhalten bleiben. Allerdings habe ich auf Joomla.org keine Doku zu den Parametern gefunden.

Schau dir doch einfach den Code von JFile::uplaod() und JFilterInput::isSafeFile() direkt an. Vielleicht gibt es hierzu noch mehr Meinungen.

PS: Ich habe in meinen Github Account ein paar Branches mit neuen Features angelegt.
Ich wäre froh deine fachkundige Meinung dazu zu erhalten.

Ja sowas, da war aber einer fleißig 👍 .

Warum hast du denn keine Pull Requests erstellt? Dann hätten ich und wahrscheinlich auch andere schon früher etwas bemerkt. Zudem muss man sich, wenn man die Features testen möchte, einen weiteren Remote auf deinen Fork anlegen, um die Branches auszuchecken. Dies ist zwar grundsätzlich kein Problem, führt aber nach meinen Erfahrungen immer wieder zu seltsamen Git Fehlermeldungen über Mehrdeutigkeiten, die ich irgendwie nicht in den Griff bekomme. Es ist kein Problem nach Erstellung eines Pull Requests noch weitere Änderungen an dem Branch vorzunehmen. Diese wirken sich dann automatisch auf den Pull Request aus.

Habe mir gerade schon kurz den ersten neuen Branch Reset-configuration angeschaut und es sind mir schon ein paar Gedanken dazu gekommen. Was meinst du, willst du nicht doch erst einen Pull Request (gegen v3.3.0) erstellen? Dann können wir und möglicherweise auch andere dort weiter diskutieren. Wenn nicht, kann ich auch auf deinem Account reagieren.

@MrMusic

This comment has been minimized.

Copy link
Contributor Author

commented Nov 13, 2015

Schau dir doch einfach den Code von JFile::uplaod() und JFilterInput::isSafeFile() direkt an. Vielleicht gibt es hierzu noch mehr Meinungen.

Beim durchschauen der Zusammenhänge komme ich schon an die Grenze meiner Möglichkeiten. 😕

Ich werde gerne die Pull-Requests anlegen, wenn das einfacher ist. 🆗

@Chraneco

This comment has been minimized.

Copy link
Member

commented May 18, 2016

Kommt es tatsächlich vor, dass binary content zufälligerweise mit Erweiterungen wie .php gematched wird?
Ich habe in #92 mal den Vorschlag von oben umgesetzt.

@Chraneco Chraneco added this to the v3.3.2 milestone May 18, 2016
@Erftralle

This comment has been minimized.

Copy link
Contributor

commented May 18, 2016

Als erstes, ich bin mir meines Vorschlags gar nicht mehr so sicher. Es wäre möglich, dass dies auf Kosten der Sicherheit geht.

Kommt es tatsächlich vor, dass binary content zufälligerweise mit Erweiterungen wie .php gematched wird?

Wenn man beispielsweise ein ZIP-Datei generiert, die eine Datei namens "xxx.php.jpg" enthält, dann enthält der (binäre) Content der ZIP-Datei diesen Dateinamen, so dass der Parameter 'fobidden_ext_in_content' => true dazu führt, dass diese als unsicher bewertet wird. Deswegen hatte ich vorgeschlagen, diesen Parameter auf false zu setzen. Worüber ich mir selbst nicht klar bin, ist folgendes: Selbst wenn in der ZIP-Datei keine Datei mit unsicherer Dateiendung enthalten wäre, dann könnte es doch sein, dass die binären Daten (der Bilder selbst) zufälligerweise einen String ".php" entspricht hexadezimal 0x2e 0x70 0x68 0x70 enthalten. Die Daten werden ja per fread() in einen String eingelesen und anschließend per strstr($data, '.php') geprüft.

Mein Vorschlag, den Parameter php_tag_in_content auf false zu setzen, ist vielleicht auch gar nicht so sinnvoll. Es könnte z.B. sein, dass bei Upload einer Bilddatei, z.B. mit uploadSingles, die Exif Daten eingeschleusten PHP Code enthalten (ausführliche Informationen gibt es hier). Die Funktion isSafeFile() prüft jede Datei, sogar unabhängig von ihrer Erweiterung, auf den Inhalt von langen PHP Tags. Die Frage, die ich mir hier wieder stelle, ist: Selbst wenn in den Metadaten kein eingeschleuster PHP Code enthalten ist, wäre im binären Content ein Folge von "<?php" entsprechend hexadezimal 0x3c 0x3f 0x70 0x68 0x70 nicht ebenso möglich? Ich habe mir daraufhin mal einige Bilddateien in HEX angeschaut, konnte aber diese Datenabfolge nicht finden.

Für den Parameter shorttag_in_content gelten ähnliche Überlegungen.
Hier prüft isSafeFile() aber nur Dateien mit ganz bestimmten Extensions. Dies hat sicher seinen Grund, denn die Folge von "<?" entsprechend hexadezimal 0x3c 0x3f konnte ich mehrfach in den von mir untersuchten Bilddateien finden. Würden auch Dateien mit z.B. der Erweiterung ".jpg" geprüft werden, würde dies wohl zu Fehlmeldungen führen.

@Chraneco

This comment has been minimized.

Copy link
Member

commented May 18, 2016

Die Frage ist also, wie wahrscheinlich es ist, dass diese Zeichenfolgen mal zufällig im binären Content auftauchen. Um die explizite Erwähnung von z.B. ".php" im Dateinamen bin ich eigentlich nicht so besorgt oder kommt es öfters vor, dass jemand versucht Bilddateien mit solchen Namen hochzuladen?

Hat jemand schon Bug-Reports speziell für die JoomGallery über dieses Problem gesehen?

@Erftralle

This comment has been minimized.

Copy link
Contributor

commented May 18, 2016

Hat jemand schon Bug-Reports speziell für die JoomGallery über dieses Problem gesehen?

Ich nicht.

@Erftralle

This comment has been minimized.

Copy link
Contributor

commented May 19, 2016

Die Frage ist also, wie wahrscheinlich es ist, dass diese Zeichenfolgen mal zufällig im binären Content auftauchen.

Da hast du Recht. Ich habe mal meine eingestaubten Mathekentnisse aus meinem Hirn gekramt:

.php im Content: ca. 1:172 Millionen
<?php im Content: ca. 1:8,6 Milliarden
Sechser im Lotto: ca. 1:14 Millionen
<? im Content: 1:32385

@Chraneco

This comment has been minimized.

Copy link
Member

commented May 20, 2016

Danke ;) Hört sich also sehr unwahrscheinlich an.
Ich würde dann vorschlagen, diesbezüglich vorerst keine Änderungen durchzuführen und diese Einträge zu schließen.

@Erftralle

This comment has been minimized.

Copy link
Contributor

commented May 21, 2016

Ich würde dann vorschlagen, diesbezüglich vorerst keine Änderungen durchzuführen und diese Einträge zu schließen.

Ich denke genauso!

@Chraneco Chraneco closed this May 21, 2016
@MrMusic

This comment has been minimized.

Copy link
Contributor Author

commented May 23, 2016

Hat jemand schon Bug-Reports speziell für die JoomGallery über dieses Problem gesehen?

Der vollständigkeit halber: http://www.forum.en.joomgallery.net/index.php?topic=7337.0

@Chraneco

This comment has been minimized.

Copy link
Member

commented May 27, 2016

Danke für den Link! Ich habe dort mal gepostet.

@Erftralle

This comment has been minimized.

Copy link
Contributor

commented Jun 22, 2016

Ich habe dort mal gepostet.

Es hat eine Antwort gegeben.

@Chraneco Chraneco reopened this Jul 21, 2016
@Chraneco

This comment has been minimized.

Copy link
Member

commented Aug 7, 2016

Wie weitreichend ist dieses Problem?
Sollen wir #92 wieder öffnen?
Andernfalls würde ich jetzt eine neue Bugfix-Version veröffentlichen.

@Chraneco Chraneco modified the milestones: v3.3.3, v3.3.2 Aug 7, 2016
@Erftralle

This comment has been minimized.

Copy link
Contributor

commented Aug 8, 2016

Wie weitreichend ist dieses Problem?

Wie meinst du das?

Sollen wir #92 wieder öffnen?
Andernfalls würde ich jetzt eine neue Bugfix-Version veröffentlichen.

Du bist hier der Boss 😄 .
Da ich persönlich den Batch Upload nie verwende, kann ich mit dem eher seltenen Problem gut leben.

@Chraneco

This comment has been minimized.

Copy link
Member

commented Aug 14, 2016

Wie meinst du das?

Ob bereits sehr viele Benutzer davon betroffen sind, aber das sieht nicht so aus. Ich habe hier einen kurzen FAQ-Artikel angelegt und würde sagen, dass wir dann hier erstmal abwarten, bevor wir die Sicherheitschecks entfernen.

@Chraneco Chraneco closed this Aug 14, 2016
@Erftralle

This comment has been minimized.

Copy link
Contributor

commented Aug 15, 2016

Einverstanden. Vielen Dank!

@sm8ps

This comment has been minimized.

Copy link

commented Jan 8, 2017

Ich kann seit dem Update von Joomla (auf aktuell 3.6.5; habe leider kein Buch geführt) KEINE gezippte Bilddateien mehr im Batch-Upload verwenden. Ich hatte schon fast überall nach Lösung gesucht und bin nun nach STUNDENLANGER Suche hierher gestossen. Damit will ich sagen, dass es nicht offensichtlich ist, dass sich alle betroffenen User zu Wort melden.

Ich muss vorausschicken, dass ich den Code nicht studiert habe, sondern meine Informationen aus dem Beitrag von @Erftralle vom 18 May 2016 entnehme.

Wie gesagt habe ich kein einziges Mal erfolgreich Zip-Files hochladen können. Nun habe ich einen interessanten Fall zur Hand, wo ich aus 12 Bilddateien diejenige aussortieren konnte, welche Probleme bereitet. Unter der Annahme, dass sich es bei den vorherigen erfolglosen Versuchen ähnlich verhielt, liegt meine Misserfolgsquote pro Datei (!) in der Grössenordnung von 1:10

Dann habe ich die Berechnungen von @Erftralle zur Frage, wie wahrscheinlich es ist, dass diese Zeichenfolgen mal zufällig im binären Content auftauchen, genauer angeschaut. Die stimmen m.E. nicht, denn sie hängen ja gar nicht von der Dateigrösse ab. Klar ist die Chance auf einen 6er im Lotto gering, aber wenn man genügend oft spielt, steigen sie natürlich gegen hohe Werte.

Konkret sieht das m.E. folgendermassen aus: Im digitalen Content kann jedes Byte 256 = 2^8 verschiedene Werte annehmen. Die Wahrscheinlichkeit, in k Bytes eine vorgegebene Zeichenfolge (bspw. '<?' mit k = 2, '.php' mit k = 4 bzw '<?php' mit k = 5) zu haben beträgt p = 1/2^(8k); für k = 2 also 1/65536, für k = 4 ca. 1/4 Mia. und für k = 5 ca. 1/1 Bio.

Diese Wahrscheinlichkeit wird an jeder Stelle einer n Byte grossen Datei (eigentlich n+k-1, aber das spielt keine Rolle) getestet. Die Frage ist eigentlich, wie gross n sein muss, sodass mit einer bestimmten Wahrscheinlichkeit W von bspw. 90% mindestens eine solche Zeichenfolge auftritt. Andersrum betrachtet: Die Wahrscheinlichkeit für keine solche Zeichenfolge soll unter bspw. 1-W = 10% liegen.
D.h. (1-p)^n < 1-W, d. h. n > log(1-W)/log(1-p) betragen. Mit den obigen Werten erhalte ich als Mindestgrösse der Datei(-en) (grob gerundete Werte jeweils für W = 50%, 90%, 95%) für ...
k = 2 : 45 kB, 150 kB, 200 kB
k = 4: 3 GB, 10 GB, 13 GB
k = 5 : 750 GB, 2.5 TB, 3.3 TB

Das sind bemerkenswert grosse Werte für k = 4, 5, für k = 2 hingegen erschreckend kleine. Ich interpretiere die Werte folgendermassen: shorttag_in_content darf nicht angewendet werden, sonst funktioniert fast sicher gar nichts. php_tag_in_content hingegen wird erst auf lange Frist falsche Fehler erzeugen, sodass man es wohl als sinnvoll erachten kann.

Ich möchte jedoch unbedingt einen Schalter empfehlen, wo diese Einstellungen getätigt werden können. Denn was mache ich sonst mit einem Zip-Datei, von der ich sicher bin, dass sie nur saubere Bilder enthält, die aber trotzdem nicht hochgeladen wird? Zusammen mit entsprechenden Warnungen natürlich.

Wie gesagt kenne ich den Code nicht und weiss deshalb auch nicht, ob ich etwas Sinnvolles beigetragen habe. Ich weiss nur, dass ich keine Zip-Dateien mehr hochladen kann, obwohl ich die Upload-Einstellungen alle entsprechend angepasst habe.

@MrMusic

This comment has been minimized.

Copy link
Contributor Author

commented Jan 9, 2017

@sm8ps: Hast du schon den Dokumentationsartiel von chraneco gelesen und es einmal mit einem anderen ZIP-Programm versucht?

@sm8ps

This comment has been minimized.

Copy link

commented Jan 9, 2017

@MrMusic: Du meinst wahrscheinlich den oben verlinkten FAQ-Artikel? Ja, den habe ich gelesen. Ich verwende den im Dateimanager Nautilus integrierten File Roller auf Ubuntu 16.04. Als Alternative kann ich auf der Command Line zippen, aber ich halte das nicht für sehr sinnvoll, denn die Zufälligkeiten verschieben sich einfach.

Es sollte ja eigentlich auch nicht notwendig sein, einen Fehler so zu beheben, dass man probiert, bis es trotzdem irgendwie funktioniert. Vor allem Benutzer, welche die Fehlerursache nicht kennen, sind hilflos, denn die Fehlermeldung ist ja nicht gerade aussagekräftig.

Ich schlage eine Art "Override"-Einstellung (nur für Backend-User?) vor. Ich selber habe die entsprechenden Werte im Code auf 'true' gesetzt, weil nur ich selber Zip-Ordner hochlade. Aber für allgemeine Sites ist das natürlich keine Lösung.

@Erftralle

This comment has been minimized.

Copy link
Contributor

commented Feb 24, 2017

Dann habe ich die Berechnungen von @Erftralle zur Frage, wie wahrscheinlich es ist, dass diese Zeichenfolgen mal zufällig im binären Content auftauchen, genauer angeschaut. Die stimmen m.E. nicht, denn sie hängen ja gar nicht von der Dateigrösse ab.

Stimmt, jetzt wo du es so sagst 😉 .

Ich schlage eine Art "Override"-Einstellung (nur für Backend-User?) vor. Ich selber habe die entsprechenden Werte im Code auf 'true' gesetzt, weil nur ich selber Zip-Ordner hochlade. Aber für allgemeine Sites ist das natürlich keine Lösung.

👍

@Chraneco Chraneco modified the milestones: v3.4.0, v3.3.3 Mar 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.