JavaScript: Dateityp vor Upload prüfen?

[Alexander Schestag]

Hallo,

gibt es eine *sichere* Methode, einen Dateityp vor einem Upload mittels
JavaScript zu prï¿œfen? Also "sicher" wie in "nicht nur im Sinne einer
Pseudoprï¿œfung der Dateiendung, sondern im Sinne einer Prï¿œfung, die
sicherstellt, dass etwa ein Bild auch ein Bild ist und keine PHP-Shell"?

Grￜￜe,

Alex

[Thomas 'PointedEars' Lahn]

Alexander Schestag wrote:

> gibt es eine *sichere* Methode, einen Dateityp vor einem Upload mittels

> JavaScript zu prüfen? Also "sicher" wie in "nicht nur im Sinne einer
> Pseudoprüfung der Dateiendung, sondern im Sinne einer Prüfung, die

> sicherstellt, dass etwa ein Bild auch ein Bild ist und keine PHP-Shell"?

Ja. Aber damit wirst Du Cracker nicht austricksen können. Du musst
zusätzlich serverseitig prüfen.


PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14

[Martin Honnen]

Man kann in modernen Browsern mehr als nur den (oder die) Dateinamen
auslesen, siehe
https://developer.mozilla.org/en-US/docs/Using_files_from_web_applications#Getting_information_about_selected_file%28s%29,
es gibt u.a. eine files-Kollektion mit File-Objekten, die Eigenschaften
wie size und type haben. Mit einem FileReader kann man auch den Inhalt
auslesen.

[Alexander Schestag]

Am 11.02.2013 19:23, schrieb Thomas 'PointedEars' Lahn:
> Alexander Schestag wrote:
>
>> gibt es eine *sichere* Methode, einen Dateityp vor einem Upload mittels
>> JavaScript zu prüfen? Also "sicher" wie in "nicht nur im Sinne einer
>> Pseudoprüfung der Dateiendung, sondern im Sinne einer Prüfung, die
>> sicherstellt, dass etwa ein Bild auch ein Bild ist und keine PHP-Shell"?
>
> Ja. Aber damit wirst Du Cracker nicht austricksen können. Du musst
> zusätzlich serverseitig prüfen.

Ja, das fürchte ich auch, nachdem ich das nochmal durchdacht habe.
Diesbezüglich die Frage, ob dann überhaupt das HTML5-Attribut "accept"
innerhalb des Formulartyps "file" einen Sinn ergibt?

Grüße,

Alex


--
http://www.parapsychologische-beratung.com

[Thomas 'PointedEars' Lahn]

Ein Programm, welches das Attribut unterstützt, kann so die auswählbaren
Dateien beschränken. Chromium 24 für Debian GNU/Linux bietet dann einen
entsprechenden Eintrag im “Filter”-Feld von KDialog.

Aussagen werden durch Fragezeichen nicht fragender.


PointedEars
--
> Einfach die xml Tags durch html Code ersetzen und gut...
Lass es mich so sagen: Die dunkle Seite gewählt Du hast. Den schnellen
Erfolg Du suchst, aber auf die Füsse fallen die Komplexität Dir wird.
Unterschätze niemals die Bugs der dunklen Seite! -- Geggo in fcc

[Thomas 'PointedEars' Lahn]

Ralf Döblitz wrote:

> Alexander Schestag <sup...@wp-care.net> schrieb:

>> gibt es eine *sichere* Methode, einen Dateityp vor einem Upload mittels

>> JavaScript zu prüfen? Also "sicher" wie in "nicht nur im Sinne einer
>> Pseudoprüfung der Dateiendung, sondern im Sinne einer Prüfung, die

>> sicherstellt, dass etwa ein Bild auch ein Bild ist und keine PHP-Shell"?
>

