CODEWITHSUNDEEP
asp.netparametersquery-string
MattSlay
MattSlay

Reputation: 9985

Query String Parameters make my app at risk?

I'm writing an Asp.Net WebForms app where I am calling an edit page an passing in the data about the record to be edited using query string parameters in the URL.

Like:

http://myapp.path/QuoteItemEdit.aspx?PK=1234&DeviceType=12&Mode=Edit

On a previous page in the app, I have presented the user with a GridView of screened items he can edit based on his account privileges, and I call the edit page with these above parameter list, and the page know what to do. I do NOT do any additional checking on the target page to validate whether the user has access to the passed in PK record value as I planned to rely on the previous page to filter the list down and I would be fine.

However, it is clear the user can now type in a URL to a different PK and get access to edit that record. (Or, he may have access to Mode=View, but not Mode=Edit or Mode=Delete. Basically, I was hoping to avoid validating the record and access rights on the target page.

I have also tested the same workflow using Session variables to store PK, DeviceType, and Mode before calling the target page, and then reading them from Session in the target page. So there are no query string paramaters involved. This would take control away from the user.

So, I'm looking for feedback on these two approaches so that I choose an accepted/standard way of dealing with this, as it seems like a very common app design pattern for CRUD apps.

Upvotes: 6

Views: 808

Answers (7)

James Lawruk
James Lawruk

Reputation: 31353

If you really don't want to check access rights on the target page:

You could hash the PK with the UserID and then add the hash value to the query string. 

string hash = hashFunction(PK.toString() + UserID.toString());

Then you have to make sure the hash in the queryString equals the hash value calculated before loading the page.

Assuming this is an internal organization Web application.

Upvotes: 1

John
John

Reputation: 17491

I believe the common practice is to do what you're avoiding: On the original page, you need to check to see what the user should have capabilities to do, and display their options appropriately. Then on the actual work page, you need to check the user again to verify they are allowed to be there, with access to that specific task.

From a usability standpoint, this is what the user would want (keeps it simple, allows them to bookmark certain pages, etc), and security on both pages is the only way to do this.

Upvotes: 1

Richard Friend
Richard Friend

Reputation: 16018

We always use querystrings so records can be bookmarked easily, however always validate in both places, if you write you access control code nicely it should just be a case of re-using the existing code...

Upvotes: 2

Zach Parrish
Zach Parrish

Reputation: 444

Agreed, you'll want to validate permissions on the target page, it's the only way to be absolutely sure. When it comes to security, redundancy isn't a bad thing. Secure your database as if you don't trust the business layer, secure your business layer as if you don't trust the UI, and secure the UI as well.

Upvotes: 6

Mark Redman
Mark Redman

Reputation: 24535

You could do the following to make your URLs a bit more secure:

-Use Guids for Primary Keys so users cant guess other record ID's

-The Mode couls be implicit: Guid = Edit, no Guid = New

and..

-Server-side validation is the only way to go.

Upvotes: 0

user253984
user253984

Reputation:

You should always validate before the real execution of the action, especially if passing the parameters by query string. For the second page that does the execution you might not need as much feedback for the user since you do not have to be nice to the user if he tries to cirumvent your security, so error handling should be a lot easier.

Passing the variables per session is acceptable but imho you should still validate the values.

Upvotes: 2

Shawn Steward
Shawn Steward

Reputation: 6825

Session variables can be manipulated as well, although not as easily. Whatever authentication you're using throughout your site, you should definitely use on your target page as well. Otherwise, you'll be open to exposing data you may not want as you have found out.

Upvotes: 0

Related Questions