Java / mime type bepalen van PNG files

[smeerbartje]

Ik gebruik onderstaande code om de mime-type van files te bepalen. Dit werkt goed voor bijvoorbeeld jpg files (type is "image/jpeg"), maar voor png files krijg ik als mime-type terug: "application/octet-stream". Ik weet zeker dat m'n testfile een plaatje is, dus wat doe ik fout?

Zijn er sowieso betere methoden om van files te bepalen of het "media" is? Met media bedoel ik dus plaatjes (jpg, png, gif, etc), maar ook video (mp4, avi, etc).

Java:

// source: http://stackoverflow.com/questions/51438/getting-a-files-mime-type-in-java
String fileName = "/Users/rlommers/Downloads/CheckIfImage/image.png";
MimetypesFileTypeMap mimeTypesMap = new MimetypesFileTypeMap();

File file = new File(fileName);
String mimeType = mimeTypesMap.getContentType(file);

System.out.println("Mimetype: " + mimeType);

[ Voor 4% gewijzigd door smeerbartje op 12-04-2014 21:52 ]

[pedorus]

Je hebt kennelijk een javaomgeving waarbij png niet in mimetypes.default staat. http://stackoverflow.com/...s-to-mimetypesfiletypemap

Hier een versie met een regel voor png: http://code.google.com/p/...ava/mimetypes.default?r=3

[smeerbartje]

Thanks; als ik 'm toevoeg, dan "ziet" hij inderdaad dat het een PNG is. Echter als ik een simpel tekstbestandje hernoem naar "test.jpg" of naar "test.png", dan denk hij ook dat dat respectievelijk een png of jpeg is. Ik wil dus eigenlijk iets hebben dat inhoudelijk naar de file kijkt en checkt of het een image/video betreft. Niet puur op extensie; want het lijkt erop dat mimTypesMap.getContentType() dat doet.

[Creepy]

Kan dan eens naar ImageIO. Daarmee kan je in elk geval bepalen of het een geldige afbeelding is, en ook wat voor type, onafhankelijk van de extensie.

[CyBeR]

smeerbartje schreef op zaterdag 12 april 2014 @ 22:31:
Thanks; als ik 'm toevoeg, dan "ziet" hij inderdaad dat het een PNG is. Echter als ik een simpel tekstbestandje hernoem naar "test.jpg" of naar "test.png", dan denk hij ook dat dat respectievelijk een png of jpeg is. Ik wil dus eigenlijk iets hebben dat inhoudelijk naar de file kijkt en checkt of het een image/video betreft. Niet puur op extensie; want het lijkt erop dat mimTypesMap.getContentType() dat doet.

Dat klopt, want zo werkt dat nou eenmaal. Om voor elke file te gaan zitten uitvogelen wat 't is aan de hand van de inhoud zou een enorme performance-hit opleveren. Er wordt dus van uitgegaan dat de extensie, indien aanwezig, correct is.

Als je zelf wilt checken of een png file een png file is, de header van een PNG is heel simpel. De eerste bytes zijn als volgt:

code:

89504E470D0A1A0A

[pedorus]

Apache Tika zou dat wel kunnen. Voorbeeldcode op http://stackoverflow.com/...tifying-file-type-in-java

Maar de performance kan wel eens minder zijn natuurlijk, en bestanden horen gewoon de juiste extensies te hebben..

[smeerbartje]

Heb nu dit... en het werkt . Ik zal Tika ook eens proberen.

Java:

   private static String getFormatName(Object o) {
      try {
         ImageInputStream iis = ImageIO.createImageInputStream(o);
         Iterator iter = ImageIO.getImageReaders(iis);
         if (!iter.hasNext()) {
            return null;
         }
         ImageReader reader = (ImageReader) iter.next();
         iis.close();

         return reader.getFormatName();
      } catch (IOException e) {
      }
      return null;
   }

[ Voor 3% gewijzigd door smeerbartje op 12-04-2014 23:26 ]

[drm]

