Dateien beim Uploaden prüfen

Seite 1 von 2 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/dateien_beim_uploaden_pruefen_62023/page_1 - zur Vollversion wechseln!

Yeahman schrieb am 08.01.2003 um 13:55

Ich hab mal ne Frage, obs ne intelligente Variante gibt, zu prüfen ob das File was der User mit dem File-Input Control in HTML upgeloadet hat?

Ich will verhindern, das z.B. exe's, oder ganze DB's auf meinem Webserver upgeloadet werden.

Dateiendungen prüfen wäre sicher ne Variante, nur ich weiss nicht ob das achso intelligent ist.

watchout schrieb am 08.01.2003 um 14:25

Zitat von Yeahman
Ich hab mal ne Frage, obs ne intelligente Variante gibt, zu prüfen ob das File was der User mit dem File-Input Control in HTML upgeloadet hat?

Ich will verhindern, das z.B. exe's, oder ganze DB's auf meinem Webserver upgeloadet werden.

Dateiendungen prüfen wäre sicher ne Variante, nur ich weiss nicht ob das achso intelligent ist.

naja, die meisten formate geben doch irgendwo an was sie sind, nur machen die das afaik alle irgendwo anders... :rolleyes:

die seite hab ich irgendwo mal aufgetrieben: http://www.wotsit.org/

und warum machst nicht einfach ein grössenlimit, dann is' ja sowieso wurscht... :confused:

Philipp schrieb am 08.01.2003 um 14:35

Welche Sprache? PHP?

Am besten du überprüfst die Länge bzw. Dateiendungen

Hier ein kleines Beispiel in PHP:

Code: PHP

$upfile = strtolower($_FILES[datei][name]);
if(!preg_match("/(gif|jpg|jpeg|png)/i", $upfile)) { 
echo "Fehler: Das ist keine GIF, JPG, JPEG oder PNG Datei";
exit;
}

if($_FILES[datei][size] > 25000) {
echo "Fehler: Datei zu lang";
exit;
}

Yeahman schrieb am 08.01.2003 um 14:42

Zitat von watchout
und warum machst nicht einfach ein grössenlimit, dann is' ja sowieso wurscht...

das Problem ist nicht die Grösse, die wird ohne hin geprüft.
Das Problem ist, das jeder User die upgeloadeten Dateien anschauen kann. Aber wenns eine Exe anschaust (doppelklickt) führst du sie aus, und das soll verhindert werden.

Nix PHP, ASP.NET, aber wie gesagt, ich wollte wissen obs was intelligenteres gibt, als Endungen prüfen.

watchout schrieb am 08.01.2003 um 14:44

Zitat von Yeahman
das Problem ist nicht die Grösse, die wird ohne hin geprüft.
Das Problem ist, das jeder User die upgeloadeten Dateien anschauen kann. Aber wenns eine Exe anschaust (doppelklickt) führst du sie aus, und das soll verhindert werden.

Nix PHP, ASP.NET, aber wie gesagt, ich wollte wissen obs was intelligenteres gibt, als Endungen prüfen.

naja, eine exe wird nicht ausgeführt, wenn sie nicht .exe oder .com heisst insofern würde es ja reichen

schrieb am 08.01.2003 um 14:47

ein upload in ein verzeichnis mit execute rechten ist sowieso der frevel schlechthin

Yeahman schrieb am 08.01.2003 um 15:36

Zitat von rettich
ein upload in ein verzeichnis mit execute rechten ist sowieso der frevel schlechthin

der Upload geht in die DB, und diese binary-Felder werden mit reponse.binarywrite rausgeschrieben.

Zitat von watchout
naja, eine exe wird nicht ausgeführt, wenn sie nicht .exe oder .com heisst insofern würde es ja reichen

is schon klar, aber die Chance das du eine Endung vergisst, oder irgentwas daherkommt, das du noch nicht kennst, oder zum Releasezeitpunkt noch nicht am Markt war, ist nicht unerheblich.

watchout schrieb am 08.01.2003 um 17:29

Zitat von Yeahman
is schon klar, aber die Chance das du eine Endung vergisst, oder irgentwas daherkommt, das du noch nicht kennst, oder zum Releasezeitpunkt noch nicht am Markt war, ist nicht unerheblich.

die chance etwas zu vergessen besteht (leider) immer

und wenn du es wie hier am forum machst, und nur gifs, jpegs, png's usw zulässt - wie gesagt die andere möglichkeit wäre die struktur des files zu prüfen...

atrox schrieb am 08.01.2003 um 20:52

unter unix gibt es ein utility namens "file", daß über magic-bytes (header-analyse) und text-analysen hunderte dateiformate erkennen kann.

aber du könntest auch eine ganz simple text-analyse machen - zb nach typischen merkmalen einer html-datei suchen (tags) bzw nach anderen ausschliesenden merkmalen - zb mit einem zeichen-histogramm (häufigkeit des auftretens jedes einzelnen zeichens)
dazu mußt du aber eine mindestanzahl an bytes lesen, da sonst das ergebnis zu ungenau ist.

in einem text- bzw html-datei wirst du ganz viele vorkommen von a-z A-Z 0-9 < > usw haben... aber (fast) gar keine von sonderzeichen (ascii 0-31 bzw ascii > 128) - "fast" deshalb, weil man nicht auschliesen kann, daß nicht jemand unabsichtlich doch ein oder 2 sonderzeichen irgendwo eingebaut hat.