> Wieso JavaScript, hast du auf dem Server nichts normales zur Verfügung?
> Auf dem Client kannst du ja eh nichts vertrauen, bleibt also nur, auf
> dem Server die Daten vor der Weiterverarbeitung eine rPrüfung zu
> unterziehen (z.B. mit file(1)).

Wenn man befürchtet, dass PHP-Shells hochgeladen werden, hat man wohl PHP
auf dem Server. Somit entfallen die nicht immer mögliche Installation von
file(1) und ein nicht immer möglicher Shell-Aufruf:

<http://php.net/fileinfo>

> Natürlich könntest du auch versuchen, file(1) in JS nachzubauen, aber

… das ist heutzutage oft überflüssig:

<http://www.w3.org/TR/html5/forms.html#dom-input-files> ff.

> zuverlässig wird das dadurch trotzdem nicht.

ACK.


PointedEars
--
Clientseitig geht das nicht wirklich, weil der Browser selbst keine
Mails verschicken kann und das Kooperieren mit Mailprogrammen eher
in ein Kollabieren entartet.
(Georg Maaß in dcljs <aoh6vi$mbrnu$4...@ID-3551.news.dfncis.de>)

[Arno Welzel]

Da der Dateiupload jederzeit auch unter Umgehung des Scripts erfolgen
kann, musst Du die Prï¿œfung ohnehin auch auf dem Server zusï¿œtzlich
implementieren. Und was bitte ist eine "PHP-Shell" als Datei?


--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[Arno Welzel]

Am 12.02.2013 13:49, schrieb Arno Welzel:
> Am 11.02.2013 18:42, schrieb Alexander Schestag:
>
>> gibt es eine *sichere* Methode, einen Dateityp vor einem Upload mittels
>> JavaScript zu prï¿œfen? Also "sicher" wie in "nicht nur im Sinne einer
>> Pseudoprï¿œfung der Dateiendung, sondern im Sinne einer Prï¿œfung, die
>> sicherstellt, dass etwa ein Bild auch ein Bild ist und keine PHP-Shell"?
>
> Da der Dateiupload jederzeit auch unter Umgehung des Scripts erfolgen
> kann, musst Du die Prï¿œfung ohnehin auch auf dem Server zusï¿œtzlich
> implementieren. Und was bitte ist eine "PHP-Shell" als Datei?

Ergï¿œnzung - damit ist wohl das gemeint:

<http://phpshell.sourceforge.net/>

[Alexander Schestag]

Am 12.02.2013 13:50, schrieb Arno Welzel:

>> Da der Dateiupload jederzeit auch unter Umgehung des Scripts erfolgen
>> kann, musst Du die Prï¿œfung ohnehin auch auf dem Server zusï¿œtzlich
>> implementieren. Und was bitte ist eine "PHP-Shell" als Datei?
>
> Ergï¿œnzung - damit ist wohl das gemeint:
>
> <http://phpshell.sourceforge.net/>

Exakt. Wegen solcher Dinge ist eine sichere Prï¿œfung zwingend notwendig.
Aber ihr habt ja alle Recht, eine Prï¿œfung auf dem Server ist unumgï¿œnglich.

Alex


--
http://www.parapsychologische-beratung.com

[Thomas 'PointedEars' Lahn]

Alexander Schestag wrote:

> Am 12.02.2013 13:50, schrieb Arno Welzel:
>>> Da der Dateiupload jederzeit auch unter Umgehung des Scripts erfolgen

>>> kann, musst Du die Prüfung ohnehin auch auf dem Server zusätzlich

>>> implementieren. Und was bitte ist eine "PHP-Shell" als Datei?
>>

>> Ergänzung - damit ist wohl das gemeint:
>>
>> <http://phpshell.sourceforge.net/>
>
> Exakt. Wegen solcher Dinge ist eine sichere Prüfung zwingend notwendig.

Das deutet allerdings auf ein grundlegendes Sicherheitsproblem auf dem
Server hin. Wird etwa exec() & Co. Benutzern normalerweise verboten, sieht
eine PHP-Shell zwar noch schön aus, man kann aber damit keinen Schaden mehr
anrichten:

