How do i set aspxauth unchangeable, like for instance the client/user change its value then after proceeding to other pages the original aspxauth value will remain and not be signout.
ASPXAuth Cookie stores in client browser (location of cookie path might be different, depends on browser) and it is impossible to avoid changing it from server. Besides, if AspxAuth cookie has been changed, the server redirects the client to login page. Because, the server decrypts auth cookie and extracts several data like Name, Expiration, IsPersistent etc. It determines that the user can remain in authentication or not. So if the cookie has been changed, authentication can't be performed no longer from server side.
Related
HI can someone please help imgetting below error when calling outlook rest api
IDX21323: RequireNonce is '[PII is hidden by default. Set the 'ShowPII' flag in IdentityModelEventSource.cs to true to reveal it.]'. OpenIdConnectProtocolValidationContext.Nonce was null, OpenIdConnectProtocol.ValidatedIdToken.Payload.Nonce was not null. The nonce cannot be validated. If you don't need to check the nonce, set OpenIdConnectProtocolValidator.RequireNonce to 'false'. Note if a 'nonce' is found it will be evaluated.
aka IDX21323 points towards losing the nonce cookie (set by the initial Challenge call). Inspect your initial SignIn call (or WebForms postback SignIn) and confirm that you have a OpenIdConnect.nonce cookie actually set (Chrome network tab).
If not, I suspect that you have the same issue we had, which is that the OWIN Middleware sets the cookie, but its content gets accidentally overwritten by some other cookie modifications of your legacy application.
This is very likely a bug of the OWIN middleware (see ASP.NET_SessionId + OWIN Cookies do not send to browser), as it handles cookies through its own OwinContext and Cookie representation implementation, which is not in sync with the standard HttpContext.
How to fix when you have the initial nonce cookie missing:
We avoided any cookie changes during the SignIn request -> therefore the OWIN middleware can read/write its cookies with no interference.
When setting the nonce cookie running on localhost (non-secure) in a Chromium based browser, it's blocked because of SameSite=none and it not being secure. The fix for this case is to change localhost to use SSL (use https on asp.net application running on localhost) and update the Azure AD redirect URL to match.
In a WebForms app I got the same error when I used my machine name in the project url, but used "localhost" as my login redirect url. When I set them both to localhost the problem went away.
If your tenant was created on or after October 22nd, 2019, it’s possible you are experiencing the new secure-by-default behavior and already have security defaults enabled in your tenant.
How to Fix :- goto your Azure AD account => properties => on tab Access management for Azure resources => enable this tab to Yes.
It appears that I am able to read the SessionID at any time, even if no cookie currently exists!
Dim SessionID As String = Request.Cookies("ASP.NET_SessionId").Value
This code will always return a value, presumably the ID held by IIS server side.
The cookie appears to be generated only when a request to store session information is made.
Why is this?
and ...
If I am using session state server will the SessionID ever differ from the cookie SessionID and which take priority if one of the ID's is lost or reset?
EDIT
If the app_pool is reset. A new session ID must be created will this cause the session cookie to be updated also? As this could create potential conflicts for users already logged in.
When a user accesses a website powered by ASP.NET IIS generates a SessionID to uniquely idetinfy the users session.
If the website is using cookies:
<sessionState mode="StateServer" cookieless="UseCookies"/>
A cookie named ASP.NET_SessionId will be generated only when a request to store session information is made by the webpage. If no session information is stored a cookie will not be created but the user will still have an active SessionID.
The SessionID is read from IIS when no cookie is present.
The SessionID on the server always takes precedence and will update the session cookie when a new request to store information in the cookie is made.
Every time that an user access the website and a session is opened ASP.Net by default creates a SessionID unless you specify the cookieless option:
If you are using a session state server the SessionID should be the same across all web servers otherwise you wouldn't be able to find the same user.
If the ID is lost or reset the state server will simply create a new one and write a new cookie with the new SessionID and the old one will be deleted after the expiration time.
I have two page P1.aspx(login page) and P2.aspx(redirect page), both configured with SSL.
In P1.aspx I created the authentication cookie with "Secure" property set to "true" and added in response object of the P1.aspx.
But when the page is redirected to P2.aspx from P1.aspx,the authentication cookie in P2.aspx request shows the cookie's "Secure" property as "false". I am not getting why "Secure" property is set to "false" in requests cookie.
If you are checking Secure on server side, then it won't be true, because browser doesn't send this attribute back. But if you check it in Chrome DevTools, then you can find that this cookie has Secure = true.
Here is a quote from wiki:
Besides the name–value pair, servers can also set these cookie attributes: a cookie domain, a path, expiration time or maximum age,
Secure flag and HttpOnly flag. Browsers will not send cookie
attributes back to the server. They will only send the cookie’s
name-value pair. Cookie attributes are used by browsers to determine
when to delete a cookie, block a cookie or whether to send a cookie
(name-value pair) to the servers.
So it's totally fine that you don't Secure attribute in Request, and has it in Response when you send it. Browser just don't send it back in each request, but it still use it anyway, and if request wont be HTTPS, then browser won't use this cookie
I have implemented ASP.Net Identity after following the sample code here:
https://github.com/rustd/AspnetIdentitySample
In my implementation I check if a user is authenticated - this is called from a FilterAttribute on my MVC Controllers; the idea is i want to confirm they are still auth'ed before serving up the page.
So in my filter, the following code eventually gets called:
_authenticationManager.User.Identity.IsAuthenticated;
_authenticationManager is here:
private IAuthenticationManager _authenticationManager
{
get
{
return _httpContext.GetOwinContext().Authentication;
}
}
The _httpContext is passed into the constructor of my identityProvider class.
Now - once I have logged in, _authenticationManager.User.Identity.IsAuthenticated; returns true as expected.
However, during development, i dumped and re-seeded my database, without adding a user. So effectively, I have deleted the IdentityUser - yet _authenticationManager.User.Identity.IsAuthenticated; STILL returns true
any idea why this is? I can only assume it's somehow checking a cookie, rather than actually looking at the DB. is this correct?
Or have i messed up my implementation.....
This does not make IsAuthenticated a security hole. Let's look at the actual authentication process.
You setup some stuff in your web.config around where the login page is, how long the login is good for and whether or not to use sliding expiration (should the time be extended if the user is active on your site)
User comes to your site, enters their username and password.
That information is posted to your server. You take that information, verify that it is correct (authenticate). If it is correct, the server then issues an encrypted cookie known as the FormsAuthenticationTicket Note - this could have a different name in the new Identity stuff, but the same principle.
The cookie's contents includes items such as the user name and expiration date of the login.
On each request, the server looks at the cookie collection for the authentication cookie. If found, it decrypts it, reads the values and determines if this is still a valid cookie (expiration time). Once it has the user information from the cookie, the server can use this information to determine if the user is authorized for the resource requested (look up by username).
5a. If the cookie is not present, or has expired, then the user is redirected back to the login page.
6.When the user logs out, the cookie is deleted from the cookie collection. Now, if the user tries to go to a resource that is for authorized users only, then the server ends up at 5a above.
So, in your case, you deleted a user manually. This does not change the fact that this user has previously been authenticated with a still valid cookie. Therefore, IsAuthenticated is returning the expected value. The user has authenticated before you changed his user status. IsAuthenticated does not mean, is this user still valid in my database.
If you are going to be running a site where you are constantly deleting/deactivating users, then override the OnRequestAuthorization method of the AuthorizeAttribute to look and see if the user is actually still in the database. Also, note that if the username is not present (because you deleted it), then any look ups for role / userId will fail. You can catch that exception / failure and return the property unauthorized response.
Q1
I’ve read that when setting the timeout of an authentication cookie, we should keep in mind that the longer the cookie persists, the greater the chance of a cookie being stolen and misused.
A) But assuming we secure our application against replay attacks by enabling SSL for the entire application, and since forms authentication module also encrypts authentication data in authentication cookie, then I would think there is no chance of this cookie being misused and thus cookies being persisted for longer periods of time should not present any security risks?!
Q2
FormsAuthentication.FormsCookiePath specifies where authentication cookie is stored. Default value is ‘/’.
A) Assuming default value ’/’ is used, where is cookie saved then?
B) Is this option only used for persistent cookies?
thanx
2A The cookie path is the path on the server the cookie relates to, not the path where the cookie is store.
From http://www.quirksmode.org/js/cookies.html
The path gives you the chance to specify a directory where the cookie is active. So if you want the cookie to be only sent to pages in the directory cgi-bin, set the path to /cgi-bin. Usually the path is set to /, which means the cookie is valid throughout the entire domain.
This script does so, so the cookies you can set on this page will be sent to any page in the www.quirksmode.org domain (though only this page has a script that searches for the cookies and does something with them).
You are using ASP.Net. Also see the "CookieLess" Session and Authenication options e.g.
http://msdn.microsoft.com/en-us/library/system.web.security.formsauthentication.formscookiepath.aspx If you are worried about cookies. This uses a URL session ID instead to track your session.
You can also use a SQL Server to track session state or a State server.
e.g.
<sessionState mode="SQLServer" sqlConnectionString="SQLSessionDB" cookieless="false" timeout="65" cookieName="MSESSID"/>
1A. SSL encrypts transport. Hence your cookies will be less likely to be stolen on route to the client or back. That doesn't mean a malicious program on the client computer can't steal it. This is very unlikely though.