CyBeR:
Dat klopt, want zo werkt dat nou eenmaal. Om voor elke file te gaan zitten uitvogelen wat 't is aan de hand van de inhoud zou een enorme performance-hit opleveren. Er wordt dus van uitgegaan dat de extensie, indien aanwezig, correct is.

Nou, liever niet eigenlijk. Ik mag hopen dat het met de betreffende library ook niet zo is. Als het inderdaad de extensie in ogenschouw neemt, kun je beter die library niet meer gebruiken.

Dit is wat mijn mime type guesser zegt (standaard GNU/Linux; Debian in dit geval):

$ wget -q http://tweakimg.net/g/if/v3/framework/logo_transparent.png
$ file ./logo_transparent.png 
./logo_transparent.png: PNG image data, 213 x 85, 8-bit/color RGBA, non-interlaced
$ mv logo_transparent.png foo.jpg
$ file ./foo.jpg 
./foo.jpg: PNG image data, 213 x 85, 8-bit/color RGBA, non-interlaced
$ mv foo.jpg bar.txt
$ file ./bar.txt 
./bar.txt: PNG image data, 213 x 85, 8-bit/color RGBA, non-interlaced

Die snapt t ook. En als je performance verkiest boven security moet je van hele goede huize komen

[CyBeR]

drm schreef op zondag 13 april 2014 @ 05:24:
[...]
Nou, liever niet eigenlijk. Ik mag hopen dat het met de betreffende library ook niet zo is. Als het inderdaad de extensie in ogenschouw neemt, kun je beter die library niet meer gebruiken.

Welkom in de echte wereld waar mime types 99 van de 100 keer gewoon op filenaam gaan.

Dit is wat mijn mime type guesser zegt (standaard GNU/Linux; Debian in dit geval):

$ wget -q http://tweakimg.net/g/if/v3/framework/logo_transparent.png
$ file ./logo_transparent.png 
./logo_transparent.png: PNG image data, 213 x 85, 8-bit/color RGBA, non-interlaced
$ mv logo_transparent.png foo.jpg
$ file ./foo.jpg 
./foo.jpg: PNG image data, 213 x 85, 8-bit/color RGBA, non-interlaced
$ mv foo.jpg bar.txt
$ file ./bar.txt 
./bar.txt: PNG image data, 213 x 85, 8-bit/color RGBA, non-interlaced

Die snapt t ook. En als je performance verkiest boven security moet je van hele goede huize komen

'file' is helemaal geen mime type guesser; file is een file type guesser die inderdaad aan de hand van de inhoud en een grote magic database werkt. En dit heeft met security helemaal geen moer te maken. Sterker nog, er zijn best een paar security advisories met betrekking tot 'file' zelf, waar een verkeerde input 'file' rare dingen kon laten doen.

[drm]

CyBeR:
Welkom in de echte wereld waar mime types 99 van de 100 keer gewoon op filenaam gaan.

Dat het vaak gebeurt wil nog niet zeggen dat het een goed idee is.

'file' is helemaal geen mime type guesser; file is een file type guesser die inderdaad aan de hand van de inhoud en een grote magic database werkt.

Dat zijn twee compleet verschillende dingen, omdat ...?

En dit heeft met security helemaal geen moer te maken.

Het doen van aannames over de inhoud van een bestand op basis van zijn bestandsextensie heeft geen moer met security te maken ....? Ik weet niet wat ik hier op moet zeggen... als je dat echt gelooft dan hoop ik dat je nooit meer iemand een advies geeft over iets dat ook maar in de verste verte met security te maken heeft... Maar je bedoelt ongetwijfeld iets anders.

Sterker nog, er zijn best een paar security advisories met betrekking tot 'file' zelf, waar een verkeerde input 'file' rare dingen kon laten doen.

Ik weet niet wat dat met mijn punt te maken heeft, maar dat zal best.

[CyBeR]

drm schreef op zondag 13 april 2014 @ 14:17:
[...]
Dat het vaak gebeurt wil nog niet zeggen dat het een goed idee is.