| Safe Mode
|
| Safe Mode is the nemisis of PHP Shell. If PHP is running in Safe Mode then
| PHP Shell will normally not work — sorry. Please read the detailed
| explaination in the SECURITY file included in the PHP Shell distribution.

(“nemisis” sollte wohl “nemesis” heissen)

Siehe hierzu auch <http://php.net/manual/en/features.safe-mode.php>, welches
zeigt, dass der “Safe Mode” inzwischen (PHP 5.4 ist aktuell) nicht mehr
unterstützt wird. Stattdessen gibt es z. B. suPHP:
<http://stackoverflow.com/a/7906631/855543> f.

> Aber ihr habt ja alle Recht, eine Prüfung auf dem Server ist unumgänglich.

Unumgänglich ist sie nicht, jedoch ratsam.


PointedEars
--
DER [Browser] soll sich um sowas kuemmern, nicht die MARKUP language,
mit der nur sematische Informationen gegeben werden sollen, keine
Layoutbeschreibung (das galt zumindest, bevor Netscape und Microsoft
in Wettstreit traten, wer das Prinzip nachhaltiger vergewaltigen darf,
der eindeutig zugunsten von Microsoft ausging) -- BGKS

[Alexander Schestag]

Am 12.02.2013 16:56, schrieb Thomas 'PointedEars' Lahn:
> Alexander Schestag wrote:

>> Exakt. Wegen solcher Dinge ist eine sichere Prüfung zwingend notwendig.
>
> Das deutet allerdings auf ein grundlegendes Sicherheitsproblem auf dem
> Server hin. Wird etwa exec() & Co. Benutzern normalerweise verboten, sieht
> eine PHP-Shell zwar noch schön aus, man kann aber damit keinen Schaden mehr
> anrichten:

Da ich das in dem Falle nicht unter Kontrolle habe, gehe ich auf Nummer
sicher.

[Oliver Betz]

Alexander Schestag schrieb:

>gibt es eine *sichere* Methode, einen Dateityp vor einem Upload mittels

>JavaScript zu prüfen? Also "sicher" wie in "nicht nur im Sinne einer
>Pseudoprüfung der Dateiendung, sondern im Sinne einer Prüfung, die

>sicherstellt, dass etwa ein Bild auch ein Bild ist und keine PHP-Shell"?

Wie will ein Angreifer den Webserver dazu bringen, eine auf .foo
endende Datei als PHP zu behandeln?

Ich verwende eine Whitelist von Dateiendungen, die hochgeladen werden
darf.

Servus

Oliver
--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:

[Thomas 'PointedEars' Lahn]

Oliver Betz wrote:

> Alexander Schestag schrieb:
>> gibt es eine *sichere* Methode, einen Dateityp vor einem Upload mittels
>> JavaScript zu prüfen? Also "sicher" wie in "nicht nur im Sinne einer
>> Pseudoprüfung der Dateiendung, sondern im Sinne einer Prüfung, die
>> sicherstellt, dass etwa ein Bild auch ein Bild ist und keine PHP-Shell"?
>
> Wie will ein Angreifer den Webserver dazu bringen, eine auf .foo
> endende Datei als PHP zu behandeln?

Aus meiner styles/.htaccess:

<IfModule mod_php5.c>
AddHandler application/x-httpd-php .css
</IfModule>

[Gelegentlich muss ich mir noch etwas Besseres überlegen. Es ist aufwändig,
für jede auch nicht dynamische .css-Datei das “Content-Type”- und die Cache-
Headerfelder mit PHP setzen zu müssen. Das Suffix .css hat im lokalen SVN-
Arbeitsverzeichnis den Vorteil, dass trotz PHP-dynamischen Teilen das CSS-
SHL in Eclipse WTP weitestgehend funktioniert, was bei .php nicht der Fall
ist.]

