locked
Cookieless Forms Auth Broken After Patch Installed RRS feed

  • Question

  • User-65334296 posted


    Hi,

    I have an asp.net web application using cookieless web forms authentication.

    After installing the patch (KB2418241 and KB2416473) some users are reporting http 400 errors.

    I reviewed my webserver logs and it looks like some users are getting forms auth tokens that are longer than normal, since these are passed in the URL they are making the URL length longer than IIS will accept (I think).


    I am using .net 3.5 sp1 on windows server 2003.


    Any ideas ?

    Update

    After examining the logs, it seems some users are getting forms auth tokens that are 264 characters long as opposed to the normal 156.

    According to this article (http://forums.iis.net/t/1105360.aspx),  ASP.NET prior to 4.0 has a URL length limit of 260 characters

    Update #2

    Is anyone from Microsoft reading these posts? can they acknowledge/confirm this issue?

    I have had to uninstall KB2418241 and KB2416473 untill this issue is fixed or a workaround is released.


    Wednesday, October 13, 2010 6:09 PM

Answers

  • User-234406897 posted

    I do not have any 2003 boxes to check this on but you seem to imply that your problem is the URL length by default has now increased.

    This is not now a asp.net issue or specfically an IIS issue but a http.sys issue. Shown by the event of the 400 error and should be in the http.sys error logs.

    You are correct that there is a limit set in the http.sys to stop the URL length per segment.

    You can change this in the registry so to increase the URL length.

    http://support.microsoft.com/kb/820129

    Hope that helps.

    EDit:

    Anil in the iis.net forums suggests that asp.net has the max limit of 260 characters http://forums.iis.net/t/1105360.aspx so maybe that is a limit but I suggest someone on these forums could confoirm deny this.

    Reading up I think this only applies to physical paths but facts are unclear. 

    I would suggets that if the http.sys is returning this 400 error (look in your http server headers on the page for the httpapi 2.0 references to confirm or in the http.sys logs) then it is nothing to do with the

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, October 22, 2010 12:02 PM

All replies

  • User-810382700 posted

    I'm experiencing the same issues on our web server. My difference is that I cannot verify that  KB2418241 and KB2416473 are installed on that server. It actually seems to be related to this patch:

    http://weblogs.asp.net/scottgu/archive/2010/09/28/asp-net-security-update-now-available.aspx

    As soon as I uninstalled KB2416471, everything went back to working.

    Sunday, October 17, 2010 3:05 PM
  • User1921622120 posted

    This post is not answered.  You have to uninstall this update to fix it.  That's not an acceptable solution.  That still leaves applications open to the ASP.NET vulnerability.  Microsoft, where is the answer to this?

    Thursday, October 21, 2010 3:16 PM
  • User-234406897 posted

    I do not have any 2003 boxes to check this on but you seem to imply that your problem is the URL length by default has now increased.

    This is not now a asp.net issue or specfically an IIS issue but a http.sys issue. Shown by the event of the 400 error and should be in the http.sys error logs.

    You are correct that there is a limit set in the http.sys to stop the URL length per segment.

    You can change this in the registry so to increase the URL length.

    http://support.microsoft.com/kb/820129

    Hope that helps.

    EDit:

    Anil in the iis.net forums suggests that asp.net has the max limit of 260 characters http://forums.iis.net/t/1105360.aspx so maybe that is a limit but I suggest someone on these forums could confoirm deny this.

    Reading up I think this only applies to physical paths but facts are unclear. 

    I would suggets that if the http.sys is returning this 400 error (look in your http server headers on the page for the httpapi 2.0 references to confirm or in the http.sys logs) then it is nothing to do with the

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, October 22, 2010 12:02 PM