session variable security

[slickwillyslim]

i have an online store just about ready to go up. users can register and set a unique user/pass to login with. my site is encrypted with SSL. however only certain pages are actually secured: order forms, registration, etc. let's say for instance a user who's already registered with me starts a session (comes to the site). now, my sign-in page and user/pass authentication page are encrypted. but, when the user is logged in, he/she is free to navigate (unsecured - http) throughout the site and add multiple items to the cart. my site uses no cookies, sessions only, so the only way i can think of to track the user through the site is with a userID session and a password session. therefore, when the user decides to checkout, these session variables can be used to access the user's personal information, of course then returning to https for security. my question is how safe is this? can a hacker easily read a server-side session variable to steal the user/pass and gain access to credit card information and such? i've heard of encrypted cookies, but i use classic ASP, and have no idea how to create one. any suggestions would be GREATLY appreciated. thanks guys.

 

[vanillapod]

to read the session variable they'd have to access the server memory wouldn't they? I've always been told they're pretty damned safe to use...

If they can access the server memory they could probably access other stuff like ya database holding client info etc?

 

[slickwillyslim]

tnx vanillapod, i'm probably just being paranoid. its just that i've heard of something called session hijacking, but i don't really know what a hacker can accomplish with that. anyway, i'll probably just use sessions as my options are pretty limited otherwise. tnx again.

 

[newmediaguy]

Hi Guys

I worked on a large Ecommerce website and part of our testing although doesnt sound related to your issue was SQL injection avoidance, what people seem to forget is that if you can break the SQL string and manipulate it you can also execute ASP for example, SQL Injection will let you add, edit and delete records, tables etc, but instead of the hacker using malicious SQL they could essetially write out everything in the session collection. This in itself is not massively dangerous but it will allow someone to see what information your holding. Combine that with SQL injection and it is potentially dangerous...


anyway will stop going on and get back to work...


Thanks

Glen

Glen
Conception | Execution

 

[vanillapod]

see what you mean, I guess ya have to make sure that any user input is checked b4 its processed by the server...

 

[Genimuse]

Indeed, and most importantly -- and the way that SQL injection works -- is that you must always always always always always replace all single quotes (apostrophes) in the user's input with double-single quotes (two apostrophes), a la:

Dim myVar, safeVar
myVar = "Bob O'Hara"

safeVar = Replace(myVar, "'", "''")

Response.Write(safeVar)

which will write out

Bob O''Hara

Not replacing those apostrophes with two apostrophes opens you up to SQL injection. Any string you're going to insert into the database (or update with, or select with, or pass to a stored procedure, or delete with, etc.) has to have that Replace.

 

[Tarwn]

The only way to truly hijack someones session is to get your hands on their Session id and send requests to the server with that session id. The session id is basically a key to a set of records that are kept on the server (in memory), ie any values you set of an individuals session. Without that session id you would have to have physical (or at the least administrative) access to themachie to get the values.
There are two methods of hijacking I can think of, brute force and interception. Basically if you can intercept someones page request then you will havethe cookie with the session id in it and can then use that to spoof a request to the web server with the same session id. The other method is to brute force it, ie send thousands of requests with random Session Id's in the hope that you will run into one that is in use.

However, as long as you only accept CC#'s via https and never display back the full number (even with https), there's not a lot that hijacking a session will do for someone. Sure they could hijack it in a non-protected area and then enter the rotected area, but it wouldn't net them anything. This means that they just spent a lot of work to mayube see whats in the shopping cart...anyone with that much time n their hands for so little gain would probably be more in danger of trying to hack your database.

That said, SQL Injection protection is a must. Even if you have client-side validation you should always validate your data server-side before sending it to the db, making any necessary changes (such as escaping sngle quotes) to ensure that the data is stored and not executed. It is simplicity itself to grab the source of a page, save it locally, delete any offending (validation) javascript, and submit whatever you like in it's place. Client-side validation should only be used to make the clients visit more comfortable. The server-side validation is for your own protection.

-T