asp.net url and or query string encryption.

[Necuno]

look around i see you can either encrypt the whole url or just parts of it being the query string.

basically from login screen to pages direct to each other my main concern was about the url itself being something like http://website.co.za/page.aspx?something=value

should i opt for rewrite, partly encryption or full url encryption ? more of what would be the best practice to achieve more secure i suppose over just having a login screen.

 

[Necuno]

ive settled for encrypting this

http://website.co.za/page.aspx?something=value

to

http://website.co.za/page.aspx?qs=Urak6+NMOIB8POPpcY9w5w==

which is decrypted internally to reflect any query string parts with their values.

 

[James]

I can understand URL re-writes for SEO and readability purposes but I have never quiet understood the need for URL encryption. If you write good code, surely this is not needed? Unless you are using something in the query string that is of course sensitive, but what would you pass through a URL that would be sensitive.

 

[koeks]

i think it's needed. encrypted query stings are a good way to take the load off the server for passing values back and forth. i also use them from time to time... good one necuno.

 

[James]

I dunno, I don't get it still and I don't buy into the 'it takes a load off' theory either as by doing this you are using extra resources encrypting it back and forth, even if this is a negligible amount of resources. If you have any personal information that would need to be encrypted, it should be stored in a session, not be passed via a URL. The only info that is 'personal' that I ever pass via URL is the users ID which is no good to man or beast without authentication. As long as you are secure and not prone to session hacking that is all good. Other than that, the only info passed via URL is my actions and various other bits needed for page logic which again, I don't think needs encryption. I am not saying encryption is wrong by any stretch of the imagination, I personally just don't get it.

 

[Necuno]

so you just going to bliksem everything into the session ? only 2 parts which i'm passing between the pages is edit or display with a clientID.

curious what happens when the pages are between different domains or from different locations? will your session still work?

http://doman1/page1 to http://doman2/page1

or

http://doman1/loc1/page1 to http://doman1/loc2/page1

...what happens when the session times out ?

 

[FarligOpptreden]

Regarding session timeout, that will only happen if the session has been inactive for the specified time-period. But yet, cross-domain session handling is a bit of an issue. I would've personally opted for URL rewriting though - the clean URLs are much easier on a user's eyes.

 

[Necuno]

Regarding session timeout, that will only happen if the session has been inactive for the specified time-period. But yet, cross-domain session handling is a bit of an issue. I would've personally opted for URL rewriting though - the clean URLs are much easier on a user's eyes.

users are not allowed to have eyes . Q without looking into it*- can you do url rewriting and have a cookie-d state or is it just with cookieless states ?


*yes i'm lazy.

 

[FarligOpptreden]

I'd avoid saving state in a cookie - what happens when the client's browser rejects the cookie? The landing page will then break if you don't cater for state-less loads. URL rewriting is really just a case beautifying the query-string. You can even rename the page and query parameters to whatever you want, because in the end you'll convert it back to the proper / actual URL on the server. So, instead of:

http://domain/site/page.aspx?param=value

...you can rewrite to:

http://domain/site/action/setting/value

You can even go as far as to encrypt the value of the query parameter to something like:

http://domain/site/action/setting/dkjj59fk5lk49d

...and then decrypt the value in the page that opens. If you're hosting on IIS7 you can rewrite extensionless pages as well. Yes, there are workarounds in the form of custom 404 pages that interpret and redirect the URL, but that kinda defeats th purpose. Just attaching an HTTP module to your application that handles the rewriting is by far the sexier option...

 

[James]

I am also a +1 for the URL rewrite, but as I am just stubborn, I would rewrite with no encryption

 

[Necuno]

if the url is rewritten i can still fishout the querystring with the dev tools in ie8 or firebug for firefox ?

because an encrypted query string will only show as qs=Urak6+NMOIB8POPpcY9w5w== where internally you take that and decrypt query string as for example param=val&param2=val2 from.

been looking at this and how to do a proper secure website. knowing that the right people are allowed in and checked on each page of the right people are able to do something or nothing- obviously this is not done via the query string.

 

[Kloon]

