application Web avec sections sécurisées, sessions et problèmes connexes

Question

Je souhaite créer une application Web avec des sections admin/checkout sécurisées. En supposant que j'ai SSL mis en place pour subdomain.mydomain.com je voudrais faire en sorte que tout ce truc top-secret;) comme les pages de paiement et la section admin est transféré en toute sécurité. Serait-il acceptable de structurer ma demande comme ci-dessous?

subdomain.mydomain.com 
    adminSectionFolder 
     adminPage1.php 
     adminPage2.php 
    checkoutPagesFolder 
     checkoutPage1.php 
     checkoutPage2.php 
     checkoutPage3.php 
    homepage.php 
    loginPage.php 
    someOtherPage.php 
    someNonSecureFolder 
     nonSecurePage1.php 
     nonSecurePage2.php 
     nonSecurePage3.php 
    imagesFolder 
     image1.jpg 
     image2.jpg 
     image3.jpg 

Les utilisateurs accéderaient à mon application Web via http car il n'y a pas besoin de SSL pour la page d'accueil et similaire. Checkout/admin pages devraient être accessibles via https si (que je m'assurerais via des redirections .htaccess). J'aimerais également avoir un formulaire de connexion sur chaque page du site, y compris les pages non sécurisées. Maintenant, mes questions sont les suivantes:

1. si je forme à la page non sécurisée par exemple http://subdomain.mydomain.com/homepage.php et cette forme envoie des données à https: //subdomain.mydomain.com/loginPage.php, est données chiffrées envoyer comme si elle a été envoyée par https://subdomain.mydomain.com/homepage.php? Je me rends compte que les utilisateurs ne verront pas le cadenas, mais le navigateur devrait encore le crypter, est-ce exact?

EDIT: mes excuses .. ci-dessus en gras je tapé à l'origine http, mais signifiait https, mon mauvais

à la page 2. Si les loginPage.php sécurisé (ou tout autre via https pour accédé cette instance) I la session créée, l'ID de la session sera attribué et dans le cas de mon application Web. quelque chose comme le nom d'utilisateur de l'utilisateur connecté. Serais-je capable d'accéder à ces variables de session de http://subdomain.mydomain.com/homepage.php pour afficher un message d'accueil par exemple? Si l'identifiant de la session est stocké dans les cookies, je suppose que ce serait un problème, mais quelqu'un pourrait-il clarifier comment cela devrait être fait? Il semble important d'avoir un nom d'utilisateur et un mot de passe envoyé par SSL.

3.Related à la question ci-dessus je pense .. Serait-il vraiment logique d'avoir une connexion sécurisée via SSL afin usenrame/mot de passe serait transféré en toute sécurité, puis ID de session en cours de transfert sans SSL? Je veux dire que ce ne serait pas la même chose vraiment si quelqu'un a attrapé le nom d'utilisateur et le mot de passe étant transféré, ou a attrapé l'identification de session? S'il vous plaît laissez-moi savoir si j'ai un sens ici parce que j'ai l'impression qu'il me manque quelque chose d'important.

EDIT: Je suis venu avec l'idée mais encore une fois s'il vous plaît laissez-moi savoir si cela fonctionnerait. Ayant ci-dessus, supposant que la session de partage entre http et https est aussi sécurisée que la connexion à l'utilisateur via http simple (pas https), je suppose sur toutes les pages non sécurisées, comme page d'accueil, etc. si c'est le cas de la redirection php vers la version https de la même page. Donc, l'utilisateur remplit le formulaire de connexion de homepage.php, plus de détails ssl sont envoyés au backend donc probablement https://.../homepage.php. Essayer d'accéder au script http://.../someOtherPage.php vérifie toujours si la session est créée et, si tel est le cas, redirige l'utilisateur vers la version https de cette page, donc https://.../someOtherPage.php. Cela fonctionnerait-il?

4.Pour éviter les messages de survol du navigateur "cette page contient des éléments non sécurisés ..." mes liens vers les css, images et tous les éléments d'actif, par ex. dans le cas de http://subdomain.mydomain.com/checkoutPage1.php devrait être absolue de sorte que "/images/image1.jpg" ou relative "../images/image1.jpg"? Je suppose que l'un de ceux qui devraient travailler :)

wow c'est long message, merci pour votre patience si vous avez jusque-là et toutes les réponses :) oh yeh et j'utiliser php/apache sur l'hébergement mutualisé

Answer 1

Si la terminaison SSL est sur le serveur web lui-même, alors vous aurez probablement besoin de configurer des racines de document séparées pour les parties sécurisées et non sécurisées - bien que vous puissiez spécifier que ces deux références référencent le même répertoire physique, vous allez être lié noeuds de commutation entre les parties.De même, si votre terminaison SSL est antérieure au serveur Web, vous n'avez pas de séparation systématique entre les parties sécurisées et non sécurisées.

Il est beaucoup plus ordonné de séparer les parties sécurisées et non sécurisées dans des arbres séparés - notez que si vous avez du contenu non-SSL sur une page sécurisée, les utilisateurs recevront des messages d'avertissement.

Salutations à vos questions

1. NO - si les données sont chiffrées dépend de l'endroit où il va, pas où il vient

2. OUI - mais seulement si vous ne définissez pas la secure_only cookie flag - notez que si vous suivez mes recommandations ci-dessus, vous devez également vous assurer que le chemin du cookie est défini sur '/'

3. la page qui traite le nom d'utilisateur et le mot de passe DOIT être sécurisée. Si ce n'est pas le cas, vous exposer les détails d'authentification de vos clients (la plupart des gens utilisent le même mot de passe pour tous les sites qu'ils visitent) et tous ceux qui utilisent un sniffer ou un proxy ont accès.

Votre EDIT m'a laissé un peu confus. Le SSL est coûteux en termes de calcul et lent - donc vous voulez minimiser son utilisation - mais vous devez équilibrer cela avec la perception de sécurité de vos utilisateurs - ne passez pas du SSL au non SSL, et bien qu'il soit parfaitement sécurisé pour que les utilisateurs entrent leur les détails sur une page servie par non-SSL qui envoie à une page SSL, les utilisateurs peuvent ne pas comprendre cette distinction.

4. Voir la première partie de ma réponse ci-dessus.

C.