Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IIS & UrlScan Issues #321

Open
blowsie opened this issue Feb 22, 2024 · 1 comment
Open

IIS & UrlScan Issues #321

blowsie opened this issue Feb 22, 2024 · 1 comment
Labels
👍 contribution welcome others are welcome to implement/fix this

Comments

@blowsie
Copy link
Sponsor

blowsie commented Feb 22, 2024

IIS and I believe Azure use UrlScan by default.
The default settings break this plugins catch all routes when using File Based routing due to the file name generated containing multiple dots eg. ...all-fc33d227.js

IIS Log

2024-02-22 12:08:00 ::1 GET /Rejected-By-UrlScan ~/assets/...all-fc33d227.js 8087 - ::1 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/121.0.0.0+Safari/537.36+Edg/121.0.0.0 - 200 0 0 113

UrlScan

Below is from the UrlScan docs on the rule.

Rule Description
AllowDotInPath Allowed values are 0 or 1. The default value for AllowDotInPath is 1. If set to 1, UrlScan will allow requests that contain multiple instances of the dot (.) character in the URL. If set to 0, UrlScan will reject requests that contain multiple instances of the dot (.) character in the URL. Note: Because UrlScan operates at a level where IIS has not yet parsed the URL, it is not possible to determine in all cases whether a dot character denotes the extension or whether it is a part of the directory path or filename of the URL. For the purposes of extension analysis, UrlScan will always assume that an extension is the part of the URL beginning after the last dot in the string and ending at the first question mark or slash character after the dot or the end of the string. Setting AllowDotInPath to 0 defends against the case where an attacker uses path info to hide the true extension of the request (for example, something like "/path/TruePart.asp/FalsePart.htm"). Setting AllowDotInPath to 0 also causes UrlScan to deny any request that contains a dot in a directory or file name.

Note: Despite the above saying the default value here is 1, its actually 0, as confirmed by downloading the default template here


Its possible to create some workarounds for this in IIS by reinstalling another instance of the UrlScan dll and creating a new .ini file. But some of that is out of reach and complex for devs in userland.

I wonder it makes sense to create a workaround and document for this using extendRoutes() or similar ?

@posva
Copy link
Owner

posva commented Feb 22, 2024

Its possible to create some workarounds for this in IIS by reinstalling another instance of the UrlScan dll and creating a new .ini file. But some of that is out of reach and complex for devs in userland.

I don't know what you are talking about but it doesn't sound related to this project

This sounds like something worth putting in documentation. Better yet: fixed in vite to replace the dot in filenames? It looks like so many other things could break this

@posva posva added the 👍 contribution welcome others are welcome to implement/fix this label Feb 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
👍 contribution welcome others are welcome to implement/fix this
Projects
None yet
Development

No branches or pull requests

2 participants