How to Tell a File's Real Type from Its Magic Bytes
Le défi
Un utilisateur a envoyé ceci en tant que 'avatar.png', mais le serveur n'a vérifié que le nom. Ses vrais octets ne commencent pas par la signature PNG 89 50 4E 47. Lisez l'en-tête ci-dessous, comparez ses premiers octets surlignés à la référence des octets magiques, et tapez la VRAIE extension du fichier (comme .png ou .pdf).
Ce que tu vas apprendre
- Understand what magic bytes (a file signature) are and where they live in a file
- Read a hex dump alongside its ASCII gutter to recognize a file's true format
- Explain why a file's name and claimed Content-Type prove nothing about its contents
- Recognize how attackers disguise one file type as another to defeat extension checks
- Describe how server-side signature validation hardens a file-upload pipeline
Compétences testées
Prérequis
- Comfort reading hexadecimal and basic ASCII
- Awareness that files have a structured binary layout, not just an extension
Comment ça marche
Almost every file format begins with a short, fixed sequence of bytes called a magic number or file signature. Programs read these leading bytes to decide what a file actually is before doing anything with it. A PNG image, for example, always opens with 89 50 4E 47 (the bytes spell .PNG in the ASCII gutter), a JPEG starts FF D8 FF, a PDF starts 25 50 44 46 (%PDF), and a ZIP archive starts 50 4B 03 04 (PK..). The signature lives at the very start of the file and does not change just because someone renames the file or sets a different Content-Type header.
That is the whole point of this challenge: the upload is named avatar.png, but a name is just a label a user chooses. The truth is in the bytes. Opening the file in a hex view shows two columns - the raw hexadecimal on the left and a printable-ASCII gutter on the right. When the leading bytes do not match the signature the extension promises, the file is not what it claims to be. The ASCII gutter is your shortcut: many signatures are human-readable text, so a quick glance often tells you the real format faster than memorizing hex.
This matters because file type is a security boundary. An image pipeline expects to decode pixels; if it is instead handed an executable, a script, or an archive, the assumptions break - and an attacker who can smuggle the wrong type past a weak check has a foothold. Reading magic bytes is the forensic skill that closes that gap.
Erreurs fréquentes
- Trusting the file extension. A
.pngending is just text in the filename; anyone can rename anything. The extension is a hint, never proof. - Trusting the Content-Type header. The browser or client sets it, and a client is fully attacker-controlled.
image/pngin a request says nothing about the actual bytes. - Reading only the hex and skipping the ASCII gutter. Many signatures spell out recognizable letters on the right-hand column - ignoring it makes you work harder than you need to.
- Assuming a valid-looking start means the whole file is safe. Matching magic bytes confirm the format, but they do not guarantee the rest of the file is benign or well-formed.
Comment s'en protéger
When you accept file uploads, never decide a file's type from its name or its Content-Type header. Read the actual leading bytes server-side and verify them against the signature for the format you expect, then enforce an allow-list of permitted types rather than a block-list of forbidden ones.
Layer additional defenses so that even a correctly-typed file cannot do harm:
- Re-encode or process accepted images through a trusted library, which rejects malformed or disguised inputs.
- Store uploads outside the web root and serve them from a separate domain with a forced
Content-Dispositionso they are never executed or interpreted in your origin. - Generate your own random filenames and ignore the user-supplied name entirely.
- Cap file size and validate dimensions before any heavy processing.