Re: a question on session ID and security

On 5/29/07, Stut <stuttle@xxxxxxxxx> wrote:

What utter crud. An SSL connection encrypts the whole HTTP conversation,
including headers and even the URL you are requesting. The response is
also encrypted. It doesn't matter whether you're doing a POST or a GET
request, it's all encrypted.


The URL string is encrypted in HTTPS? Well, I was certainly under a
different impression (same with headers). Since I can't say I know any
better beyond a shadow of a doubt, I'll take your word for it. : )

Cookies are no more secure than the session ID. The general conclusion
from many years of discussion in the web community is that the user
experience is diminished so much by not trusting a session ID that the
security improvements are not justified.


So by storing sensitive information in a SESSION, you're safer? Only if the
session doesn't get read... I don't know, I guess in the security sense, it
should be seen as a part of the "conversation" as you put it, so if you
can't trust SESSION, you probably shouldn't use it at all for secure
applications. I still don't see the sense in storing sensitive information
in a session, at least one that persists; if it is passed to a temp table in
a database and destroyed across calls, I can see that as a better solution,
as long as you have a strong database security configuration.

If you're really concerned then your best bet is to reduce the session
lifetime to 5-10 minutes. Another 'trick' people sometimes use is to
store the user agent in the session and expire it if a request tries to
use an existing session with a different user agent. Unfortunately you
cannot rely on the IP address remaining the same throughout a session,
so don't build that into your session validation.


Well, if you use COOKIES, you can pass a secondary hash key that can be used
to validate the actual key against a footprint for a visitor (from
$_SERVER). Salt in a date/timestamp and SHA1 or other, and I feel like
that's a pretty good way to check against a visitor. I just think it feels
flimsy to validate a user on a SESSION key only.

--
Jared Farrish
Intermediate Web Developer
Denton, Tx

Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$


--
Jared Farrish
Intermediate Web Developer
Denton, Tx

Abraham Maslow: "If the only tool you have is a hammer, you tend to see
every problem as a nail." $$

Relevant Pages

  • Re: User control remember state across pages without session
    ... Its a shame Microsoft don't extend viewstate beyond a single page because it ... An HTTP Request is received by the web server. ... It sends a Response to the client. ... > Request for a Page comes from any client, the Session Collection has a new ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ
    ... into the session object. ... You can not have 2 simultaneous request for the same session. ... public partial class slow: System.Web.UI.Page ... public override void ProcessRequest ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: IIS bug-Concurrent request lock before IHttpModule.AcquireRequ
    ... shutDownMessage, ... IHttpModule stores the Hashtable of session objects in a private member ... You can not have 2 simultaneous request for the same ... protected void Page_Load(object sender, EventArgs ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Multiple instances of app under IIs and global com object - is it a problem?
    ... If IIS has, say, a pool of 25 threads, and your ASP Sessions do not exhibit ... objects) then you may not be looking at the same data when your next request ... This is why Session-level variables were provided -- in the Session ... this multiplicity of Module-level data means that you cannot ...
    (microsoft.public.vb.com)
  • Re: Multiple instances of app under IIs and global com object - is it a problem?
    ... If IIS has, say, a pool of 25 threads, and your ASP Sessions do not exhibit ... objects) then you may not be looking at the same data when your next request ... This is why Session-level variables were provided -- in the Session ... this multiplicity of Module-level data means that you cannot ...
    (microsoft.public.vb.general.discussion)