I was recently handed over the support of an already built logic app that accepts some json and performs some validations and send it to some endpoint. There's nothing wrong with the Logic app functionality, it works completely fine.
The problem is, penetration testing was done on the app and it presented us with security concern of X-aspnet-Version:4.0.30319.
I found this post here and it says:
That is not the actual .NET framework version. It is the version of
the CLR
My questions are, can the above quote be considered as the valid reference to address the issue? If not, can the logic app be somehow upgraded to use aspnet version 4.5 or higher?
And if I can change the version, can this have impacts on my current logic app's behavior?
Note: The app was made entirely through logic app designer and not a
single chunk of coding was implemented
No, the problem is with the test tool, not Logic Apps.
Just because it infers a problem doesn't mean there is a problem.
Explain to you 'security' testers that this is an Azure Logic App, not Windows/IIS. If you tell us the exact 'security concern' we can explain why it's irrelevant.
X-AspNet-Version: specifies the version of ASP.NET being used. Note that this value returns the core framework version. Typical examples include 1.1.4322, 2.0.50727 and 4.0.30319.
ASP.NET web sites send the ASP.NET version information in the web server HTTP Response Header as X-AspNet-Version value automatically to the client. So, you could not change it in logic app.
Related
I'm having issues with a SignalR project I'm currently working on. I'm trying to build a server using .Net Core, and a client using traditional .Net (framework 4.6.1). However the server and client don't seem to be compatible.
The last issue I've run into is a StatusCode: 405, ReasonPhrase: 'Method Not Allowed'. I found an answer on GitHub that states that there are many breaking changes between versions.
Looking at the NuGet package versions available, I get even more confused. for the .Net Core server I'm using 1.0.0-preview1-final. There's also a 1.0.0-alpha2-final available, but I have no clue if 'alpha' is newer or older than 'preview'.
On the client side I was using version 2.2.2, and there's a whole range of versions to choose from, I tried the oldest and latest, but both versions give me the same "method not allowed" error.
The error is on the client side, on the server side, my breakpoints are not even hit, so it could be an Owin/iis issue as well.
Is there any chart out there that can map SignalR clients and server version compatability? I guess that would be a great step moving forward.
You can't mix the .NET Core 1.x with the older client (1.x or 2.x). You will need to decide which is the best option for you but you need to implement the same compatible version across CLIENT and SERVER.
Check the link for more details but essentially:
What’s Changed?
We added a number of new features to SignalR for ASP.NET Core but we
also decided to remove support for some of the existing features or
change how they work. One of the consequences of this is that SignalR
for ASP.NET Core is not compatible with previous versions of SignalR.
This means that you cannot use the old server with the new clients or the old clients with the new server.
Check the services are injected, possible some is not yet injected in the service container.
When add the signalR service you can enable detailed errors to know what is happening.
builder.Services.AddSignalR(o=>
{
o.EnableDetailedErrors = true;
});
I am currently prototyping OAuth2 authorization server options, and want to use IdentityServer4.
But it would require alot of work to put an ASP.NET Core App on top of the current .NET Framework stack (v4.5) that I am working on. This stack also relies heavily on the IoC container "Spring", so thats another issue.
I have tried looking at ASOS, but I run in to similar problems.
Isn't there a proper OAuth2 authorization server framework made for good old ASP.NET that is still being maintained?
Maybe some of you have some input to how you solved a similar situation?
I have an ASP.NET C# WebForms application built using the following:
Mono
Apache
PostgreSql
NPGSQL
OS Linux
Because those platforms are used a custom user/role management system was written for the application login.
One of the features we need is to redirect a visitor if they try to access a page if they have not logged in to the application.
I have been researching the Forms Authentication
As expected almost everything I find is using the ASP.NET built-in tools that are prominently used in Windows environments. (Which is not necessarily the case I have in my application)
My question is can Forms Authentication be used in my scenario? Or is there another approach I could take to accomplish the same result.
PLEASE NOTE: Before marking this as a possible duplicate question notice my environment is not the normal ASP.NET stack.
Using [Sessions] is my solution.
This StackoverFlow question gives a really good explanation.
I am looking to build a small ASP.NET application using WebAPI and a html front-end, on .NET 4.0. I need to support authentication, authorization, data access (EF), logging / tracing. It can be an intranet/internet application, so it should support load balancing / clustering.
I am sure if I just go with ASP.NET and IIS I will get all these features. However I like OWINs idea of independent async modules and its goal of being high performance hosting environment. But how much of OWIN/ KATANA is matured and what functionalities are still missing/buggy?
The whole idea of Owin/Katana is to build a light weight server with only the function we need. Your question is better to be "What are things missing in Owin/Katana, which is available in IIS?"
The short answer is, IIS is a full-blown server. Many of the websites we developed only requires a small fraction of all its functions. It is like shipping a bag of grocery using an 18 wheeler.
If you look at Katana, all functions are modular. Say, if I need WebAPI, I can add in that function. When CORS is needed, I will extend appBuilder to the related functions. So in a sense, we have a fully customizable server. Since all functions can be added in, I would say nothing is missing.
Another thing to mention is that an installation of IIS would require you to run a Windows Server. If you are on a Mac or not a server version of Windows, you can host your website on Katana or any other OWIN implementation.
We are planning on replacing a legacy "server" app (a Windows form app with, although it does not really need it, a GUI representation (showing status messages)) with a simplified service of some sort. The server/service responds to requests for data and sends said data. Will a legacy (.NET CF 1.0) app, which cannot be updated to a newer technology (because the handheld devices on which they run don't have room for the more recent/larger .NET Compact Framework runtime) be able to access "newfangled" services such as an asp.net RESTful web service? If not, what are some other options? Or, if there are better options even with that being feasible, what might y'all suggest?
No, the older .Net "Service references" don't understand newer formats/protocols.
But, at the end of the day, it's all just a bunch of auto-generated code mapping "objects" to XML.
SUGGESTION:
Just parse the XML directly.
If in doubt, play with your target service using SoapUI
Unless you've got a really complicated schema, that's probably the easiest to program - and most memory efficient - solution.
IMHO...