A potentially dangerous Request.Cookies value was detected from the client?

Ron Howerton · September 27th, 2011, 04:02 PM

I just created a BRAND NEW project. The code runs as expected in VS 2011. None of the code I have written uses cookies.

Yet when I publish to our production server, it throws this error:

A potentially dangerous Request.Cookies value was detected from the client (S8ContactName="<a href=`Documentati...").

"S8ContactName" IS a cookie used by ANOTHER process, but I can find no reference to that string anywhere in the solution throwing this error.

I've temporarily worked around this weirdness by adding this to my web.config:

<httpRuntime requestValidationMode="2.0" />.

But working around this avoids the question: what could be causing one web application to try to request a cookie used by an entirely different solution? And how could a reference to this cookie be so well hidden in this solution that Find in Entire Solution does not turn it up?

Imar · September 27th, 2011, 05:37 PM

Quote:

what could be causing one web application to try to request a cookie used by an entirely different solution?

Maybe this site runs against localhost or another URL you used before? That would force the browser to submit a previous cookie for that domain / URL to the server where it gets rejected....

Imar

Ron Howerton · September 28th, 2011, 09:33 AM

Curiously, I tried creating a brand new web application, and though I made no changes (except for adding the httpRuntime setting noted above), it throws the same error when published to our production IIS server. But, if I create a new BLANK web application and then add the same objects and code contents as the project producing this error, it runs just fine. Furthermore, publishing to our development server does not cause this problem!

In a possibly related matter, IIS Manager appears to be crashing the application pool when I change framework on the asp.net tab of the application properties window. So whenever we publish a new application to the production server for the first time and create the virtual directory, we must manually stop and restart the application pool, rendering all of our production applications unavailable for a brief time. It's further complicated by having to actually log into the production server to do this, because the list of available frameworks in blank when running IIS Manager on our local workstations?

This is most peculiar!

Imar · September 28th, 2011, 11:04 AM

But isn't this just a matter of a bad cookie in your browser that keeps getting sent to the server? have you tried clearing your cookies?

Imar

Ron Howerton · September 28th, 2011, 12:50 PM

I hadn't tried clearing my cookies because the application returning the error wasn't using cookies, although I tried closing the browser to clear the cache. It therefore seemed like a cross-post issue to me, or maybe a server problem?

But...I kept getting stranger and stranger error messages with each subsequent publish (problems with authentication settings in web.config and html that I know I did not change, since I did not change anything, etc.) and was finally so frustrated I rebooted. I've since published several new web applications with success, so I cannot now reproduce the problem to test your suggestion.

So, at this point it seems like there was something going on with my w/s. It took a lot longer than usual to reboot and I got the BSOD yesterday (not seen since my last o/s upgrade!), so maybe this is just nature's way of telling me it's time to replace my h/w? I will certainly try rebooting should something like this happen again!

Thanks, Imar!

Imar · September 28th, 2011, 02:38 PM

I think you're overlooking something really simple here. Here are the steps to easily reproduce this problem:

1. Create a new web site and deploy to http://whatever

2. From this site, create a cookie with an invalid value and send it to the browser

3. Delete the entire site (the cookie remains in the browser)

4. Create a brand new web site that does not use cookies and deploy to http://whatever

5. Request http://whatever in your browser.

The browser submits the cookie to the sevrer (not knowing this is a different site or application) where it gets rejected by the server because of its value.

The server rejecting the cookie doesn't have to set it in the first place; it's automatically sent to each site matching the domain name.

Does this clarify things?

Imar

Ron Howerton · October 4th, 2011, 03:59 PM

I've had no time to try what you suggested, but the problem started occuring again today with an old program that worked before this started happening. I've been in and out of VS 2010 at least a dozen times today (one of those days, you know?) before it started happening, which still leads me to believe VS is weirding out.

But upon clearing cookies, it went away!

Thanks as always, Imar!