Content-Type and Code Execution

IIS, like most web application servers, automatically recognizes requests for URLs that contain server-side code and executes that code on the server. This means that, if I can upload a .ASP or .ASPX or similar file to your server, and then send a request to a URL that maps to the uploaded file, IIS will load the file and execute the code it contains. This code will execute in the user context of the IIS service, which generally has restricted privileges but nonetheless has access to lots of sensitive data (at minimum, all of the data that your webapp has any legitimate need for, TLS private keys, system-wide environment variables, and so on) plus of course it can be used to attempt internal network pivots or local EoP attacks.

There are a few ways to prevent this code execution risk. This is not a comprehensive list - I haven't done any IIS sysadmin work in over a decade, and am not fully familiar with its behavior these days - but it should get you started.

• Don't upload user content to anywhere within the webroot. If the user can't provide a URL that maps to the uploaded file, the server won't try to execute it. (This does usually require providing a way for users to refer to the file in some other way, which opens the risk of arbitrary file reads from outside the webroot, though; that's also very bad.)
• Disable execution of files from the location where the user content is uploaded to.
• Don't allow file extensions that the server will recognize as server-side code. You can find a list of these in IIS's list of known file types. Ideally, you should disallow all extensions except for the specific ones you want to allow (use an allow-list, rather than a block-list). If you add (or modify) the extension to uploaded files yourself based on the client-supplied content-type value, be sure to disallow all content-types that would lead to dangerous extensions.
• Disable execution of file types you don't need. This isn't a perfect solution - you probably still need to have at least one type of server-executable file - but you can reduce the attack surface somewhat.
• Disable execution of the uploaded files by removing the "Execute" bit from the file ACL. This may or may not be effective for different file types - it depends how they are executed, as an interpreter might not check that access control flag - but it probably won't hurt, anyhow.

Solved by user53333 (40,283 )
Aug 10, 2022 at 11:14