If you are so worried about users seeing the query string, why dont you just post the data instead of using a get request

 

[Necuno]

If you are so worried about users seeing the query string, why dont you just post the data instead of using a get request

it's response.redirect or server.transfer. or am i confusing post and get of form values with something else here ?

it's not a matter of "so worried" it's implementing the best practice here. i see however there is another way of passing things between pages by using httpcontext which 'm reading up on with server.transfer VS response.redirect

over point being. i have a login page a user object is created to show that the user is logged in and can do some things;

a) where should that user detail be stored. for example just the ID in a cookie so that can be used to reread any other related info from a sql db.
b) any thing passed via the query string would be better to be encrypted which stops ****oring with it.
c) what would have been the best practice to have a more stream lined and secure page to page implementation over just passing and storing **** around.

.asp net is an ongoing thing as i've done way more desktop development and would have wanted to properly know wtf i'm really doing in some areas of implementation and this is why i'm reading and asking.

 

[Kloon]

POST and GET methods at the different ways how form values can be passed to other pages. GET makes use of a URL while POST you does what it says, it posts the form values without the user being able to see it. Im not sure how this is done is aspx, haven't touched aspx since uni.

As for storing logged in user data, what I have seen most people do and I myself is store a select * from the user table in a session variable for that specific user. That way it minimizes the amount of queries you do to the db.

 

[FarligOpptreden]

User table in SESSION variable?! That's ridiculous! You'll have a copy of the user table (possibly thousands of records?) for every single user sessions that's open on the server! A better option would be to store it in an application cache - that way it's loaded only once for the application instance. Much better on resources and performance.

I'm still not convinced that posting data cross-domain is the best option. For cross-domain I'd prefer URL rewriting. As for debugging the query-string, of course you can! If you know the rewriting-rules you can easily figure out what the name of the query parameter is and take any encrypted part and decrypt it on your side. All it is is renaming parts of the URL and having some translation table to get to the actual URL on the server.

 

[Kloon]

User table in SESSION variable?! That's ridiculous! You'll have a copy of the user table (possibly thousands of records?) for every single user sessions that's open on the server! A better option would be to store it in an application cache - that way it's loaded only once for the application instance. Much better on resources and performance.

I dont think there is much difference as far as performance between session vs cache. I prefer to use cache for datasets that is used by all the users. For user specific data I would still stick with sessions. The main goal in the end is to reduce the trips to the database.

 

[Obelix]

Use POST method for your forms instead of GET ( its an attribute on your FORM definition )

 

[Necuno]

I'm still not convinced that posting data cross-domain is the best option. For cross-domain I'd prefer URL rewriting

Use POST method for your forms instead of GET ( its an attribute on your FORM definition )

it's not a fill in form for godsakes

user -> login -> [create user mini object in session] -> default page

default page -> select recorded via button -> go to another page

a few things are done before user is redirected from "default" to "another page" where selected record is managed.

http://ilia.ws/archives/152-Cross-Domain-POST-Redirection.html

Alas, unlike the Opera and FireFox developers, the IE developers have never read the spec, and even the latest, most secure IE7 will redirect the POST request from domain A to domain B without any warnings or confirmation dialogs! Safari also acts in an interesting manner, while it does not raise a confirmation dialog and performs the redirect, it throws away the POST data, effectively changing 307 redirect into the more common 302.

 

[James]

If you are so worried about users seeing the query string, why dont you just post the data instead of using a get request

POST is just as accessible to the user as GET is, if you want it. If you are trying to make a secure website, just keep this in mind when ever you do anything. Always remember that the request on the other end IS NOT always a browser. If you are worried about security, it is not the layman you are worried about. It is not people using browsers either that are the problem.

 

[Kloon]

POST is just as accessible to the user as GET is, if you want it. If you are trying to make a secure website, just keep this in mind when ever you do anything. Always remember that the request on the other end IS NOT always a browser. If you are worried about security, it is not the layman you are worried about. It is not people using browsers either that are the problem.

Yes it is if you know where to look for it, what the OP wants is a way to hide/disguise the query string from the user eye if I understand correctly.