Dan gebruik jij toch lekker elke keer file om 't uit te zoeken? Moet je niet terug komen als je server staat te roken omdat 'ie het niet bijhoudt.

Dat zijn twee compleet verschillende dingen, omdat ...?

Komt er een MIME-type uit file? Nee.

Het doen van aannames over de inhoud van een bestand op basis van zijn bestandsextensie heeft geen moer met security te maken ....? Ik weet niet wat ik hier op moet zeggen... als je dat echt gelooft dan hoop ik dat je nooit meer iemand een advies geeft over iets dat ook maar in de verste verte met security te maken heeft... Maar je bedoelt ongetwijfeld iets anders.

Als je applicatie een securityprobleem heeft als je een image/jpeg file doorstuurt met een text/plain mime type dan is je applicatie brak. Server-side heeft dat echter geen enkele invloed op de beveiliging ervan.

[...]
Ik weet niet wat dat met mijn punt te maken heeft, maar dat zal best.

Op het moment dat je met de inhoud van user-input (files) bezig gaat, heb je het probleem dat je je juist openstelt voor security problemen. Bijvoorbeeld file wat meermaals in het verleden zo'n probleem gehad heeft, of een file die specifiek gemaakt is om het een te zijn maar voor dat soort guessers te lijken op iets anders.

Kijk, ik ga je niet tegenhouden als jij iets anders wilt doen maar neem van mij aan dat de industry practise is om dit gewoon op file extension te doen, en dat er in de meeste situaties geen reden is om dat niet te doen.

[drm]

CyBeR:
Dan gebruik jij toch lekker elke keer file om 't uit te zoeken? Moet je niet terug komen als je server staat te roken omdat 'ie het niet bijhoudt.

Again... performance over security?

Komt er een MIME-type uit file? Nee.

Met de juiste flags wel Een MIME type is alleen maar een representatie van een file type.

Als je applicatie een securityprobleem heeft als je een image/jpeg file doorstuurt met een text/plain mime type dan is je applicatie brak. Server-side heeft dat echter geen enkele invloed op de beveiliging ervan.

Tsja... zo zou de bouwer van de "applicatie" ook kunnen redeneren: meh, ik ga niet moeilijk doen want had de user input maar goed gevalideerd moeten zijn.... Met zo'n houding weet je zeker dat er ergens een gat in je systeem zit.

Op het moment dat je met de inhoud van user-input (files) bezig gaat, heb je het probleem dat je je juist openstelt voor security problemen. Bijvoorbeeld file wat meermaals in het verleden zo'n probleem gehad heeft, of een file die specifiek gemaakt is om het een te zijn maar voor dat soort guessers te lijken op iets anders.

Kortom: vertrouw userinput nooit. Hoe je dat dan precies regelt moet je zelf weten, maar een extensie is ook user input. Dat is precies mijn punt.

Kijk, ik ga je niet tegenhouden als jij iets anders wilt doen maar neem van mij aan dat de industry practise is om dit gewoon op file extension te doen, en dat er in de meeste situaties geen reden is om dat niet te doen.

Ik ga jou niet tegenhouden als je extensions wilt vertrouwen, maar als je beweert dat dat geen veiligheidsimplicaties heeft, vind ik dat een slecht advies.

[CyBeR]

Prima hoor.

[Adion]

Ik ben nu toch wel benieuwd naar een voorbeeld van wanneer het onveilig zou zijn om het foute mime-type gegokt te hebben...

[MSalters]

drm schreef op zondag 13 april 2014 @ 16:50:
[...]
Again... performance over security?

Als je ongecontroleerd files in je file system, krijgt, dan maakt content sniffing vs extensie niets meer uit. Dan heb je grotere problemen.

[drm]

MSalters:
Als je ongecontroleerd files in je file system, krijgt, dan maakt content sniffing vs extensie niets meer uit. Dan heb je grotere problemen.

Prima, zo lang dan maar helder is waar die controle dan wél ligt.

[HollowGamer]

