1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Webapplikationen: Sicherheitslücke in…

Sorry, aber der Artikel ist (fast) kompletter Unsinn

  1. Thema

Neues Thema Ansicht wechseln


  1. Sorry, aber der Artikel ist (fast) kompletter Unsinn

    Autor: Cybso 23.10.18 - 12:01

    jQuery ist nur ein JavaScript-Framework, komplett auf der Client-Seite. Wenn es dem Anwender möglich ist, PHP-Dateien auf den Server hochzuladen und diese dann dort auch noch auszuführen, dann ist das ein reines Serverproblem. Das geht dann nämlich auch völlig ohne jQuery. Ein kleines Werkzeug wie curl oder wget reicht aus. Oder ein HTML-Formular mit einem Upload-Feld.



    2 mal bearbeitet, zuletzt am 23.10.18 12:06 durch Cybso.

  2. Re: Sorry, aber der Artikel ist (fast) kompletter Unsinn

    Autor: Gunah 23.10.18 - 12:10

    naja eher ist es der "dumme" Entwickler welche es einfach so nutzt und den Upload Filter nicht selber setzt.

  3. Re: Sorry, aber der Artikel ist (fast) kompletter Unsinn

    Autor: Cybso 23.10.18 - 12:13

    Gunah schrieb:
    --------------------------------------------------------------------------------
    > naja eher ist es der "dumme" Entwickler welche es einfach so nutzt und den
    > Upload Filter nicht selber setzt.

    Aber der glaubt jetzt, er konfiguriert den Upload-Filter in jQuery richtig und wäre vor Angreifern geschützt. Was schlicht nicht der Fall ist.

  4. Re: Sorry, aber der Artikel ist (fast) kompletter Unsinn

    Autor: bummelbär 23.10.18 - 12:18

    Der nachfolgende hat uns erklärt, dass ein jquery-plugin, zumindest dieses, php-code enthält, der auf dem Server ausgeführt wird. Wer hätte das gedacht. :) Ich nicht. ;-)



    2 mal bearbeitet, zuletzt am 23.10.18 12:30 durch bummelbär.

  5. Re: Sorry, aber dein Kommentar ist (fast) kompletter Unsinn

    Autor: Xiut 23.10.18 - 12:25

    Cybso schrieb:
    --------------------------------------------------------------------------------
    > jQuery ist nur ein JavaScript-Framework, komplett auf der Client-Seite.
    > Wenn es dem Anwender möglich ist, PHP-Dateien auf den Server hochzuladen
    > und diese dann dort auch noch auszuführen, dann ist das ein reines
    > Serverproblem. Das geht dann nämlich auch völlig ohne jQuery. Ein kleines
    > Werkzeug wie curl oder wget reicht aus. Oder ein HTML-Formular mit einem
    > Upload-Feld.

    Eher ist dein Kommentar (fast) kompletter Unsinn. Hier geht es nämlich nicht um jQuery, sondern um den jQuey File Upload, eine sozuagen Komplettlösung, um eben einen einfachen Upload von Dateien zu ermöglichen.

    Der jQuery File Upload besteht aber NICHT nur aus einem clientseitigen jQuery Plugin, sondern auch aus (unter anderem) einem PHP Skript, um das möglichst auf jedem Server installieren zu können. Zusätzlich gibt es auch schon vorgefertigte Skripte für Go und Python in Verbindung mit der Google App Engine, wenn man den Upload dort verwenden möchte.

    Also ist der Artikela lles andere als (fast) kompletter Unsinn. DU hast entsprechend bloß etwas verwechselt bzw. offenbar sehr viel überlesen.

    Edit: Hier geht es zum entsprechenden Repository bzw. direkt zu dem enthaltenen serverseitigen Teil vom jQuery File Upload: https://github.com/blueimp/jQuery-File-Upload/tree/master/server



    1 mal bearbeitet, zuletzt am 23.10.18 12:27 durch Xiut.

  6. Re: Sorry, aber dein Kommentar ist (fast) kompletter Unsinn

    Autor: bummelbär 23.10.18 - 12:29

    Danke für die Aufklärung. Dann ist also der PHP-Code falsch.
    Ich wäre nie auf die Idee gekommen in einem jquery-plugin php-code zu finden. :) So kann man sich täuschen.

  7. Re: Sorry, aber dein Kommentar ist (fast) kompletter Unsinn

    Autor: Xiut 23.10.18 - 12:39

    bummelbär schrieb:
    --------------------------------------------------------------------------------
    > Danke für die Aufklärung. Dann ist also der PHP-Code falsch.
    > Ich wäre nie auf die Idee gekommen in einem jquery-plugin php-code zu
    > finden. :) So kann man sich täuschen.

    Nein, das hat nichts mit PHP zu tun, auch wenn das leider bei der Formulierung im Artikel auf den ersten Blick so scheinen mag.

    Das einzige, was das mit PHP zutun hat, ist, dass PHP Anwendungen meist genau wie eben dieser jQuery File Upload darauf vertrauen, dass .htaccess Dateien aktiv sind bzw. funktionieren, was eben seit 2010 nicht standardmäßig der Fall ist, da der Apache Webserver standardmäßig .htaccess Dateien ignoriert. Eben aus Gründen der Performance. Mir ist aber ehrlich gesagt noch nie ein Hoster untergekommen, der das nicht aktiv hatte. Und ich hatte schon mit sehr vielen zu tun.

    Wenn man das Skript mit Python oder einer anderen Sprache entwickelt hätte und sich auf .htaccess Dateien verlassen hätte, wäre die Sicherheitlücke jetzt genau so vorhanden.

    Da aber die meisten, vor allem kleinen Webspace Pakete .htaccess berücksichtigen, allein weil viele Wordpress und co. installieren wollen, dürfte die Lücke meiner Meinung nach nicht so extrem verbreitet sein, wie es im Artikel scheint. Entweder man verwendet ein kleines Webhosting Paket, da ist es meiner Erfahrung nach zu 99% aktiviert oder man nutzt ein großes Paket bzw. einen eigenen Server, aber dann wird man selten auf so ein Plugin zurückgreifen oder so ein Verzeichnis eben generell anders absichern.

    Edit: Ich habe mir jetzt mal den Fix im Repository genauer angeschaut. Wenn ich nichts übersehen habe, besteht der Fix einfach nur darin, dass standardmäßig nicht mehr jede Art von Dateien hochgeladen werden dürfen, sondern nur Bilder (gif, jpg und png). Aus meiner Sicht hätte das generell auch schon vorher so sein sollen... Also eigentlich sollte man eher eine Whitelist führen und auch keine Blacklist oder gar alles erlauben...
    Und eigentlich sollte man die Dateien auch nicht mit Originalnamen und -endung speichern, um generell die Angriffsfläche von Anfang an möglichst klein zu halten...

    Edit2: Meine Quelle bzw. der Link zum Fix https://github.com/blueimp/jQuery-File-Upload/commit/aeb47e51c67df8a504b7726595576c1c66b5dc2f



    2 mal bearbeitet, zuletzt am 23.10.18 12:48 durch Xiut.

  8. Re: Sorry, aber dein Kommentar ist (fast) kompletter Unsinn

    Autor: Cybso 23.10.18 - 12:55

    Hi,

    > Eher ist dein Kommentar (fast) kompletter Unsinn. Hier geht es nämlich
    > nicht um jQuery, sondern um den jQuey File Upload, eine sozuagen
    > Komplettlösung, um eben einen einfachen Upload von Dateien zu ermöglichen.

    Danke für die Aufklärung, ich kannte bisher nur reinen Client-Code als jQuery-Plugin. Dass es ein Plugin gibt, welches selbst eine PHP-Komponente enthält, war mir neu - und ging für mich auch so nicht aus dem Artikel hervor.

    Im Gegenteil, auch die Projektseite auf Github deutet an, dass das Plugin mit einem regulären Fileupload arbeitet, welcher von der Serversoftware bereit gestellt werden muss:

    > Works with any server-side platform (Google App Engine, PHP, Python, Ruby on Rails, Java, etc.)
    > that supports standard HTML form file uploads



    1 mal bearbeitet, zuletzt am 23.10.18 12:58 durch Cybso.

  9. Re: Sorry, aber dein Kommentar ist (fast) kompletter Unsinn

    Autor: Xiut 23.10.18 - 13:08

    Cybso schrieb:
    --------------------------------------------------------------------------------
    > Hi,
    >
    > > Eher ist dein Kommentar (fast) kompletter Unsinn. Hier geht es nämlich
    > > nicht um jQuery, sondern um den jQuey File Upload, eine sozuagen
    > > Komplettlösung, um eben einen einfachen Upload von Dateien zu
    > ermöglichen.
    >
    > Danke für die Aufklärung, ich kannte bisher nur reinen Client-Code als
    > jQuery-Plugin. Dass es ein Plugin gibt, welches selbst eine PHP-Komponente
    > enthält, war mir neu - und ging für mich auch so nicht aus dem Artikel
    > hervor.
    >
    > Im Gegenteil, auch die Projektseite auf Github deutet an, dass das Plugin
    > mit einem regulären Fileupload arbeitet, welcher von der Serversoftware
    > bereit gestellt werden muss:
    >
    > > Works with any server-side platform (Google App Engine, PHP, Python, Ruby
    > on Rails, Java, etc.)
    > > that supports standard HTML form file uploads

    Ja, das hätte auch meiner Meinung nach auch deutlicher im Artikel hervorgehen sollen, dass es nicht am eigentlichen Plugin liegt, sondern einem Skript, welches diesem Plugin sozusagen bei liegt.

    Generell ist das Plugin aber eben auch in erster Linie für die clientseitige Handhabung von File Uploads. Also Fortschritte anzeigen, Upload abbrechen können usw., was man entsprechend auch ohne die beiligende Skripte super verwenden kann, aber dann muss man die serverseitige Logik eben selbst entwickeln.

    Also zusammengefasst könnte man das eher so sagen: Die Sicherheitslücke ist nicht direkt in dem Plugin selbst, sondern eher in der Implementiertung des serverseitigen Codes eines sehr einfachen und schlichten File Uploads, der "beiliegt" und entsprechend leicht verwendet werden kann, ohne Serverseitig Ahnung von dem Umgang mit File Uploads haben zu müssen. Aber gerade das wäre eigentlich wichtig, wenn man so etwas nutzt, weil da kleine Fehler schnell sehr kritisch werden können.
    Entsprechend sollte ein solches beiliegende Skript immer eher alles doppelt und dreifach absichern, gerne mit Einstellmöglichkeiten, mit denen man dann bewusst (!!) die Sicherheit herunterschrauben bzw. bestimmte Sicherheitsmaßnahmen abschwächen oder komplett deaktivieren kann, um das für irgendwelche Fälle speziell anpassen zu können, ohne den Code an sich ändern zu müssen.

  10. Re: Sorry, aber dein Kommentar ist (fast) kompletter Unsinn

    Autor: bummelbär 23.10.18 - 13:51

    Also der Fehler ist klar ein Fehler. Soweit so gut, eigentlich ja eher schlecht. Aber es wird, wenn man sich das jetzt mal genau betrachtet, eigentlich nicht besser mit dem Patch.
    Manuelle Realität: Der Benutzer lädt das Archiv, entpackt es und lädt dann alles einfach auf den Webserver. Der macht sich das so einfach wie das Plugin es sich selbst macht. Alles nehmen, hinwerfen, fertig. Nur dass die Programmierer durchaus Erfahrung und Sicherheitsbewußtsein haben müßten.
    Automatische Realität: npm lädt es selbst herunter und entpackt es. bower lädt es selbst herunter und entpackt es. Sonstwas lädt es selbst herunter und entpackt es (manche bauen eigene Tools)
    Hier kann man garnicht mehr sinnvoll eingreifen, ausser man will die Automatisierung manuell durchführen...

    Alle Methoden führen zu theoretisch ausführbarem Code auf einem Server in go, python und php, im Jahre 2018. :)

  11. Re: Sorry, aber dein Kommentar ist (fast) kompletter Unsinn

    Autor: piros 24.10.18 - 00:30

    Xiut schrieb:
    --------------------------------------------------------------------------------
    > Cybso schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > jQuery ist nur ein JavaScript-Framework, komplett auf der Client-Seite.
    > > Wenn es dem Anwender möglich ist, PHP-Dateien auf den Server hochzuladen
    > > und diese dann dort auch noch auszuführen, dann ist das ein reines
    > > Serverproblem. Das geht dann nämlich auch völlig ohne jQuery. Ein
    > kleines
    > > Werkzeug wie curl oder wget reicht aus. Oder ein HTML-Formular mit einem
    > > Upload-Feld.
    >
    > Eher ist dein Kommentar (fast) kompletter Unsinn. Hier geht es nämlich
    > nicht um jQuery, sondern um den jQuey File Upload, eine sozuagen
    > Komplettlösung, um eben einen einfachen Upload von Dateien zu ermöglichen.
    >
    > Der jQuery File Upload besteht aber NICHT nur aus einem clientseitigen
    > jQuery Plugin, sondern auch aus (unter anderem) einem PHP Skript, um das
    > möglichst auf jedem Server installieren zu können. Zusätzlich gibt es auch
    > schon vorgefertigte Skripte für Go und Python in Verbindung mit der Google
    > App Engine, wenn man den Upload dort verwenden möchte.
    >
    > Also ist der Artikela lles andere als (fast) kompletter Unsinn. DU hast
    > entsprechend bloß etwas verwechselt bzw. offenbar sehr viel überlesen.
    >
    > Edit: Hier geht es zum entsprechenden Repository bzw. direkt zu dem
    > enthaltenen serverseitigen Teil vom jQuery File Upload: github.com


    Ich stimme dem Ganzen nicht vollständig zu. Zunächst es ist ein jQuery-Plugin somit Javascript und hat nicht den Anspruch eine Komplettlösung zu sein. Die Scripte für PHP, Go und Python sind ausschließlich Beispiele bzw für Funktiontests, schreibt der Autor des Plugins auch selbst (https://news.ycombinator.com/item?id=18267309). Du musst doch nur mal sehen was du denn hast wenn du das Repository clonst, das ist nichts funktionierendes du musst doch ein Frontend bauen, irgendeine User Authentifizierung brauchts auch und dann ist es immer noch nur ein Upload Button und nichts weiter. Das ist kein Projekt das sich Hans und Dampf clonen, allein um Interesse daran zu haben musst du schon einiges davon verstehen. Leute die Projekte clonen und alles offen im Web, aufrufbar für jeden präsentieren haben keine Ahnung und sollten von vornherein keine Server administrieren.

    Und jeder der lesen kann hätte in diesem Beispielcode auch die Kommentarzeile "// Defines which files (based on their names) are accepted for upload:" finden und den Regex ändern können wenn er es denn gewollt hätte. Das hier ist der neuere Commit zum Fix (der von Xiut war nur für die index.php):

    https://github.com/blueimp/jQuery-File-Upload/commit/ad4aefd96e4056deab6fea2690f0d8cf56bb2d7d#diff-6ebc0394569c042ff1535cfa1a0ce132

    Der Golem Autor tut so als wäre es des Plugin Autors Schuld, die der Entwickler in anderen Projekten oder die der Entwickler des Webservers aber auf keinem Fall die des Admins bzw Anwenders der hier meiner Meinung nach fahrlässiger handelt.
    Zur Verbreitung würde ich auch sagen das es maßlos übertrieben ist zu behaupten, dass der Beispiel PHP Code welcher den Upload ermöglicht in "Hunderten, wenn nicht Tausenden anderen Projekten, darunter Content Management Systems (CMS)" steckt, zumindest nicht in Projekten die weiter distribuiert werden oder Bestandteil von größerem sind, Beispiel CMS.

    Es hätte eben auch ein konstruktiver Artikel sein können, von Beispielen wie es besser gemacht werden könnte oder eben auch Erläuterungen zu Entscheidungen die zum aktuellem Zustand geführt haben bspw die Entscheidung des Apache Projekts die Option allowOverride per Default auf none zu setzen und weshalb das auch sinnvoll ist als Standardwert.
    Eigentlich würde ich die Überschrift des Threaderstellers bestätigen, der Artikel hilft und informiert niemanden zu einem vernünftigem Grad.

  12. Re: Sorry, aber dein Kommentar ist (fast) kompletter Unsinn

    Autor: Xiut 24.10.18 - 08:50

    piros schrieb:
    --------------------------------------------------------------------------------
    > Xiut schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Cybso schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > jQuery ist nur ein JavaScript-Framework, komplett auf der
    > Client-Seite.
    > > > Wenn es dem Anwender möglich ist, PHP-Dateien auf den Server
    > hochzuladen
    > > > und diese dann dort auch noch auszuführen, dann ist das ein reines
    > > > Serverproblem. Das geht dann nämlich auch völlig ohne jQuery. Ein
    > > kleines
    > > > Werkzeug wie curl oder wget reicht aus. Oder ein HTML-Formular mit
    > einem
    > > > Upload-Feld.
    > >
    > > Eher ist dein Kommentar (fast) kompletter Unsinn. Hier geht es nämlich
    > > nicht um jQuery, sondern um den jQuey File Upload, eine sozuagen
    > > Komplettlösung, um eben einen einfachen Upload von Dateien zu
    > ermöglichen.
    > >
    > >
    > > Der jQuery File Upload besteht aber NICHT nur aus einem clientseitigen
    > > jQuery Plugin, sondern auch aus (unter anderem) einem PHP Skript, um das
    > > möglichst auf jedem Server installieren zu können. Zusätzlich gibt es
    > auch
    > > schon vorgefertigte Skripte für Go und Python in Verbindung mit der
    > Google
    > > App Engine, wenn man den Upload dort verwenden möchte.
    > >
    > > Also ist der Artikela lles andere als (fast) kompletter Unsinn. DU hast
    > > entsprechend bloß etwas verwechselt bzw. offenbar sehr viel überlesen.
    > >
    > > Edit: Hier geht es zum entsprechenden Repository bzw. direkt zu dem
    > > enthaltenen serverseitigen Teil vom jQuery File Upload: github.com
    >
    > Ich stimme dem Ganzen nicht vollständig zu. Zunächst es ist ein
    > jQuery-Plugin somit Javascript und hat nicht den Anspruch eine
    > Komplettlösung zu sein. Die Scripte für PHP, Go und Python sind
    > ausschließlich Beispiele bzw für Funktiontests, schreibt der Autor des
    > Plugins auch selbst (news.ycombinator.com Du musst doch nur mal sehen was
    > du denn hast wenn du das Repository clonst, das ist nichts funktionierendes
    > du musst doch ein Frontend bauen, irgendeine User Authentifizierung
    > brauchts auch und dann ist es immer noch nur ein Upload Button und nichts
    > weiter. Das ist kein Projekt das sich Hans und Dampf clonen, allein um
    > Interesse daran zu haben musst du schon einiges davon verstehen. Leute die
    > Projekte clonen und alles offen im Web, aufrufbar für jeden präsentieren
    > haben keine Ahnung und sollten von vornherein keine Server administrieren.

    Stimmt so einfach nicht. Kann ja sein, dass er auf einer anderen Seite zu irgendwas anderem geraten hat, aber vor dem Fix stand noch im Repository, also da wo das vor allem stehen müsste, wenn man das nicht so installieren sollte.
    Was stand da aber stattdessen als Anleitung zur Installation?

    "Using jQuery File Upload (UI version) on PHP websites
    The provided example implementation works out of the box and only needs one step for you to add it to your PHP based website:

    1. Download the plugin archive, extract it and upload the extracted folder (you may rename it) to your server.
    Visit the uploaded directory - you should see the same file upload interface as the demo, allowing you to upload files to your website.

    If uploading files doesn't work, make sure that the php/files directory permissions allow your server write access."

    Kann jeder über die Revisionen nachvollziehen. Und das stand offensichtlich seit 2014 da...
    Wo wird da darauf hingewiesen, dass man das nicht nutzen soll?! Ganz im Gegenteil... Gerade der erste Satz deutet eher darauf hin, dass man es offenbar so bereits verwenden kann, wenn man einen einfachen File Upload braucht. Und es gibt eben viele, die sich mit File Uploads und deren Sicherheit nicht beschäftigt haben und das dann nicht einschätzen können. Klar, die müssten sich damit dann eigentlich auch beschäftigen, aber hier hätte ganz klar dann dieser Hinweis hingehört, dass man das nicht produktiv einsetzen sollte...

    Auf der von dir verlinkten Seite kann ich auch nirgendwo finden, dass dieser serverseitige Code nicht für den produktiven Einsatz verwendet werden sollte. Er schreibt, dass ER das Skript bloß für die Demo und lokale Tests verwendete hat und es dann für IHN eben nicht so kritisch war, dass man alle möglichen Dateien hochladen konnte. Er hat offenbar ja auch die Sicherheit per .htaccess getestet, weswegen er ja auch geschrieben hat, dass er es eben nur mit Webserver Einstellungen getestet hat, wo .htaccess Dateien aktiviert waren. Also scheint er es schon irgendwie wenigstens etwas sicherer machen zu wollen und eben nicht nur für lokale Tests verwenden und anbieten zu wollen...

    > Und jeder der lesen kann hätte in diesem Beispielcode auch die
    > Kommentarzeile "// Defines which files (based on their names) are accepted
    > for upload:" finden und den Regex ändern können wenn er es denn gewollt
    > hätte. Das hier ist der neuere Commit zum Fix (der von Xiut war nur für die
    > index.php):
    >
    > github.com#diff-6ebc0394569c042ff1535cfa1a0ce132
    >
    Ich habe in meinem Kommentar vom Fix der Sicherheitslücke gesprochen und das was du da verlinkt hast, ist nicht der Fix, der mit 9.22.1 umgesetzt wurde, sondern wurde vor gut 20 Stunden (also gestern Mittag) hinzugefügt. Da wurde die Änderung, die in der index.php beim ersten Fix vorgenommen wurde, entsprechend in die Standardeinstellungen übernommen, was generell auch so deutlich besser ist. Der eigentliche erste Fix der Sicherheitlücke, auf den ich mich bezogen habe, fand aber bereits vor 11 Tagen statt.
    Entsprechend ist das, was du verlinkt hast, auch komplett unerheblich was meinen Kommentar betrifft.

    Generell sieht man aber ja ganz deutlich, zum einen an dem von dir verlinkten Beitrag des Entwicklers und auch der Nachbesserung gestern mit der Übernahme in die Standardeinstellungen, dass der Entwickler SEINEN Fehler eingesehen hat. Klar, jeder der so ein Skript verwenden möchte, sollte sich wenigstens grundlegend mit der Sicherheit auseinandersetzen, aber er sagt ja eben jetzt selbst, dass man sich darauf nicht verlassen darf, dass jeder das macht (was ja bei weitem eben nicht jeder macht). Zumal man so ein Skript ja recht leicht entsprechend absichern kann, so dass man es sogar 1:1 verwenden kann.
    Und dafür muss man sich eben nicht auf .htaccess Dateien verlassen, was er aber entsprechend getan hat, was aber eben sein Fehler war. Das hätte nur ein Schutz von mehreren sein dürfen.

    Edit: Ich finde aber auch, dass der Artikel von Golem so formuliert ist, dass man den leicht falsch verstehen kann.



    1 mal bearbeitet, zuletzt am 24.10.18 08:53 durch Xiut.

  13. Re: Sorry, aber dein Kommentar ist (fast) kompletter Unsinn

    Autor: piros 24.10.18 - 12:45

    Xiut schrieb:
    --------------------------------------------------------------------------------
    > Stimmt so einfach nicht. Kann ja sein, dass er auf einer anderen Seite zu
    > irgendwas anderem geraten hat, aber vor dem Fix stand noch im Repository,
    > also da wo das vor allem stehen müsste, wenn man das nicht so installieren
    > sollte.
    > Was stand da aber stattdessen als Anleitung zur Installation?
    >
    > "Using jQuery File Upload (UI version) on PHP websites
    > The provided example implementation works out of the box and only needs one
    > step for you to add it to your PHP based website:
    >
    > 1. Download the plugin archive, extract it and upload the extracted folder
    > (you may rename it) to your server.
    > Visit the uploaded directory - you should see the same file upload
    > interface as the demo, allowing you to upload files to your website.
    >
    > If uploading files doesn't work, make sure that the php/files directory
    > permissions allow your server write access."
    >
    > Kann jeder über die Revisionen nachvollziehen. Und das stand offensichtlich
    > seit 2014 da...
    > Wo wird da darauf hingewiesen, dass man das nicht nutzen soll?! Ganz im
    > Gegenteil... Gerade der erste Satz deutet eher darauf hin, dass man es
    > offenbar so bereits verwenden kann, wenn man einen einfachen File Upload
    > braucht. Und es gibt eben viele, die sich mit File Uploads und deren
    > Sicherheit nicht beschäftigt haben und das dann nicht einschätzen können.
    > Klar, die müssten sich damit dann eigentlich auch beschäftigen, aber hier
    > hätte ganz klar dann dieser Hinweis hingehört, dass man das nicht produktiv
    > einsetzen sollte...

    Wer hat den was davon gesagt das man den Code so nicht verwenden kann oder soll? Ich hab nur wiederholt was sowohl du jetzt zitiert hast wie auch der Entwickler in seiner Stellungnahme schreibt, es handelt sich um Beispielcode den der Entwickler hauptsächlich zum Testen verwendet hat. Das heißt doch nicht das den Code niemand anders verwenden kann/soll aber es ist beispielhafter Code der die Funktionen des Plugins demonstriert und keine fertige Anwendung die auf jegliche Sicherheitsbedenken zu achten hat.


    > Auf der von dir verlinkten Seite kann ich auch nirgendwo finden, dass
    > dieser serverseitige Code nicht für den produktiven Einsatz verwendet
    > werden sollte. Er schreibt, dass ER das Skript bloß für die Demo und lokale
    > Tests verwendete hat und es dann für IHN eben nicht so kritisch war, dass
    > man alle möglichen Dateien hochladen konnte. Er hat offenbar ja auch die
    > Sicherheit per .htaccess getestet, weswegen er ja auch geschrieben hat,
    > dass er es eben nur mit Webserver Einstellungen getestet hat, wo .htaccess
    > Dateien aktiviert waren. Also scheint er es schon irgendwie wenigstens
    > etwas sicherer machen zu wollen und eben nicht nur für lokale Tests
    > verwenden und anbieten zu wollen...

    Es geht darum dass es BS ist dem Entwickler hier eine Sicherheitslücke in Demonstrationscode vorzuwerfen, es macht den Code auch wenig sicherer wenn er nur Dateien mit Endung png erlaubt - es ist nur eine verdammte Dateiendung.

    > > Und jeder der lesen kann hätte in diesem Beispielcode auch die
    > > Kommentarzeile "// Defines which files (based on their names) are
    > accepted
    > > for upload:" finden und den Regex ändern können wenn er es denn gewollt
    > > hätte. Das hier ist der neuere Commit zum Fix (der von Xiut war nur für
    > die
    > > index.php):
    > >
    > > github.com#diff-6ebc0394569c042ff1535cfa1a0ce132
    > >
    > Ich habe in meinem Kommentar vom Fix der Sicherheitslücke gesprochen und
    > das was du da verlinkt hast, ist nicht der Fix, der mit 9.22.1 umgesetzt
    > wurde, sondern wurde vor gut 20 Stunden (also gestern Mittag) hinzugefügt.
    > Da wurde die Änderung, die in der index.php beim ersten Fix vorgenommen
    > wurde, entsprechend in die Standardeinstellungen übernommen, was generell
    > auch so deutlich besser ist. Der eigentliche erste Fix der Sicherheitlücke,
    > auf den ich mich bezogen habe, fand aber bereits vor 11 Tagen statt.
    > Entsprechend ist das, was du verlinkt hast, auch komplett unerheblich was
    > meinen Kommentar betrifft.

    Dein Link verweist halt auf den Change der index.php, sieht halt einfach schlampig aus und erklärt nix.

    https://github.com/blueimp/jQuery-File-Upload/commit/ad4aefd96e4056deab6fea2690f0d8cf56bb2d7d#diff-6ebc0394569c042ff1535cfa1a0ce132

    Hier siehste doch wenigstens das die Variable accept_file_types vorher bereits vorhanden war, der Regex nur nicht auf Bildtypen begrenzt war.

    > Generell sieht man aber ja ganz deutlich, zum einen an dem von dir
    > verlinkten Beitrag des Entwicklers und auch der Nachbesserung gestern mit
    > der Übernahme in die Standardeinstellungen, dass der Entwickler SEINEN
    > Fehler eingesehen hat. Klar, jeder der so ein Skript verwenden möchte,
    > sollte sich wenigstens grundlegend mit der Sicherheit auseinandersetzen,
    > aber er sagt ja eben jetzt selbst, dass man sich darauf nicht verlassen
    > darf, dass jeder das macht (was ja bei weitem eben nicht jeder macht).
    > Zumal man so ein Skript ja recht leicht entsprechend absichern kann, so
    > dass man es sogar 1:1 verwenden kann.
    > Und dafür muss man sich eben nicht auf .htaccess Dateien verlassen, was er
    > aber entsprechend getan hat, was aber eben sein Fehler war. Das hätte nur
    > ein Schutz von mehreren sein dürfen.
    > Edit: Ich finde aber auch, dass der Artikel von Golem so formuliert ist,
    > dass man den leicht falsch verstehen kann.

    Seine Kommentare sind an dir auch völlig verloren?

    - Prior to adding the .htaccess file, I mistakenly assumed developers would configure their Apache server themselves so that no PHP scripts would be executed in the uploads folder. It was only added in this commit:
    - Never assume people actually read information about security

    Nur für User die einen Warnungssticker auf der Microwelle benötigen damit sie darin nicht ihre Haustiere trocknen, wird hier so ein Aufwand betrieben. Das geilste darin ist ja das man die ganzen Warnungen usw nicht anbringt um die Leute davon abzuhalten, weil lesen können die nach wie vor nicht, man möchte nur gerne mit dem Finger drauf zeigen können um ihm zu zeigen wie dumm er sich verhalten hat.

  14. Re: Sorry, aber dein Kommentar ist (fast) kompletter Unsinn

    Autor: Xiut 24.10.18 - 13:19

    piros schrieb:
    --------------------------------------------------------------------------------
    > Xiut schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Stimmt so einfach nicht. Kann ja sein, dass er auf einer anderen Seite
    > zu
    > > irgendwas anderem geraten hat, aber vor dem Fix stand noch im
    > Repository,
    > > also da wo das vor allem stehen müsste, wenn man das nicht so
    > installieren
    > > sollte.
    > > Was stand da aber stattdessen als Anleitung zur Installation?
    > >
    > > "Using jQuery File Upload (UI version) on PHP websites
    > > The provided example implementation works out of the box and only needs
    > one
    > > step for you to add it to your PHP based website:
    > >
    > > 1. Download the plugin archive, extract it and upload the extracted
    > folder
    > > (you may rename it) to your server.
    > > Visit the uploaded directory - you should see the same file upload
    > > interface as the demo, allowing you to upload files to your website.
    > >
    > > If uploading files doesn't work, make sure that the php/files directory
    > > permissions allow your server write access."
    > >
    > > Kann jeder über die Revisionen nachvollziehen. Und das stand
    > offensichtlich
    > > seit 2014 da...
    > > Wo wird da darauf hingewiesen, dass man das nicht nutzen soll?! Ganz im
    > > Gegenteil... Gerade der erste Satz deutet eher darauf hin, dass man es
    > > offenbar so bereits verwenden kann, wenn man einen einfachen File Upload
    > > braucht. Und es gibt eben viele, die sich mit File Uploads und deren
    > > Sicherheit nicht beschäftigt haben und das dann nicht einschätzen
    > können.
    > > Klar, die müssten sich damit dann eigentlich auch beschäftigen, aber
    > hier
    > > hätte ganz klar dann dieser Hinweis hingehört, dass man das nicht
    > produktiv
    > > einsetzen sollte...
    >
    > Wer hat den was davon gesagt das man den Code so nicht verwenden kann oder
    > soll? Ich hab nur wiederholt was sowohl du jetzt zitiert hast wie auch der
    > Entwickler in seiner Stellungnahme schreibt, es handelt sich um
    > Beispielcode den der Entwickler hauptsächlich zum Testen verwendet hat. Das
    > heißt doch nicht das den Code niemand anders verwenden kann/soll aber es
    > ist beispielhafter Code der die Funktionen des Plugins demonstriert und
    > keine fertige Anwendung die auf jegliche Sicherheitsbedenken zu achten
    > hat.
    >
    > > Auf der von dir verlinkten Seite kann ich auch nirgendwo finden, dass
    > > dieser serverseitige Code nicht für den produktiven Einsatz verwendet
    > > werden sollte. Er schreibt, dass ER das Skript bloß für die Demo und
    > lokale
    > > Tests verwendete hat und es dann für IHN eben nicht so kritisch war,
    > dass
    > > man alle möglichen Dateien hochladen konnte. Er hat offenbar ja auch die
    > > Sicherheit per .htaccess getestet, weswegen er ja auch geschrieben hat,
    > > dass er es eben nur mit Webserver Einstellungen getestet hat, wo
    > .htaccess
    > > Dateien aktiviert waren. Also scheint er es schon irgendwie wenigstens
    > > etwas sicherer machen zu wollen und eben nicht nur für lokale Tests
    > > verwenden und anbieten zu wollen...
    >
    > Es geht darum dass es BS ist dem Entwickler hier eine Sicherheitslücke in
    > Demonstrationscode vorzuwerfen, es macht den Code auch wenig sicherer wenn
    > er nur Dateien mit Endung png erlaubt - es ist nur eine verdammte
    > Dateiendung.
    >
    > > > Und jeder der lesen kann hätte in diesem Beispielcode auch die
    > > > Kommentarzeile "// Defines which files (based on their names) are
    > > accepted
    > > > for upload:" finden und den Regex ändern können wenn er es denn
    > gewollt
    > > > hätte. Das hier ist der neuere Commit zum Fix (der von Xiut war nur
    > für
    > > die
    > > > index.php):
    > > >
    > > > github.com#diff-6ebc0394569c042ff1535cfa1a0ce132
    > > >
    > > Ich habe in meinem Kommentar vom Fix der Sicherheitslücke gesprochen und
    > > das was du da verlinkt hast, ist nicht der Fix, der mit 9.22.1 umgesetzt
    > > wurde, sondern wurde vor gut 20 Stunden (also gestern Mittag)
    > hinzugefügt.
    > > Da wurde die Änderung, die in der index.php beim ersten Fix vorgenommen
    > > wurde, entsprechend in die Standardeinstellungen übernommen, was
    > generell
    > > auch so deutlich besser ist. Der eigentliche erste Fix der
    > Sicherheitlücke,
    > > auf den ich mich bezogen habe, fand aber bereits vor 11 Tagen statt.
    > > Entsprechend ist das, was du verlinkt hast, auch komplett unerheblich
    > was
    > > meinen Kommentar betrifft.
    >
    > Dein Link verweist halt auf den Change der index.php, sieht halt einfach
    > schlampig aus und erklärt nix.
    >
    > github.com#diff-6ebc0394569c042ff1535cfa1a0ce132
    >
    > Hier siehste doch wenigstens das die Variable accept_file_types vorher
    > bereits vorhanden war, der Regex nur nicht auf Bildtypen begrenzt war.
    >
    > > Generell sieht man aber ja ganz deutlich, zum einen an dem von dir
    > > verlinkten Beitrag des Entwicklers und auch der Nachbesserung gestern
    > mit
    > > der Übernahme in die Standardeinstellungen, dass der Entwickler SEINEN
    > > Fehler eingesehen hat. Klar, jeder der so ein Skript verwenden möchte,
    > > sollte sich wenigstens grundlegend mit der Sicherheit auseinandersetzen,
    > > aber er sagt ja eben jetzt selbst, dass man sich darauf nicht verlassen
    > > darf, dass jeder das macht (was ja bei weitem eben nicht jeder macht).
    > > Zumal man so ein Skript ja recht leicht entsprechend absichern kann, so
    > > dass man es sogar 1:1 verwenden kann.
    > > Und dafür muss man sich eben nicht auf .htaccess Dateien verlassen, was
    > er
    > > aber entsprechend getan hat, was aber eben sein Fehler war. Das hätte
    > nur
    > > ein Schutz von mehreren sein dürfen.
    > > Edit: Ich finde aber auch, dass der Artikel von Golem so formuliert ist,
    > > dass man den leicht falsch verstehen kann.
    >
    > Seine Kommentare sind an dir auch völlig verloren?
    >
    > - Prior to adding the .htaccess file, I mistakenly assumed developers would
    > configure their Apache server themselves so that no PHP scripts would be
    > executed in the uploads folder. It was only added in this commit:
    > - Never assume people actually read information about security
    >
    > Nur für User die einen Warnungssticker auf der Microwelle benötigen damit
    > sie darin nicht ihre Haustiere trocknen, wird hier so ein Aufwand
    > betrieben. Das geilste darin ist ja das man die ganzen Warnungen usw nicht
    > anbringt um die Leute davon abzuhalten, weil lesen können die nach wie vor
    > nicht, man möchte nur gerne mit dem Finger drauf zeigen können um ihm zu
    > zeigen wie dumm er sich verhalten hat.

    1. Du hast geschrieben "Die Scripte für PHP, Go und Python sind ausschließlich Beispiele bzw für Funktiontests, schreibt der Autor des Plugins auch selbst" und genau das steht bei der Aussage von dem Entwickler NICHT drin. Zitiere doch bitte mal die Stelle, wo genau das steht. Vielleicht habe ich ja was übersehen...
    Das was er schreibt ist, dass ER diese Skripte nur für Tests und die Demo verwendet hat. Ich kann da 0 finden, was die Aussage begründet, dass dieses Skript NICHT für mehr als Funktionstests verwendet werden sollte. Zumal die von mir zitierte Installationsanleitung, bei der bis vor ein paar Tagen eben KEINE Sicherheitshinweise enthalten waren, auch rein GAR NICHTS dazu steht, sondern sogar noch, dass es ein Skript ist, welches "out of the box" funktioniert...
    Also WO behauptet der Entwickler, dass diese Skripte nur für Funktionstests gedacht waren? Und selbst wenn ich das überlesen haben sollte (bin auf das Zitat gespannt), war eben die Dokumentation bzw. das Wiki in dem Repository, also da wo so Sicherheitshinweise nun einmal vor allem hingehören, so leicht miss zu verstehen (wenn er wirklich das Skript nur für Funktionstests angeboten hat), dass er allein da schon einen Fehler gemacht hat...

    2. Der von dir verlinkte Commit fand Gestern um 12:50 Uhr (!!) statt und mein Kommentar wurde von mir Gestern um 12:25 Uhr geschrieben... Das heißt also?! Genau! Der Sicherheits Patch bestand zu diesem Zeitpunkt nur aus der Änderung, die ich gepostet habe und nur um den ging es in meinem Kommentar... Was interessiert es, dass es da bereits vorher die Möglichkeit gab, das entsprechend selbst einzuschränken, was für Dateien hochgeladen werden dürfen? Genau, es spielt bei meinem Kommentar bzw. bei dieser Sicherheitslücke keine Rolle, weil zum einen dürfte diese Einstellung eben Standardmäßig nicht so gesetzt werden, weil auch für normale Funktionstests muss man nicht alle möglichen Dateien hochladen können...
    Auch alle anderen Einstellungen spielen keine Rolle, selbst wenn es da eine Option "SUPER_SECURE_UPLOAD = false" gegeben hätte... Der Fehler bzw. das was zu kritisieren ist und das auch mit Recht, ist einfach die Qualität des Skriptes wenn man es 1:1 übernimmt.

    3. Ich glaube, du hast die aufgelisteten Äußerungen selbst nicht wirklich verstande... Die am Ende des Kommentars aufgelisteten Äußerungen sagen genau was aus? Erstens: Dass er zugibt, dass er fälschlicherweise ("I mistakenly assumed") davon ausging, dass die Entwickler ihre Server selbst konfigurieren würden, was zum einen aber gar nicht immer möglich ist und zum anderen nutzen das Plugin sicher nicht nur professionelle Entwickler... Und zweitens: Dass er niemals davon ausgehen oder das vorraussetzen sollte, dass sich die Leute mit dem Thema Sicherheits auseinandersetzen.

    Entsprechend kann man das super zusammenfassen: Der Entwickler hat einfach zu naiv gehandelt und einen Fehler eben ganz klar gemacht. Entweder, weil er selbst bei der Installationsanleitung, die eigentlich niemand braucht, der Entwickler ist und weiß was er tut, darauf hinzuweisen, dass diese Skripte nur für Testzwecke gedacht sind... Oder er eben (selbst jetzt nicht einmal) wirklich Sicherheitsmechanismen einbaut, die eigentlich grundlegend vorhanden sein sollten und nicht nur auf den Namen/die Endung der Datei beruhen, sondern darüber hinaus gehen und auch nicht kompliziert umzusetzen sind, wenn man weiß was man tut...

  15. Re: Sorry, aber dein Kommentar ist (fast) kompletter Unsinn

    Autor: piros 24.10.18 - 15:07

    Xiut schrieb:
    --------------------------------------------------------------------------------
    > 1. Du hast geschrieben "Die Scripte für PHP, Go und Python sind
    > ausschließlich Beispiele bzw für Funktiontests, schreibt der Autor des
    > Plugins auch selbst" und genau das steht bei der Aussage von dem Entwickler
    > NICHT drin. Zitiere doch bitte mal die Stelle, wo genau das steht.
    > Vielleicht habe ich ja was übersehen...
    > Das was er schreibt ist, dass ER diese Skripte nur für Tests und die Demo
    > verwendet hat. Ich kann da 0 finden, was die Aussage begründet, dass dieses
    > Skript NICHT für mehr als Funktionstests verwendet werden sollte. Zumal die
    > von mir zitierte Installationsanleitung, bei der bis vor ein paar Tagen
    > eben KEINE Sicherheitshinweise enthalten waren, auch rein GAR NICHTS dazu
    > steht, sondern sogar noch, dass es ein Skript ist, welches "out of the box"
    > funktioniert...

    Was funktioniert "out of the Box"

    > The provided example implementation works out of the box and only needs one step for you to add it to your PHP based website:

    Richtig, die "provided EXAMPLE implementation", Funktion heißt nicht Sicherheit schon gar nicht wenn die Funktion im Rahmen eines Beispiels demonstriert wird.

    > 2. Der von dir verlinkte Commit fand Gestern um 12:50 Uhr (!!) statt und
    > mein Kommentar wurde von mir Gestern um 12:25 Uhr geschrieben... Das heißt
    > also?! Genau! Der Sicherheits Patch bestand zu diesem Zeitpunkt nur aus der
    > Änderung, die ich gepostet habe und nur um den ging es in meinem
    > Kommentar...

    Ich wollte mit dem Link nur sagen das es eine bessere Veranschaulichung der Änderungen gab.

    > Was interessiert es, dass es da bereits vorher die Möglichkeit
    > gab, das entsprechend selbst einzuschränken, was für Dateien hochgeladen
    > werden dürfen? Genau, es spielt bei meinem Kommentar bzw. bei dieser
    > Sicherheitslücke keine Rolle, weil zum einen dürfte diese Einstellung eben
    > Standardmäßig nicht so gesetzt werden, weil auch für normale Funktionstests
    > muss man nicht alle möglichen Dateien hochladen können...
    > Auch alle anderen Einstellungen spielen keine Rolle, selbst wenn es da eine
    > Option "SUPER_SECURE_UPLOAD = false" gegeben hätte ... Der Fehler bzw. das
    > was zu kritisieren ist und das auch mit Recht, ist einfach die Qualität des
    > Skriptes wenn man es 1:1 übernimmt.

    Das Problem ist dass du es als Funktion zugehörig zum Projekt betrachtest, ich sage es ist Beispielcode zur Veranschaulichung in welchem auch der Sicherheitsaspekt vernachlässigt werden kann da klar ist dass der Code nicht ungelesen übernommen werden kann.

    > 3. Ich glaube, du hast die aufgelisteten Äußerungen selbst nicht wirklich
    > verstande... Die am Ende des Kommentars aufgelisteten Äußerungen sagen
    > genau was aus? Erstens: Dass er zugibt, dass er fälschlicherweise ("I
    > mistakenly assumed") davon ausging, dass die Entwickler ihre Server selbst
    > konfigurieren würden, was zum einen aber gar nicht immer möglich ist und
    > zum anderen nutzen das Plugin sicher nicht nur professionelle Entwickler...
    > Und zweitens: Dass er niemals davon ausgehen oder das vorraussetzen sollte,
    > dass sich die Leute mit dem Thema Sicherheits auseinandersetzen.

    Ich kann nicht anders als den Aussagen eine gewisse Ironie zu entnehmen, denn davon auszugehen das Entwickler wissen was sie tun wenn sie eine Uploadmöglichkeit einrichten, sie nicht einfach blind Code übernehmen und sich ansonsten entsprechend informieren ist jetzt nicht naiv.

    > Entsprechend kann man das super zusammenfassen: Der Entwickler hat einfach
    > zu naiv gehandelt und einen Fehler eben ganz klar gemacht. Entweder, weil
    > er selbst bei der Installationsanleitung, die eigentlich niemand braucht,
    > der Entwickler ist und weiß was er tut, darauf hinzuweisen, dass diese
    > Skripte nur für Testzwecke gedacht sind... Oder er eben (selbst jetzt nicht
    > einmal) wirklich Sicherheitsmechanismen einbaut, die eigentlich grundlegend
    > vorhanden sein sollten und nicht nur auf den Namen/die Endung der Datei
    > beruhen, sondern darüber hinaus gehen und auch nicht kompliziert umzusetzen
    > sind, wenn man weiß was man tut...

    Meiner Meinung nach hat er nicht naiv gehandelt sondern nur erwartet was man von jemandem der sich mit diesem Thema beschäftigt auch erwarten kann. An seiner Stelle hätte ich den Serverpfad mit den Beispielscripten unverändert in ein eigenes Rep ausgelagert.

  16. Re: Sorry, aber dein Kommentar ist (fast) kompletter Unsinn

    Autor: Xiut 24.10.18 - 15:48

    piros schrieb:
    --------------------------------------------------------------------------------
    > Xiut schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > 1. Du hast geschrieben "Die Scripte für PHP, Go und Python sind
    > > ausschließlich Beispiele bzw für Funktiontests, schreibt der Autor des
    > > Plugins auch selbst" und genau das steht bei der Aussage von dem
    > Entwickler
    > > NICHT drin. Zitiere doch bitte mal die Stelle, wo genau das steht.
    > > Vielleicht habe ich ja was übersehen...
    > > Das was er schreibt ist, dass ER diese Skripte nur für Tests und die
    > Demo
    > > verwendet hat. Ich kann da 0 finden, was die Aussage begründet, dass
    > dieses
    > > Skript NICHT für mehr als Funktionstests verwendet werden sollte. Zumal
    > die
    > > von mir zitierte Installationsanleitung, bei der bis vor ein paar Tagen
    > > eben KEINE Sicherheitshinweise enthalten waren, auch rein GAR NICHTS
    > dazu
    > > steht, sondern sogar noch, dass es ein Skript ist, welches "out of the
    > box"
    > > funktioniert...
    >
    > Was funktioniert "out of the Box"
    >
    > > The provided example implementation works out of the box and only needs
    > one step for you to add it to your PHP based website:
    >
    > Richtig, die "provided EXAMPLE implementation", Funktion heißt nicht
    > Sicherheit schon gar nicht wenn die Funktion im Rahmen eines Beispiels
    > demonstriert wird.

    Eine Beispielimplementierung bedeutet nicht, dass es nur für Testzwecke gedacht ist, sondern sollte ja eben erst recht zeigen, wie man es richtig macht. Und das war und ist vor allem immer noch nicht der Fall. Wäre ja auch mies und ein Fehler, wenn jemand ein Beispiel für eine Datenbankabfrage mit PHP oder einer anderen Sprache veröffentlicht, welches aber für SQL Injection anfällig ist, die sichere Variante aber nicht wirklich groß komplexer ist, sondern nur paar Zeichen Code mehr benötigt.

    Vor allem meint er ja selbst, dass er nicht davon ausgehen sollte, dass jemand entsprechend Sicherheitshinweise durchliest, hat den Code aber nicht entsprechend angepasst, wenn er ja jetzt weiß, dass er das eben nicht voraussetzen sollte.
    Weil es gibt deutlich sichereres, als nur auf die Dateiendung zu achten und vielleicht noch im Dateinamen Punkte durch z.B. Bindestriche zu ersetzen. Zum Glück hat er aber wenigstens noch letzteres dann gestern hinzugefügt, was zumindest grundlegend auch sehr mies konfigurierte Server besser schützen sollte. Ich hätte aber effektiveren Schutz gewählt.

    > > 2. Der von dir verlinkte Commit fand Gestern um 12:50 Uhr (!!) statt und
    > > mein Kommentar wurde von mir Gestern um 12:25 Uhr geschrieben... Das
    > heißt
    > > also?! Genau! Der Sicherheits Patch bestand zu diesem Zeitpunkt nur aus
    > der
    > > Änderung, die ich gepostet habe und nur um den ging es in meinem
    > > Kommentar...
    >
    > Ich wollte mit dem Link nur sagen das es eine bessere Veranschaulichung der
    > Änderungen gab.

    Nein, gab es ja zu dem Zeitpunkt meines Kommentars ja eben nicht. Vor allem nicht, um auf das einzugehen, worauf ich eingehen wollte: Dem Sicherheits Patch. Und das war eben vor allem die von mir gepostete Änderung, die eben gestern noch verbessert wurde. Die Verbesserung spielt aber ja entsprechend auch keine Rolle für meinen Kommentar, gerade weil es ja eben die Option bereits vorher gab. Die ist ja schon seit 2014 drin, nur eben auf einen ungeschickten Standardwert.

    > > Was interessiert es, dass es da bereits vorher die Möglichkeit
    > > gab, das entsprechend selbst einzuschränken, was für Dateien hochgeladen
    > > werden dürfen? Genau, es spielt bei meinem Kommentar bzw. bei dieser
    > > Sicherheitslücke keine Rolle, weil zum einen dürfte diese Einstellung
    > eben
    > > Standardmäßig nicht so gesetzt werden, weil auch für normale
    > Funktionstests
    > > muss man nicht alle möglichen Dateien hochladen können...
    > > Auch alle anderen Einstellungen spielen keine Rolle, selbst wenn es da
    > eine
    > > Option "SUPER_SECURE_UPLOAD = false" gegeben hätte ... Der Fehler bzw.
    > das
    > > was zu kritisieren ist und das auch mit Recht, ist einfach die Qualität
    > des
    > > Skriptes wenn man es 1:1 übernimmt.
    >
    > Das Problem ist dass du es als Funktion zugehörig zum Projekt betrachtest,
    > ich sage es ist Beispielcode zur Veranschaulichung in welchem auch der
    > Sicherheitsaspekt vernachlässigt werden kann da klar ist dass der Code
    > nicht ungelesen übernommen werden kann.

    Das betrachte nicht ich so, sondern die, die das Plugin und den UploadHandler entsprechend übernommen haben. Und wie gesagt: Es wurde zwar zu dem Zeitpunkt schon von einer Beispielimplementation gesprochen, was aber nicht direkt bedeutet, dass es unsicher ist und vor allem eben genau dann ja zeigen sollte, wie es sicher umgesetzt wird. Vor allem gab es ja wie gesagt bereits die entsprechende Option und zumindest das hochladen von Skripten wäre für das Testen nicht notwendig gewesen. Wieso also als Standardwert, wenn es den schon gibt, alles erlauben und nicht (wie jetzt passiert) nur auf Endungen von Bildern setzen oder auch andere gängige Dateien? Deutet eben auch noch zusätzlich darauf hin, dass das Skript dafür gedacht war, dass man es möglichst 1:1 so serverseitig verwenden kann, was ja auch möglich ist, wenn ich nichts übersehen habe.

    > > 3. Ich glaube, du hast die aufgelisteten Äußerungen selbst nicht
    > wirklich
    > > verstande... Die am Ende des Kommentars aufgelisteten Äußerungen sagen
    > > genau was aus? Erstens: Dass er zugibt, dass er fälschlicherweise ("I
    > > mistakenly assumed") davon ausging, dass die Entwickler ihre Server
    > selbst
    > > konfigurieren würden, was zum einen aber gar nicht immer möglich ist und
    > > zum anderen nutzen das Plugin sicher nicht nur professionelle
    > Entwickler...
    > > Und zweitens: Dass er niemals davon ausgehen oder das vorraussetzen
    > sollte,
    > > dass sich die Leute mit dem Thema Sicherheits auseinandersetzen.
    >
    > Ich kann nicht anders als den Aussagen eine gewisse Ironie zu entnehmen,
    > denn davon auszugehen das Entwickler wissen was sie tun wenn sie eine
    > Uploadmöglichkeit einrichten, sie nicht einfach blind Code übernehmen und
    > sich ansonsten entsprechend informieren ist jetzt nicht naiv.

    Doch, das ist naiv, wenn man wirklich professioneller Entwickler ist und sich mit dem Thema beschäftigt. Weil gerade so Beispiele, wie MongoDB, wo es zehntausende Datenbanken gibt, die offen im Netz sind, sollte zeigen, dass man eben nicht davon ausgehen kann, dass sich wirklich jeder vorher damit auseinandersetzt. Und ER selbst hat doch genau denselben Fehler begannen... Er hat doch selbst geschrieben "The Apache servers I tested with always had support for .htaccess enabled, so I never bothered to check that the default Apache configuration since version 2.3.9 actually disabled it". Also weil es bei ihm immer funktioniert hat, hat er sich nicht weiter mit der Wirksamkeit seines Schutzes durch .htaccess Dateien in verbindung mit Apache Webservern beschäftigt, weil sonst hätte er das ja wissen müssen... Zumal er die .htaccess Dateien ja extra als Schutz hinzugefügt hat, nachdem er darauf hingeweisen wurde, dass nicht jeder den Server selbst konfigurieren kann, was er vorher angenommen hat. Gerade dann, wenn man so einen Schutz einbaut, sollte man sich doch selbst damit entsprechend auseinandersetzen, wie wirksam dieser ist.
    Klar, der Schutz ist in den meisten Fällen wirksam. Mir ist noch kein Server untergekommen, der nicht .htaccess Dateien berücksichtigt. Trotzdem hat er sich ja offenbar selbst nicht so sehr mit dem Thema .htaccess Dateien und Apache beschäftigt, weil er sonst sicher einen anderen Schutz gewählt hätte, wie jetzt eben auch implementiert.

    > > Entsprechend kann man das super zusammenfassen: Der Entwickler hat
    > einfach
    > > zu naiv gehandelt und einen Fehler eben ganz klar gemacht. Entweder,
    > weil
    > > er selbst bei der Installationsanleitung, die eigentlich niemand
    > braucht,
    > > der Entwickler ist und weiß was er tut, darauf hinzuweisen, dass diese
    > > Skripte nur für Testzwecke gedacht sind... Oder er eben (selbst jetzt
    > nicht
    > > einmal) wirklich Sicherheitsmechanismen einbaut, die eigentlich
    > grundlegend
    > > vorhanden sein sollten und nicht nur auf den Namen/die Endung der Datei
    > > beruhen, sondern darüber hinaus gehen und auch nicht kompliziert
    > umzusetzen
    > > sind, wenn man weiß was man tut...
    >
    > Meiner Meinung nach hat er nicht naiv gehandelt sondern nur erwartet was
    > man von jemandem der sich mit diesem Thema beschäftigt auch erwarten kann.
    > An seiner Stelle hätte ich den Serverpfad mit den Beispielscripten
    > unverändert in ein eigenes Rep ausgelagert.

    Ja, ich finde ja auch nicht, dass er alleine Schuld daran ist, wenn jemand das 1:1 übernommen hat und dann der Server gehackt wird. Und ja, eigentlich sollte man erwarten können, dass sich jemand erst einmal mit dem Thema und dem Skript beschäftigt, bevor er es einfach 1:1 so übernimmt und produktiv einsetzt. Dagegen sage ich ja nichts. Ich sage nur, dass die Realität eben anders aussieht und man das gerade als erfahrender Entwickler wissen sollte. Und genau deswegen ist er in meinen Augen naiv gewesen, weil er diese perfekten Umstände vorausgesetzt hat, die einfach nicht der Fall sind und auch nie der Fall sein werden. In meinem Fall meine ich also mit "naiv" die Bedeutung des Wortes, dass er das nicht kritisch genug hinterfragt hat.

  17. Re: Sorry, aber der Artikel ist (fast) kompletter Unsinn

    Autor: Vash 11.11.18 - 07:24

    Eine eindeutige Schuld ist keinem, bzw allen zuzuschreiben: der Entwickler der verwundbaren Code als Beispiel öde ausliefert. Dem Entwickler der fremden Code übernimmt ohne sich Gedanken zu machen. Der Administrator der ein System konfiguriert wo Uploads in ungesichertem Rahmen möglich sind.

    Kann man sich nun über die Schuld Anteile streiten: ich komm so bei 20/40/40 von 100 raus.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. THE BRETTINGHAMS GmbH, Berlin
  2. SCHOTT AG, Mainz
  3. KION Group AG, Frankfurt am Main
  4. IT-Servicezentrum der bayerischen Justiz, Amberg/Oberpfalz, Landshut, Nürnberg, Würzburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-40%) 32,99€
  2. (-35%) 25,99€
  3. 4,49€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Holo-Monitor angeschaut: Looking Glass' 8K-Monitor erzeugt Holo-Bild
Holo-Monitor angeschaut
Looking Glass' 8K-Monitor erzeugt Holo-Bild

CES 2020 Mit seinem neuen 8K-Monitor hat Looking Glass Factory eine Möglichkeit geschaffen, ohne zusätzliche Hardware 3D-Material zu betrachten. Die holographische Projektion wird in einem Glaskubus erzeugt und sieht beeindruckend realistisch aus.
Von Tobias Költzsch und Martin Wolf

  1. UHD Alliance Fernseher mit Filmmaker-Modus kommen noch 2020
  2. Alienware Concept Ufo im Hands on Die Switch für Erwachsene
  3. Galaxy Home Mini Samsung schraubt Erwartungen an Bixby herunter

Lovot im Hands-on: Knuddeliger geht ein Roboter kaum
Lovot im Hands-on
Knuddeliger geht ein Roboter kaum

CES 2020 Lovot ist ein Kofferwort aus Love und Robot: Der knuffige japanische Roboter soll positive Emotionen auslösen - und tut das auch. Selten haben wir so oft "Ohhhhhhh!" gehört.
Ein Hands on von Tobias Költzsch

  1. Orcam Hear Die Audiobrille für Hörgeschädigte
  2. Viola angeschaut Cherry präsentiert preiswerten mechanischen Switch
  3. Consumer Electronics Show Die Konzept-Messe

Open Power CPU: Open-Source-ISA als letzte Chance
Open Power CPU
Open-Source-ISA als letzte Chance

Die CPU-Architektur Power fristet derzeit ein Nischendasein, wird aber Open Source. Das könnte auch mit Blick auf RISC-V ein notwendiger Befreiungsschlag werden. Dafür muss aber einiges zusammenkommen und sehr viel passen.
Eine Analyse von Sebastian Grüner

  1. Open Source Monitoring-Lösung Sentry wechselt auf proprietäre Lizenz
  2. VPN Wireguard fliegt wegen Spendenaufruf aus Play Store
  3. Picolibc Neue C-Bibliothek für Embedded-Systeme vorgestellt

  1. Kickstarter: Gebundener Mars-Atlas zeigt Karten des Roten Planeten
    Kickstarter
    Gebundener Mars-Atlas zeigt Karten des Roten Planeten

    The Mars-Atlas ist ein interessantes Buch: Es zeigt detaillierte Karten vom Mars statt der Erde. Mehr als 2.000 Standorte sind darauf zu sehen. Auch eine digitale Applikation wird angeboten, auf der Hobbyforscher ein 3D-Modell des Mars erkunden können - ähnlich wie bei Google Mars.

  2. 5G: Österreich sieht sich beim Mobilfunk klar vor Deutschland
    5G
    Österreich sieht sich beim Mobilfunk klar vor Deutschland

    Das schlechteste Mobilfunknetz in Österreich sei immer noch besser als das beste Netz in Deutschland, hat Wirtschaftsministerin Margarete Schramböck behauptet. Auch Messungen bestätigen das.

  3. TLS: Netgear verteilt private Schlüssel in Firmware
    TLS
    Netgear verteilt private Schlüssel in Firmware

    Sicherheitsforscher haben private Schlüssel für TLS-Zertifikate veröffentlicht, die Netgear mit seiner Router-Firmware verteilt. Der Hersteller hatte nur wenige Tage Reaktionszeit. Die Forscher lehnen die Praktiken von Netgear prinzipiell ab, was zur Veröffentlichung geführt hat.


  1. 17:20

  2. 17:07

  3. 16:45

  4. 15:59

  5. 15:21

  6. 13:38

  7. 13:21

  8. 12:30