Is it possible to store encrypted connection string so it can be used from server-side vbscript?
Was there an equivalent of web.config in 'the good old days'?
As I dust off the ol' memory banks...
I recall that in classic ASP systems, we would put the connection string (and most other config settings) in the Windows registry, in a custom registry key for the web app. We'd use a COM DLL to read the settings.
You can encrypt the connection string that is stored in the registry, but you will have to roll your own encryption/decryption.
So the answer is yes, it is definitely possible, but there is no easy tooling built into the framework to encrypt/decrypt on the fly, you have to do it yourself.
.Net has all the encryption and decryption code built in so the easiest way to encrypt the string is to use the .Net encryption/decryption functions. Create a .Net component that does the decription and a COM callable wrapper for it which should register it. Then call it from your ASP page.
Related
Whenever any application(browser, thick client application) is requesting to generate an AES key, I would like to supply a static key to that application.
Is there any way to do this in Linux or windows?
There is not an universal way of generating AES keys that applications needs to adhere to.
Forcing a static key on an arbitrary application ought to be hard/impossible if the application is secure - and would be a case by case activity.
I work on an app that is scanned by the Burp tool before the code is released to production. The recent scan has resulted in OS Injection attack vulnerabilities.
In doing research the only examples of OS injection attacks I saw were for unix, java, php apps.
Are these attacks possible against an ASP.NET (MVC) application? If so, how do you mitigate this risk? Does ASP.NET (and/or MVC) itself prevent OS Injection attacks?
The framework is not vulnerable to OS injection attacks itself. It is the code that you write with this framework that can be vulnerable. For example if you have a controller action that executes a command that is passed as parameter from the outside your application immediately becomes vulnerable. Consider this example:
public ActionResult Index(string fileName, string arguments)
{
Process.Start(fileName, arguments).WaitForExit();
return View();
}
So basically no matter what framework or programming language you are using for developing your application you should never trust user input and perform proper sanitation before accepting it.
OS Injection is defined by the OWASP Foundation as follows:
Operating system commands Calling external applications from your application.
[...]
What we should be looking for are relationships between the application and the operating system. The application utilising functions of the underlying operating system.
In java using the Runtime object, java.lang.Runtime does this. In .NET calls such as System.Diagnostics.Process.Start are used to call underlying OS functions. In PHP we may look for calls such as exec() or passthru().
But of course your research already showed that.
Are these attacks possible against an ASP.NET/MVC application?
So, yes, anywhere you use, or any library you use uses System.Diagnostics.Process.Start(), either directly or indirectly supplied with user input, you're at risk.
If so, how do you mitigate this risk?
As usual, by properly escaping and sanitizing user input where necessary. This includes not only query string or route parameters, but also cookies, HTTP headers and whatnot.
I'm reading the OWIN 1.0 spec at http://owin.org/spec/owin-1.0.0.html and just can't wrap my head around how it works. I've downloaded Katana source, but that's huge and didn't help any. I'm familiar with the somewhat standard way of having a project/assembly with interfaces only, which allows to integrate two projects without direct regencies. But I can't understand how the web server will call into the web app with only Func<> and Action<> definitions.
OWIN boils down to two things:
1) an "environment" dictionary
2) a method that processes requests and sends responses.
For #1, this is just a property bag that gives you access to the request headers, request stream, response headers, response stream and server data. Think of this as your HttpContext for ASP.NET or HttpListenerContext for System.Net.HttpListener. In fact, in more recent builds of Katana (https://katanaproject.codeplex.com/, which is an open source implementation from the ASP.NET team, there have been improvements (more to come) to simplify this down to an easier to use object model, including an OwinRequest, OwinResponse, and IOwinContext.
For #2, this is often called the "AppFunc" and the signature is:
using AppFunc = Func<IDictionary<string, object>, Task>;
This signature is used for "Middleware" that is in a pipeline of request handlers or it can be the end application which is generating HTML, is a WebAPI, etc.
In Katana, there is a class you can inherit from that simplifies this signature to consume the IOwinContext I mentioned previously. Take at look at OwinMiddlware
You can also read this article which gives an overview of the Katana/OWIN effort: http://www.asp.net/aspnet/overview/owin-and-katana/an-overview-of-project-katana
OWIN just defines how the web server and web application will talk to each other. Your application must implement one side of this contact, the other side which connects to the web server must be provided by installing a NuGet package specific to the web server. There is one for IIS, one for self hosting (stand alone application) etc.
Other than database connection strings, by default are there any sensitive values populated in web.config by Visual Studio 2008? What are PublicKeyToken values are these sensitive values? Would it be bad security practice to publish web.config files with connection strings redacted?
PublicKeyToken are not sensitive.
As to redacting connection strings, who are you afraid of? Who's going to get hold of your web.config?
Public key tokens are used in association with private key tokens to sign .NET assemblies. The public key tokens are not sensitive. As for connection strings, it is common practice to encrypt the connection string and keep them in the web.config.
I modified the ASP.NET login control to also allow specifying UserRole ('Employee' or 'Volunteer'). Users are authenticated via a call to a webservice written by our client, which accepts username/password/role and returns true or false.
If role is 'Employee' it represents an active directory user. The application should impersonate the user with the given username/password.
If role is 'Volunteer' the application should run under a set Windows account whose username/password are known in advance (i.e. hard-coded in web.config file).
The server runs on Windows Server 2003. I am confused by the myriad of configuration choices and trying to understand my options;
Is it possible to have multiple scenarios as described?
Should I specify the impersonation programmatically or can it be done through the config file? If so, is it required to use LogonUser or WindowsIdentity?
What config file setup should I use? (i.e. Forms authentication, impersonate=true, etc..)
Thank you in advance.
Because the decision about which identity to impersonate is based on run-time data, you'll likely have to deal with impersonation programmatically.
I use a combination of interop and WindowsIdentity to handle impersonation. The steps I follow are:
Log on using the interop LogonUserA(), which fills a handle to an IntPtr (token).
Duplicate the token with the interop DuplicateToken().
Create a new windows identity, a la: var identity = new WindowsIdentity(tokenDuplicate);.
Create an impersonation context via: var context = identity.Impersonate();
Close both tokens with the interop CloseHandle()
When finished impersonating, undo the impersonation context via: context.Undo();
I keep a disposable class around to handle the details. Steps 1-5 occur in a constructor, and step 6 occurs in the dispose routine. This helps ensure that I properly revert even in the face of an exception.
With this approach, since you are passing credentials via a service method, the web.config authentication scheme is not entirely forced. If, however, you are using integrated Windows auth, you could programmatically impersonate the current user from HttpContext.Current.User.Identity.Impersonate(), without passing credentials in a service method.
On an aside, and you may already know, PInvoke.net is a valuable resource for configuring signatures for interop methods.