search

posva / unplugin-vue-router

Next Generation file based typed routing for Vue Router
https://uvr.esm.is
MIT License
1.44k stars 66 forks source link

IIS & UrlScan Issues #321

Open blowsie opened 4 months ago

blowsie commented 4 months ago

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 commented 4 months ago

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