Server side cookie injection

I have an application that is a combination of asp / asp.net and both sides depend on the same cookie (they are on the same domain). There are several values โ€‹โ€‹in cookies that I no longer want to give to the client due to security concerns. What I was hoping to accomplish was pulling out those values โ€‹โ€‹so they don't go to the client anymore, and then, on every server request, somehow "push" the values โ€‹โ€‹back into the cookie so that the application still functions as expected.

Is it possible? I thought it might be through ISAPI, but I don't know C ++ is good.

0


source to share


3 answers


I think the isapi filter is your only option. If you don't want to use C ++, it can be done in python .

Another option is to upgrade the server to windows 2008. In IIS 7, you can write the isapi filter in .net language.



Changing applications is more reliable.

+1


source


Use the Set-Cookie header.

"Set-Cookie:Test=test_value; expires=Sat, 01-Jan-2000 00:00:00 GMT; path=/;"

      



Providing a back date for "expires" will remove the cookie from the client.

+1


source


Just a guess, since the question is not specific, but if the reason you don't want the information in the cookies to allow someone else to read it and use it for other purposes, you might want to look at some kind of reversible encryption, or any other obfuscation method so that the information is not readable by a person.

I don't know if Session or App variables can be read by both ASP and ASP.NET, but you can also look into using a database table to store information and just give them the session ID that was used to look for it. Kind of like an ad hoc Session variable.

For a better answer, you might want to modify the question to clarify what "security issues" you are concerned about. They might be irrelevant or there might be a way to deal with the problem itself, which is not related to odd hacks.

As much as I would like to say, "Just change everything to one or the other," I understand that this is not always an option.;)

+1


source







All Articles