CC BY
20УДК: 004.056.5
МЕТОДЫ ЗАЩИТЫ ДАННЫХ В СЕТИ ИНТЕРНЕТ НА СТОРОНЕ КЛИЕНТА
Липартелиани Г. Г., магистрант Невежин В.П., к.т.н., профессор - научный руководитель
Финансовый Университет при Правительстве Российской Федерации (Финуниверситет), г. Москва
Аннотация. На сегодняшний день подавляющее большинство приложений работают в разных информационных сетях и используют самую распространенную сетевую архитектуру «клиент-сервер». В статье рассмотрены методы защиты на стороне клиента, которыми оперирует разработчик во время проектирования алгоритмов функционирования веб-приложений, а также наглядно показаны примеры пренебрежения перечисленными методиками на примере обезличенных общедоступных сервисов в сети Интернет, функционирующих на территории Российской Федерации.
Ключевые слова: защита данных, сеть интернет, веб-приложения, уязвимость веб-приложений, сети, базы данных.
METHODS OF CLIENT-SIDE DATA PROTECTION ON THE INTERNET
Liparteliani G., student Nevezhin Viktor, professor - scientific director Financial University under the Government of the Russian Federation, Moscow
Abstract. To date, the vast majority of applications work in different informational networks and use the most common network architecture "client-server". The article considers the methods of protection on the client side, which operates the developer during the design of algorithms web applications, and illustrated the examples of neglect listed methods on the example of the impersonal public services in the Internet, functioning on the territory of the Russian Federation.
Key words: data protection, Internet, web application vulnerability, web application, network, database.
Всемирная сеть Интернет позволяет человечеству объединять свои знания, делиться новостями, просто общаться или даже совершать покупки в сети Интернет. В век инновационных технологий использование сетевых ресурсов стало настолько привычным для людей занятием, что мало кто задумывается о том, как работают сервисы, без которых последние не могут представить себе и дня.
Многие слышали слово «сервер», некоторые даже знают, что по факту это ничто иное как обычный компьютер, который сегодня стоит в каждом доме. Сервер (англ. обработчик, распределитель) - компьютер к которому клиент (веб-браузер пользователя) отправляет структурированные запросы с заданными параметрами, исходя из которых на сервере выполняется специальный заданный
разработчиком алгоритм, возвращающий «Хроноэкономика» № 5 (7). Октябрь 2017
ответный пакет данных браузеру пользователя. При переходе пользователя на любой веб-сайт, происходит передача пакета данных на сервер для обработки. В частности, передаются:
• URL-адрес, содержащий в себе открытые данные для обработки
• служебная информация такая как, браузер пользователя, его часовой пояс, №-адреса, адрес предыдущего посещенного сайта и др.
Сервер получает эту информацию, обрабатывает в соответствии с
запрограммированной логикой и передает пользователю так называемый ответ, который может содержать сформированную вебстраницу, отказ в доступе, команду перенаправления на другой сайт или любую другую информацию. Браузер, в свою очередь,
имеет собственные «вшитые» в его ядро обработчики, отображающие пользователю ответные данные в понятном и ясном для него виде. Ответный пакет данных напрямую зависит от того, как было настроено поведение сервера в зависимости от конкретного запроса пользователя. Концепция «клиент-сервер» подразумевает хранение на сервере программного кода, к которому рядовой пользователь не имеет прямого доступа. Как описывалось ранее, последний может лишь отправлять в этот «черный ящик» данные и получать на них от последнего ответ, к которому пользователь имеет абсолютно полный доступ к восприятию и, при желании, к последующему редактированию. Но стоит отметить, что редактируя уже полученный ответ сервера, пользователь не меняет логику работы сервера для последующих запросов.
Но на самом ли деле это так? С первого взгляда может показаться, что при такой структуре взаимодействия веб приложение абсолютно защищено от действий злоумышленников или неумелых пользователей сети Интернет. Но в действительности имеется не одна уязвимость, которые с первого взгляда неочевидны. Далее будут рассмотрены лишь некоторые из них и даны рекомендации по методам уменьшения вероятности их возникновения.
Рассмотрим форму обратной связи на каком-нибудь сайте К, который занимается продажей каких-либо товаров. В данной форме от пользователя просят заполнить два поля: электронную почту и номер телефона для дальнейшей связи с ним. Пользователь, заполняя требуемые от него для отправки поля, может легко допустить ошибку, поэтому не исключено, что телефон или электронная почта могут оказаться неверными. В результате компания может потерять ценного клиента и прибыль, ради которой она и работает. Данную проблему можно легко избежать, проверяя данные перед отправкой их на сервер. Например, можно было бы встроить проверку на обязательное наличие символов «@» и «.», а также проверить отсутствие невозможных символов в адресе
электронной почты. Тогда клиент сразу бы увидел допущенную ошибку и для отправки формы ему пришлось бы внести необходимые корректировки. Рассмотренная проверка требует обработки на языке программирования, который выполнялся бы в среде браузера до отправки запроса с на сервер.
Основным стандартным языком
программирования в среде любого браузера является JavaScript (далее по тексту - JS). Он позволяет обрабатывать данные прямо на стороне клиента используя мощности компьютера и, в некоторых случаях, снижать нагрузку на сервер. Благодаря ему визуальные составляющие веб-сайтов сегодня получили массу возможностей в изменении контента прямо в браузере пользователя без необходимости перезагрузки страницы.
Ранее был рассмотрен относительно безобидный пример ошибки при заполнении полей формы. Но злоумышленники могут в своих целях намеренно подставлять неверные данные, чтобы незапланированно повлиять на работу сервера. Программный код на стороне клиента большинство браузеров позволяет редактировать. В результате пользователь может полностью изменить структуру веб-страницы, заложенную логику отправки данных на сервер. Поэтому обрабатывая данные, полученные от клиента, на сервере разработчику необходимо повторно проверять полученные данные. Возвращаясь к рассматриваемому примеру, злоумышленник может отправить вместо электронной почты вредоносный скрипт, который нарушит работу сервера или, что еще хуже, передаст конфиденциальные данные другим злоумышленникам. Поэтому, в первую очередь, разработчику веб-приложения необходимо четко продумать, какими способами изменение программного кода, находящегося на стороне клиента, можно нарушить заложенную логику поведения сайта. Стоит еще раз подчеркнуть, что изменение данных в браузере не означает, что другие пользователи сети Интернет также увидят эти изменения. Последние хранятся только на устройстве клиента. В результате сразу после перезагрузки
веб-страницы, данные с сервера будут получены заново и все локальные изменения будут потеряны. Однако, как уже отмечалось, можно изменить локально код, который, например, отвечает за отправку данных на сервер, и тем самым вызвать незапланированное поведение веб-приложения.
Широкий функционал JS влечет за собой больше возможностей для возникновения ошибок и атак злоумышленников. В частности, JS позволяет динамически изменять контент страницы или просто передавать/получать данные, выполняя при этом запросы к серверу, без перезагрузки страницы. Данная технология получила название AJAX. Наиболее распространенная ошибка при использовании данной технологией состоит в отсутствии проверки на повторную отправку запроса на сервер. Иными словами, пользователь совершает какое-либо действие на веб-странице, которое влечет за собой запуск синхронного AJAX-запроса серверу. Т.к. выполнение данного запроса не сопровождается перезагрузкой страницы, то в процессе обмена данными и ожидания получения ответа от сервера на сайте не будет происходить никаких изменений. Пользователь сайта, не ведая о работающем процессе, может попробовать выполнить такой же запрос повторно. В результате возникает так называемое «накладывание» запросов, что может привести не только к некорректной работе сайта, но и повлечет повышенную нагрузку на сервер. Для избегания данной проблемы опытные разработчики специально внедряют проверки на повторный запуск не завершенных AJAX-запросов.
Для того, чтобы максимально снизить вероятность редактирования JS программного кода на клиентской стороне разработчики не редко прибегают к использованию процесса минификации или обфускации готового JS-кода. Этот процесс представляет из себя сжатие написанного кода путем удаления всех лишних пробелов, табуляции, переводов строк, комментариев разработчиков, а также изменение названий переменных на короткие интуитивно-непонятные. Наиболее известны следующие
«минификаторы»: S Packer, JSmin, YUI Compressor, Closure compiler и др. Применение названных инструментов позволяет сократить размер исходного кода в несколько раз, что уменьшает размер ответного пакета данных, что повышает скорость загрузки сайта и, как следствие, сокращает расход пользовательского и серверного Интернет-трафика. Помимо этого, код становится гораздо более сложным к восприятию человеческим глазом. Даже опытному разработчику будет тяжело вникнуть в заложенную в код логику после его минификации.
Естественно существуют инструменты, позволяющие произвести обратный процесс деминификации, но они лишь помогают сделать код чуть более «читаемым», оставляя сложность понимания его действий. Наиболее распространенный деминификатор - jsbeautifier. В конечном итоге, если злоумышленник захочет разобраться в JS-коде для его последующего редактирования, то ему придется скопировать сжатый код, деминизировать его и затем, путем поиска нужных фраз, заменять его части. Однако, минификация позволяет затруднить этот процесс редактирования кода в несколько раз и возможно оттолкнуть часть тех, кто хотел «поэкспериментировать» с кодами сайта.
Сразу несколько уязвимостей не были закрыты в веб приложении разработчиками одной из компаний, которая по случайному стечению обстоятельств является разработчиком известного программного продукта на территории РФ. Это веб-приложение было создано для тестирования знания методов работы в продаваемом продукте для последующей выдачи сертификата, подтверждающее знания тестируемого.
Тестирование состоит из 20 текстовых вопросов с 4 вариантами ответа на выбор, при этом имеется возможность пропускать вопросы, менять ответы, возвращаясь к уже отвеченным вопросам. По прохождению всех 20 вопросов, пользователь подтверждает завершение теста, после чего он узнает свой результат и видит таблицу сверки его ответов в сопоставлении с верными ответами.
На сегодняшний день у любого современного браузера есть консоль для разработчика, которая помогает удобно просматривать, вносить изменения и выполнять JS-коды без необходимости перезагрузки страницы, таким образом «превращая» веб-страницу в среду программирования.
Используя данный инструмент мной был обнаружен основной файл теста: main.js. Данный скрипт не был минифицирован или как-либо зашифрован перед загрузкой его на работающий сервер, поэтому даже комментарии разработчика оставались на месте. В этом скрипте было найдено событие onclick (нажатие левой кнопкой мыши), которое было привязано к кнопке "Завершить тестирование". Данное событие вызывало функцию sendData с единственным параметром - true, а также перекидывало пользователя на страницу с результатами:
document.getElementById(„submittest'). onclick =function(){
sendData(true); //Отправка ответов на сервер для обработки
document.location = „/test/results/';
//Перенаправление на страницу с результатами }
Таким образом, мною было замечено, что функция sendData не перенаправляет информацию на другую страницу, а это значит, что можно вызвать ее из консоли браузера. Тем самым, отправив данные для проверки на сервер, остаться на странице с условиями теста, где можно менять ответы. Проверка замечания дала ожидаемый результат: ответы на вопросы теста были отправлены на сервер для проверки, а пользователь остался на странице с тестированием.
Осталось лишь проверить еще одну уязвимость на доверие полученным от пользователя данных. Для этого были отправлены новые ответы на тестирование, которые перезаписали предыдущие результаты теста. Методом подбора можно было подобрать правильные ответы, сверяясь со страницей результатов тестирования. Но, в данном случае, как уже упоминалось ранее, тест не только дает
возможность узнать пользователю свои результат, но и указывает ему верные ответы на все вопросы завершенного тестирования.
Таким образом, мноИ был разобран пример того, как пренебрежение средствами «закрытия» уязвимостей веб-приложения, в частности отсутствие минификации сценария JS, а что еще важнее, непродуманность логики работы приложения, как на стороне клиента, так и на стороне сервера, привело к появлению метода прохождения теста на 100% вне зависимости от сложности вопросов. Это делает веб-приложение бесполезным, а выдаваемый сертификат незначимым.
Список использованных источников
1. Асланов Рамиль Махир Оглы Проблемы защиты корпоративной информации в сети Интернет // Мониторинг правоприменения. 2012. №1. - URL: http://cyberleninka.ru/article/n/problemy-zaschity-korporativnoy-informatsii-v-seti-internet (дата обращения: 24.10.2017)
2. Германова Валерия Александровна, Атабекян Анаит Саргисовна Проблемы защиты персональных данных в сети интернет // Символ науки. 2016. №12-3. - URL: http://cyberleninka.ru/article/n/problemy-zaschity-personalnyh-dannyh-v-seti-internet (дата обращения: 24.10.2017)
3. Жуйков Роман, Шарыгин Евгений Методы предварительной оптимизации программ на языке JavaScript // Труды ИСП РАН. 2015. №6. -URL: http://cyberleninka.ru/article/n/metody-predvaritelnoy-optimizatsii-programm-na-yazyke-javascript (дата обращения: 24.10.2017)
4. Зотов В.А. Реализация языка JavaScript ajах и node. Js // Вестник МГУП. 2013. №9. - URL: http://cyberleninka.ru/article/n/realizatsiya-yazyka-javascript-ajah-i-node-js (дата обращения: 24.10.2017)
5. Макфарланд Дэвид. JavaScript и jQuery. Исчерпывающее руководство. 3-е издание // Издательство "Эксмо" ООО, 2015
: V V :
