By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,650 Members | 1,871 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,650 IT Pros & Developers. It's quick & easy.

(Hopefully) Quick Question about Session Variables

P: n/a
DLN
Hello all,

I apologize for the naivety of this question, but I'm wondering whether
session variables can ever be modified (somehow) by a client without having
to go through code that I write. If I read in user input from a web form,
sanitize the input to make sure there isn't any injected data, and then
store the sanitized input in a session variable, is there any way for that
session variable to be modified by the client afterwards? I would prefer to
not have to re-validate a session variable every time I use it and instead
just do the validation once, when session variable is set. However, is it
guaranteed that the client accessing web application has no way of
"injecting" (for lack of a better word) their own session variables? I'm
not interested in how it can be done, just how to protect my applications
against it or is this even possible to begin with?

Thanks,

dln
Apr 30 '07 #1
Share this Question
Share on Google+
2 Replies


P: n/a
your application is the api to session variables (or databases). anyone
can write an app to post whatever data they want to your postback pages.
its up to your page code to not change session variables without full
validation.
-- bruce (sqlwork.com)
DLN wrote:
Hello all,

I apologize for the naivety of this question, but I'm wondering whether
session variables can ever be modified (somehow) by a client without having
to go through code that I write. If I read in user input from a web form,
sanitize the input to make sure there isn't any injected data, and then
store the sanitized input in a session variable, is there any way for that
session variable to be modified by the client afterwards? I would prefer to
not have to re-validate a session variable every time I use it and instead
just do the validation once, when session variable is set. However, is it
guaranteed that the client accessing web application has no way of
"injecting" (for lack of a better word) their own session variables? I'm
not interested in how it can be done, just how to protect my applications
against it or is this even possible to begin with?

Thanks,

dln

Apr 30 '07 #2

P: n/a
On Apr 30, 11:41 pm, "DLN" <dnadon_no...@hotmail.comwrote:
Hello all,

I apologize for the naivety of this question, but I'm wondering whether
session variables can ever be modified (somehow) by a client without having
to go through code that I write. If I read in user input from a web form,
sanitize the input to make sure there isn't any injected data, and then
store the sanitized input in a session variable, is there any way for that
session variable to be modified by the client afterwards? I would prefer to
not have to re-validate a session variable every time I use it and instead
just do the validation once, when session variable is set. However, is it
guaranteed that the client accessing web application has no way of
"injecting" (for lack of a better word) their own session variables? I'm
not interested in how it can be done, just how to protect my applications
against it or is this even possible to begin with?

Thanks,

dln
Session variables are stored either in the memory of your server
(InProc or StateServer) or in a database (SQL). At no point are the
variables sent out to the client, nor is there a mechanism for a
client to send new values/variables in. The only way for Session
variables to be modified is for a piece of your code to perform the
action.

So, if you've already sanitised some data and you place it in a
session variable, then yes, you can trust that data at a later point,
provided none of the rest of *your* code can change that variable.
However, if you've got a function somewhere like:

Session(Request("Key")) = Request("Value")

then all bets are off :-)

Damien

May 1 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.