Richard Lynch wrote: >>>Your form action parameter has an absolute url specifying an https >>>protocol. When the browser submits the form, it uses the url you specify >>>which is https. So the request is going to be encrypted. You might >>>consider serving the form page from https as well to kind of tighten >>>things up a little >>> >>> >>What is tightened up exactly? The original poster is probably trying to >>avoid SSL everywhere possible, thus the question. This is a very >>considerate approach, because SSL more than triples the amount of time >>taken to complete the HTTP transaction. He's trying to be polite to his >>users, rather than using SSL on one more page just to be safe, which is >>a tactic I applaud. >> >> > >Unfortunately, the messages going to the naive surfer will not make it clear >when/where the "secure zone" is entered: *BEFORE* my data is sent, or >*AFTER*? > >Better to have the *USER* (who shouldn't have to understand squat about >HTTPS and SSL and servers) be told they are "secure" when they hit the form, >and "insecure" only on the page after the page that took their information. >
This is actually a very good point. In my purely logical approach to the question, I did not stop to think that a user entering a credit card number on a page without a little lock icon is not going to feel secure. >>Why would you consider this badly misconfigured? I would wager that >>*most* Web sites use the same document root for both http and https. Do >>you think this is insecure? Remember, the reason for using SSL is to >>protect the data during transmission, *not* the data sitting on the >>server, wherever that may be. >> >> > >In a shared server environment, if an ISP wants to provide SSL, and they let >anybody put anything into the web-tree... > >Hey, I like the convenience, and that's how my host does it, but I'm not >fooling myself that there aren't dumb CGI scripts out there that are >exposing data they shouldn't between my colleagues' web-sites. > >I know *I* work very hard to not let any data "leak" into the file-system, >process space, or any place that my fellow users can get to it, but I'm >pretty damn sure other web developers are clueless about how much info I >could go digging for if I wanted to. > >My old ISP had SSL on another server (or at least directory) and personally >vetted every line of code that went on it. Royal PITA, but more secure. > >You are correct that SSL only protects the data between browser/server. >That does not negate the "chinks" in the armor in a shared environment using >the same web-tree directory to store scripts, and probably sensitive data, >by the stupid. > >In other words, it won't make SSL itself any more secure, but it *DOES* make >a difference in the data/scripts after SSL is done, and before they safely >store/remove the data. > I still don't buy any of this. *shrug* I fail to see how having your SSL document root in a different place is a security benefit. Whether SSL or not, a configuration that allows other users to access your files poses a potential risk. Using separate trees in this way to isolate yourself from others users is just one way of avoiding this, and not one that I would consider that good. Maybe it's just me though. :) Cheers. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