> Ich verwende eine Whitelist von Dateiendungen, die hochgeladen werden
> darf.

Security by obscurity.


PointedEars
--
Aber das Sperren der rechten Maustaste hat auch seine Vorteile: so
bleibt uns der Anblick einer ganzen Menge dilettantisch und lieblos
zusammengewurstelten Quellcodes erspart. (Ulrich 'Droeppez' Kritzner in
http://selfhtml.de/forum/zeigebeitrag.php3?fid=5&id=31594&thread=31592)

[Oliver Betz]

Thomas 'PointedEars' Lahn schrieb:

>> Wie will ein Angreifer den Webserver dazu bringen, eine auf .foo
>> endende Datei als PHP zu behandeln?
>
>Aus meiner styles/.htaccess:
>
> <IfModule mod_php5.c>
> AddHandler application/x-httpd-php .css
> </IfModule>

ist schon klar (siehe anderes Posting mit "ForceType"), aber das muss
ich ja nicht in den Verzeichnissen machen, wo Leute etwas hochladen
k�nnen.

Und auch nicht mit Erweiterungen, die in der "darfst Du hochladen"
Whitelist (s.u.) stehen.

[...]

>> Ich verwende eine Whitelist von Dateiendungen, die hochgeladen werden
>> darf.
>
>Security by obscurity.

Da ist keine Obscurity, die Liste ist nicht geheim. Effekt ist, dass
nur .txt .jpg .png und so weiter hochgeladen werden darf.

Wenn jemand dann phpshell mit einer dieser Erweiterungen hochl�dt,
wird der freundliche Indianer das (hoffentlich) nicht an PHP
�bergeben.

Ich sehe da noch kein Risiko, aber vielleicht habe ich ja etwas
�bersehen. In dem Fall w�rde ich mich �ber einen entsprechenden
Hinweis freuen.

Servus

Oliver
--
Oliver Betz, Muenchen http://oliverbetz.de/

[Markus Grob]

Oliver Betz schrieb:

> Da ist keine Obscurity, die Liste ist nicht geheim. Effekt ist, dass
> nur .txt .jpg .png und so weiter hochgeladen werden darf.
>
> Wenn jemand dann phpshell mit einer dieser Erweiterungen hochl�dt,
> wird der freundliche Indianer das (hoffentlich) nicht an PHP
> �bergeben.

Nun, ein Dateifilter auf Clientseite ist nichts, was die Sicherheit
erh�ht, sondern nur den Komfort des Benutzers, der automatisch sieht,
was akzeptiert wird, bevor er es hochl�dt.

Will jemand Deinen Server missbrauchen, dann wird er schauen, dass er
Dein JS ausschaltet, das kann er ganz nach belieben.

Bei Problemen mit Bildern, welche einen �berlauf beim verarbeiten
verursachen, kannst Du als "Anwender" nichts machen, ausser hoffen, dass
Du ein Update einspielen kannst, bevor jemand die verwundbare Stelle in
PHP ausnutzt.

Gruss, Markus

[Oliver Betz]

Markus Grob schrieb:

>> Da ist keine Obscurity, die Liste ist nicht geheim. Effekt ist, dass
>> nur .txt .jpg .png und so weiter hochgeladen werden darf.
>>
>> Wenn jemand dann phpshell mit einer dieser Erweiterungen hochl�dt,
>> wird der freundliche Indianer das (hoffentlich) nicht an PHP
>> �bergeben.
>
>Nun, ein Dateifilter auf Clientseite ist nichts, was die Sicherheit

nat�rlich auf dem Server, nicht clientseitig.

[...]

>Bei Problemen mit Bildern, welche einen �berlauf beim verarbeiten
>verursachen, kannst Du als "Anwender" nichts machen, ausser hoffen, dass

Du meinst beim Verarbeiten auf dem Server durch PHP oder z.B.
ImageMagick?

Das ist wahr. Beunruhigt mich nicht allzusehr, weil auf den von mir
betreuten Seiten "Fremde" nichts hochladen d�rfen. Vereinsmitgliedern
traue ich so weit.

Besonders oft scheint das aber auch nicht auf �ffentlichen Seiten zu
passieren.

Ich hoffe, dass "meine" Hoster da auf Zack sind.

[Manuel Reimer]

Thomas 'PointedEars' Lahn wrote:
> | Safe Mode

Also für mich wäre "Safe Mode aktiv" auf jedem Fall ein Ausschlusskriterium bei
der Hosterwahl.

> Siehe hierzu auch <http://php.net/manual/en/features.safe-mode.php>, welches
> zeigt, dass der “Safe Mode” inzwischen (PHP 5.4 ist aktuell) nicht mehr
> unterstützt wird. Stattdessen gibt es z. B. suPHP:
> <http://stackoverflow.com/a/7906631/855543> f.

Wird auch langsam zeit, dass dieses "Feature" endlich abgeschafft wird.

"suphp" ist letztlich nichts anderes als "Führe PHP-Scripte im Kontext des Users
aus, der sie erstellt hat". Der Feature-Umfang von PHP bleibt dabei voll erhalten.

Die meisten, die "shared Hosting" anbieten nutzen mittlerweile entweder suphp
oder suexec.

Gruß

Manuel

[Karl Pflästerer]

Oliver Betz <OB...@despammed.com> writes:

[...]

> Da ist keine Obscurity, die Liste ist nicht geheim. Effekt ist, dass
> nur .txt .jpg .png und so weiter hochgeladen werden darf.

.php.txt wird angenommen?

> Wenn jemand dann phpshell mit einer dieser Erweiterungen hochlädt,

> wird der freundliche Indianer das (hoffentlich) nicht an PHP

> übergeben.

Je nachdem, wie Apache eingestellt ist, wird eine .php.txt Datei auch
an PHP übergeben (dies ist ein Apache Feature; siehe:
http://httpd.apache.org/docs/2.2/mod/mod_mime.html#multipleext )

> Ich sehe da noch kein Risiko, aber vielleicht habe ich ja etwas

> übersehen. In dem Fall würde ich mich über einen entsprechenden
> Hinweis freuen.

Bitte. Hochgeladene Dateien benennt man immer um; die Dateiendung ergibt
sich aus dem Typ der Datei (den man serverseitig ermittelt) und der als
Filterkriterium dient (und nicht die Dateiendung). Zusätzlich werden
hochgeladene Dateien in einem Verzeichnis abgelegt, in dem man nichts
ausführen lässt.

KP

[Alexander Schestag]

Am 12.02.2013 22:05, schrieb Oliver Betz:
> Thomas 'PointedEars' Lahn schrieb:

>>> Ich verwende eine Whitelist von Dateiendungen, die hochgeladen werden
>>> darf.
>>
>> Security by obscurity.
>
> Da ist keine Obscurity, die Liste ist nicht geheim. Effekt ist, dass
> nur .txt .jpg .png und so weiter hochgeladen werden darf.

Nein. Die Dateiendung sagt nichts �ber den Inhalt einer Datei aus.
Dieser Irrglaube ist Windowsdenke. Eine reine Pr�fung der Dateiendung
ist nachgewiesenerma�en nicht hinreichend sicher.

> Wenn jemand dann phpshell mit einer dieser Erweiterungen hochl�dt,
> wird der freundliche Indianer das (hoffentlich) nicht an PHP
> �bergeben.

Da gibt es M�glichkeiten, das zu umgehen, siehe Karls Beispiel mit .php.txt.

Alex


--
http://www.parapsychologische-beratung.com

[Arno Welzel]

Oliver Betz, 2013-02-12 18:54:

> Alexander Schestag schrieb:
>
>> gibt es eine *sichere* Methode, einen Dateityp vor einem Upload mittels
>> JavaScript zu prüfen? Also "sicher" wie in "nicht nur im Sinne einer
>> Pseudoprüfung der Dateiendung, sondern im Sinne einer Prüfung, die
>> sicherstellt, dass etwa ein Bild auch ein Bild ist und keine PHP-Shell"?
>
> Wie will ein Angreifer den Webserver dazu bringen, eine auf .foo
> endende Datei als PHP zu behandeln?
>
> Ich verwende eine Whitelist von Dateiendungen, die hochgeladen werden
> darf.

Die bringt aber nur etwas, wenn diese Liste auf dem Server geprüft wird.

[Alexander Schestag]

Am 14.02.2013 05:06, schrieb Arno Welzel:
> Oliver Betz, 2013-02-12 18:54:
>

>> Ich verwende eine Whitelist von Dateiendungen, die hochgeladen werden
>> darf.
>
> Die bringt aber nur etwas, wenn diese Liste auf dem Server geprüft wird.
>

Selbst dann nicht, da der Inhalt der Datei nicht durch die Endung
determiniert wird. Es gibt diverse Möglichkeiten, auch mit scheinbar
"korrekten" Dateiendungen böse Dinge zu tun.

[Matthias Würfl]

Am 13.02.2013 22:42, schrieb Alexander Schestag:

> Nein. Die Dateiendung sagt nichts über den Inhalt einer Datei aus.

Es besteht diesbezüglich keine Sicherheit, aber Konventionen.

> Dieser Irrglaube ist Windowsdenke. Eine reine Prüfung der Dateiendung
> ist nachgewiesenermaßen nicht hinreichend sicher.

Das bedeutet? Apache soll bei jeder Datei den Inhalt überprüfen statt
nach der Dateiendung zu gehen damit er den richtigen mime-Typ sendet?

Was willst Du damit sagen? Nicht hinreichend sicher für *was*?

Ich kann doch hier den dollsten Virus auf meinem Windows-Rechner in
einer txt-Datei haben. Warum nicht? Der Virus ist trotzdem noch da, aber
er wird beim anklicken nicht ausgeführt und ist somit ungefährlich.

Ich kann die dollsten PHP-Shells in .txt-Dateien auf dem Server haben:
Mein Webserver wird sie nicht ausführen.

Grüße, Matthias

[Stefan Froehlich]

On Thu, 14 Feb 2013 08:05:39 Alexander Schestag wrote:
> >> Ich verwende eine Whitelist von Dateiendungen, die hochgeladen werden
> >> darf.

> > Die bringt aber nur etwas, wenn diese Liste auf dem Server geprüft
> > wird.
>
> Selbst dann nicht, da der Inhalt der Datei nicht durch die Endung
> determiniert wird. Es gibt diverse Möglichkeiten, auch mit scheinbar
> "korrekten" Dateiendungen böse Dinge zu tun.

Aber auch nur dann, wenn (im Fall der PHP-Shell) die Datei ausgefuehrt
wird. Und wer _das_ mit einem Upload versucht, der ist eh nicht mehr zu
retten.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan - niemand kichert arger oder auch starker.
(Sloganizer)

[Arno Welzel]

Am 14.02.2013 09:06, schrieb Stefan Froehlich:
> On Thu, 14 Feb 2013 08:05:39 Alexander Schestag wrote:
>>>> Ich verwende eine Whitelist von Dateiendungen, die hochgeladen werden
>>>> darf.
>
>>> Die bringt aber nur etwas, wenn diese Liste auf dem Server geprüft
>>> wird.
> >
>> Selbst dann nicht, da der Inhalt der Datei nicht durch die Endung
>> determiniert wird. Es gibt diverse Möglichkeiten, auch mit scheinbar
>> "korrekten" Dateiendungen böse Dinge zu tun.
>
> Aber auch nur dann, wenn (im Fall der PHP-Shell) die Datei ausgefuehrt
> wird. Und wer _das_ mit einem Upload versucht, der ist eh nicht mehr zu
> retten.

Es geht ja auch darum, dass die "böse" Datei erst hochgeladen und
*danach* ausgeführt wird.

[Gustaf Mossakowski]

Karl Pfl�sterer schrieb:

> Bitte. Hochgeladene Dateien benennt man immer um; die Dateiendung ergibt
> sich aus dem Typ der Datei (den man serverseitig ermittelt) und der als
> Filterkriterium dient (und nicht die Dateiendung).

Soweit die Theorie. In der Praxis ist es aber nicht immer m�glich, den
Dateityp ohne Dateiendung herauszubekommen.

> Zus�tzlich werden

> hochgeladene Dateien in einem Verzeichnis abgelegt, in dem man nichts

> ausf�hren l�sst.

Am Besten schiebt man hochgeladene Dateien in ein Verzeichnis, was gar
nicht direkt unterhalb des DOCUMENT ROOT liegt.

Viele Gr��e
Gustaf

[Karl Pflästerer]

Gustaf Mossakowski <gus...@gmx.de> writes:

> Karl Pflästerer schrieb:

>
>> Bitte. Hochgeladene Dateien benennt man immer um; die Dateiendung ergibt
>> sich aus dem Typ der Datei (den man serverseitig ermittelt) und der als
>> Filterkriterium dient (und nicht die Dateiendung).
>

> Soweit die Theorie. In der Praxis ist es aber nicht immer möglich, den
> Dateityp ohne Dateiendung herauszubekommen.

Für die Dateien, wo wir Uploads zulassen, ist es möglich. Bilder aller
Art, PDFs, Word-Doc und Konsorten etc. kann man gut identifizieren.

>> Zusätzlich werden

>> hochgeladene Dateien in einem Verzeichnis abgelegt, in dem man nichts

>> ausführen lässt.

>
> Am Besten schiebt man hochgeladene Dateien in ein Verzeichnis, was gar
> nicht direkt unterhalb des DOCUMENT ROOT liegt.

Es geht ja hier darum, dass der Nutzer diese Dateien auch angezeigt
bekommt; wer ein Bild hochlädt will das Bild auch nachher sehen. Wer
einen Artikel schreibt und eine Power Point Datei als Anlage hochlädt,
will nachher einen Link im geschriebenen Artikel zum Download. Also
müssen diese Dateien per HTTP abrufbar sein. Bei deiner Lösung benötigt
man ein proxy Skript, über das all diese Aufrufe geroutet werden; kann
man machen, es kommt dann darauf an, ob die Performance noch ausreichend
ist (und das Skript so geschrieben ist, das Caching auch funktioniert
(korrekte HTTP header)). Performance und Caching bekommt man mit
X-Sendfile hin (Apache oder Nginx können das zum Beispiel).

KP

[Arno Welzel]

Am 15.02.2013 13:04, schrieb Karl Pflästerer:

> Gustaf Mossakowski <gus...@gmx.de> writes:
[...]

>> Am Besten schiebt man hochgeladene Dateien in ein Verzeichnis, was gar
>> nicht direkt unterhalb des DOCUMENT ROOT liegt.
>
> Es geht ja hier darum, dass der Nutzer diese Dateien auch angezeigt
> bekommt; wer ein Bild hochlädt will das Bild auch nachher sehen. Wer
> einen Artikel schreibt und eine Power Point Datei als Anlage hochlädt,
> will nachher einen Link im geschriebenen Artikel zum Download. Also
> müssen diese Dateien per HTTP abrufbar sein. Bei deiner Lösung benötigt
> man ein proxy Skript, über das all diese Aufrufe geroutet werden; kann
> man machen, es kommt dann darauf an, ob die Performance noch ausreichend
> ist (und das Skript so geschrieben ist, das Caching auch funktioniert
> (korrekte HTTP header)). Performance und Caching bekommt man mit
> X-Sendfile hin (Apache oder Nginx können das zum Beispiel).

Es geht auch so:

<https://arnowelzel.de/wiki/de/misc/finland-2012>

Diese Bildersammlung wird komplett durch serverseitige Scripte dynamisch
erzeugt. Hier dauert das komplette Laden der Übersicht inkl. der etwa
200 Bilder rund 6 Sekunden (sofern der Browser SPDY unterstützt - sonst
eben etwas länger).

[Oliver Betz]

k...@rl.pflaesterer.de schrieb:

[...]

>> Da ist keine Obscurity, die Liste ist nicht geheim. Effekt ist, dass
>> nur .txt .jpg .png und so weiter hochgeladen werden darf.
>
>.php.txt wird angenommen?

ja.

>Je nachdem, wie Apache eingestellt ist, wird eine .php.txt Datei auch

>an PHP �bergeben (dies ist ein Apache Feature; siehe:
>http://httpd.apache.org/docs/2.2/mod/mod_mime.html#multipleext )

danke f�r den Hinweis. Bei meiner wichtigsten Website ist das nicht
so: Der Server liefert es einfach als text/plain aus.

Bei einem von zwei anderen Hostern, die ich kurz testete, konnte ich
einen kritischen Fall konstruieren (kein "Options -ExecCGI", bestimmte
Permissions). Beide brauchen auch noch ein "AddHandler text/plain
.txt", um die Datei anzuzeigen.

>> Ich sehe da noch kein Risiko, aber vielleicht habe ich ja etwas

>> �bersehen. In dem Fall w�rde ich mich �ber einen entsprechenden

>> Hinweis freuen.
>
>Bitte. Hochgeladene Dateien benennt man immer um; die Dateiendung ergibt
>sich aus dem Typ der Datei (den man serverseitig ermittelt) und der als
>Filterkriterium dient (und nicht die Dateiendung).

GIGO: Der Nutzer darf die Endung bestimmen, keine Bevormundung, kein
unerwartetes Verhalten. Wenn er Unfug macht, kommt Unfug raus. Eine
Rechteerh�hung muss aber ausgeschlossen sein.

> Zus�tzlich werden

>hochgeladene Dateien in einem Verzeichnis abgelegt, in dem man nichts

>ausf�hren l�sst.

Das sehe ich nicht als zus�tzlichen, sondern als den entscheidenden
Punkt an.

"Options -ExecCGI" sollte auf den meisten shared Hostings
funktionieren.

Servus

Oliver
--

[Stefan Froehlich]

On Fri, 15 Feb 2013 19:16:44 Oliver Betz wrote:
> >Zusätzlich werden hochgeladene Dateien in einem Verzeichnis abgelegt, in
> >dem man nichts ausführen lässt.

> Das sehe ich nicht als zusätzlichen, sondern als den entscheidenden

> Punkt an.

> "Options -ExecCGI" sollte auf den meisten shared Hostings
> funktionieren.

Universeller sollte "php_value engine off" sein.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Der stumpfe Mensch will Stefan. Das muß ja wohl einen Grund haben?
(Sloganizer)

[Oliver Betz]

(Stefan Froehlich) schrieb:

>> >Zusätzlich werden hochgeladene Dateien in einem Verzeichnis abgelegt, in
>> >dem man nichts ausführen lässt.
>
>> Das sehe ich nicht als zusätzlichen, sondern als den entscheidenden
>> Punkt an.
>
>> "Options -ExecCGI" sollte auf den meisten shared Hostings
>> funktionieren.
>
>Universeller sollte "php_value engine off" sein.

Danke für den Hinweis, ich dachte, das geht nur für php als Modul.

Allerdings: Perl, Python, Ruby zähle ich auch zu "universell".

Servus

Oliver
--
Oliver Betz, Muenchen http://oliverbetz.de/