I have a question regarding Blazor Web Assembly DLL Downloading and security. It is known that there are tools that can reverse engineer a DLL to get an idea on how the source code functions. Wouldn't Blazor Wasm model be less secure, since all a potential attacker would need to do is access a Blazor Wasm site for the first time, and pull the DLLs from their local computer to then later analyze them; they wouldn't even need to login? I would think Blazor Server would be a better option, slower yes, but safer. Or is assumed that Blazor Wasm is only recommended for sites who do not have high security concerns?
Related
do you know how I can change the
_framework directory,
for security? Why does this directory show security information?
I have one solution
client
server
shared
I have 127.0.0.1/site/_framework/blazor.boot.json
and show information private
enter image description here
Help me, please
In short, show the sensitive information about assembly and others is expected behavior.
From the design of Blazor WASM, this is unavoidable. This is the same as static files such as Javascript, confidential information should not be kept, but we can obfuscate it in a certain way. But I don't think it is necessary.
Regarding Blazor WASM usage recommendations and safety, this thread will inspire you.
I am supporting an ancient web application which still uses some VB6 for the data sources behind ASP classic web pages, running on IIS.
Historically we have always loaded the VB6 COM components into COM+, which was considered the best way to make them available to IIS services. I cannot find any reliable documentation on this now - sure I have the management documentation telling me HOW but I'm not sure about WHY, what is best practice, what is required or optional etc.
Has anything changed in recent years? Can we just register the VB6 DLLs and let IIS manage how they are used, or do they need to be put in COM+ for proper threading or pooling etc?
We have 5 IIS servers in a farm, with up to 3000 users at a time. The VB6 data methods are accessing a number of SQL Server databases via ADODB. The DLLs are installed and registered on each server, we don't use DCOM, but load them into a number of application groups in COM+. Servers are Windows Server 2012 R2 with IIS 8.5.
Does anyone know of any article/publication on the security architecture of Metro app?
For example, can the metro app call an external service. If it can,
under what condition. Will it prompt the user first? And if so will
they be able to change their restriction later and how?
Cross domain scripting in a website is usually considered a big
no-no. But if I were to turn the same code into a metro app (since
presumably they're both written in Html 5 + js), does it mean I can
make ajax calls to any server irrespective of their domain? Is it
even possible to port a website into an app? If so how easy is that?
What about accessing local file system? Or does it have to go
through the contracts to do so?
And this is kind of related but if I were to write a website (not an
app). And the site was opened using Metro IE10, can it subscribe
into the metro specific js events? I guess I'm trying to figure out
how to save cost by doing as little development as possible. I
prefer a website that can target multiple platforms and only target
specific platform for the features that absolutely require it - also
not to thrilled with the idea of having to go through microsoft in
order to publish my app.
Any help appreciated.
Metro applications can call into web services located on other machines, but their ability to interact with the local machine is severely limited.
Similarly, accessing arbitrary parts of the local filesystem is not permitted. If your application has the documents (or music or photos) library permission, it can access the files in those libraries.
When I create an Azure ASP.NET application, by default .NET trust level is Full trust. I always change it to Windows Azure partial trust which is similar to ASP.NET's medium trust level.
You can do it either by using GUI when you select Properties on the Role or by setting enableNativeCodeExecution to false in the definition file (.csdef) just like below:
<WebRole name="ServiceRuntimeWebsite" enableNativeCodeExecution="false">
As a security conscious developer I want by default to run my application in partial trust mode that provides a higher level of security. If I need to use something like Reflection or P/Invoke, as a developer I want to make the decision to lower that trust level by myself.
I'm sure there's a reason why Microsoft decided to use Full trust as a default .NET trust level, I just fail to see it. If you know the reason, or you think you know it, please let me know.
Full trust is not only required for P/Invoke for .NET reflection as well. As a bottom line result, nearly all moderately sized apps need full trust because nearly all widespread libraries need it too (NHibernate for example). Actually, I have been asking from the exact opposite question on the Azure forums too.
The issue of full or partial trust pertains to the environment in which your application runs. The more control and/or "ownership" of the environment and assemblies you have, the more acceptable it is to have full-trust settings.
For example, if you create an Azure web site (July 2012 capability) and, mimicking wordpress or Umbraco, your web site allows arbitrary assembly plugins to be downloaded and installed, then it is important to have a partially-trusted environment. It is possible that one of the plugins downloaded and executed, which you don't control or own, contains malware. Not only does this impact the security and stability of your web site, but some may argue it impacts other (multi-tenant) hosted web-sites which have no relation to yours.
Certainly your web site will rely on 3rd party libraries, such as Log4Net or StructureMap, but those are extremely well-known and vetted libraries that are not in question regarding their security impact. Ergo, if you are running an Azure web-role (a much less "multi-tenant" type affair) and you are merely running such "trusted" 3rd party apps, then there really is not an issue with running as full-trust.
Yes, unfortunately it is still very hard (if not impossible) to write large .NET apps that run in partial trust.
We need much better technology and tools (like CAS.NET)
Because Medium Trust is now officially obsolete. If you start a new web project in Visual Studio, it already requires Full Trust (and doesn't work partial trust). Microsoft says: Do not depend on Medium Trust, instead, use Full Trust, and isolate untrusted applications in separate application pools.
Sources:
Stackoverflow answer: Quoted response ASP.NET team
Microsoft: ASP.NET Partial Trust does not guarantee application isolation
Microsoft: ASP.NET web development best practices
We have developed a large number of websites using ASP (jscript flavour), talking to the underlying intelligence layer (written in Delphi) through COM. These websites are running on IIS (5 and 6).
Over the years this ASP layer has grown into something quite heavy (no business logic, but lots of controller/scenario/view/ajax/etc handling), and we'd like to do a bit of performance tuning on it. According to the creator, AQTime (we have the latest version) can be used for this purpose (profiling both the serverside script and the underlying com objects in one go), but I simply can't figure out how to get it to work.
The help files explain how to profile COM dll's, ISAPI dll's and even client-side scripting, but not a word on how to profile the server-side script running on the ASP pages. Can't select .asp files as a "profiling module". Google is not helpful either.
Any word of advice on how to accomplish this? Alternative suggestions for profiling classic asp pages is welcome, too.
Well, as it turns out, this isn't possible (according to Official Support). Of the tree layers in our application,
Delphi code running on the server
ASP code (jscript) running on the server
Client-side jscript running on the client (ajax, etc)
AQTime can only profile (1) and (3). Although it can perfectly well profile windows scripting host .js files on the server, it will not profile .asp code. Which I was really hoping it would, seeing how both are executed through the same jscript.dll.