Re: Apache vs IIS
- From: Jerry Stuckle <jstucklex@xxxxxxxxxxxxx>
- Date: Wed, 05 Mar 2008 13:01:31 -0500
Lars wrote:
"Jerry Stuckle" <jstucklex@xxxxxxxxxxxxx> skrev i meddelandet news:FeudndMq9pnpaFDanZ2dnUVZ_sytnZ2d@xxxxxxxxxxxxxxLars wrote:"Jerry Stuckle" <jstucklex@xxxxxxxxxxxxx> skrev i meddelandet news:ZK-dnX_HBoX6XVDanZ2dnUVZ_o7inZ2d@xxxxxxxxxxxxxx<snip>Lars wrote:I stand corrected. After reading the page http://se2.php.net/manual/sv/ref.session.php I wonder if I even should use Sessions at all.But a session cockie can be stored on the clients computer. My homepages that runs Apache on Linux does so. I have to give information to the users on the pages that I use session cockies. It's the law in EU.Incorrect. Session information is always stored on the host. The cookie is only the session ID. No other information related to sessions is stored on the clients computer.
Depending on how Apache server is set up the session cockie can be stored on the clients computer. That way you keep passwords and such things on the clients computer.
LarsYes, I know what the page says. And why not use sessions?
Sure, it's *theoretically* possible that someone can steal your session data - it would have to be another site on the same host with a script specifically written to read the session file.
The problem is that AntiVirus programs like Norton Antivirus and F-Secure mark the site as "Pottential Fraud Page". This just because the page uses session cookies. Norton Antivirus then sends a link to them for evaluation if it is a dangerous site or not. Many users may close the page just by seeing this message even though the page is safe.
That sounds like an over-zealous antivirus program. I admit I don't use either, but I would check to ensure it actually is the session cookie doing it. A lot of sites use cookies. Are you doing something like setting the domain to something other than your site, for instance?
If you really want the session data to be secure, encrypt it before placing it in the session. But that's overkill - a good hosting company will terminate the account of anyone trying to read from someone else's session. Not that it helps much; by the time they discover it, your data can be gone.
But the users will still get the Antivirus Message.
The question is - how important is the data? If you're need absolute security, get your own server and lock it in a closet where only you have the key. Don't allow any ftp, sftp, telnet, ssh, etc. Make it secure. Of course, you'll also have to get multiple T-3 lines through different ISP's for backup and a generator for when power goes out.
I see no problem using sftp or ssh for an ordinary homepage as mine. After all I need to be able to upload the files to the server some how since the server isn't in the same office.
My point being that it's the only way you can ensure true security for a server.
If you really need to store secure things like backuped healt insurance on a site for customers you need to encrypt the data before sending them to the server. This is a demand from the healt department in country where I live. As long as the customer who uploads the backuped files encrypt them the safety is accaptable good.
Backed up files is one thing - live data is another. Are you expecting the user to download the data then run a program to decrypt it?
As for backups: If the imnormation is realy important you need to do more than send the information over a T3 line. You need to make sure you have at least 3 copies of the data on 3 different locations. I was involved in such a project for more than 2 years.
I wasn't talking about backups. I was talking about your web server.
That's what banks and other financial institutions do, for instance.
But 99.9999% of the sites don't need that level of security, and the risk is manageable.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@xxxxxxxxxxxxx
==================
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@xxxxxxxxxxxxx
==================
.
- Follow-Ups:
- Re: Apache vs IIS
- From: Lars
- Re: Apache vs IIS
- References:
- Re: Apache vs IIS
- From: Lars
- Re: Apache vs IIS
- From: Jerry Stuckle
- Re: Apache vs IIS
- From: Lars
- Re: Apache vs IIS
- From: Jerry Stuckle
- Re: Apache vs IIS
- From: Lars
- Re: Apache vs IIS
- From: J.O. Aho
- Re: Apache vs IIS
- From: Lars
- Re: Apache vs IIS
- From: J.O. Aho
- Re: Apache vs IIS
- From: Lars
- Re: Apache vs IIS
- From: Jerry Stuckle
- Re: Apache vs IIS
- From: Lars
- Re: Apache vs IIS
- From: Jerry Stuckle
- Re: Apache vs IIS
- From: Lars
- Re: Apache vs IIS
- Prev by Date: Re: Apache vs IIS
- Next by Date: Re: Apache vs IIS
- Previous by thread: Re: Apache vs IIS
- Next by thread: Re: Apache vs IIS
- Index(es):