Does aspnetcore have a galaxy-sized security hole with controllers or am I missing something?

Question

Checking a colleague's library I saw two ways he described of working with his new StatusController. Either override a GetStatus method to return more specific data or simple let the default implementation work. Okay, so I do the override as I'm not yet sure what he means about the latter and it works. Another colleague asks if I've looked at the latter and I reply

"well no, 'cos it won't work if I just reference the project/nuget and not tell the framework about it in some way"

"well try it"

"ok, but I'll be staggered if it works".

I am now staggered.

I then went on to try this by an indirect reference and it still worked. I'm deliberately not showing any code because it is simply the boiler plate controller code from a Visual Studio MVC web app or web API and you can literally knock this out in minutes. But let me give you an example.

Let's say I'm writing an application for www.electioncomission.gov.us and I want to do some special string parsing on a particular file format and there's a nuget package that can help me, let's call that VotingMachineFormatParser and unbeknown to me it uses a package called Tviker (Russian for Tweaker), don't know why but they found it useful. Tviker has inside it a controller class called GosudarstvennoyeVmeshatelStvoController which does something - it means State Interference.

If you now go to www.electioncomission.gov.us/gosudarstvennoyevmeshatelstvo that something code is now running, doing whatever.

I thought you were supposed to use the concept of Application Parts to pull a controller in from another assembly. Please, what am I missing? Surely this can't be the hole I think it is?

Edit: I've not included any code as that's the point, you don't need any code. I forgot to say that this is behaviour that is "new" to .Net Core 3.1+ It did NOT work that way previously. The only way to pull in a controller from another assembly was via ApplicationParts.

It's easy to test this without doing more than renaming two boiler-plate classes.

Let VStudio create a boiler-plate WebAPI in .NetCore 5 and select the OpenAPI check box. Do this in two separate folders but for one of them rename the WeatherForecastController to ToldYouController and rename (with refactoring) the WeatherForecast class to say WeatherForecast1.

Reference the project with ToldYouController in the first project, run and you'll see both controllers in the Swagger and you did literally NOTHING more than reference to make that happen! You can try this by having an indirect reference and it'll do the same.

Answer 1

.NET Core 3.x has automatic application part registration for assemblies that reference MVC.

From Andrew Locks blog:

Note that in ASP.NET Core 3.x, when you compile an assembly that references ASP.NET Core, an assembly attribute is added to the output, [ApplicationPart]. ASP.NET Core 3.x apps look for this attribute on referenced assemblies and registers them as application parts automatically.

About ApplicationPartAttribute on the ASP.NET Core documentation:

Specifies an assembly to be added as an ApplicationPart.

In the ordinary case, MVC will generate ApplicationPartAttribute instances on the entry assembly for each dependency that references MVC. Each of these assemblies is treated as an ApplicationPart.

---

Since GosudarstvennoyeVmeshatelStvoController is a Controller, its assembly will have a reference to MVC and therefore be registered as an application part.