How can I protect an ASP Classic page with either HTTP AUTH (you must provide a username and password to service) or a randomly generated access key that will be included as one of the parameters of the HTTP POST using the variable name access_key.
Can anybody provide asp classic code in this regard?
Quick help will be appreciated...
PS: OrderGroove is a 3rd party service... neglect it.
Basic HTTP Authentication is something you can turn on by configuring your web server (probably IIS). There isn't any ASP classic code that can do it, as far as I know.
Another option is to store login information in a Session variable (i.e. Session("LoggedInUser")). On every page, just check to see if that variable is set, and if it's not, redirect them to a login page.
Note that both these methods will send username/password unencrypted, so you would probably want to get an SSL certificate for security reasons.
See also:
HTTP Authentication (Basic or Digest) in ASP Classic via IIS
https://web.archive.org/web/20211020140227/https://www.4guysfromrolla.com/webtech/020201-1.shtml
You can manipulate IIS metadata using the IIS:// protocol scheme with GetObject. Check out your adsutil.vbs file, usually in C:\Inetpub\AdminScripts
Furthermore you can implement Basic Auth with plain/text by getting/setting HTTP Headers along with a Base64 encoder/decoder. Although this is highly insecure.
Related
I want to create an internal website, preferably in asp.net, that uses ajax calls for performing all operations.
The requirements are that the site should use windows domain authentication (to act as a single-sign-on solution) for verifying which user is sending the request. What is the best way to accomplish this in a secure fashion? I am open to a solution using https or cookies or anything else feasible.
( I would prefer regular ajax using jquery since I havent used asp.net ajax but if that solves some issues more easily, then let me know)
The current way I am doing this (not through ajax) is disabling anonymous access in iis and then getting the logged in username from asp.net, but this requires the site to perform postbacks, etc which i want to avoid.
An Ajax request is not different from any other HTTP request when it comes to authentication.
Your user will most likely be authenticated when they access the index of your site. Any subsequent request, Ajax or not, will be authenticated. There is nothing special to do, and your jQuery code will look just like what it normally looks.
Windows authentication is checked on every request.
How this is checked depends which authentication method /provider is enabled and supported on the server (kerberos, ntlm, custom, etc)
Credentials are automatically sent over under certain rules (I believe intranet trusted for IE, I dont recall what else outside of that).
Firefox will prompt you if I recall every time.
Check out:
http://www.winserverkb.com/Uwe/Forum.aspx/iis-security/5707/IIS-6-0-Windows-Authentication-401-Every-Request
The important thing to note is the browser and server will take care of this and prompt the user when necessary.
Also to note is I highly highly suggest ALL traffic is under an SSL connection at this point to prevent sniffing and credential stealing/token stealking (such as is extremely easy for basic auth)
You can enable this protection inside of IIS and use all file permissions or you can control this in your web applications web.config by enabling windows authentication. How this is accomplished though depends on your server config (kerberos support, etc)
You should absolutely:
Use an https connection to transmit username and password
Authenticate on the server side, with asp.net
Leverage the asp.net session to as great an extent as possible.
If you're not familiar with ASP.Net ... well, consider this a good opportunity to learn :)
jQuery is great, but it's just a tool. In this case, it's probably not the best tool for this particular job.
IMHO...
Here's the situation, I've got a console application that needs to run once a day and make a few requests to pages that require authentication to view. The pages are hosted in a really basic ASP.Net Web Application.
So, I know that in order for the requests to go through successfully I have to authenticate with the server. So I've hooked up the console application to the ASP.Net Membership Provider I'm using for the web app and it successfully determines if a set of a credentials are valid. However, after calling Membership.ValidateUser() any requests I make just get the login screen. After doing some reading it seems that this is because I'm missing the important cookie information that persists my login or what-have-you.
I'm using a basic WebClient to make the requests and then reading/discarding the result.
So the meat of the question is this: Is there a simple way to validate the login information and hold on to it so that I can make the requests successfully, or is this the exact same case as the other two questions I found that require the WebClient to make a "manual" login request to the login.aspx page and try to hold on to the cookie from there?
The questions I'm referencing are:
Authenticating ASP.NET MVC user from a WPF application
and
Login to website and use cookie to get source for another page
With FormsAuthentication the webserver has to generate a Forms Authentication Ticket for you. The best (only?) way to do this is to log into the site, so I'd just log in like the other questions.
If the intent is to send data to the server and/or get data from the server, then the most logical architecture is probably to create a web service using either ASMX or WCF. Then configure the service to use a security token, such as a username token or a SAML token. This will make the client less likely to break when the server code changes its data model.
Otherwise, if you wish to use only a basic WebClient, then you will have to find a way to pass your credentials to the login page and retain the login cookie that is returned from the login request. Then, make sure that the login cookie is included on all subsequent requets, similar to the Stack Overflow question that you referenced, "Login to website and use cookie to get source for another page".
I have an ASP.NET web service that I can access via a windows program but now I want to secure the web service. I can secure the web service using forms authentication. How do you access the secured web service from a windows forms application?
Although this is not the right approach, tt is theoretically possible to use forms authentication in the manner you describe. This could be accomplished by either:
Using a WebRequest to send your requests in raw form to the web service. This will involve inspecting the response, extracting the relevant forms-authentication fields, and sending a response back which logs the user in. This will generate a cookie which you must send along with each subsequent response to the service
Generate the FormsAuhentication authentication cookie yourself. This is complex as it involves synchronising the machine key on the calling application, and artificially manipulating the headers being sent to the machine hosting the service.
Display the forms-authentication form for the user to log in to at the beginning of a session requiring interaction with the web-service. You can then harvest the generated cookie and present it to the service in HTTP headers as in option (2).
As you can see, these methods are highly complex, and are fundamentally a hack to use forms-authentication where it was never intended.
Microsoft intended us to use either Windows authentication, or SSL certs to secure access to ASP.NET web services. See HTTP Security and ASP.NET Web Services on MSDN.
If you are able to use WCF, then a few more options present themselves, including the ability to build a custom authentication mechanism into the SOAP, with some support from WCF.
For the most part, securing web services is one of the trickiest parts of the job. Many live solutions which I have seen are compromises such as the ones above.
It seems the answer is no. Forms authentication is a cookie-based mechanism, and your WinForms app won't be able to hold and relay the cookies (without some serious workarounds, if at all).
A potential workaround that I wrote up when researching your question attempted to use a NetworkCredential object, but that didn't work. Also tried was the ClientCredentials in .NET 4.0.
var ss = new MySecureWebService.MyServiceSoapClient();
ss.ClientCredentials.UserName.UserName = "abc";
ss.ClientCredentials.UserName.Password = "123";
string asmxReturn = ss.HelloWorld(); //exception returned here
The console app was still presented with the login html page when calling the webmethod.
Other Suggestions
If you have the source to your web service, extract its logic out into an assembly of its own. Reference that assembly in your WinForms app, and it's just as if you're calling the web service.
I understand that your goal is to reuse the app that's deployed, but the next best thing would be to use the same logic/implementation via .dll reference.
This might help: http://dotnetslackers.com/articles/aspnet/Securing-ASP-Net-Web-Services-with-Forms-Authentication.aspx.
I've built ASP.NET Web Services in the past that either were publicly consumed, or used Windows Authentication. I now need to build a Web Service that uses the SOAP 1.1 protocol and it needs to be secured with a username and password from the caller.
It seems setting up the infrastructure for WCP is overkill for one or two Web Services. Any other suggestions? I was also thinking of using ASP.NET 4.0 Beta, if anyone has explored that for this scenario, it would be helpful to know your opinion.
Thanks in advance for your suggestions.
The simple way is to create a special header that carries the auth info for every call and authenticate/authorize the user that way
Here's some sample code:
http://aspalliance.com/805_Soap_Headers_Authentication_in_Web_Services
Note that in this way you are sending clear text username and password so you would want to use ssl or use some kind of digest authentication
There are different ways of doing this. One could be enabling access to a specific sets of IPs. If the IP doesn't match one of the lists then you could easy reject the call at method's level.
Otherwise, you could create another method that would return a token and then make all the relevant methods to expect that token in return in order to process the request.
Use SSL. Force everyone who consumes your webservice to use https.
//Check for Secure Channel: HTTPS
if (!Context.Request.IsSecureConnection)
return "The HTTP Connection must use Secure Sockets (HTTPS)";
I've built an application that uses jQuery and JSON to consume an ASP.NET .asmx web service to perform crud operations. The application and .asmx are on the same domain. I dont mind people consuming the read operations of the .asmx remotely but dont want people randomly deleting stuff!!!
I can split the methods i'd like to be publicly accessible and the 'hidden' ones into 2 web services. How can I lock calls to the 'hidden'.asmx web service to the same domain that its hosted in?
Thanks in advance.
Edit:
Can someone comment on this, seems plausible ( source: http://www.slideshare.net/simon/web-security-horror-stories-presentation ):
Ajax can set Http headers, normal forms cant.
Ajax requests must be from the same domain.
So "x-requested-with" "XMLHttpRequest" requests must be from the same domain.
There are two scenarios you need to secure with web services:
Is the user authenticated?
Is the action coming from my page?
The authentication piece is already taken care of if you're using Forms Authentication. If your web service sits in a Forms Authentication-protected area of the site, nobody will be able to access your web services unless they're logged in.
The second scenario is a slightly trickier story. The attack is known as CSRF or XSRF (Cross Site Request Forgery). This means that a malicious website performs actions on behalf of your user while they're still logged in to your site. Here's a great writeup on XSRF.
Jeff Atwood sort of sums it all up in the link above, but here is XSRF protection in four steps:
Write a GUID to your user's cookie.
Before your AJAX call, read this value out of the cookie and add it
to the web service POST.
On the server side, compare the FORM value with the cookie value.
Because sites cannot read cookies from another domain, you're safe.
In AJAX the browser makes the calls, so even if you were to check that the domain is the same it wouldnt be secure enough because it can easily be faked.
You need to use some sort of authetication/autharization tokens (preferably with a time out) to keep things safe.
Quick and dirty solution would be to use IP address restrictions to allow only your domain's IP address access via IIS.
Probably better would be using HTTP authentication. There are many ways to do this, I found Authentication in ASP.NET Web Services a helpful overview.