Waarom dump je niet in een file of tabel, wat voor een bestandstype bij die bestandsnaam hoort?
Zo kun je een schakel functie maken en hoef je server niet gaan 'gokken' welk bestandrype jij bedoeld en het scheelt weer load.

[Gomez12]

HollowGamer schreef op dinsdag 15 april 2014 @ 01:24:
Waarom dump je niet in een file of tabel, wat voor een bestandstype bij die bestandsnaam hoort?
Zo kun je een schakel functie maken en hoef je server niet gaan 'gokken' welk bestandrype jij bedoeld en het scheelt weer load.

Hoe wil je die file/tabel gaan vullen?

[HollowGamer]

Is dit zo moeilijk dan?
Bestandsnaam|type
Fjsnssnsbddkenxbs|image/png

[Herko_ter_Horst]

En wat gaat je dat meer opleveren t.o.v. de oplossing die de TS al in z'n openingspost had staan? Want dit is dus precies wat MimetypesFileTypeMap al doet o.b.v. de mimetypes.default file.

[begintmeta]

drm schreef op zondag 13 april 2014 @ 16:50:
...
Kortom: vertrouw userinput nooit. Hoe je dat dan precies regelt moet je zelf weten, maar een extensie is ook user input. Dat is precies mijn punt.
...

De bestandsnaam is user input, de bestandsinhoud is user input, allebei dus niet te vertrouwen. Waar je op af gaat om het bestandstype te bepalen zou niet uit mogen maken.

[ Voor 9% gewijzigd door begintmeta op 15-04-2014 11:19 ]

[HollowGamer]

Herko_ter_Horst schreef op dinsdag 15 april 2014 @ 11:03:
En wat gaat je dat meer opleveren t.o.v. de oplossing die de TS al in z'n openingspost had staan? Want dit is dus precies wat MimetypesFileTypeMap al doet o.b.v. de mimetypes.default file.

Omdat TS als opmerking maakte, wat als ik de extensie verander van .png naar .andere-ext?

[Hydra]

HollowGamer schreef op dinsdag 15 april 2014 @ 13:48:
[...]

Omdat TS als opmerking maakte, wat als ik de extensie verander van .png naar .andere-ext?

Het is maar net de vraag of dat een probleem is. Enige wat je daardoor krijgt is dat images waarschijnlijk niet goed geladen worden. Aangezien dit opzet is, hoeft dat geen issue te zijn.

[MSalters]

begintmeta schreef op dinsdag 15 april 2014 @ 11:18:
[...]
De bestandsnaam is user input, de bestandsinhoud is user input, allebei dus niet te vertrouwen.

De bestandsinhoud is user input en niet te vertrouwen? In welk model denk jij?

In een serveromgeving komt data pas op disk nadat het gecheckt is; er ontstaan niet spontaan .PNG files op disk.

In een client omgeving kun je dat niet afdwingen, maar hoef je user input ook niet te vertrouwen. Users kunnen alleen bij hun eigen files. Dit introduceert geen enkel nieuw risico.

[begintmeta]

MSalters schreef op donderdag 17 april 2014 @ 17:23:
...
In een serveromgeving komt data pas op disk nadat het gecheckt is; er ontstaan niet spontaan .PNG files op disk.
...

Wat ik bedoel is dus dat je altijd voorzichtig moet zijn bij het checken van bestanden, omdat PNG-inhoud noch bestandsnamen vanzelf ontstaan (maar altijd (eventueel indirect) van een user afkomstig zijn)

[ Voor 11% gewijzigd door begintmeta op 17-04-2014 18:18 ]

[smeerbartje]

Mensen, wat een discussie. Ik wil voorkomen dat kwaadwillenden (we hebben ook te maken met externe leveranciers) foutieve files aanleveren, onder de noemen: "het is een plaatje". Vandaar dat ik nu Apache TIKA gebruik om te bepalen of "iets" een media asset is. Werkt goed en de performance is goed genoeg. Alléén mime-type checking is voor ons té risico-vol, ook al is het sneller.

[ Voor 3% gewijzigd door smeerbartje op 17-04-2014 20:02 ]