eAExperts
asked on
QueryString Security in ASP.NET 2.0
For security reasons, I'm trying to create an algorithm that prevents querystrings on a website from being hackable. To do this, I'm tacking a securely generated checksum based on the querystring value onto the end of the querystring as a page request begins using the Begin_Request event in global.asax. I can tack the checksum onto the querystring fine, and I can prevent the user from editing the querystring, and I can even prevent the user from deleting the checksum after the page has loaded for the first time. However, I cannot prevent the user from typing in a custom querystring on their own the first time a page loads without a checksum, which in effect defeats my security system. What I'm assuming needs to be done here is to create a method to apply the checksum to a URL with a querystring before the page even begins loading. Anyone have an idea how to accomplish this?
Last Comment
ASKER
In an attempt to explain more clearly, what I need is to append a querystring with an extra "checksum" value before the page request is sent. I'd rather not use a 3rd party component. URL rewritting may be the answer here, I'm not sure.
What I mean is that the user initially clicks a link on the page for the following URL:
http:///www.somedomain.com/defualt.aspx?testval=123
Before the request is finalized to the server and the page request is made, I need to create a checksum value based on the querystring in the URL and then append the URL so that it looks like this:
http://www.somedomain.com/default.aspx?testval=123&checksum=5678
I have the code written to generate the checksum, and put it on the querystring, and then verify the checksum at the page level. The question here is the timing of WHEN the checksum is added to the querystring so that it can be verified when the page loads. As I have it now, if I use the Begin_Request event in global.asax, or the Page_Init at the page level, the user can still simply type in:
http:///www.somedomain.com/defualt.aspx?testval=123
I want to get around that problem by tacking on the querystring at an earlier time and then just verify the checksum at the page level. The checksum is generated based on the querystring directly, so that if its changed the user is kicked out to the home page.
What I mean is that the user initially clicks a link on the page for the following URL:
http:///www.somedomain.com/defualt.aspx?testval=123
Before the request is finalized to the server and the page request is made, I need to create a checksum value based on the querystring in the URL and then append the URL so that it looks like this:
http://www.somedomain.com/default.aspx?testval=123&checksum=5678
I have the code written to generate the checksum, and put it on the querystring, and then verify the checksum at the page level. The question here is the timing of WHEN the checksum is added to the querystring so that it can be verified when the page loads. As I have it now, if I use the Begin_Request event in global.asax, or the Page_Init at the page level, the user can still simply type in:
http:///www.somedomain.com/defualt.aspx?testval=123
I want to get around that problem by tacking on the querystring at an earlier time and then just verify the checksum at the page level. The checksum is generated based on the querystring directly, so that if its changed the user is kicked out to the home page.
ASKER CERTIFIED SOLUTION
THIS SOLUTION IS ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
It's not clean by any stretch of the imagination, but you could inherit the Hyperlink object, override the render method and change how it works, squirting your checksum onto the end of a querystring.
I would cache these in the application pool thought because doing this is going to be hard work on the server if you do this for every link on every page of every request.
Because of the way the controls of a ASPNET page render, you need to catch this before things start generating... Or you need to build a "dam" on the Page Object's Render method so the child controls render into static memory (rather than the output stream), so you can probe the URLs and append querystrings and then squirt the data out.
Either method is going to have a massive performance impact in your application -- therefore I would advise you do not go down this road.
You might find it a lot easier requiring cookies (or allowing cookieless sessions) and storing the last requested page in their session. Then you can allow entrance to a page/querystring/etc based on the session value. It's still complex but it's a lot nicer on the server than hashing and inserting querystrings on the fly.
I would cache these in the application pool thought because doing this is going to be hard work on the server if you do this for every link on every page of every request.
Because of the way the controls of a ASPNET page render, you need to catch this before things start generating... Or you need to build a "dam" on the Page Object's Render method so the child controls render into static memory (rather than the output stream), so you can probe the URLs and append querystrings and then squirt the data out.
Either method is going to have a massive performance impact in your application -- therefore I would advise you do not go down this road.
You might find it a lot easier requiring cookies (or allowing cookieless sessions) and storing the last requested page in their session. Then you can allow entrance to a page/querystring/etc based on the session value. It's still complex but it's a lot nicer on the server than hashing and inserting querystrings on the fly.
.NET Programming
The .NET Framework is not specific to any one programming language; rather, it includes a library of functions that allows developers to rapidly build applications. Several supported languages include C#, VB.NET, C++ or ASP.NET.
137K
Questions
--
Followers
--
Top Experts
Get a personalized solution from industry experts
TRUSTED BY
Anyhow, if you're really looking for indestructible URLs, consider URL Rewriting. That way all your URLs have to match a REGEX pattern to get through to your pages. They also look a lot nicer!
http://www.urlrewriting.net