Уязвимые интерактивные государственные услуги на пороге Нового Года (часть 2/5)

Знакомство

«Дерево, как бы мощны и крепки ни были его корни, можно выкорчевать за какой-нибудь час,

но нужны годы, чтобы оно стало плодоносить»

– Ас-Самарканди


За несколько минут перерыва произошло не мало интересного. C новостями/акциями удалось ознакомиться и неожиданный флешбэк, но главное это то, что разрешилась дилемма, и нашлась задача, где будут применены новые знания языка Lua. Пожалуй, можно начинать новый проект, в котором будет проведено исследование, цель которого оценить масштаб одной обнаруженной уязвимости. Подумав еще немного от оставшегося времени перерыва, параллельно набросав план действий и запустив новый раунд помидора, был дан старт проекта. Тут все элементарно и как бывает обычно по RDD. Инструментами в проекте были выбраны, Lua-cURL и парсер xml2lua. Схема работы предельно проста, с помощью Lua-cURL отправляется запрос на целевой ресурс, конечно же через проски, полученный ответ постоянно перезаписывал содержимое временного файла, который создавался благодаря стандартному методу io.tmpfile() существующего в средствах ввода-вывода, далее содержимое считывалось и прогонялось через xml2lua. Все это работало медленно, возможных причин тому несколько, например, по причине использования бесплатного анонимного прокси или ответ был достаточно велик, достигая ~45Кб и для библиотеки парсинга уже становилось не легкой задачей. Однако, хуже всего, что были проблемы со стабильностью, временами интерпретатор сильно спотыкался и падал. Понятно, что изначально плохой идеей является использование парсера заточенного под валидный XML для не совсем валидного HTML который обычно встречается на сайтах. Основная причина, падения была установлена опытным путем и это «[[» в скрипте Google Analytics, которые встречались в исходном коде страницы. Данная скобочная форма служит в языке Lua для задания строковых литералов и корректно расцениваются интерпретатором, а в текущий момент этого как раз не требовалось, поэтому пришлось отказаться от способа. Ну что ж, была идея с самого начала построить проект на регулярных выражениях и обойтись без каких-либо библиотек парсинга. Возвращение к первичной идее означало, что теперь в схеме работы вместо парсинга содержимого временного файла, применялось регулярное выражение, приблизительно такого вида: <input type="text".-name=\'EMAIL\'.-> и выдергивалась часть, подходящая под выражение. Отлично, теперь все завелось и работало стабильно, а спустя некоторое время первые результаты были получены. Число e-mail адресов оказалось не много меньше 1000 – интересно, но как же так, почему официальный сайт, разработанный некоторой известной компанией, на известном платном движке, скорее всего с 2011 года светит в сети приватными данными, а так же мог не однократно использоваться в качестве источника. А заинтересованных здесь достаточно это и спамеры, и конкуренты – в принципе уже не мало, хотя безусловно это только начало списка. Очевидным становится факт, что уязвимости могут жить годами, что довольно печально, особенно если организаций Республиканского масштаба.

Скорректировав изначальный план, было решено поближе познакомиться с портфолио компании-разработчика. Из списка реализованных проектов отобрались еще 3 кандидата, оф. сайты которых были реализованы в 2014-2015 годах. Та же проблема оказалась и на всех кандидатах. Исследование было продолжено, общее число e-mail адресов на новых целевых ресурсах не было слишком большим, хотя тоже исчислялось несколькими сотнями единиц. Количественный результат на первом целевом ресурсе в разы превышал суммарный результат всех остальных целей. К этому моменту, число объектов исследования выросло до шести. В портфолио компании-разработчика еще было множество проектов, но и 6 исследованных оф. сайтов крупных организаций уже было более чем достаточно. Какое можно было сделать заключение, что видимо с 2011 года ничего не изменилось у компании-разработчика и это, конечно же, огорчало. Предположим, ошибки допущены во время разработки, но приемку осуществляет компания-заказчик. Основываясь на имеющихся данных, получается ли так, что приемка ничем не отчается даже в одном из двух банков с рейтингом uzA+ (данные рейтинга 2016 года), которым «посчастливилось» попасть в качестве объектов исследования. В каждом случае была допущена одна и та же ошибка, еще один вопрос возник сам собой: «А были ли вообще приемки?», если «Да», то почему такого качества и сколько еще граблей подложит компания-разработчик своим клиентам, прежде чем это кто-то заметит и каким-то образом устранит. Вопросов всегда больше, чем ответов. В такие моменты складывается впечатление, что заказ оф. сайта у разработчика, походит на покупку продуктов на рынке, по принципу «купил-забыл». Но столько раз уже обсуждалось и доказывалось, что платный движок – не гарант безопасности. А разработка чего-бы там ни было – это в первую очередь услуга, а значит и должна быть какая-то поддержка, внутренняя или внешняя.

Уровень сервиса не должен находиться на одном уровне годами. Японская мудрость гласит: "Быстро — это медленно, но без перерывов", вероятно, можно будет провести параллели между качеством предоставляемых услуг, которое должно расти, пусть и медленно. А вот пребывание без изменений на одном уровне достаточно долго – равносильно падению, на фоне тех, кто продолжает достигать новые высоты. Нужно отметить еще тот факт, что все оф. сайты принадлежащие к объектам исследования, продолжают работать по http протоколу, то есть никакого шифрования при передаче данных по сетям. Пользователи даже не могут быть уверены, что открывают «правильный» сайт, а не подложенный злоумышленниками. Иными словами, владельцы сайтов, продолжают подвергать риску данные, которые передаются от клиента к серверу, путем потенциальной возможности применения MITM-атаки. Разработчики Google писали в своем блоге, что в 2017 году будут помечать все сайты без SSL-сертификатов как ненадежные, кроме того, ранее еще сообщалось о негативном влиянии на ранжирование в выдачи результатов поисковых систем. Возможно и WWW.UZ когда-нибудь станет помечать тегами доверенные и не доверенные ресурсы Узнета. Видимо, несмотря на все требования времени к безопасности, в том числе информационной и возможности получения бесплатного криптографического сертификата от существующих центров сертификации, чего-то все равно не хватает. В подпункте «г» пункта 10 из ПКМ № 355, указана необходимость безопасного доступа к оф. сайтам. Формулировка, не явно, но и так понятно, что указывает на наличие https. Вот только, не многие решаются проявить инициативу и присоединиться к проекту «Зеленый Узнет», – таким образом, повысить доверие пользователей к ресурсу и обезопасить данные. Организации, работающие в сфере услуг, лучше других вроде бы должны понимать, что забота о клиентах проявляется в именно деталях – это один из факторов влияющий на долгосрочные перспективные отношения.


Izohlar (0)

Авторизуйтесь, чтобы добавлять комментарии
Bizga xabar yuboring