CODEWITHSUNDEEP
blazorblazor-server-side
user4779
user4779

Reputation: 817

Security question about C# code on Blazor server

From what I understand, all C# code on Blazor Server occurs on the server, not the client. Now say for example I have a page login.Razor, that accepts a client inputted username and password and binds these to corresponding variables in the @code section, call them "username" and "pass".

If I authenticate the user based upon these two variables, then set two new variables "username2" and "pass2" with the same values if and only if the authentication passes, can I trust that these two variables cannot be tampered by the client? In other words, I'll be using "username2" throughout the rest of the app to display the users username, and I can trust that the only way it could have been set was via a successful authentication of the original "username" variable?

I know if any of the code was client side this wouldn't be the case, the client could set "username2" directly themselves, but if it's all server side, then this shouldn't be possible? And is this the case even if all the logic is still stored in the same client-facing .razor files? I'm just trying to get my head around conceptually that even in .razor files such variables cannot be manipulated in any way by the client other than where I allow it (eg: binding the original "username" variable to an HTML input element), and I can trust this to the point of security as posited in my scenario?

Upvotes: 0

Views: 279

Answers (1)

Arani
Arani

Reputation: 1243

The username2 is held in the server's memory in a circuit. So, to change the username2 value, the hacker must has access to the server's RAM, and you should not worry about this.

Examples of user state held in a circuit include:

  • The hierarchy of component instances and their most recent render output in the rendered UI.
  • The values of fields and properties in component instances.

For transient data that the user is actively creating, a commonly used storage location is the browser's localStorage and sessionStorage collections:

  • localStorage is scoped to the browser's window. If the user reloads the page or closes and re-opens the browser, the state persists. If the user opens multiple browser tabs, the state is shared across the tabs. Data persists in localStorage until explicitly cleared.
  • sessionStorage is scoped to the browser tab. If the user reloads the tab, the state persists. If the user closes the tab or the browser, the state is lost. If the user opens multiple browser tabs, each tab has its own independent version of the data.

Third-party NuGet packages provide APIs for working with localStorage and sessionStorage. It's worth considering choosing a package that transparently uses ASP.NET Core Data Protection. Data Protection encrypts stored data and reduces the potential risk of tampering with stored data.

For more info, you can refer to ASP.NET Core Blazor state management and also Browser storage (localStorage/sessionStorage)

Upvotes: 2

Related Questions