Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Scriptausführung generell verhindern per htaccess?
26 views
Skip to first unread message
Oliver Betz
Mar 25, 2013, 10:39:29 AM3/25/13
to
Hallo Alle,
nachdem die Anfrage in d.c.i.w.a.m keine Ergebnisse im Sinne der
Fragestellung brachte, bel�stige ich Euch hier nochmal:
Welche m�glichst universelle L�sung verhindert die Ausf�hrung
beliebiger Scripte in einem Verzeichnis (in dem Nutzer Dateien
hochladen k�nnen)? Inhalte von Dateien sollen ausgeliefert werden.
Da es so viele M�glichkeiten gibt, Scriptsprachen einzubinden,
bef�rchte ich, etwas �bersehen haben k�nnte.
"Options -ExecCGI" funktioniert in den meisten Shared Hostings.
Funktioniert aber nicht, wenn der Interpreter als Modul l�uft.
�bersehe ich bei "SetHandler default-handler" etwas?
Gibt es weitere M�glichkeiten? Mittlerweile habe ich von Hostings
geh�rt, wo beides nicht hilft.
Das in http://httpd.apache.org/docs/current/mod/core.html#sethandler
dokumentierte "SetHandler None" hat in meinen Versuchen keine
erkennbare Wirkung gezeigt, �ber eine Erkl�rung w�rde ich mich freuen.
Die Alternativen "alles �ber Script ausliefern" und "keine
gef�hrlichen Dateien hochladen lassen" sind schon durch. Ich suche
eine simple und performante Alternative zu ersterem bzw. zus�tzlichen
Schutz zu letzterem.
Servus
Oliver
--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:
nachdem die Anfrage in d.c.i.w.a.m keine Ergebnisse im Sinne der
Fragestellung brachte, bel�stige ich Euch hier nochmal:
Welche m�glichst universelle L�sung verhindert die Ausf�hrung
beliebiger Scripte in einem Verzeichnis (in dem Nutzer Dateien
hochladen k�nnen)? Inhalte von Dateien sollen ausgeliefert werden.
Da es so viele M�glichkeiten gibt, Scriptsprachen einzubinden,
bef�rchte ich, etwas �bersehen haben k�nnte.
"Options -ExecCGI" funktioniert in den meisten Shared Hostings.
Funktioniert aber nicht, wenn der Interpreter als Modul l�uft.
�bersehe ich bei "SetHandler default-handler" etwas?
Gibt es weitere M�glichkeiten? Mittlerweile habe ich von Hostings
geh�rt, wo beides nicht hilft.
Das in http://httpd.apache.org/docs/current/mod/core.html#sethandler
dokumentierte "SetHandler None" hat in meinen Versuchen keine
erkennbare Wirkung gezeigt, �ber eine Erkl�rung w�rde ich mich freuen.
Die Alternativen "alles �ber Script ausliefern" und "keine
gef�hrlichen Dateien hochladen lassen" sind schon durch. Ich suche
eine simple und performante Alternative zu ersterem bzw. zus�tzlichen
Schutz zu letzterem.
Servus
Oliver
--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:
Message has been deleted
Message has been deleted
Oliver Betz
Mar 30, 2013, 6:30:02 AM3/30/13
to
"Walter H." schrieb:
>> Die Alternativen "alles �ber Script ausliefern" und "keine
>> gef�hrlichen Dateien hochladen lassen" sind schon durch. Ich suche
>> eine simple und performante Alternative zu ersterem bzw. zus�tzlichen
>> Schutz zu letzterem.
>
>die einfachste Sache in diesem Zusammenhang, es k�nnen entweder nur
>Bilddateien oder Archivdateien hochgeladen werden;
Wenn ich Dich richtig verstehe, entspricht das dem zitierten "keine
gef�hrlichen Dateien hochladen lassen". Das geht oft, manchmal sollen
aber gerade Quelltexte angeboten werden k�nnen.
>die Frage: was hast Du eigentlich vor - nur mal neugierig gefragt ...
Es geht um Dateien, die Benutzer per CMS auf den Server hochladen
k�nnen. In den betreffenden Verzeichnissen soll sichergestellt werden,
dass z.B. PHP, Python, Perl nicht ausgef�hrt werden.
"Options -ExecCGI" und "SetHandler default-handler" funktionieren in
vielen "shared hosting" Umgebungen (aber nicht immer). Mich
interessieren weitere, m�glichst universelle M�glichkeiten, die man
versuchen kann.
Servus
Oliver
--
Oliver Betz, Munich http://oliverbetz.de/
>> Die Alternativen "alles �ber Script ausliefern" und "keine
>> gef�hrlichen Dateien hochladen lassen" sind schon durch. Ich suche
>> eine simple und performante Alternative zu ersterem bzw. zus�tzlichen
>> Schutz zu letzterem.
>
>Bilddateien oder Archivdateien hochgeladen werden;
Wenn ich Dich richtig verstehe, entspricht das dem zitierten "keine
gef�hrlichen Dateien hochladen lassen". Das geht oft, manchmal sollen
aber gerade Quelltexte angeboten werden k�nnen.
>die Frage: was hast Du eigentlich vor - nur mal neugierig gefragt ...
Es geht um Dateien, die Benutzer per CMS auf den Server hochladen
k�nnen. In den betreffenden Verzeichnissen soll sichergestellt werden,
dass z.B. PHP, Python, Perl nicht ausgef�hrt werden.
"Options -ExecCGI" und "SetHandler default-handler" funktionieren in
vielen "shared hosting" Umgebungen (aber nicht immer). Mich
interessieren weitere, m�glichst universelle M�glichkeiten, die man
versuchen kann.
Servus
Oliver
--
Oliver Betz, Munich http://oliverbetz.de/
Message has been deleted
Oliver Betz
Mar 31, 2013, 9:16:00 AM3/31/13
to
"Walter H." schrieb:
>der Quelltext ist ja nur gef�hrlich, wenn er .php, .shtm(l), .phtm(l),
>.pl - je nach Serverarchitektur auch .asp(x) ... hei�t; als .txt aber nicht;
>beim Upload einfach Dropdownbox �ber Programmiersprache und sobald er
>oben ist einfach als .txt benannt;
Apache kann "schlauer" eingestellt werden:
http://httpd.apache.org/docs/2.2/mod/mod_mime.html#multipleext
damit w�rde boese.php.txt ausgef�hrt.
Zus�tzlich zur "Whitelist", welche Endungen erlaubt sind, habe ich
deshalb eine "Blacklist", welche Namensbestandteile verboten sind, und
au�erdem entsprechende Eintr�ge in htaccess. Blacklists sind aber vom
Prinzip her riskanter als Whitelists, als alleinige Ma�nahme w�re mir
das zu unsicher. Deshalb die Frage nach L�sungen in htaccess.
[...]
>bei Quelltexten w�re es ein Goodie sie so zu liefern, da� auch
>zeilennummern angezeigt werden ..., und vielleicht eine kleine farbige
>syntaxdarstellung;
daf�r habe ich bei Bedarf L�sungen.
In diesem Thread geht es mir nur um eine Sammlung von Optionen, mit
denen man in htaccess daf�r sorgen kann, dass Skripte nicht ausgef�hrt
werden k�nnen.
>der Quelltext ist ja nur gef�hrlich, wenn er .php, .shtm(l), .phtm(l),
>.pl - je nach Serverarchitektur auch .asp(x) ... hei�t; als .txt aber nicht;
>beim Upload einfach Dropdownbox �ber Programmiersprache und sobald er
>oben ist einfach als .txt benannt;
Apache kann "schlauer" eingestellt werden:
http://httpd.apache.org/docs/2.2/mod/mod_mime.html#multipleext
damit w�rde boese.php.txt ausgef�hrt.
Zus�tzlich zur "Whitelist", welche Endungen erlaubt sind, habe ich
deshalb eine "Blacklist", welche Namensbestandteile verboten sind, und
au�erdem entsprechende Eintr�ge in htaccess. Blacklists sind aber vom
Prinzip her riskanter als Whitelists, als alleinige Ma�nahme w�re mir
das zu unsicher. Deshalb die Frage nach L�sungen in htaccess.
[...]
>bei Quelltexten w�re es ein Goodie sie so zu liefern, da� auch
>zeilennummern angezeigt werden ..., und vielleicht eine kleine farbige
>syntaxdarstellung;
daf�r habe ich bei Bedarf L�sungen.
In diesem Thread geht es mir nur um eine Sammlung von Optionen, mit
denen man in htaccess daf�r sorgen kann, dass Skripte nicht ausgef�hrt
werden k�nnen.
Gustaf Mossakowski
Mar 31, 2013, 10:25:47 AM3/31/13
to
Oliver Betz schrieb:
> Zus�tzlich zur "Whitelist", welche Endungen erlaubt sind, habe ich
> deshalb eine "Blacklist", welche Namensbestandteile verboten sind, und
> au�erdem entsprechende Eintr�ge in htaccess. Blacklists sind aber vom
> Prinzip her riskanter als Whitelists, als alleinige Ma�nahme w�re mir
> das zu unsicher. Deshalb die Frage nach L�sungen in htaccess.
Sprach etwas dagegen, den . im Dateinamen zu verbieten?
Abgesehen davon kann man einen Apache so konfigurieren, dass er alles
m�gliche als Skript interpretiert, daher verstehe ich deinen Ansatz,
sich gegen alle m�glichen Apache-Konfigurationen abzusichern, nicht so
ganz. Ich kenne z. B. Konfigurationen, in denen alles, was auf .html
endet, durch PHP geschickt wird.
Viele Gr��e, Gustaf
> Zus�tzlich zur "Whitelist", welche Endungen erlaubt sind, habe ich
> deshalb eine "Blacklist", welche Namensbestandteile verboten sind, und
> au�erdem entsprechende Eintr�ge in htaccess. Blacklists sind aber vom
> Prinzip her riskanter als Whitelists, als alleinige Ma�nahme w�re mir
> das zu unsicher. Deshalb die Frage nach L�sungen in htaccess.
Abgesehen davon kann man einen Apache so konfigurieren, dass er alles
m�gliche als Skript interpretiert, daher verstehe ich deinen Ansatz,
sich gegen alle m�glichen Apache-Konfigurationen abzusichern, nicht so
ganz. Ich kenne z. B. Konfigurationen, in denen alles, was auf .html
endet, durch PHP geschickt wird.
Viele Gr��e, Gustaf
Oliver Betz
Mar 31, 2013, 1:18:28 PM3/31/13
to
Gustaf Mossakowski schrieb:
>> Zusätzlich zur "Whitelist", welche Endungen erlaubt sind, habe ich
>> Prinzip her riskanter als Whitelists, als alleinige Maßnahme wäre mir
>> das zu unsicher. Deshalb die Frage nach Lösungen in htaccess.
>Abgesehen davon kann man einen Apache so konfigurieren, dass er alles
>mögliche als Skript interpretiert, daher verstehe ich deinen Ansatz,
>sich gegen alle möglichen Apache-Konfigurationen abzusichern, nicht so
>> Zusätzlich zur "Whitelist", welche Endungen erlaubt sind, habe ich
>> deshalb eine "Blacklist", welche Namensbestandteile verboten sind, und
>> außerdem entsprechende Einträge in htaccess. Blacklists sind aber vom
>> Prinzip her riskanter als Whitelists, als alleinige Maßnahme wäre mir
>> das zu unsicher. Deshalb die Frage nach Lösungen in htaccess.
>
>Sprach etwas dagegen, den . im Dateinamen zu verbieten?
fragst Du das im Ernst?
>Sprach etwas dagegen, den . im Dateinamen zu verbieten?
>Abgesehen davon kann man einen Apache so konfigurieren, dass er alles
>sich gegen alle möglichen Apache-Konfigurationen abzusichern, nicht so
>ganz. Ich kenne z. B. Konfigurationen, in denen alles, was auf .html
>endet, durch PHP geschickt wird.
Siehe letzter Satz im OP.
>endet, durch PHP geschickt wird.
Gustaf Mossakowski
Mar 31, 2013, 6:16:48 PM3/31/13
to
Oliver Betz schrieb:
> Gustaf Mossakowski schrieb:
oder .gif oder .css, aber nicht .php.txt oder so etwas). Bei
Datei-Uploads generiere ich immer neue Namen, die meistens nur a-z0-9-
enthalten. Mit dem . wird anschlie�end die Dateiendung angeh�ngt, die
nach Untersuchung mit file oder �hnlichen Tools bestimmt wird.
>> Abgesehen davon kann man einen Apache so konfigurieren, dass er
>> alles m�gliche als Skript interpretiert, daher verstehe ich deinen
>> Ansatz, sich gegen alle m�glichen Apache-Konfigurationen
nur darauf hinweisen, dass du eh die Konfiguration des Webservers pr�fen
mu�t, weil es auch sein kann, dass .html als Skript interpretiert wird.
Viele Gr��e, Gustaf
> Gustaf Mossakowski schrieb:
>> Sprach etwas dagegen, den . im Dateinamen zu verbieten?
>
> fragst Du das im Ernst?
Ja. In URLs reicht eine Endung, wenn �berhaupt (also .txt oder .html
>
> fragst Du das im Ernst?
oder .gif oder .css, aber nicht .php.txt oder so etwas). Bei
Datei-Uploads generiere ich immer neue Namen, die meistens nur a-z0-9-
enthalten. Mit dem . wird anschlie�end die Dateiendung angeh�ngt, die
nach Untersuchung mit file oder �hnlichen Tools bestimmt wird.
>> Abgesehen davon kann man einen Apache so konfigurieren, dass er
>> Ansatz, sich gegen alle m�glichen Apache-Konfigurationen
>> abzusichern, nicht so ganz. Ich kenne z. B. Konfigurationen, in
>> denen alles, was auf .html endet, durch PHP geschickt wird.
>
> Siehe letzter Satz im OP.
>> denen alles, was auf .html endet, durch PHP geschickt wird.
>
> Siehe letzter Satz im OP.
| Ich suche eine simple und performante Alternative zu ersterem bzw.
| zus�tzlichen Schutz zu letzterem.
? Ich hab nicht gesagt, dass du alles an PHP schicken sollst. Ich wollte
| zus�tzlichen Schutz zu letzterem.
nur darauf hinweisen, dass du eh die Konfiguration des Webservers pr�fen
mu�t, weil es auch sein kann, dass .html als Skript interpretiert wird.
Viele Gr��e, Gustaf
Oliver Betz
Apr 1, 2013, 4:10:02 AM4/1/13
to
Gustaf Mossakowski schrieb:
>>> Sprach etwas dagegen, den . im Dateinamen zu verbieten?
>>
>> fragst Du das im Ernst?
>
>Ja. In URLs reicht eine Endung, wenn �berhaupt (also .txt oder .html
>oder .gif oder .css, aber nicht .php.txt oder so etwas). Bei
ah so, da hast Du Dich unklar ausgedr�ckt, denn das ist ja _ein_ Punkt
>>> Sprach etwas dagegen, den . im Dateinamen zu verbieten?
>>
>> fragst Du das im Ernst?
>
>Ja. In URLs reicht eine Endung, wenn �berhaupt (also .txt oder .html
>oder .gif oder .css, aber nicht .php.txt oder so etwas). Bei
im Dateinamen. Du meintest "mehrere Punkte".
Auch eine M�glichkeit, danke!
[...]
>? Ich hab nicht gesagt, dass du alles an PHP schicken sollst. Ich wollte
>nur darauf hinweisen, dass du eh die Konfiguration des Webservers pr�fen
>mu�t, weil es auch sein kann, dass .html als Skript interpretiert wird.
0 new messages