Are you content with our current attacks on Content-Type?

The talk starts from the idea that browsers depend heavily on the Content-Type header in HTTP responses to decide how to render a file. The presenters argue that this trust is weak. Attackers used to struggle to set an arbitrary Content-Type, because upload checks looked at file extensions, declared types and file signatures. Object storage changed that, since an object's metadata can hold any Content-Type string, and SDK-based uploads often skip the validation developers assume is handled for them.

The presenters described how they searched for this pattern. A bug bounty target with an unverified S3-backed upload allowed cross-site scripting, though they could not escalate it further. A code search of well-known open-source JavaScript and TypeScript projects returned thousands of hits, most with no validation or weak validation, and some passed the browser-supplied type straight to object storage. Recurring flaws included client-side-only checks that a proxy can bypass, and prefix, suffix or substring tests on the type. They showed how an allow list turned into a regular expression could be defeated by a crafted value, and how a check that only looked at the start of the string could accept text/html after an image type. Examples included the CarrierWave library for Rails, an Electron application and a Chrome extension, where the impact could be higher.

The takeaway is to stop trusting the response Content-Type and instead compare it against an exact match on a known set of values, such as image/png or image/jpeg, enforced on the server. Teams using object storage should treat any metadata they set on uploads as user-controlled input.