Возможно ли, будучи совместимым с PCI, иметь безопасный вход в лайтбокс (https) на незащищенной странице (http)? Если да, будут ли на странице отображаться правильные значки/замки безопасности?
Https (безопасный) вход в лайтбокс на http-странице
Ответы (1)
Это уязвимо по нескольким причинам. Злоумышленник может просто использовать SSLStrip, чтобы удалить логин https и пароль MITM.
Кроме того, почему вы просто используете HTTPS для входа в систему? Его следует использовать на протяжении всей жизни сеанса или же он полностью бесполезен. Вы нарушаете OWASP A9, и это может быть использовано с помощью Firesheep.
person
rook
schedule
02.03.2011
Полностью и совершенно бесполезно — это преувеличение. Направление пользователя на HTTPS для входа предотвращает кражу его учетных данных для входа, и, учитывая скорость повторного использования пароля, это очень полезная вещь. Сеанс пользователя может быть захвачен, но не другие учетные записи пользователя. Кроме того, если приняты соответствующие меры (например, требование повторного ввода пароля через HTTPS перед определенными действиями), сам сеанс может быть перехвачен, но злоумышленник ограничен в действиях, которые он или она может выполнять с ним.
- person Ben Regenspan; 25.08.2011
@ Бен, что, если это учетная запись администратора? Я по-прежнему поддерживаю OWASP, HTTPS — это все или ничего.
- person rook; 25.08.2011
если это учетная запись администратора, то не использовать HTTPS — определенно ужасная идея. И я полностью согласен с тем, что идеально следовать OWASP буквально. Но в гипотетическом случае, когда кто-то не может получить бюджетные ресурсы, чтобы полностью использовать HTTPS (скажем, они стоят за Akamai, которая, по-видимому, может взимать 2X или больше за HTTPS-трафик через HTTP), им будет, по крайней мере, немного лучше указать функциональность входа в HTTPS, а также требование подтверждения пароля через HTTPS для любого критического изменения учетной записи. Это не будет идеальной реализацией, но она также не будет отправлять пароли в открытом виде.
- person Ben Regenspan; 26.08.2011
@Ben Это плагиат, и он подвергает ваших пользователей атаке. Это почти идентично принуждению вашего приложения к уязвимости XSS, любой злоумышленник может просто прийти и перехватить сеанс. Может быть случай, когда вы манипулируете двумя идентификаторами сеанса, один из которых имеет установленный безопасный флаг, чтобы всегда передавать через https и требуется для изменения состояния. Но это очень сложно, и я не знаю ни одного приложения, которое бы это использовало.
- person rook; 26.08.2011
Один пример сайта с открытой сессией: Stack Overflow. (Я не уверен, что они делают для интерфейса администратора, и если это тот же файл cookie сеанса или безопасный файл cookie)
- person Ben Regenspan; 26.08.2011
Извините, @Rook, я вижу, вы уже знаете об этом из соответствующего обсуждения на meta.so :)
- person Ben Regenspan; 26.08.2011
