веб-приложение с защищенными разделами, сессиями и связанными с ними проблемами - PullRequest
1 голос
/ 12 мая 2010

Я хотел бы создать веб-приложение с защищенными разделами admin / checkout. Предполагая, что у меня настроен SSL для subdomain.mydomain.com, я хотел бы убедиться, что все эти сверхсекретные вещи;), такие как страницы оформления заказа и раздел администратора, передаются безопасно. Было бы хорошо структурировать мою заявку, как показано ниже?

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

Пользователи будут получать доступ к моему веб-приложению через http, так как не требуется SSL для домашней страницы и тому подобное. Страницы Checkout / admin должны быть доступны через https (что я бы гарантировал через перенаправления .htaccess). Я также хотел бы иметь форму входа на каждой странице сайта, включая незащищенные страницы. Теперь мои вопросы:

  1. если у меня есть форма на незащищенной странице, например, http://subdomain.mydomain.com/homepage.php, и эта форма отправляет данные на https : //subdomain.mydomain.com/loginPage.php, данные отправляются в зашифрованном виде как если бы оно было отправлено с https://subdomain.mydomain.com/homepage.php? Я понимаю, что пользователи не увидят замок, но браузер все равно должен его зашифровать, верно?

РЕДАКТИРОВАТЬ: мои извинения .. выше жирным шрифтом я первоначально набрал http, но имел в виду https, мой плохой

2. Если на защищенной странице loginPage.php (или любой другой доступ, доступный через https для этого экземпляра) я создал сеанс, ему будет назначен идентификатор сеанса, а в случае моего веб-приложения. что-то вроде имени пользователя вошедшего в систему пользователя. Смогу ли я получить доступ к этим переменным сеанса из http://subdomain.mydomain.com/homepage.php, например, для отображения приветствия? Если идентификатор сессии хранится в файлах cookie, то я предполагаю, что это будет проблемой, но кто-то может прояснить, как это сделать? Кажется важным, чтобы имя пользователя и пароль отправлялись через SSL.

3. В связи с вышеупомянутым вопросом, я думаю ... действительно ли имеет смысл иметь вход в систему защищенным с помощью SSL, чтобы идентификатор пользователя / пароль передавался безопасно, а затем идентификатор сеанса передавался без SSL? Я имею в виду, не будет ли это на самом деле, если кто-то поймал имя пользователя и пароль передается, или поймал идентификатор сессии? Пожалуйста, дайте мне знать, если у меня есть смысл, потому что мне кажется, что я упускаю что-то важное.

РЕДАКТИРОВАТЬ: Я пришел с идеей, но еще раз, пожалуйста, дайте мне знать, если это будет работать. Имея вышесказанное, предполагая, что совместное использование сеанса между http и https так же безопасно, как вход пользователя в систему через обычный http (не https), я предполагаю, что на всех незащищенных страницах, таких как домашняя страница и т. Д., Я могу проверить, вошел ли пользователь в систему, и Если это так, из php перенаправьте на https версию той же страницы. Таким образом, пользователь заполняет форму входа из homepage.php, более ssl детали отправляются в бэкэнд, так что, вероятно, https: //.../homepage.php. Попытка доступа к сценарию http: //.../someOtherPage.php всегда будет проверять, создан ли сеанс, и если это так, перенаправить пользователя на https версию этой страницы, чтобы https: // ... /someOtherPage.php. Будет ли это работать?

4. Во избежание появления в браузере сообщения "эта страница содержит незащищенные элементы ...", мои ссылки на CSS, изображения и все ресурсы, например, в случае http://subdomain.mydomain.com/checkoutPage1.php должно быть абсолютным, так что "/images/image1.jpg" или относительным так "../images/image1.jpg"? Я думаю, один из них должен был бы работать:)

вау, это длинный пост, спасибо за ваше терпение, если вы зашли так далеко и получили ответы :) о да, и я использую php / apache на виртуальном хостинге

1 Ответ

0 голосов
/ 12 мая 2010

Если SSL-завершение находится на самом веб-сервере, вам, вероятно, потребуется настроить отдельные корни документов для защищенных и незащищенных частей - хотя вы можете указать, что они оба ссылаются на один и тот же физический каталог, вы собираетесь завязывать узлы, переключаясь между частями. Точно так же, если ваше SSL-завершение предшествует веб-серверу, у вас нет систематического разделения защищенных и незащищенных частей.

Намного удобнее разделить защищенные и небезопасные части на отдельные деревья - имейте в виду, что если на защищенной странице есть содержимое, отличное от SSL, пользователи получат предупреждающие сообщения.

Относительно ваших конкретных вопросов

  1. НЕТ - зашифрованы ли данные, зависит от того, куда они идут, а не от того, откуда они поступают

  2. ДА - но только если вы НЕ устанавливаете флаг cookie secure_only - учтите, что если вы следуете моим рекомендациям, указанным выше, вам также необходимо убедиться, что путь к cookie установлен на '/'

  3. страница, которая обрабатывает имя пользователя и пароль, ДОЛЖНА быть безопасной. Если нет, то вы предоставляете данные аутентификации своих клиентов (большинство людей используют один и тот же пароль для всех сайтов, которые они посещают), и любой, кто использует сетевой анализатор или прокси, будет иметь доступ.

Ваш EDIT оставил меня немного смущенным. SSL является вычислительно дорогим и медленным - поэтому вы хотите минимизировать его использование - но вы должны сбалансировать это с восприятием безопасности ваших пользователей - не продолжайте переключаться с SSL на не-SSL, и хотя он совершенно безопасен для пользователей, чтобы ввести их детали на странице, обслуживаемой не-SSL, который отправляет на страницу SSL, пользователи могут не понимать это различие.

  1. См. Первую часть моего ответа выше.

С

...