Aspnetcore: Blazor Release compile exposing the path of developer machine.

[ghost]

I was in travel last week and I see a tweet replied by steve about clock demo. I talk with that person on FB and chat with him if his demo is published under Debug.

We both realize the code is compiled under Release and later on I open the dll and able to see the path of his developer machine.

I think the path can be either relative but not absolute or should not expose the machine path of developer in first place, This could be a lead to some hack.

I was thinking for another scenario last week, If someone made a blazor app and user use it, user can easily figure out some endpoint which never should be exposed in first place.

For example Facebook.com have a secret admin panel at admin.facebook.com user will never know the ajax endpoint since they are not seeing anything without login, in Blazor I can figure out what kind of html admin.faceook.com have ( I am saying that admin.facebook.com is part of same app or I should better say facebook.com/admin) and what ajax endpoint they might have. Is this not a security issues.

I am not a security expert but this thing make me worried (I am really new to WASM). Is this thing can lead to some trouble, for a common person who didn't prepare himself for DDOS, exposing ajax endpoint could cause a lot of trouble.

From this thread 2 thing need to be checked.

1. Exposing the develop machine path.
2. Security for exposing ajax Endpoint (Someone can DDOS it by figure out the endpoint easily).
3. Are we going to have any security for point 2 or does it already solved by any kind of thing implemented here.

Thanks

cc @Lupusa87 @SteveSandersonMS

[SteveSandersonMS]

Exposing the develop machine path.

If you can provide minimal repro steps, we'd definitely be happy to figure out whether this is avoidable. By "minimal repro steps" I mean, having created a fresh new project using the Blazor project template, what's the smallest set of code changes or publishing steps that result in other people on the internet being able to observe this?

Security for exposing ajax Endpoint

I don't think that's got anything to do with Blazor. It's just a feature of all client-side web apps that the end user can observe their HTTP traffic and inspect all the code that was delivered to the browser. It wouldn't be any different with another SPA framework. Developers need a security model that doesn't rely on this information being secret (not just with Blazor, but with all client-side apps).

[csnewman]

I imagine you are more talking about security by obscurity for the admin endpoints etc? Then lazy loading as tracked by aspnet/AspNetCore#5465 would solve this. The dll containing information about the admin panel for example would not be loaded until the user is authorised as an admin. However, this isn't much of a security guarantee and shouldn't be relied on as a way of protecting your admin endpoints.

[ghost]

I haven't the linked anymore , @SteveSandersonMS It's from your twitter feed, the one tweet you like last weekend called "Blazor Clock" I also cc the person who wrote the code in my post. When I open demo it's download the dll and I open that dll I see the machine related code, I confirm with the person that he is using release builds. I will check tonight my Facebook and update you the link.

[SteveSandersonMS]

Rather than sending a link, could you supply info on how to reproduce the issue? Otherwise we don't know whether it was something unusual that the developer did, and would not really be in a position to investigate.

[ghost]

@SteveSandersonMS yes, Please give me sometime, I am in Office, I will build demo from my home

[Lupusa87]

Hello. It was my project.
Thank you for mention.
I have regular blazor app and blazor lib published on azure.
I downloaded publish profile for my free app service, imported in VS and just published project.
Sure publish means build release version, I checked and after publish there appears release sub folder in bin.
Only one thing I changed in both projects config was:

<PropertyGroup>
<UseRazorBuildServer>false</UseRazorBuildServer>
<PropertyGroup>

because build was very slow and when I did research I found this advice with worked for me.
But I don't think it matters for this issue.

I don't shared my project on github yet, because I'm ashamed to show you my code before good refactoring.

I am not good in security field and I can't say nothing helpful, I'm ready to do what else will requested from me.

[SteveSandersonMS]

I'll close this due to lack of info about where this path is being exposed.

If anyone is still affected and can supply repro info, please let us know!

[Lupusa87]

I published repo after my last comment.

This project was the reason of this issue.

@anirudhagupta can you provide more details please.

I don't know what else I can do.

[ghost]

@Lupusa87 sure,

I try to reproduce on my machine, I better find it in your online running demo.

I open the demo at latest chrome. please check the screenshot

cc @SteveSandersonMS

[SteveSandersonMS]

Thanks @anirudhagupta, that's helpful! Reopening for consideration.

[SteveSandersonMS]

On further consideration, this isn't specific to Blazor at all, but rather is an aspect of how .NET overall works. It does embed the absolute path to PDBs.

I understand that with Blazor, you're supplying the .dll files to clients in a way that you wouldn't with a server-only .NET app. But Blazor is not the only case where people distribute .NET assembly files to third parties. For example, there's also:

• Publishing NuGet packages to nuget.org
• Other .NET client application project types (WinForms, UWP, etc.)

In these cases you are also exposing the build server's paths to the public. For example, I just got the current version of Json.NET from NuGet, inspected Newtonsoft.Json.dll, and found this:

That file path isn't on my PC. It must be from the CI machine (or @JamesNK's laptop?) that built the package.

So I don't think it's any more of a concern for Blazor app publishers than it would be for, say, anyone publishing NuGet packages. If this really does concern you, there's probably some way to modify the generated assembly file, or you could raise this with the C# compiler team as something that could be changed.

cc @rynowak @danroth27 in case they have other opinions or ideas of how this could be changed.

[JamesNK]

From my laptop 😄

[chucker]

If this really does concern you, there's probably some way to modify the generated assembly file,

If I'm not mistaken, and a quick test with a Blazor release build appears to confirm this, you can simply configure this in your .csproj. In Visual Studio, in the project properties, Build, Advanced…, set Debugging information: to None. I can no longer find the .pdb path in the DLL.

This will do:

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
    <DebugType>none</DebugType>
    <DebugSymbols>false</DebugSymbols>
  </PropertyGroup>

Presumably, other DebugType settings will also be sufficient.