Первым делом отключил JavaScript в отладочной консоли Chrome:
Так, и что же мы видим:
А видим мы то, что чудесным образом покинули зону https и браузер никак про это не сообщил. Аналогично происходит в Internet Explorer в Windows и в Safari в OS X. Это кажется немного странным, при том, что браузеры обычно переживают из-за смешанного содержимого на странице или о том, что вы покидаете безопасную зону.
Разбор лога показал, что происходит следующая цепочка перенаправлений:
- Заходим на https://pgu.mos.ru и получаем ответ от сервера «301 Moved Permanently» с адресом http://pgu.mos.ru/ru/ (вот он, тихий выход из https).
- По адресу http://pgu.mos.ru/ru/ возвращается ответ «403 Forbidden» и страница «Privacy Required» как на картинке выше. На странице, которая «This is a WebSEAL error message template file», содержится следующий скрипт:
<script language="JavaScript"> var href = self.location.href; var originalURL = href.substring(7,href.length); self.location = 'https://' + originalURL;</script>
- Попадаем на https://pgu.mos.ru/ru/.
В результате видим небольшое мерцание в адресной строке и вроде бы все хорошо, но данная странная реализация делает возможной атаку, когда можно подменить сайт http и перенаправить на свой фейковый https сервер. Другими словами становится легко реализуема MITM-атака. Особенно опасно это из-за того, что пользователи если и смотрят на валидность сертификата сайта, до делают это только на первой странице.
Перенаправление с главной страницы не единственное. Аналогично происходит если ткнуть во многие ссылки на портале. Например, так происходит со ссылкой «Центры госуслуг» на главной страницы (https://pgu.mos.ru/ru/mfc). Серверу не нравится что адрес не имеет «/» на конце и он перенаправляется через http зону в правильный, по мнению сервера, адрес.
Собственно, о результатах своего расследования я и написал в форму обратной связи на сайте pgu.mos.ru. Ответ получил совершенно шикарный: «Пришлите скриншот ошибки». При том, что ни про какую ошибку я им вообще не писал, а писал о проблеме с безопасностью. За все это время (обращение и ожидание ответа), проблема так и не была исправлена. В статью добавил скриншот ошибки как раз на случай, если прочитают админы городского портала.
Хм. а как само наличие редиректа помогает в проведении атаки? Беда тут только в том, что способ кривой (на стороне клиента), а в остальном - вполне себе типовое решение. Например:
ОтветитьУдалитьwget http://www.facebook.com
--2015-05-13 10:46:56-- http://www.facebook.com/
Resolving www.facebook.com... 31.13.64.1, 2a03:2880:f01c:2:face:b00c:0:1
Connecting to www.facebook.com|31.13.64.1|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://www.facebook.com/ [following]
--2015-05-13 10:46:56-- https://www.facebook.com/
В вашем примере переход идет изначально с http адреса. А я говорю о том, что перенаправление идет с https на http. Что, вообще говоря, небезопасно.
ОтветитьУдалитьЭто означает, что пользователь зашел на https, убедился, что сертификат верен (сайт не поддельный). Далее большинство тыкает в ссылки уже не задумываясь, т.к. сайт надежный. Но ссылки ведут на небезопасный адрес, который злоумышленники могут подменить своим сервером. Далее данные пользователя попадают на сервер злоумышленника и только потом на конечный сервер. По пути остаются данные аутентификации, номера кредитных карт и т.п.
Атаку особенно удобно осуществлять в общественных местах, т.к. часто публичные точки доступа не изолируют пользователей. Но это уже другая история.
ОтветитьУдалитьАаа, понял, спасибо.Там беда в том, что используется две различные системы, причём во вторую приходит вcегда HTTP. Вот и начинается пинг-понг. По идее, должно будет уйти после переделки системы проксирования, у них это в планах на этот год
ОтветитьУдалитьГлавное, чтобы до закрытия всех проблем никто не использовал эту уязвимость.
ОтветитьУдалитьМожно еще поговорить о том, что прямо в ответе видно, что там WebSEAL используется. Это тоже дает некоторую информацию о внутренней структуре и дает потенциальную возможность атаковать уже сам портал.