If you have anything worth obscuring then I would suggest going to HTTPS and dumping HTTP.
Typically I would not put anything related to customer, vendor or order identifiers in the query string. But that is me.
Perhaps you could expand on what you're trying to accomplish? In general you should avoid putting important things (like login credentials) in a URL. URLs have a habit of "leaking" out.
General advice: set up your robots.txt to prevent Google from indexing any of these pages and make the login tokens (or whatever) one-time use only.
Edit: I would suggest not using weak XOR "encryption." If you're worried about people tampering with the URL parameters then add a secure hash. If you actually need to hide what information the query contains then encrypt it for real, don't roll your own weak algorithm.
I think you should never obscure GET parameters.
If you need to hide the parameters in the query String at the navigation bar, you should use post.
If you want to prevent sniffers to intercept you GET parameters data, use HTTPS.
A few come to mind...
Authentication and Authorization may be needed, depending upon what is being requested.
How one consumes and uses query parameter data is worth considering. If the parameter data is used in any manner other than a set selection of options, and if it is coming from an untrusted source potentially, then one may want to validate the parameter values.
Caution returning error codes. An attacker can use error codes to determine possible attack vectors by learning the topography of your site: what is returned if the resource either does not exist or the parameters are bad, etc.
You could use HttpModule in asp.net, which could encrypt HTTP Get values globally - HttpModule for query string encryption. Also, use SessionId as a key for encryption/description, which makes querystring more secure for each session. However, it's not 100% secure, and I would not recommend it for high security website.
As 'JD' suggested, It's better to use HTTPS to secure communication between server and client. However, client could change parameter value on the browser easily e.g. /showinvoice.aspx?id=1000 to /showinvoice.aspx?id=1001
I suggest to validate each validate each parameter's value on the server-side before executing the page. This would stop executing a request, which is not valid.
Never but secure information in a GET request. These requests get logged directly by the web server. So, the information is available in plain text format for a 3rd party to review and crack if they wish to do so.
If you need to pass credentials, use a cookie to store the state information and layer everything over SSL.
Use POST if you want more security?
You shouldn't be passing account information in the querystring.
My honest answer is that unless the data is REALLY sensitive (like a password, or credit card number, etc) then whoever coded the "encryption" was probably trying to cover up a lack of proper authentication/authorization in the app.
If for instance you are concerned that if you don't encrypt the "accountId=1" part of the URL then someone will be able to tamper it to "accountId=2" and view someone else's account, then the real flaw in the app is that it doesn't check the ownership of the account before delivering the goods!
Trying to fix this lack of authorization checking with encryption is at best a bandaid. Note that bandaids are sometimes necessary - it may be too hard to do anything else at this point - but we should still recognize it for what it is.