IIS 7 and Above
IIS 8.5 .well-known 404 issue ("." dot in url issue)
Last post Mar 24, 2020 08:56 AM by david.meyer
Mar 05, 2020 07:21 AM|david.meyer|LINK
Hello IIS support team,
I am touching on a known issue regarding "." (dot) characters in the URL which causes a 404, more specifically with the .well-known for google deep links.
The main issue is that when I create a virtual folder called ".well-known" (on the root or any other location of the site) and link it to the physical path I am not able to access the virtual folder path via the URL.
Please take note of the following information below:
1. I am able to access the physical "well-known" folder directly in the URL with folder browsing enabled.
2. I am able to access ANY virtual directory
WITHOUT the "." (dot) in the URL.
3. I have tested with the following modifications to the web.config:
<modules runAllManagedModulesForAllRequests="true" />
<validation validateIntegratedModeConfiguration="false" />
<requestFiltering allowDoubleEscaping="true" />
<httpRuntime relaxedUrlToFileSystemMapping="true" />
4. I have attempted to convert the folder to an application and copy the URL scan ini into the "app" but it does not seem to work either.
5. The only working solution I have found is to modify the "AllowDotInPath=0" to "AllowDotInPath=1" in the URLscan file, this however is considered as a security risk and will not be allowed on the particular site we are hosting.
If you could please advise on a solution or work around that possibly does not involve hosting another site on the server.
Mar 05, 2020 01:01 PM|Rovastar|LINK
Mar 05, 2020 01:05 PM|Rovastar|LINK
Mar 06, 2020 03:26 AM|Yuk Ding|LINK
You could enable failed request tracing to narrow down the module that return 404 error. Now that you can fix this by setting AllowDotInPath, it should be a urlscan issue.
Could you provide an example about how your URL looks like?
URlscan should be a legacy extension that haven't been updated for about ten years. AllowDotInPath should only block the request with multiple ".". Are you sending a request with multiple "."? If so, maybe you'd better modify your URL format to fix this.
Mar 06, 2020 08:58 AM|david.meyer|LINK
You are correct, it is the URLscan.ini in the system32 folder. I had spent some time identifying this before posting.
You mention this is a legacy product? According to my research this was initially designed to add an extra layer of security to avoid mainly SQL injection attacks, is this correct?
I had 100% confirmed it was the URL scan blocking the URL access.
We are using URL scan for a most of our hosted products, this is used as an extra layer of security to stop possible attacks, directory traversal or unintentional file access on the sites.
as for point 5, yes, we want to restrict the . in the URL but was hoping for some work around method in a sub managed web.config file specifically for that folder on the site.
The URL is basically "domainname.com/.well-known/file.ext"
We are not attempting to use multiple .. in the path.
After much testing I have however managed to create a separate site on the same server and registered a modified URLscan.ini in the ISAPI config for that respective site, the site obviously has a different port too, the downside is that we now have to reserve
another public IP pointing to the other site specifically for the .well-known google deep links access.
Basically I was hoping to set a exclusion via the web.config but that didn't work, so the only other option is to have another site with the custom bound URLScan.ini and DLL, this does work and is an acceptable workaround but again I was hoping there was
another possible easier solution.
Mar 12, 2020 09:33 AM|Yuk Ding|LINK
I think you can create a rewrite rule to block URL with "\.\." so that you can enable allowDoubleEscaping="true" and don't need to be afraid of multiple dot.
Mar 24, 2020 08:56 AM|david.meyer|LINK
Hey Yuk Ding,
I will take another look into the rewrite you have mentioned above and give it a go.
For the concern of deployment time and time saving we have gone with the original comment I had given above.
We will just create a new site with the custom bound URLscan config and take it from there.
Thanks for the support guys.