2

I am going to frame this question using ASP.NET Core in mind since that is what I'm using, though my question is applicable to any scenario in which you have a client that makes requests to a server storing static files.

In the Microsoft docs on how to order middleware in an ASP.NET Core application, it specifies:

The static file middleware is called early in the pipeline so it can handle requests and short-circuit without going through the remaining components. The static file middleware provides no authorization checks. Any files served by it, including those under wwwroot, are publicly available. See Work with static files for an approach to secure static files.

I can see that it would be useful to bypass authentication

  1. in order to serve these files faster.

  2. because these static files (consisting mainly of HTML, CSS, JavaScript, and various types of image files) are in no way obfuscated on the client (for authenticated users, mind you).

However, there's a part of me that feels iffy about allowing all these files to be publicly available considering you have to be authenticated to be able to access the site. Since these static files contain a lot of the site's scripts and other resources, an unauthenticated user who would normally be able to not interact at all with the application can suddenly see a lot of how the front end works.

Is there any information contained in static files that would be useful for an attacker, such as a partially-complete picture of the front end codebase? My guess is no, because if that were the case then that implies that we trust all authenticated users to not use that information maliciously. Nevertheless, I wanted to make sure by asking here.

Drew
  • 123
  • 4
  • 3
    If you use a CDN you generally make static files public, so this isn't such a stretch. And [security by obscurity](https://en.m.wikipedia.org/wiki/Security_through_obscurity) is bad. – Neil Smithline Apr 07 '18 at 02:22
  • 4
    I can't point to proof positive that there is or isn't an issue with this. While I'm inclined to agree with @NeilSmithline, it's also worth noting that Security Misconfiguration is one of the OWASP Top 10. What you should be watching out for is files accidentally ending up in that directory that has no auth mechanism applied, that shouldn't be there. – nbering Apr 07 '18 at 04:58
  • Cheers for the responses -- makes sense. And good point about security by obscurity. – Drew Apr 09 '18 at 16:22

1 Answers1

2

There could be risk if any of the static content is customer data or PII for example things like personal photos , scanned in drivers licenses , medical images like xrays, completed user forms scanned in, etc.

If that data is only accessible behind a login screen normally but then you dump it into a publicly accessible CDN or AWS bucket for example now you have an issue of data leakage.

I would not be worried about HTML , CSS, or JavaScript as none of that should contain the keys to your kingdom anyways. That's all stuff you expect to be accessible client side and so you treat as public already.

neonprimetime security
  • 936
  • 4
  • 15