mit doppelbuchstaben-analysen läßt sich zb schon sehr zuverlässig die sprache eines natürlichen textes ermitteln (zb englisch, deutsch, französisch,....) - aber das nur so am rande erwähnt, quasi als exkursion.

manalishi schrieb am 08.01.2003 um 21:21

ich würd nur dateiformate, die mir wirklich passen, erlauben. sonst kannst du jedes andere dateiformat eigens behandeln -> lame.

watchout schrieb am 09.01.2003 um 00:15

Zitat von atrox
unter unix gibt es ein utility namens "file", daß über magic-bytes (header-analyse) und text-analysen hunderte dateiformate erkennen kann.

aber du könntest auch eine ganz simple text-analyse machen - zb nach typischen merkmalen einer html-datei suchen (tags) bzw nach anderen ausschliesenden merkmalen - zb mit einem zeichen-histogramm (häufigkeit des auftretens jedes einzelnen zeichens)
dazu mußt du aber eine mindestanzahl an bytes lesen, da sonst das ergebnis zu ungenau ist.

in einem text- bzw html-datei wirst du ganz viele vorkommen von a-z A-Z 0-9 < > usw haben... aber (fast) gar keine von sonderzeichen (ascii 0-31 bzw ascii > 128) - "fast" deshalb, weil man nicht auschliesen kann, daß nicht jemand unabsichtlich doch ein oder 2 sonderzeichen irgendwo eingebaut hat.

mit doppelbuchstaben-analysen läßt sich zb schon sehr zuverlässig die sprache eines natürlichen textes ermitteln (zb englisch, deutsch, französisch,....) - aber das nur so am rande erwähnt, quasi als exkursion.

also, häufigkeitsanalysen verwendet man eher um verschlüsselungen zu knacken, als um dateiformate zu bestimmen... :rolleyes:

atrox schrieb am 09.01.2003 um 04:16

es geht dabei darum zu unterscheiden ob es eine text-/html-datei handelt oder nicht - bei binär-dateien erhalte ich nur die information, daß es eine solche ist, aber nicht welche. Yeahman wollte ja einen test wie man auf html prüfen kann, nicht wie man jedes dateiformat erkennt. für letzeres wird eine header-untersuchung ähnlich dem 'file' util unter unix und dem 'magic-bytes-file' das geschickteste sein.

AmenophisIII schrieb am 09.01.2003 um 07:04

Zitat von atrox
Yeahman wollte ja einen test wie man auf html prüfen kann, nicht wie man jedes dateiformat erkennt.

nochmal lesen....

atrox schrieb am 09.01.2003 um 07:13

you are right - das "HTML" bezog sich nur auf das file-input control.

hier die ensprechenden auszüge aus dem erwähnten "magic"-file unter unix - die ersten paar bytes reichen für einen einfachen test. (einfach mal ein paar dateien mit einem hex-viewer ansehen!)

Code:

# PNG [Portable Network Graphics, or "PNG's Not GIF"] images
# (Greg Roelofs, [email]newt@uchicago.edu[/email])
# (Albert Cahalan, [email]acahalan@cs.uml.edu[/email])
#
# 137 P N G \r \n ^Z \n [4-byte length] H E A D [HEAD data] [HEAD crc] ...
#
0       string          \x89PNG         PNG image data,
>4      belong          !0x0d0a1a0a     CORRUPTED,
>4      belong          0x0d0a1a0a
>>16    belong          x               %ld x
>>20    belong          x               %ld,
>>24    byte            x               %d-bit
>>25    byte            0               grayscale,
>>25    byte            2               \b/color RGB,
>>25    byte            3               colormap,
>>25    byte            4               gray+alpha,
>>25    byte            6               \b/color RGBA,
#>>26   byte            0               deflate/32K,
>>28    byte            0               non-interlaced
>>28    byte            1               interlaced
1       string          PNG             PNG image data, CORRUPTED

# GIF
0       string          GIF8            GIF image data
>4      string          7a              \b, version 8%s,
>4      string          9a              \b, version 8%s,
>6      leshort         >0              %hd x
>8      leshort         >0              %hd
#>10    byte            &0x80           color mapped,
#>10    byte&0x07       =0x00           2 colors
#>10    byte&0x07       =0x01           4 colors
#>10    byte&0x07       =0x02           8 colors
#>10    byte&0x07       =0x03           16 colors
#>10    byte&0x07       =0x04           32 colors
#>10    byte&0x07       =0x05           64 colors
#>10    byte&0x07       =0x06           128 colors
#>10    byte&0x07       =0x07           256 colors

# JPEG images.
#
0       beshort         0xffd8          JPEG image data
>6      string          JFIF            \b, JFIF standard
>6      string          Exif            \b, EXIF standard

du siehst, die ersten 4-6 bytes sollten reichen - die zusatzdaten über auflösung etc sind ja nicht relevant.

Yeahman schrieb am 09.01.2003 um 08:15

ok thx, werd mich mal damit rumspielen, wenns nicht klappt (aus Zeitgründen), werd ich mit der Dateiendungsversion leben müssen.