nicht angemeldet
Der Martin
MudGuard
Der Martin
Felix Riesterer
Matthias Apsel
Der Martin
dedlfix
Julius
dedlfix
dedlfix
dedlfix
Felix Riesterer
Hallo,
ich möchte meinen Usern einen Dateiupload anbieten. Es sollen nur Bilddateien und PDF erlaubt sein.
Ich habe mir hierzu auch diesen Artikel gelesen.
Meine Frage, reicht es nciht aus, folgende .htaccess anzulegen?
Tabellenkalk# Ausführung von PHP unterbinden
php_flag engine off
# Abschalten: cgi, SSI, Auflisten von Inhalten
Options -ExecCGI -Includes -Indexes
# Ausliefern von .php, .php3 und .cgi - Dateien unterbinden
<Files ~ "\.(php3?|cgi)$">
deny from all
</Files>
# Nur Bild-Dateien: *.jpg, *.png, *.gif, *.pdf sind erlaubt,
# alle anderen sind nicht lesbar
order deny,allow
deny from all
<Files ~ ".+\.(jpg|png|gif|pdf)$">
allow from all
</Files>
Ed
Hi,
eins vorweg: Du hättest deinen ersten Beitrag editieren können, anstatt ihn ein zweites Mal zu posten. Da es offensichtlich ist, dass dies hier eine korrigierte Fassung des vorangegangenen Postings ist, habe ich das mal gelöscht.
ich möchte meinen Usern einen Dateiupload anbieten. Es sollen nur Bilddateien und PDF erlaubt sein.
Okay.
Meine Frage, reicht es nciht aus, folgende .htaccess anzulegen?
Nein. Die hat eigentlich nichts mit deinem Ansinnen zu tun, widerspricht teilweise sogar.
# Ausführung von PHP unterbinden php_flag engine off # Abschalten: cgi, SSI, Auflisten von Inhalten Options -ExecCGI -Includes -Indexes # Ausliefern von .php, .php3 und .cgi - Dateien unterbinden <Files ~ "\.(php3?|cgi)$"> deny from all </Files> # Nur Bild-Dateien: *.jpg, *.png, *.gif, *.pdf sind erlaubt, # alle anderen sind nicht lesbar order deny,allow deny from all <Files ~ ".+\.(jpg|png|gif|pdf)$"> allow from all </Files>
Zunächst mal: Ausführung von PHP unterbinden? Womit willst du dann die hochgeladenen Dateien annehmen, prüfen und verarbeiten (z.B. im gewünschten Verzeichnis ablegen)?
Dann: Alle Direktiven, die du notiert hast, betreffen nur den Abruf von PDF- und Bilddateien vom Server, nicht den Upload solcher Dateien (abgesehen davon, dass Bilddateien auch noch andere Extensions habekönnen als die von dir aufgezählten).
Der Ansatz muss daher anders sein. Der eigentliche Upload wird als POST-Request vermutlich ein PHP-Script aufrufen. Dieses Script muss die angelieferte Datei daraufhin überprüfen, ob sie wirklich in die Menge der erlaubten Typen passt. Dazu genügt es nicht, den Namen bzw. die Extension anzuschauen, auch der vom Browser gesendete MIME-Typ kann Bullshit sein. Du müsstest tatsächlich den Dateiinhalt prüfen. Bilddateien erkennt man beispielsweise daran, dass getimagesize() plausible Werte liefert; PDF-Dokumente erkennt man daran, dass sie mit dem String "PDF%" beginnen.
So long,
Martin
Hi,
Du müsstest tatsächlich den Dateiinhalt prüfen. Bilddateien erkennt man beispielsweise daran, dass getimagesize() plausible Werte liefert; PDF-Dokumente erkennt man daran, dass sie mit dem String "PDF%" beginnen.
Nein. Am Nicht-Vorhandensein von PDF% am Dateianfang kann man erkennen, daß es sich nicht um eine PDF-Datei handelt.
Der Anfang PDF% ist eine notwendige, aber nicht hinreichende Bedingung, daß es sich bei der Datei um ein PDF handelt. Wenn ich am Anfang einer beliebigen Text-Datei "PDF%" einfüge, wird aus der Datei noch keine PDF-Datei.
cu,
Andreas a/k/a MudGuard
Hi,
Der Anfang PDF% ist eine notwendige, aber nicht hinreichende Bedingung, daß es sich bei der Datei um ein PDF handelt. Wenn ich am Anfang einer beliebigen Text-Datei "PDF%" einfüge, wird aus der Datei noch keine PDF-Datei.
Das ist einer der Gründe, warum ich das Pferd von hinten aufzäumen will. Wie präpariere ich meinen Server, wenn ich davon ausgehe, dass es einem User gelingt, schadhafte Dateien aufzuspielen, sodaß diese letztlich dann doch nichts anrichten können.
Das ich nachher dann doch noch die hochgeladenen Dateien vor dem Speichern prüfe, ist eh klar, aber darum geht es mir grad nciht.
Ed
Hallo,
Du müsstest tatsächlich den Dateiinhalt prüfen. Bilddateien erkennt man beispielsweise daran, dass getimagesize() plausible Werte liefert; PDF-Dokumente erkennt man daran, dass sie mit dem String "PDF%" beginnen.
Nein. Am Nicht-Vorhandensein von PDF% am Dateianfang kann man erkennen, daß es sich nicht um eine PDF-Datei handelt.
ja, das Ausschlussverfahren. So meinte ich das auch. War das so missverständlich?
Wenn ich am Anfang einer beliebigen Text-Datei "PDF%" einfüge, wird aus der Datei noch keine PDF-Datei.
Klar. Ebensowenig wie in einer Dose plötzlich gebackene Bohnen in Tomatensauce drin sind, bloß weil jemand ein solches Etikett draufklebt.
So long,
Martin
Hallo,
War das so missverständlich?
Es war logisch nicht korrekt formuliert.
Gruß
Kalk
eins vorweg: Du hättest deinen ersten Beitrag editieren können, anstatt ihn ein zweites Mal zu posten.
Auch als nicht registrierter?
Nein. Die hat eigentlich nichts mit deinem Ansinnen zu tun, widerspricht teilweise sogar.
Die .htaccess soll nur dazu dienen, zu verhindern, dass eventuelle Schaddateien auf dem Server (oder auch auf dem Client je nach Schadcode) Schaden anrichten. Völlig unabhängig vom Upload erstmal. Das hätte ich dazu schreiben sollen.
Zunächst mal: Ausführung von PHP unterbinden? Womit willst du dann die hochgeladenen Dateien annehmen, prüfen und verarbeiten (z.B. im gewünschten Verzeichnis ablegen)?
s.o.
Dann: Alle Direktiven, die du notiert hast, betreffen nur den Abruf von PDF- und Bilddateien vom Server, nicht den Upload solcher Dateien (abgesehen davon, dass Bilddateien auch noch andere Extensions habekönnen als die von dir aufgezählten).
s.o.
Der Ansatz muss daher anders sein. Der eigentliche Upload wird als POST-Request vermutlich ein PHP-Script aufrufen. Dieses Script muss die angelieferte Datei daraufhin überprüfen, ob sie wirklich in die Menge der erlaubten Typen passt. Dazu genügt es nicht, den Namen bzw. die Extension anzuschauen, auch der vom Browser gesendete MIME-Typ kann Bullshit sein. Du müsstest tatsächlich den Dateiinhalt prüfen. Bilddateien erkennt man beispielsweise daran, dass getimagesize() plausible Werte liefert; PDF-Dokumente erkennt man daran, dass sie mit dem String "PDF%" beginnen.
Einverstanden. Da ich mich aber nicht so gut mit Binärdateiuen auskenne, kann ich trotz deiner Prüfungen nicht ausschließen, dass außer dem gewünscht/geprüften Inhalt noch weiterer Schadinhalt vorliegt. Daher meine Idee, dass Thema von der anderen Seite anzugehen. Was wäre, wenn Schadinhalt vorliegt und ich verhindern will, dass er Schaden anrichtet?
Ed
Hallo Eddy.,
eins vorweg: Du hättest deinen ersten Beitrag editieren können, anstatt ihn ein zweites Mal zu posten.
Auch als nicht registrierter?
Ja, innerhalb der ersten 15 Minuten oder bis eine Antwort vorhanden ist.
Da ich mich aber nicht so gut mit Binärdateiuen auskenne, kann ich trotz deiner Prüfungen nicht ausschließen, dass außer dem gewünscht/geprüften Inhalt noch weiterer Schadinhalt vorliegt.
Das kannst du so oder so nicht. Was hindert mich daran, ein mit Schadcode versehenes Bild hochzuladen?
LG,
CK
Lieber Eddy.,
die .htaccess kann sich nur auf einen Teilbaum des Dateisystems beziehen. Das ist in Deinem Fall vielleicht nicht sinnvoll. Die hochgeladenen Dateien sollten überhaupt nicht direkt über den Webserver erreichbar sein (wenn Dein Webspace das erlaubt), sondern nur über ein (in Deinem Fall PHP-)Script aufgelistet und zum Download angeboten werden können.
Ansonsten schließe ich mich Dem Martin an.
Liebe Grüße,
Felix Riesterer.
Hallo Felix,
die
.htaccesskann sich nur auf einen Teilbaum des Dateisystems beziehen. Das ist in Deinem Fall vielleicht nicht sinnvoll. Die hochgeladenen Dateien sollten überhaupt nicht direkt über den Webserver erreichbar sein (wenn Dein Webspace das erlaubt), sondern nur über ein (in Deinem Fall PHP-)Script aufgelistet und zum Download angeboten werden können.
Dann sind sie ja immer noch über HTTP erreichbar. Durch diese Indirektion hast du nichts erreicht (die Files sind weiterhin erreichbar) und trotzdem mit Performance bezahlt.
Hört sich nicht sinnvoll an für mich.
LG,
CK
Lieber Christian,
Dann sind sie ja immer noch über HTTP erreichbar. Durch diese Indirektion hast du nichts erreicht (die Files sind weiterhin erreichbar) und trotzdem mit Performance bezahlt.
Hört sich nicht sinnvoll an für mich.
wenn jemand ein (unerlaubtes) PHP-Script hochlädt, dann ist es auf diese Weise nicht ausführbar erreichbar. Man sähe im Listing, dass es dort steht, kann es aber per URL nicht so aufrufen, dass es von PHP geparst und ausgeführt würde - wenn der Filter nach dem Upload das Script nicht ohnehin wieder entfernt. Und ja, dafür bezahle ich gerne mit Performance.
Liebe Grüße,
Felix Riesterer.
Hallo Felix,
wenn jemand ein (unerlaubtes) PHP-Script hochlädt, dann ist es auf diese Weise nicht ausführbar erreichbar. Man sähe im Listing, dass es dort steht, kann es aber per URL nicht so aufrufen, dass es von PHP geparst und ausgeführt würde - wenn der Filter nach dem Upload das Script nicht ohnehin wieder entfernt. Und ja, dafür bezahle ich gerne mit Performance.
Wenn es möglich ist, ein ausführbares Script hochzuladen, ist bereits an zwei Stellen etwas schief gelaufen: in der Webserver-Konfiguration und im Sicherheits-Konzept vor dem Upload.
LG,
CK
Meine Frage, reicht es nciht aus, folgende .htaccess anzulegen?
Meine Frage ist vollkommen unbeantwortet. Nicht, dass auf die Beantwortung ein Anspruch meinerseits bestünde, ich stelle es nur fest.
Woran liegt das? Wisst Ihr es auch nicht? Dann würde ich ggf. nochmal woanders anklopfen. Ich will nur nicht einfach so "crossposten".
Ed
Hallo Eddy.,
Meine Frage, reicht es nciht aus, folgende .htaccess anzulegen?
Meine Frage ist vollkommen unbeantwortet.
Das sehe ich nicht so. Die kurze Antwort: Nein, es reicht nicht aus. Die lange Antwort entnimmst du bitte den anderen Antworten und fragst dort konkret noch mal nach.
Ich will nur nicht einfach so "crossposten".
Das finde ich gut.
Bis demnächst
Matthias
Das sehe ich nicht so. Die kurze Antwort: Nein, es reicht nicht aus. Die lange Antwort entnimmst du bitte den anderen Antworten und fragst dort konkret noch mal nach.
Aber was, wenn ich keine Antwort finde, die auch nur ansatzweise auf meine Frage eingeht?
Ich versuchs mal anders:
Kann mir jemand ein (oder mehrere) gefaktes "Bild oder PDF" zur Verfügung stellen, das bei gegebener .htaccess (s.o.) in der Lage wäre, Schaden anzurichten? Ich habe es selber mal versucht, ein php-script mit falscher Endung wird schlicht nicht angezeigt, weil es "Fehler enthält".
Ed
Hallo Eddy.,
Aber was, wenn ich keine Antwort finde, die auch nur ansatzweise auf meine Frage eingeht?
Dann hast du vielleicht die Frage falsch oder unklar gestellt? :)
Kann mir jemand ein (oder mehrere) gefaktes "Bild oder PDF" zur Verfügung stellen, das bei gegebener .htaccess (s.o.) in der Lage wäre, Schaden anzurichten? Ich habe es selber mal versucht, ein php-script mit falscher Endung wird schlicht nicht angezeigt, weil es "Fehler enthält".
Du musst unterscheiden zwischen Schaden auf dem Server und Schaden am Client. Schaden am Server wird so ohne weiteres nicht möglich sein, allerdings würde ich dir aus Prinzip raten PHP für dieses Verzeichnis auszuschalten (z.B. via php_flag engine off in der .htaccess).
Schaden am Client schliesst du damit allerdings nicht aus. Eine Zeit lang sind z.B. die Jailbreaks für das iPhone durch den PDF-Reader eingefallen. Die Rendering-Engine für Bilder hatte auf MS-Betriebssystemen zwischenzeitlich ein Memory-Corruption-Bug, der dazu geführt hat, dass man mit einem Bild beliebigen Code auf dem Client ausführen konnte.
Das so etwas hochgeladen wird wirst du so ohne weiteres nicht verhindern können.
LG,
CK
Hi CK,
Dann hast du vielleicht die Frage falsch oder unklar gestellt? :)
Ich glaubs auch langsam ;)
Du musst unterscheiden zwischen Schaden auf dem Server und Schaden am Client. Schaden am Server wird so ohne weiteres nicht möglich sein, allerdings würde ich dir aus Prinzip raten PHP für dieses Verzeichnis auszuschalten (z.B. via
php_flag engine offin der.htaccess).
Hab ich ja.
Schaden am Client schliesst du damit allerdings nicht aus. Eine Zeit lang sind z.B. die Jailbreaks für das iPhone durch den PDF-Reader eingefallen. Die Rendering-Engine für Bilder hatte auf MS-Betriebssystemen zwischenzeitlich ein Memory-Corruption-Bug, der dazu geführt hat, dass man mit einem Bild beliebigen Code auf dem Client ausführen konnte.
Das so etwas hochgeladen wird wirst du so ohne weiteres nicht verhindern können.
Naja... ich kann wohl tatsächlich nichts für Lücken in Betriebssystemen jeglicher Art ;)
Würde dann doch aber im Umkehrschluß bedeuten, dass meine Ausgangsfrage eindeutig mit JA zu beantworten wäre, oder?
Ed
Hallo Eddy.,
Hab ich ja.
Habs gesehen, aber ein dritter, der via Google direkt auf das Posting kommt vielleicht nicht ;-)
Würde dann doch aber im Umkehrschluß bedeuten, dass meine Ausgangsfrage eindeutig mit JA zu beantworten wäre, oder?
Wenn du die gängigen Vorkehrungen beim Upload getroffen hast (Absicherung beim Namen der Datei, so dass andere Dateien vor allem ausserhalb des Verzeichnisses nicht überschrieben werden, Beschränkung auf bestimmte Suffixes, etc, pp), dann ja.
LG,
CK
Hi CK,
Wenn du die gängigen Vorkehrungen
... Absicherung beim Namen der Datei, so dass andere Dateien vor allem ausserhalb des Verzeichnisses nicht überschrieben werden...
Was meinst Du genau damit?
Ed
Hallo Eddy.,
Was meinst Du genau damit?
Ich weiss nicht, wie du deine Dateinamen generierst. Aber prinzipiell könnte ich dir für die hochgeladene Datei einen Dateinamen unterschieben, der nach diesem Muster aufgebaut ist: ../foo.php. Wenn du das ungeprüft benutzt, um die Datei zu schreiben, dann hättest du jetzt deine Datei nicht in /uploads/foo.php sondern in /foo.php.
LG,
CK
Hi CK,
Ich weiss nicht, wie du deine Dateinamen generierst. Aber prinzipiell könnte ich dir für die hochgeladene Datei einen Dateinamen unterschieben, der nach diesem Muster aufgebaut ist:
../foo.php. Wenn du das ungeprüft benutzt, um die Datei zu schreiben, dann hättest du jetzt deine Datei nicht in/uploads/foo.phpsondern in/foo.php.
Ah, verstehe. Aber nein, das geht in meinem Fall nicht, da ich die Dateinamen, sowie den Uploadpfad vollkommen unabhängig von Deinem Dateinamen.
Ed
Moin,
Dann hast du vielleicht die Frage falsch oder unklar gestellt? :)
Ich glaubs auch langsam ;)
ja, zumindest am Anfang. Da hast du im Titel von "Dateiupload und Sicherheit" gesprochen, im Beitrag selbst aber nur Maßnahmen für den Dateidownload vorgestellt. Deswegen war ich ja dann auch auf der falschen Fährte und habe gesagt, das hätte nichts mit der Frage zu tun.
Schaden am Server wird so ohne weiteres nicht möglich sein
Denke ich auch. Man könnte jetzt anfangen, Angriffsszenarien zu konstruieren: Angenommen, ein manipuliertes JPEG-Bild enthält in einem Freitext-Feld des EXIF-Blocks PHP-Code. Muss nicht viel sein, ein include (auf Verdacht von einem anderen HTTP-Server, könnte ja mal funktionieren) würde schon genügen. Übliche Testmethoden würden diese JPEG-Datei als korrekt durchgehen lassen, sie lässt sich auch mit sämtlichen Programmen anzeigen und bearbeiten.
Damit der PHP-Code beim Ausliefern per HTTP ausgeführt wird, müsste nun noch eine Fehlkonfiguration des Webservers dazukommen. Zum Beispiel die Einstellung, dass alle Dateien im Verzeichnis durch den PHP-Parser gejagt werden. Wenn das Bild dann von einem Client angefordert wird, wird der sich eventuell über den unpassenden MIME-Typ beklagen, aber in dem Moment ist der Schaden am Server schon passiert.
Zugegeben, das ist vielleicht an den Haaren herbeigezogen - aber nicht unmöglich.
allerdings würde ich dir aus Prinzip raten PHP für dieses Verzeichnis auszuschalten (z.B. via
php_flag engine offin der.htaccess).Hab ich ja.
Genau, dann kann eigentlich nicht mehr wirklich viel passieren.
Würde dann doch aber im Umkehrschluß bedeuten, dass meine Ausgangsfrage eindeutig mit JA zu beantworten wäre, oder?
Eindeutig? Weiß ich nicht.
Aber "sehr wahrscheinlich ja".
Ciao,
Martin
Hi Martin,
ja, zumindest am Anfang. Da hast du im Titel von "Dateiupload und Sicherheit" gesprochen, im Beitrag selbst aber nur Maßnahmen für den Dateidownload vorgestellt. Deswegen war ich ja dann auch auf der falschen Fährte und habe gesagt, das hätte nichts mit der Frage zu tun.
Kein Vorwurf. Deshalb sagte ich ja auch "Ich glaubs auch langsam"...
Denke ich auch. Man könnte jetzt anfangen, Angriffsszenarien zu konstruieren: Angenommen, ein manipuliertes JPEG-Bild enthält in einem Freitext-Feld des EXIF-Blocks PHP-Code. Muss nicht viel sein, ein include (auf Verdacht von einem anderen HTTP-Server, könnte ja mal funktionieren) würde schon genügen. Übliche Testmethoden würden diese JPEG-Datei als korrekt durchgehen lassen, sie lässt sich auch mit sämtlichen Programmen anzeigen und bearbeiten.
Gibt es nicht irgendwo so ein Bild zum Download? ich würde es gerne mal testhalber einspeisen, um zu sehen, was dann passiert...
Eindeutig? Weiß ich nicht.
Aber "sehr wahrscheinlich ja".
Bleiben aber immer noch die PDFs. Wie stelle ich sicher, dass ein PDF keinen Schadcode enthält?
Zudem: Reicht es aus, den php-Interpreter für dieses Verzeichnis auszuschalten? Was ist mit dem Perl-Interpreter? Reicht es da aus, die Dateirechte auf 644 zu setzen?
Ed
Hallo Eddy.,
Wie stelle ich sicher, dass ein PDF keinen Schadcode enthält?
Ich versuche dir die ganze Zeit zu erklären, dass du das nicht sicherstellen kannst. Auch nicht bei Bildern. Du kannst nur verhindern, dass der Schadcode ausgeführt wird.
Zudem: Reicht es aus, den php-Interpreter für dieses Verzeichnis auszuschalten? Was ist mit dem Perl-Interpreter? Reicht es da aus, die Dateirechte auf 644 zu setzen?
Diese Frage kann dir so nur dein Server-Administrator beantworten, denn das ist eine Frage der Konfiguration.
LG,
CK
Hi CK,
Ich versuche dir die ganze Zeit zu erklären, dass du das nicht sicherstellen kannst. Auch nicht bei Bildern. Du kannst nur verhindern, dass der Schadcode ausgeführt wird.
Sorry, hab mich falsch ausgedrückt.
Zudem: Reicht es aus, den php-Interpreter für dieses Verzeichnis auszuschalten? Was ist mit dem Perl-Interpreter? Reicht es da aus, die Dateirechte auf 644 zu setzen?
Diese Frage kann dir so nur dein Server-Administrator beantworten, denn das ist eine Frage der Konfiguration.
Diese Frage war mehr darauf bezogen, ob ich per .htaccesss den Perl-Interpreter für das Verzeichnis abschalten kann...
Ed
Hallo Eddy.,
Diese Frage war mehr darauf bezogen, ob ich per .htaccesss den Perl-Interpreter für das Verzeichnis abschalten kann...
Das kannst du, z.B. mit Options -ExecCGI. Aber auch hier gilt: wie genau du das machen kannst ist abhängig von der Server-Konfiguration.
LG,
CK
Tach!
Schaden am Server wird so ohne weiteres nicht möglich sein, allerdings würde ich dir aus Prinzip raten PHP für dieses Verzeichnis auszuschalten (z.B. via
php_flag engine offin der.htaccess).
Das passt nur für als Apache-Modul ausgeführtes PHP. In Mehrbenutzerumgebungen möchte man das aber lieber als FCGI laufen lassen, und dann kann man keine wirksamen PHP-Direktiven in der Apache-Konfiguration setzen. Im Apachen selbst kann man in dem Fall nur verhindern, dass Dateien bestimmter Endungen an den jeweiligen Handler weitergegeben werden. Wie das geht? Das kommt auf die individuelle Konfiguration an. Kann man sich diese ansehen, kann man auch im Zusammenspiel mit der Dokumentation die entsprechenden Negativdirektiven finden. Bei Providern helfen da oft nur dessen Support-Seiten oder Erfahrungsberichte anderer Kunden.
dedlfix.
Hallo dedlfix,
Schaden am Server wird so ohne weiteres nicht möglich sein, allerdings würde ich dir aus Prinzip raten PHP für dieses Verzeichnis auszuschalten (z.B. via
php_flag engine offin der.htaccess).Das passt nur für als Apache-Modul ausgeführtes PHP.
Deshalb das „z.B.“ ;-)
LG,
CK
Hi dedlfix,
Das passt nur für als Apache-Modul ausgeführtes PHP. In Mehrbenutzerumgebungen möchte man das aber lieber als FCGI laufen lassen, und dann kann man keine wirksamen PHP-Direktiven in der Apache-Konfiguration setzen. Im Apachen selbst kann man in dem Fall nur verhindern, dass Dateien bestimmter Endungen an den jeweiligen Handler weitergegeben werden. Wie das geht? Das kommt auf die individuelle Konfiguration an. Kann man sich diese ansehen, kann man auch im Zusammenspiel mit der Dokumentation die entsprechenden Negativdirektiven finden. Bei Providern helfen da oft nur dessen Support-Seiten oder Erfahrungsberichte anderer Kunden.
In meiner Konfigurations ist es so, dass inklusive meiner .htaccess ein php-script einben Fehler 403 erwirkt, lösche ich aber die .htaccess wieder, läßt sich die php-datei ausführen.
Ed
Hallo Eddy,
Dieser Artikel von Golem.de, der XSS via JavaScript-Code in Bildern eingebettet werden kann, ist für dich evtl. ebenfalls von Interesse.
Gruß
Julius
Meine Frage, reicht es nciht aus, folgende .htaccess anzulegen?
In Verzeichnissen, wo Du hochgeladene Dateien sicher speicherst, wird eine .htaccess gar nicht wirksam. Es sei denn, Du verbiegst mit Deinem Framework DOCUMENT_ROOT aber da musst Du schon genau wissen was Du tust.
Tipp: Begrenze die Länge eines Upload-Streams und guck dass nicht irgendwo temporäre Dateien hängenbleiben.
Meine Frage, reicht es nciht aus, folgende .htaccess anzulegen?
In Verzeichnissen, wo Du hochgeladene Dateien sicher speicherst, wird eine .htaccess gar nicht wirksam. Es sei denn, Du verbiegst mit Deinem Framework DOCUMENT_ROOT aber da musst Du schon genau wissen was Du tust.
Du meinst sicher, ich sollte die Dateien außerhalb des htdocs speichern. Geht in meinem Fall eher nicht, weil ich die Bilder anzeigen möchte.
Tipp: Begrenze die Länge eines Upload-Streams und guck dass nicht irgendwo temporäre Dateien hängenbleiben.
Das verstehe ich leider nicht.
Andere Frage: Ich verändere in jedem Fall die upgeloadeten Bilder mit imagick. Was würde imagick denn machen, wenn hier ein manipuliertes Bild ankäme?
Ed
Hallo Eddy.,
Andere Frage: Ich verändere in jedem Fall die upgeloadeten Bilder mit imagick. Was würde imagick denn machen, wenn hier ein manipuliertes Bild ankäme?
Einen Fehler melden.
LG,
CK
Andere Frage: Ich verändere in jedem Fall die upgeloadeten Bilder mit imagick. Was würde imagick denn machen, wenn hier ein manipuliertes Bild ankäme?
Einen Fehler melden.
Hi CK,
hört sich doch schonmal nicht schlecht an...
Somit wäre imagick für mich doch zugleich sowas wie ein "Schadcodewächter", oder? (zumindest für die Bilder...nicht für die PDFs)
Ed
Hallo Eddy.,
Somit wäre imagick für mich doch zugleich sowas wie ein "Schadcodewächter", oder? (zumindest für die Bilder...nicht für die PDFs)
In dem Fall in dem die hochgeladene Datei kein valides Bild ist.
LG,
CK
In dem Fall in dem die hochgeladene Datei kein valides Bild ist.
Könnte es valide Bilder geben, die Schadcode beinhalten?
Ed
Hallo Eddy.,
Könnte es valide Bilder geben, die Schadcode beinhalten?
Klar. Bilder haben Metadaten, in denen man mehr oder weniger freien Text eintragen kann (z.B. den Autoren). Es ist denkbar, dass der Parser für diese Metadaten einen Bug hat. Damit wärst du dann wieder in der Situation, dass jemand Schadcode hat einschleusen können.
Aber ich denke nicht, dass du dich sinnvoll dagegen absichern kannst, da helfen nur mitigation strategies, etwa strenge Beschränkung der Rechte, ggfls ein chroot oder sowas aufbauen, etc.
LG,
CK
Meine Frage, reicht es nciht aus, folgende .htaccess anzulegen?
In Verzeichnissen, wo Du hochgeladene Dateien sicher speicherst, wird eine .htaccess gar nicht wirksam. Es sei denn, Du verbiegst mit Deinem Framework DOCUMENT_ROOT aber da musst Du schon genau wissen was Du tust.
Du meinst sicher, ich sollte die Dateien außerhalb des htdocs speichern. Geht in meinem Fall eher nicht, weil ich die Bilder anzeigen möchte.
Selbstverstänlich kannst Du Bilder auch anzeigen/ausgeben, wenn sie woanders gespeichert sind. PDF genauso. Aber ein öffentliches Upload in ein per DOCUMENT_ROOT zugängliches Verzeichnis würde ich auf gar keinen Fall zulassen.
Schließlich möchtest Du eine Zugriffskontrolle über die Inhalte. Und das ist was Anderes als eine Kontrolle über URLs zu haben (.htaccess). Das sind zwei grundverschiedene Dinge.
Tipp: Begrenze die Länge eines Upload-Streams und guck dass nicht irgendwo temporäre Dateien hängenbleiben.
Das verstehe ich leider nicht.
Bei einem Upload sendet der Client einen Request-Header Content-Length. In diesem Header steht die Anzahl der gesendeten Bytes. Der Webserver nun nimmt diesen Wert und setzt den in eine Umgebungsvariable CONTENT_LENGTH. Auf diese Variable kannst Du mit PHP zugreifen und somit Deinen eigenen Upload-Prozess sofort beenden wenn ein Schwellwert überschritten wird.
Was temp. Dateien angeht informiere Dich bitte selbst.
Tach!
Bei einem Upload sendet der Client einen Request-Header Content-Length. In diesem Header steht die Anzahl der gesendeten Bytes. Der Webserver nun nimmt diesen Wert und setzt den in eine Umgebungsvariable CONTENT_LENGTH. Auf diese Variable kannst Du mit PHP zugreifen und somit Deinen eigenen Upload-Prozess sofort beenden wenn ein Schwellwert überschritten wird.
PHP ist nicht Perl! PHP-Scripte werden erst gestartet, wenn der Request vollständig beim Server angekommen ist. Man kann nur die generelle Requestgröße konfigurativ beschränken.
dedlfix.
Tach!
Bei einem Upload sendet der Client einen Request-Header Content-Length. In diesem Header steht die Anzahl der gesendeten Bytes. Der Webserver nun nimmt diesen Wert und setzt den in eine Umgebungsvariable CONTENT_LENGTH. Auf diese Variable kannst Du mit PHP zugreifen und somit Deinen eigenen Upload-Prozess sofort beenden wenn ein Schwellwert überschritten wird.
PHP ist nicht Perl! PHP-Scripte werden erst gestartet, wenn der Request vollständig beim Server angekommen ist.
Das ist in Perl ganz genauso. CGI/1.1
PHP ist nicht Perl! PHP-Scripte werden erst gestartet, wenn der Request vollständig beim Server angekommen ist.
Das ist in Perl ganz genauso.
Das ist falsch. Das Thema hatten wir doch vor Jahren schon. Wenn man CGI.pm verwendet (ja, ich weiß: Du hast was viel besseres selbst gebaut), dann mag sich das vielleicht so anfühlen. Aber selbst CGI.pm kennt Upload-Hooks, die während des Requests greifen.
Tach!
In Verzeichnissen, wo Du hochgeladene Dateien sicher speicherst, wird eine .htaccess gar nicht wirksam. Es sei denn, Du verbiegst mit Deinem Framework DOCUMENT_ROOT aber da musst Du schon genau wissen was Du tust.
Ein Framework verändert die Apache-Konfiguration? Und sonst so?
Tipp: Begrenze die Länge eines Upload-Streams und guck dass nicht irgendwo temporäre Dateien hängenbleiben.
Das verstehe ich leider nicht.
Keine Sorge, auch viele andere verstehen oftmals nicht, was pl wirklich meint.
Üblicherweise muss man bei PHP die Konfigurationswerte so verändern, dass die Upload-Begrenzung hochgesetzt wird, weil die Standardwerte für heutige Datenmengen meist zu klein sind, gerade bei Bildern. 2MB dürfen Upload-Datei groß sein, 8M der gesamte POST-Request. Die Speicherbegrenzung ist 128MB, was für Bildverarbeitung auch nicht gerade viel ist.
PHP räumt seine eigenen temporären Dateien selbst auf. Das gilt auch für Uploads. Wenn man temporäre Dateien selbst anlegt, sollte man das mit tmpfile() tun, die werden auch zum Scriptende (oder beim expliziten Schließen) aufgeräumt.
Andere Frage: Ich verändere in jedem Fall die upgeloadeten Bilder mit imagick. Was würde imagick denn machen, wenn hier ein manipuliertes Bild ankäme?
Was würdest du denn machen, wenn du manipulierte Daten bekommst? Die eigentliche Frage ist, wie du das für alle möglichen Manipulationen erkennen willst. Mit anderen Worten: Deine Frage kann dir keiner auf generelle Weise beantworten. Da musst du schon mit konkreten Daten kommen und dann schauen (zur Not in seinem Code), was imagick damit anstellt. Das kann von Ignorieren über Fehlermeldung ausgeben bis hin zu wegen Pufferüberlauf oder ähnlichem mit anschließendem unberechenbarem Verhalten alles mögliche sein.
dedlfix.
In Verzeichnissen, wo Du hochgeladene Dateien sicher speicherst, wird eine .htaccess gar nicht wirksam. Es sei denn, Du verbiegst mit Deinem Framework DOCUMENT_ROOT aber da musst Du schon genau wissen was Du tust.
Ein Framework verändert die Apache-Konfiguration? Und sonst so?
Nein. Mein FW verwaltet eine eigene DOCUMENT_ROOT unabhängig von der Serverkonfiguration.
Tipp: Begrenze die Länge eines Upload-Streams und guck dass nicht irgendwo temporäre Dateien hängenbleiben.
Das verstehe ich leider nicht.
Keine Sorge, auch viele andere verstehen oftmals nicht, was pl wirklich meint.
Du hast meinen Artikel postmax nicht gelesen, nicht verstanden oder ignoriert.
Wenn hier jemand was nicht versteht bist du es Meister dedlfix. Informiere Dich bitte richtig und unterlasse es auch bitte, meine fachdienlichen Beiträge schlecht zu machen.
Ich habe mehr als 20 Jahre Programmiererfahrung im Produktiven Umfeld, da ist ein bischen Respekt wirklich angebracht.
Hast Du das verstanden?
Tach!
In Verzeichnissen, wo Du hochgeladene Dateien sicher speicherst, wird eine .htaccess gar nicht wirksam. Es sei denn, Du verbiegst mit Deinem Framework DOCUMENT_ROOT aber da musst Du schon genau wissen was Du tust.
Ein Framework verändert die Apache-Konfiguration? Und sonst so?
Nein. Mein FW verwaltet eine eigene DOCUMENT_ROOT unabhängig von der Serverkonfiguration.
Dann musst du erstmal definieren, was der Begriff DOCUMENT_ROOT in deinem Fall meint. Allgemein versteht man wohl eher darunter, was man im Apachen mit der Direktive DocumentRoot konfiguriert. Dieser Wert lässt sich mit einem Script nicht ändern (wenn der Serveradmin keinen Fehler gemacht hat).
Tipp: Begrenze die Länge eines Upload-Streams und guck dass nicht irgendwo temporäre Dateien hängenbleiben.
Das verstehe ich leider nicht.
Keine Sorge, auch viele andere verstehen oftmals nicht, was pl wirklich meint.
Du hast meinen Artikel postmax nicht gelesen, nicht verstanden oder ignoriert.
Letzteres. Aber selbst wenn ich das nun nachgeholt habe, gelingt es mir noch nicht zu verstehen, worauf du hinauswillst und was das nun für das Vorhaben des Probleminhabers konkret bedeutet.
Wenn hier jemand was nicht versteht bist du es Meister dedlfix. Informiere Dich bitte richtig und unterlasse es auch bitte, meine fachdienlichen Beiträge schlecht zu machen.
Das ich vieles nicht verstehe, gebe ich gern zu. Ob ich richtig informiert bin, kann ich auch nicht immer mit Bestimmtheit sagen. Aber wenn ich Beiträge anderer oder anderenorts lese, dann meine ich, dass ich es meist verstehe, was da geschrieben wird. Bei deinen Beiträgen gelingt mir das aber auffallend selten. Es kann durchaus sein, dass ich nicht verstehe, was du erklären möchtest. Aber ich habe den Anschein, dass es nicht wenigen anderen auch so geht. Vielleicht ist es einfach nur schlecht erklärt, mit verwirrenden weil anders als üblich verwendeten Begriffen, gepaar mit schlecht nachvollziehbaren Gedankengängen.
Ich habe mehr als 20 Jahre Programmiererfahrung im Produktiven Umfeld, da ist ein bischen Respekt wirklich angebracht.
Hast Du das verstanden?
Ja, großer Meister, ich verbeuge mich untertänigst.
dedlfix.
Hallo pl,
Ich habe mehr als 20 Jahre Programmiererfahrung im Produktiven Umfeld, da ist ein bischen Respekt wirklich angebracht.
Berufserfahrung ist kein bisschen Grund für Respekt, erst recht nicht in der Informatik.
LG,
CK
Lieber Rolf,
Mein FW verwaltet eine eigene DOCUMENT_ROOT unabhängig von der Serverkonfiguration.
Dein Framework erwähnst Du inflationär oft in diesem Forum. Wenn ich mich richtig erinnere ist es in Perl geschrieben. Was Du mit Deinem FW in Perl machst, interessiert die üblichen Fragesteller sowas von überhaupt nicht! Und Deine Antworten, die Dein FW anscheinend sehr oft im Hintergrund voraussetzen, haben dann für Fragende keinen Wert. Überhaupt keinen. Sie verunsichern diese eher noch, als dass Deine Antworten irgendwie weiterhelfen könnten.
Du hast meinen Artikel postmax nicht gelesen, nicht verstanden oder ignoriert.
Warum sollte dieser für einen Fragenden hier überhaupt von Bedeutung sein? Inwiefern kann dieser Artikel im für den Fragenden aktuellen Fall von irgendwelcher Relevanz sein, wenn Dein FW mit Perl, der Fragende aber mit PHP und deshalb erst recht ohne Dein Framework arbeitet?
Wenn hier jemand was nicht versteht bist du es Meister dedlfix. Informiere Dich bitte richtig und unterlasse es auch bitte, meine fachdienlichen Beiträge schlecht zu machen.
Deine Beiträge sind in letzter Zeit leider kaum fachdienlich! Das ist ja gerade das Problem! Nur Du willst es wohl einfach nicht wahrhaben, denn...
Ich habe mehr als 20 Jahre Programmiererfahrung im Produktiven Umfeld, da ist ein bischen Respekt wirklich angebracht.
Hast Du das verstanden?
... in Deiner Selbstwahrnehmung (die spricht übrigens Bände!) bist Du Dir über jeden Zweifel erhaben. Dabei nennst Du als Argument nicht fachliche Kompetenz, sondern die Anzahl an Jahren, die Du in einem bestimmten beruflichen Umfeld verbracht hast (Du nennst es wörtlich "Programmiererfahrung"). Damit untergräbst Du Deine Glaubwürdigkeit! Hast Du wenigstens das verstanden?
Liebe Grüße,
Felix Riesterer.
Hi,
Nein. Mein FW verwaltet eine eigene DOCUMENT_ROOT unabhängig von der Serverkonfiguration.
In deiner Welt mag das so sein, in der IT-Welt jedoch wird unter DOCUMENT_ROOT die DocumentRoot-Direktive des Apaches verstanden. So eine Vermischung der Begrifflichkeiten erwartet man eigentlich nicht von erfahrenen Entwicklern.
Du hast meinen Artikel postmax nicht gelesen, nicht verstanden oder ignoriert.
Keinen Tag spaeter hast du bereits wieder zwei von vier Punkten nicht eingehalten.
Ich habe mehr als 20 Jahre Programmiererfahrung im Produktiven Umfeld, da ist ein bischen Respekt wirklich angebracht.
Man bittet nicht um Respekt!
VG Thars