Re: Forms Authentication w/SubFolders

From: Glen M (glen_at_lfsh.com)
Date: 08/10/03 

Date: 9 Aug 2003 20:53:43 -0700

The solution is in the machine.config file. Under .Net 1.1, there is
an option to isolate the security used by each application. The
standard machineKey looks like the following.

<machineKey validationKey="AutoGenerate,IsolateApps"
decryptionKey="AutoGenerate" validation="SHA1"/>

Under .Net 1.0 there was no option to "IsolateApps". So changing the
key to the following will fix the problem.

<machineKey validationKey="AutoGenerate" decryptionKey="AutoGenerate"
validation="SHA1"/>

Please note that this means that applications will now share security.
If this is not what you intend to do then do not make this change. Of
course if you're having the "problem" then it's because you want to
share security across applications, right?

-Glen

John Kraft <jhkraft@ilstu.edu> wrote in message news:<bgro3c$djo$1@malachite.ilstu.edu>...
> Joel Finkel wrote:
>
> > I have come into this newsgroup precisely to look for an answer to this. I
> > am quite amazed to see this very question! Furthermore, I see a posting
> > made a few days later that reports a similar issue: Sucessful authentication
> > returns to the login page.
> >
> > My situation is that in root, aspx pages authenticate fine (the login.aspx
> > form is in the root, as well). But in sub-directories, while the login.aspx
> > form is correctly invoked, the redirect returns to the login.aspx page.
> > This happens regardless of the presense of a web.config file in the
> > subdirectory, or the contents of it. I have played around with variations
> > for about 3 hours. I have verified that the cookies is being created and
> > sent, but for some reason the application in the sub-directory is not hip to
> > the fact that this cookie exists, and returns to the login.aspx page.
> >
> > Pretty big problem. Hope there is a simple fix.
> >
> > Thanks for all suggestions.
> > -Joel
> >
> >
> > "JTR" <jtrichard@sotasw.com> wrote in message
> > news:038001c35618$a80ca270$a601280a@phx.gbl...
> >
> >>I'm trying to create a structure I can share
> >>authentication from a root application with many
> >>subordinate applications (subfolders).
> >>
> >>The web.config file for the root has:
> >>
> >><authorization>
> >><allow users="*" />
> >></authorization>
> >>
> >>Then, each subordinate application (subfolder) has a
> >>web.config with the following:
> >>
> >> <authentication mode="Forms">
> >><forms name=".BUZZARD"
> >>loginUrl="../login.aspx">
> >></forms>
> >> </authentication>
> >> <authorization>
> >><deny users="?" />
> >> </authorization>
> >>
> >>When the user access a resource in a subfolder, the login
> >>form is displayed and authenticates the user correctly,
> >>including the creation of an authentication ticket. But,
> >>when the login form attempts to redirect the browser to
> >>the requested secure resource, the login form is
> >>redisplayed. I have tried using
> >>FormsAuthentication.RedirectFromLoginPage() and
> >>Response.Redirect() with the same results.
> >>
> >>Any ideas?
> >>
> >>JTR.
> >
> >
> >
> I was having this problem too. It turned out to not be a problem with
> the cookie, but with the encryption/decryption of the cookie. Even
> though the cookie was inside the same project, even though a subfolder,
> the encryption key is supposed to be the same. It wasn't. I tried
> manually setting the encryption key in the webconfig. I even tried
> putting another copy of the same web.config into the subdirectory. For
> some reason nothing seemed to work. We ended up setting the
> protection="All" to protection="None" to get around it. We still have
> not corrected the problem, but if you make that change it might indicate
> that the problem is not actually with the cookie.
>
> John

Relevant Pages

  • Re: Forms Authentication w/SubFolders
    ... > Please note that this means that applications will now share security. ... >> manually setting the encryption key in the webconfig. ... >> that the problem is not actually with the cookie. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • [REVS] Cross Site Cooking
    ... Get your security news from a reliable source. ... On sites where authentication data is tied on a server to a session ID, ... Let's begin with a quick primer on cookie parsing: ... For security purposes, the browser ...
    (Securiteam)
  • [UNIX] PHPNuke Admin Password Can Be Stolen
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... Vulnerabilities in PHPNuke expose the administrative password. ... To successfully exploit this vulnerability you will need to rely on two ... The administrator login/password pair is stored in a cookie like this: ...
    (Securiteam)
  • Re: A technique to mitigate cookie-stealing XSS attacks
    ... I'd like to thank the "Microsoft Internet Explorer Team" for ... I'd like to point out that this security feature does not help ... This new HTTPOnly security feature would simply stop cookie hijacking ... > During the Windows Security Push in Feb/Mar 2002, the Microsoft Internet ...
    (Bugtraq)
  • [UNIX] YaBB Security Vulnerabilities (CSS in Login, Insecure Password Handling)
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... attacker to steal user's cookies, hijacking user's accounts, and more. ... stealing the username cookie is easy. ...
    (Securiteam)