Is it possible that form authentication can work in asp.net without cookies? I have learnt some where that without cookies authentication work normally but with help of token in query string but when I am disabling cookies my form authentication is failing with message in browser similar as shown in
Figure
Do I need to make some configuration changes to make it work with help of query string token?
Related
I'm trying to add both default identity login and jwt bearer login to my app but when i try signin in using the default web sign in form it accepts my password and sets the cookie correctly but when i'm redirected i'm not signed in. I think the problem is related to my app not reading cookie correctly but I cannot figure out if it's that or something else. jwt auth works perfectly though. here's my program.cs it's probably just some really small mistake. Thanks for help
What i'm trying to do is:
Receive username and password via form and authenticate them with IIS using basic authentication.
The thing is, I want to do this without the built in browser popup.
Is there a way to override the popup and authenticate through code?
My website is in ASP.NET and i'm using IIS7.
Thanks to all helpers!
You can put the credentials in the URL. See for instance https://serverfault.com/questions/371907/can-you-pass-user-pass-for-http-basic-authentication-in-url-parameters. Note the remark in that question that it doesn't work in IE.
Basic authentication uses a base64 encoded string containing [username:password] in the http authentication header.
You can simply add this to your request using jQuery's header function before performing the request. But wrong credentials would still cause a pop up.
In asp.net, I am able to login using forms authentication as usual, copy our auth cookie value, log out, add the cookie artificially to the client using the 'Edit This Cookie' addon for Chrome, refresh the (anonymous) landing page and hey presto i'm logged in again. This seems to be a vulnerability - is there any way of fixing it using the the standard forms auth or will I have to do something like use a custom Authorize attribute which overrides the existing one in asp.net mvc?
I don't think this is a bug per se. The following happens during forms authentication
You provide a username/password to the server
Server validates username/password
If valid, the server then sends an encrypted authentication ticket (cookie) to the client with the expiration time (set in the web.config forms authentication section) and username (all encrypted)
On each request that requires authorization, the cookie is decrypted on the server, expiration time is checked and username is used to see if authorized (or getting that role for the requested resource).
When you logout, the expiration time on the cookie is set in the past, therefore, it is not longer a valid cookie
Now, as to why you are seeing what you are seeing... You are copying the cookie before you logout. Thus your copied cookie never registers the logout (moved expiration time). When you reattach, you still have a valid auth cookie. Now, if your forms authentication timeout is set to...let's say 20 minutes...this method would fail if you copy the cookie and wait 21 minutes as by that time, it has expired.
Cookies are always vulerable and we can't do much about that. What we can do is prevent someone from stealing the cookies.
Regarding ASP.NET MVC it does a good job to avoid stealing cookies. Some of the main things it does by default as part of security are:
Encode the strings that are rendered to the view (if you are using Razor don't know about others) to prevent from XSS attacks.
Request validation (stop potentially dangerous data ever reaching the
application).
Preventing GET access for JSON data.
Preventing CSRF Using the Antiforgery Helpers
Regarding cookies Microsoft provides HttpOnly feature and this helps to hide the cookies from javascript. The Forms authentication that you are talking about is a HttpOnly cookie means someone can't steal that through JavaScript and it's more safe.
You can do that with any cookie/s. You can inspect/copy all the cookies from any given domain, and spoof if you want. You can do that to yourself (only) because its your PC (or user logged in to PC). Obviously if you're on a shared PC, that is a problem (across all your info).
The act of "copying your cookie" is in fact one way malware attempts to steal/hijack your identity (or current session on some web site). That said, unless you have some malware, you can't just "copy cookies" of someone else.
Assuming logout is done, you can ask users to close their browsers so the expired cookie is removed from the (file) system.
Ignore for the moment that not all browsers support LocalStorage.
Would it be possible to roll your own authentication "handler" (for want of a better word) that makes use of LocalStorage rather than a Cookie for FormsAuthentication within an ASP.NET web app?
If it is possible where would I find the best information to start learning how to do it?
Generally, your authentication happens at the server end and cookie contents are passed along with every request. So, by using the information available in request before accessing the resource, server can see if the user is logged in.
But, in case of localStorage the contents are not passed to the server with every request and is accessible only to Javascript. Hence it is not possible to use localStorage for authentication instead of cookie.
We're trying to test an API that requires HTTP Basic Access Authentication credentials (http://en.wikipedia.org/wiki/Basic_access_authentication) in the request.
Ideally, we could just test the API using a web browser by putting all API parameters in the URL querystring, but we haven't yet found a way to encode the HTTP Basic Access Authentication credentials (username and password) in the querystring.
Does anyone know a way to do this?
Thus far, we've tried:
https://username:password#mydomain.com/
...without success.
username:password#url authentication has been disabled in many browsers for security reasons.
For example in IE:
Internet Explorer does not support user names and passwords in Web site addresses (HTTP or HTTPS URLs)
As far as I know, there is no way to circumvent this if this is blocked. It's possible that this can be turned of in Firefox using a setting in about:config. Or use some other browser that doesn't block it - I don't know which ones do and which don't.
Alternatively, consider building a quick web form that submits the option to a server-side language (e.g. PHP) that makes the request, or use a command line client like wget to send the requests. The latter might even be easiest