1

I want to add Querystring "checking" and logging in the case of any "tampered with" querystrings. Is the Page_Init event on a given page the right place to do that in the ASP.Net page lifecycle?

Michael Shimmins
  • 19,961
  • 7
  • 57
  • 90
BuffDev1
  • 51
  • 1
  • 4
  • 4
    What would be an example of tampering? – Quick Joe Smith Dec 05 '10 at 03:49
  • In my case I would be checking whether specific key values are empty or out of a specified range. I'm not only thinking of checking for malicious tampering but also if somehow incoming requests get trimmed or affected in the process of emailing out links with querystring paramaters and expecting users to use them. I would then know by looking through my event log if something might be happening and be able to do some research into what the problem might be. – BuffDev1 Dec 05 '10 at 04:14

2 Answers2

1

My general rule is to do everything as early as possible. This might even include checking as early as Application.BeginRequest (which occurs may events before the page is even loaded), so long as query string verification is not page-dependent.

The question here is "What do you consider to be tampering?" Invalid keys? Invalid values? Attempts to encode tags that might hopefully be written to the resulting page as part of an XSS attack?

It's hard to give any sort of specific advice without knowing more about what you're trying to accomplish.

EDIT: To access the application events, add a Global Application Class to your project from the 'Add New Item' option.

Every request triggers the application lifecycle, and the page lifecycle is just a sub-process within that when the request handler happens to be an aspx file.

EDIT2: Cleaning query string data depends entirely on what you are using the data for. Some potentially dangerous uses for query string data include:

  • Values for an SQL command: SQL injection can be largely mitigated by using 'parameterised queries'.
  • File locations: This could be used to make the server cough up any file on the hard drive if NTFS permissions on the server are lax.
  • Values written into the HTML response: A user could encode a tag and execute some JavaScript. Be sure to use Server.Encode() or manually cleanse the string.

  • ID values: If you are using the query string to store ID values, a user could replace those with others in at attempt to access information about things they shouldn't see, an example of which may be:

    http://domain.com/somepage.aspx?userid=1343243

The user makes an educated guess and changes this to:

http://domain.com/somepage.aspx?userid=0

And that could bring up the admin user.

Quick Joe Smith
  • 8,074
  • 3
  • 29
  • 33
  • Do you have a link which has what are the suggested checks one should do regarding querystrings and attacks using them? – BuffDev1 Dec 05 '10 at 04:07
  • Also, the earliest I know how to deal with an incoming request to a page is in Page_Init. Where would the code live in the case of it being in Application.BeginRequest? – BuffDev1 Dec 05 '10 at 04:08
  • Answer updated with application lifecycle info. I also don't entirely understand what your first question was asking. Can you rephrase? – Quick Joe Smith Dec 05 '10 at 04:15
  • Sorry, I was asking, "How are querystrings exploitable and what should I be checking for with regards to security?" – BuffDev1 Dec 05 '10 at 04:18
  • It depends entirely on what you are doing with them. I will update my answer again. – Quick Joe Smith Dec 05 '10 at 04:20
  • I don't contstruct any SQL statements directly based on Querystring paramaters as I'm aware of SQL Injection. – BuffDev1 Dec 05 '10 at 04:22
  • Cool, I'm aware of the first two items and know I've mitigated those types of threats. I'm not sure about the third though. Could you give an example of how you'd handle that? Instead of directly setting a string variable to the querystring value you should call Server.Encode on it? Is that it? – BuffDev1 Dec 05 '10 at 04:32
  • Server.Encode is just one possible solution if you plan on using that query string value in the HTML response sent back to the client. – Quick Joe Smith Dec 05 '10 at 04:43
  • Thanks, Joe! I have a good amount to start with and think I will be good in this area. – BuffDev1 Dec 05 '10 at 05:04
0

What we follow in our project to use encrypt and decrypt querystring. I can send you that class for encrypt and decrypt function. But for reference you can start with following URL if it helps.

http://geekswithblogs.net/casualjim/articles/64639.aspx

Now in this if it is tempered, it could not be decrypted. You can write page level exception for it and redirect to proper error page.

Let me know if you require more information on any specific point.

Cheers!!!

Manish Pansiniya
  • 537
  • 4
  • 14
  • I've seen this mentioned in other posts and it's relevant to this topic and something I will keep in mind for later security efforts around querystring. Thanks! – BuffDev1 Dec 05 '10 at 07:24