HTTPS или SSL или TLS, или как вы хотите это назвать, может быть странным чудовищем. Некоторые говорят, что речь идет только о защите вашего пароля и банковской информации, пока пакеты летают по сети, но я давно говорил, что SSL — это не шифрование .
В качестве указания на всю сложность ситуации OWASP говорит о недостаточной безопасности транспортного уровня . Не «сделали ли вы это правильно» или «сделали ли вы это неправильно», скорее вы рассмотрели все мелкие нюансы, которые влияют на правильную реализацию этой бесценной функции безопасности.
Естественно, когда этот твит от Марка Хеммингса появился на моей временной шкале, он был немного заинтригован:
Мы все видели это раньше, верно? Ясно, что это означает, что ваш ценный пароль отправляется по проводам в виде простого текста, и призраки в проводах будут немедленно собирать их и делать с ними ужасные вещи, не так ли? Очевидно нет:
Это не обычная риторика обслуживания клиентов — эти ребята знают об iFrames! Они продолжают:
Ключ здесь — это слово «ключ» в этом предложении. Держись — значит, другие страницы не отправляются через безопасные соединения? Что произойдет, если вы уже вошли в систему?
Это прекрасная возможность вновь рассмотреть причуды HTTPS, потому что, как выясняется, у Марка все в порядке, и здесь происходят некоторые очень недостаточные практики. Позвольте мне разбить его на 5 отдельных проблем и почему каждая из них подрывает реализацию HTTPS не только в Top CashBack, но и на многих других сайтах, следуя той же схеме.
Проблема 1: Отправка конфиденциальных данных по небезопасному соединению
Конечно, вы можете увидеть, где проблема начинается прямо здесь:
Это верно, это регистрационная форма, загруженная по HTTP. Еще до того, как мы приступим к рассмотрению заявления о загрузке имени пользователя по HTTPS, у нас возникла серьезная проблема. Это даже не одно из распространенных недоразумений в духе «О, но это безопасно, потому что оно отправляет сообщения в HTTPS», потому что, ну, это не так (и это не так). Посмотрите HTTP-запрос после заполнения формы, и он выглядит так:
POST http://www.topcashback.co.uk/light-box/join/ HTTP/1.1
А вот переменные формы в теле запроса:
Да, это действительно пароль, который я создал, и да, он действительно отправляется с моего компьютера через все провода на их сервер в виде простого текста. Фактически после регистрации браузером было сделано 140 запросов на загрузку ресурсов на страницу, и некоторые из них были сделаны через HTTPS; один для Facebook, один для Google, один для Doubleclick, но ноль для Top CashBack!
Проблема 2: Смешанный режим
Двигаясь дальше, после регистрации мне было отправлено письмо с подтверждением, и я должным образом перешел по ссылке. Хорошие новости — это HTTPS-адрес! Плохие новости, это не безопасно:
Видите ошибку в нижней части браузера? Это ваша классическая проблема HTTPS в смешанном режиме, когда страница запрашивается по HTTPS, но затем она встраивает ресурсы, запрошенные по HTTP. Риск здесь заключается в том, что целостность этих активов больше не может быть проверена — ими можно было манипулировать. Теперь представьте, что вы можете манипулировать загруженным на сайт JavaScript-кодом, чтобы делать все, что вы хотите; изменить все ссылки на странице, переписать содержимое, украсть куки и так далее и так далее. Короче говоря, после небезопасной загрузки контента вы больше не можете доверять странице, которая его встроила, даже если она была загружена по HTTPS-адресу.
Проблема 3: Отправка файлов cookie авторизации через незащищенное соединение
Ясно, что теперь мы вошли в систему, что дает нам возможность перейти к следующей проблеме. Давайте вернемся к домашней странице, и вы сразу увидите проблему:
Ты видишь это?! Позвольте мне помочь: эта страница была запрошена через HTTP, но каким-то образом она знает, что я вошел в систему, поскольку она может отображать ссылки «Моя учетная запись» и «Выйти» в правом верхнем углу. Как это может быть?
Давайте сделаем шаг назад, и я предоставлю некоторый контекст. HTTP — это протокол без сохранения состояния, который означает, что каждый раз, когда ваш браузер делает запрос, он переходит через совершенно новое соединение без подразумеваемой непрерывности между ними. Это проблематично, потому что это означает, что вы не можете сохранять информацию между запросами, такими как идентификационные данные и тот факт, что вы вошли в систему. Чтобы обойти это ограничение, у нас есть cookie, те небольшие байты данных, которые передаются между клиентом и сервер в заголовках запроса и ответа. Когда вы входите на веб-сайт, это (почти всегда) файл cookie, который отправляется вашему браузеру в ответе, а затем отправляется обратно на сервер с каждым запросом, чтобы убедиться, что он знает, кто вы и что вы аутентифицированы.
Проблема заключается в следующем: если кто-то еще может достать этот cookie, он может стать вами! Это называется перехватом сеанса и включает в себя не что иное, как взломщик, перехватывающий cookie, устанавливающий в своем браузере, а затем вуаля — это вы! Это то, что Firesheep сделал несколько лет назад и вызвал такую суету. Возможно, это был существенный фактор для веб-сайтов, таких как Facebook, везде внедряющих HTTPS, так что сессии не могли быть взломаны таким способом. На самом деле многие сайты получили сообщение очень быстро, но некоторые не …
Этот риск легко проверить, так как HTTP-запрос к странице выше содержал следующий файл cookie:
.TCBAUTH=33813F16896A3527C7B4AC6B8988CE50A694329C9403579EB798A74B1AF938251C6AE61C703CB4FC761A587BE9F6BA4BAC46EE62A015A07E57E3252469C7954A7EBA0AA43121620BC66A7767F85B0064906D5B0F24CBF6D5A17F3AF0392D8889F9F04B80B1AEB3AC3E7376A205D8BB795A1C64BE30AA8073FCD89289A2B8AEBF914D0F4F4EA439BB8A8F16B353AB47EECE0997D089088D8BEDB847B038A9E41FDE9E320935772FB4CAE29FF767702D30C0608FC6054F51BDF4EED3747234AC0212D359B1;
Здесь я покажу вам: я скопировал указанный выше файл cookie, вставил его в сеанс Chrome с помощью « Редактировать этот файл cookie» , загрузил страницу сведений об учетной записи и вот что у меня теперь есть:
Это мои данные! В моем «режиме злоумышленника» я никогда не видел пароль, все, что мне было нужно, — это несколько байтов из файла cookie, отправленного по незащищенному соединению, и я нахожусь. Существует много способов получения злоумышленником файла cookie из незащищенного соединения. , Один из самых простых способов — просто прослушивание беспроводного трафика, как я ранее продемонстрировал , затем старый добрый физический прослушивание телефонных разговоров или просто наблюдение за трафиком через любой из законных узлов, через которые он проходит; маршрутизатор, шлюз, провайдер и т. д.
Как только у вас есть cookie, у вас есть доступ ко всему, что может видеть аутентифицированный пользователь. Например:
Я уверен, что Top CashBack, вероятно, чувствует, что они в безопасности, отправляя это по HTTPS (и, конечно, это само по себе хорошо), но как злоумышленник, это не имеет значения, потому что я уже похитил сеанс, когда печенье было отправлено небезопасно. Все HTTPS на странице выше позволяет злоумышленнику безопасно загрузить страницу!
Проблема 4. Не помечать аутентичные куки как «безопасные»
Это тесно связано с предыдущим пунктом, о котором я писал на прошлой неделе на C, это для cookie, H для хакера — понимание только HTTP и Secure cookie . Давайте снова войдем в систему через Chrome и проверим тот файл cookie авторизации, который мы рассматривали ранее. Вот:
Видите этот «безопасный» вариант? Ну, очевидно, это не так! Проблема, которую это создает, заключается в том, что браузер с радостью отправит этот файл cookie через небезопасное соединение, и на самом деле это проблема, которую мы видели выше, когда страница, загруженная по HTTP, смогла распознать, что мы прошли аутентификацию. В этом случае я подозреваю, что это на самом деле дизайн (что еще хуже), как если бы cookie был действительно безопасным, тогда вы никогда не сможете увидеть свое аутентифицированное состояние, отраженное на этих небезопасных страницах.
Пометка файла cookie как безопасного означает, что браузер просто не будет отправлять его через небезопасное соединение, а это именно то, что вы хотите, когда мы говорим об файлах cookie авторизации. Все HTTPS в мире не спасут вас, когда есть только один непреднамеренный HTTP-запрос, который раскрывает auth cookie, и мы видели ранее, что эта простая ошибка может означать раскрытие серьезных данных, таких как банковская информация.
Задача 5. Использование HTTP для загрузки форм входа
Это заняло до последнего пункта, но позвольте мне вернуться к первоначальному утверждению о загрузке формы входа через HTTPS. Во-первых, мы уже зарегистрировались по протоколу HTTP и отправили наш пароль по небезопасному каналу, а затем отправили этот файл cookie для проверки подлинности в открытом виде, так что к настоящему времени значение, представленное HTTPS, в любом случае практически разбито на куски. Но давайте продолжим.
Когда вы нажимаете кнопку входа в систему, вы получаете следующее:
Вы знаете, что это безопасно, потому что у него есть битмап с замком и он говорит «SECURE LOGIN», верно ?! Здесь на самом деле происходит то, что браузер делает отдельный запрос к этой странице, содержащий форму входа, которая действительно запрашивается через HTTPS. Вопрос в том, как браузер узнал, что нужно запросить эту страницу? Я расскажу вам, как на странице, которую мы первоначально загрузили — небезопасно запрошенной через HTTP — есть следующая разметка:
<a class="login-toggle" href="#" title="Login" onclick="ToggleLogin('https://www.topcashback.co.uk/login?RedirectURL=http%3a%2f%2fwww.topcashback.co.uk%2fhome');return false;" ><span>Login</span></a>
Проблема, конечно, в том, что когда вы загружаете страницу через HTTP, тогда нет защиты от человека, который посередине манипулирует содержимым страницы. Например, ничто не мешает злоумышленнику изменить этот путь входа в систему на свой собственный веб-сайт, после чего он может легко скопировать схему управления входом в систему, и жертва не станет мудрее. Подобное вмешательство не является чем-то новым, на самом деле это то, что мы видели много раз прежде, включая пример правительства Туниса, на который я ссылаюсь здесь .
Так как же это отличается от других более безопасных реализаций? Главное, что «не мудрый» бит; поскольку страница входа в систему загружается в iframe, у пользователя нет возможности видеть сертификат, загруженный в браузер, вы знаете, тот, который обычно совершенно четко виден в адресной строке:
На самом деле, только на этой основе — тот факт, что сертификат не виден — это означает, что реализация полагается на доверие пользователя, а не явно показывает ему «Эй, вот адрес HTTPS и сертификат». Без чего-либо из этого пользователь может лишь предположить, что Марк сделал это с самого начала, а именно, что его учетные данные отправляются в виде простого текста.
Norton обеспечен (поэтому он должен быть безопасным!)
Одна из главных ироний этого сайта — логотип Norton Secured в правом нижнем углу:
Это дает очень обнадеживающий отчет сайта:
Я включил это, чтобы подчеркнуть, что, хотя это может быть обнадеживающим, в этом случае это совершенно бесполезно. Печать находится на странице, загруженной по HTTP-адресу, поэтому теоретически она могла прийти откуда угодно. Но, кроме этого, само утверждение о том, что логотип на странице подразумевает некоторую форму безопасности, когда есть такие явные дыры, немного смешно.
Резюме
Суть всех HTTPS на сайте Top CashBack заключается в следующем: не имеет значения, сколько страниц вы загружаете безопасно, сколько значков замков или сертификатов поставщиков вы перетаскиваете на сайт, когда вы начинаете небезопасно отправлять файлы cookie для проверки подлинности. Тост. Это совершенно бессмысленно , чтобы обеспечить эти банковские реквизиты в пути , но затем дайте аутентификации печенье , которое может загрузить финансовые данные обратно плавать вокруг в незашифрованном виде . Это действительно недостаточное использование HTTPS.