3

Visual studio: 2019 .NET Core: 2.2 Language: C#

Issue: I have created .NET Core API with GET endpoint decorated by attribute routing which accepts string parameter and here I am getting 404.7 response for some keywords e.g. ".master", ".cs", ".mdf" etc.

Not Working code:

Accessing path: http://baseUrl/api/test/test.master

[HttpGet("{userName}")] 
public ActionResult<string> Get(string userName) 
{ 
    return userName; 
}

Working code:

Accepting userName as a query string is working perfectly. Is it best practice?

Accessing path: http://baseUrl/api/test?userName=test.master

[HttpGet] 
public ActionResult<string> Get(string userName) 
{ 
    return userName; 
}

I know that these are the file extensions which are not allowed to access as resources. But is there any other way to make it work other than accepting a parameter as a query string. Can I make it work with attribute routing?

I tried to repro this issue in .NET Framework as well and its failing with the same error.

TylerH
  • 20,799
  • 66
  • 75
  • 101
Mahesh More
  • 821
  • 1
  • 8
  • 23
  • Your second example URL is not using a query string? – Nkosi Sep 13 '19 at 15:32
  • 1
    Check the following https://learn.microsoft.com/en-us/aspnet/core/fundamentals/routing?view=aspnetcore-2.2#route-template-reference – Nkosi Sep 13 '19 at 15:35
  • 2
    If I saw succesfull requests for stuff that ended in `.mdf` or `.cs` in the web server logs I'd freak out and run to check whether it was breached. Production web servers like IIS decline requests for specific file types before they even forward the request to the application. So do firewalls. How do you host your web app and why are such paths allowed or expected in the first place? – Panagiotis Kanavos Sep 13 '19 at 15:57
  • 1
    Possible duplicate of [What file extensions are blocked by default in IIS](https://stackoverflow.com/questions/12828476/what-file-extensions-are-blocked-by-default-in-iis) – Panagiotis Kanavos Sep 13 '19 at 16:03
  • 1
    How do you host your application? IIS definitely blocks those extensions. If you really want to allow them (*why?*) you'll have to configure the server itself. – Panagiotis Kanavos Sep 13 '19 at 16:04
  • Also found this for the `404.7` HTTP Status code https://stackoverflow.com/questions/13455939/http-error-404-7-not-found-the-request-filtering-module-is-configured-to-deny – Nkosi Sep 13 '19 at 16:07
  • @Nkosi Second point is accepting a parameter as query string. I have corrected my typo mistake. Thanks for the quick reply. – Mahesh More Sep 14 '19 at 06:40
  • @PanagiotisKanavos I use IIS server to host web api. Actually I really don't want to add those extensions in my IIS allowed extensions but my endpoint it's returning data by accepting userName as parameter and user can choose any name whatever he wants. Recently we found an issue on production where some users are getting 404.7 and after digging into it found that those user's name ending with these extensions so I trying to figure out the solution instead of blindly changing the endpoint which is running on prod. – Mahesh More Sep 14 '19 at 06:48
  • @MaheshMore are you sure it's real users instead of pranksters (at best)? Who's going to use a username ending in `.mdf` or `.cs`? If you want to support such names without compromising security you'll have to change the API, eg to accept POST for that operation, use a user ID/token instead of the username (allowing the name exposes you to account sniffing after all), get the username from a header etc – Panagiotis Kanavos Sep 16 '19 at 07:46
  • @MaheshMore in any case you shouldn't allow `http` or unauthenticated/unauthorized calls to such an API. – Panagiotis Kanavos Sep 16 '19 at 07:47
  • @PanagiotisKanavos Actual user names are not ending with `.mdf` or `.cs` but there are few actual users who're names are ending with .master and which was causing issue and `test.master` is the valid name because that user has some admin permission and they want to differentiate it. And yes I don't need to make that endpoint POST as I am able to fix that issue by accepting the userName parameter from query string. Thanks for your help. – Mahesh More Sep 17 '19 at 06:34

0 Answers0