Media webp files shown as plain text

Hi there, I have a problem on one of my projects where the webp files in the media are showing binary code instead of rendering the image. In the frontend the files don’t seem to have a problem but if you access them directly it just shows binary code.

Also my media folder seems to be vulnerable :grimacing: Index of /media (cloudfactory.com)

wiki.cloudfactory.com/media/pages/docs/mp-wiki/metrics/average-loss/32ad014688-1684142765/averageloss.webp

Could this be a server configuration issue?

My server is running on Apache with php 8.2.1 and kirby 4 on a public folder setup.

That is definitely a server configuration setup.

As regards the webp image shown as binary data, that also seems to be configuration issue, because if you look at the image in your browsers network tab, you will see that it shows up as plain text. So it seems that your mapping of extensions to mime types is not correct.

@texnixe I’ve managed to find why the webp is displaying as plain text. It seems happen once I’ve added this vulnerability fix inside .htaccess presented here:

Update .htaccess · getkirby/starterkit@db49a55 (github.com)

Idk if that’s the outcome of giving these settings or why it detects webp as unknown.

Also my media vulnerability was indeed a server configuration issue that I’ve solved.

I think I can exclude webp from that rule with the following, but I wonder if that wouldn simply make the initial vulnerability fix obsolete?

<FilesMatch "\.webp$">
    Header unset Content-Type
</FilesMatch>

Edit: Adding this would not take effect in fixing the correct webp display. For now removing the vulnerability fix in the .htaccess seems to be the only option until I get more into this.

What if you remove that again and instead set the media types, e.g.

<IfModule mod_mime.c>

  # Data interchange

    AddType application/atom+xml                        atom
    AddType application/json                            json map topojson
    AddType application/ld+json                         jsonld
    AddType application/rss+xml                         rss
    AddType application/vnd.geo+json                    geojson
    AddType application/xml                             rdf xml


  # JavaScript

    # Normalize to standard type.
    # https://tools.ietf.org/html/rfc4329#section-7.2

    AddType application/javascript                      js


  # Manifest files

    # If you are providing a web application manifest file (see
    # the specification: https://w3c.github.io/manifest/), it is
    # recommended that you serve it with the `application/manifest+json`
    # media type.
    #
    # Because the web application manifest file doesn't have its
    # own unique file extension, you can set its media type either
    # by matching:
    #
    # 1) the exact location of the file (this can be done using a
    #    directive such as `<Location>`, but it will NOT work in
    #    the `.htaccess` file, so you will have to do it in the main
    #    server configuration file or inside of a `<VirtualHost>`
    #    container)
    #
    #    e.g.:
    #
    #       <Location "/.well-known/manifest.json">
    #           AddType application/manifest+json               json
    #       </Location>
    #
    # 2) the filename (this can be problematic as you will need to
    #    ensure that you don't have any other file with the same name
    #    as the one you gave to your web application manifest file)
    #
    #    e.g.:
    #
    #       <Files "manifest.json">
    #           AddType application/manifest+json               json
    #       </Files>

    AddType application/x-web-app-manifest+json         webapp
    AddType text/cache-manifest                         appcache


  # Media files

    AddType audio/mp4                                   f4a f4b m4a
    AddType audio/ogg                                   oga ogg opus
    AddType image/bmp                                   bmp
    AddType image/svg+xml                               svg svgz
    AddType image/webp                                  webp
    AddType video/mp4                                   f4v f4p m4v mp4
    AddType video/ogg                                   ogv
    AddType video/webm                                  webm
    AddType video/x-flv                                 flv

    # Serving `.ico` image files with a different media type
    # prevents Internet Explorer from displaying then as images:
    # https://github.com/h5bp/html5-boilerplate/commit/37b5fec090d00f38de64b591bcddcb205aadf8ee

    AddType image/x-icon                                cur ico


  # Web fonts

    AddType application/font-woff                       woff
    AddType application/font-woff2                      woff2
    AddType application/vnd.ms-fontobject               eot

    # Browsers usually ignore the font media types and simply sniff
    # the bytes to figure out the font type.
    # https://mimesniff.spec.whatwg.org/#matching-a-font-type-pattern
    #
    # However, Blink and WebKit based browsers will show a warning
    # in the console if the following font types are served with any
    # other media types.

    AddType application/x-font-ttf                      ttc ttf
    AddType font/opentype                               otf


  # Other

    AddType application/octet-stream                    safariextz
    AddType application/x-bb-appworld                   bbaw
    AddType application/x-chrome-extension              crx
    AddType application/x-opera-extension               oex
    AddType application/x-xpinstall                     xpi
    AddType text/vcard                                  vcard vcf
    AddType text/vnd.rim.location.xloc                  xloc
    AddType text/vtt                                    vtt
    AddType text/x-component                            htc

</IfModule>

Adding the MIME types suggested alongside the security headers indeed solves the issue.

Now I’m just wondering what’s the best method going forward.

  1. Should I still keep the security headers?
  2. Do these mime types surpass the security headers and in this case make the whole subject obsolete?
  3. Should I keep all these mime types or just the ones I’m using?
  4. Is this supposed to be addressed in the plainkit/starterkit?

Given the fact that removing the security headers introduced fixes my issue, I’m just wondering if it’s really worth keeping it giving the circumstances. :slight_smile:

Defining the media types with AddType is indeed the correct solution that fixes the root cause.

Such media type definitions generally belong into the global server configuration, so it looks like your hosting provider uses an outdated configuration.

If you don’t have access to the global configuration, you can use AddType in your .htaccess. Of course it’s enough to define just the types for file extensions you actually use (like AddType image/webp webp).

We recommend to. They ensure a “better broken than unsafe” setup. The reason for this being that broken setups (like the display of binary data instead of an image) are quickly discovered and fixed while unsafe setups are often only discovered when harm has been done.

If you are the only one with access to the server and the Panel, you don’t need to use the headers as the attacks that the headers protect against are not possible in that case.

No. The only goal is to disable auto-detection of MIME types. Once you explicitly define the correct MIME type with AddType, there is no need for auto-detection, so it cannot be abused.

As I wrote above, MIME types are supposed to be defined by the global server configuration. We cannot include every single piece of configuration in the .htaccess.