ИМПОРТОЗАМЕЩЕНИЕ В КОНТЕКСТЕ ЗАЩИТЫ КЛИЕНТ-СЕРВЕРНОГО ВЗАИМОДЕЙСТВИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

IMPORT SUBSTITUTION IN THE CONTEXT OF PROTECTION OF CLIENT-SERVER INTERACTION OF INFORMATION SYSTEMS

Anton Melchakov

PhD candidate, Volga State Technological University,

Russia, Yoshkar-Ola

АННОТАЦИЯ

В статье рассматривается возможность замещения иностранных алгоритмов отечественными разработками в тех случаях, где такие алгоритмы играют решающую роль в целостности и безопасности данных. В работе предложен метод защиты передачи данных между клиентами и сервером по архитектуре REST API, основанный на использовании JSON Web Token с применением отечественного алгоритма шифрования «Кузнечик». В ходе работы было уделено внимание необходимости шифрования данных, передающихся в JWT, а также преимущества перехода на российские методы шифрования.

ABSTRACT

The article considers the possibility of replacing foreign algorithms with domestic developments in cases where such algorithms play a crucial role in the integrity and security of data. The paper proposes a method for protecting data transmission between clients and the server using the REST API architecture, based on the use of a JSON Web Token using the domestic encryption algorithm "Grasshopper". In the course of the work, attention was paid to the need to encrypt data transmitted to JWT, as well as the advantages of switching to Russian encryption methods.

Ключевые слова: безопасность данных, шифрование, клиент-серверная архитектура.

Keywords: data security, encryption, client-server architecture.

В настоящее время довольно значимую часть рынка мобильных и веб приложений занимают системы, передача данных в которых реализована по распределенной архитектуре REST. С каждым днем количество информации, передаваемой по таким сетям, растет, а вместе с тем растет интерес злоумышленников к получению доступа к конфиденциальным данным пользователей. Наряду с построением высоконагруженных систем обмена запросами не всегда должное внимание уделяется защите. В таких случаях под угрозу попадает большое количество пользователей и их информация.

Одним из ключевых преимуществ API является то, что «клиенту» не нужно знать внутреннюю работу программного обеспечения, используемого сервером, и наоборот. Это позволяет службам, использующим различные технологии, обмениваться данными стандартным способом.

Система защиты информации – это комплекс направлений, методов, средств и мероприятий, уменьшающих уровень уязвимости информации и препятствующих несанкционированному доступу к информации, ее разглашению или утечке.

Раскрытие конфиденциальных данных из-за отсутствия шифрования при передаче или хранении может привести к потере данных. Раскрытие конфиденциальных данных происходит всякий раз, когда приложение не может должным образом защитить конфиденциальные данные. Информация может отличаться от частной медицинской информации до информации о кредитной карте, токенов сеанса, паролей и многого другого, как правило, уязвимо для атак. Конфиденциальные данные требуют высокого уровня безопасности, которая включает в себя шифрование при хранении или передаче, в дополнение к чрезвычайным мерам безопасности при обмене с клиентом.

Обычно клиенту не нужно определять, подключен ли он напрямую к конечному серверу или к посреднику по пути. Если между клиентом и сервером размещен прокси-сервер или подсистема балансировки нагрузки, это не повлияет на их взаимодействие, и не потребуется обновлять код клиента или сервера. Промежуточные серверы могут улучшить масштабируемость системы за счет балансировки нагрузки и предоставления общих кешей. Кроме того, безопасность может быть добавлена ​​как слой поверх веб-сервисов, отделяя бизнес-логику от логики безопасности. Добавление безопасности в качестве отдельного уровня обеспечивает соблюдение политик безопасности. Наконец, промежуточные серверы могут вызывать несколько других серверов для генерации ответа клиенту.

Для защиты данных в таких системах всё чаще используют токены защиты. Они могут содержать открытую информацию, либо являются зашифрованными. Однако не всегда такой подход является надежным и безопасным. Поэтому построение системы защиты REST API является новой веткой развития клиент-серверных систем, а безопасность передаваемых внутри данных – один из самых важных аспектов функционирования приложения.

  Текущая ситуация на рынке информационных технологий (на примере отказа от SSL сертификатов) показывает,  что использование отечественных алгоритмов позволяет обособить информационную систему от несанкционированного доступа в случае отказа. Это как никогда заметно на клиент-серверных системах, самых широко используемых в сети Интернет.

Рисунок 1. Отправка запроса

Как показано на рисунке 1, использование токенов – лишь надстройка над HTTP протоколом, а значит, инженеры, строящие системы защиты, вольны выбирать методы самостоятельно, исходя из требований, задокументированных в стандартах. Одни из самых опасных угроз  - инъекции и межсайтовая подделка запроса. Из этих уязвимостей следует множество дополнительных угроз.

Создание HTML, необходимого для эксплойта CSRF, вручную может быть непростой задачей, особенно если желаемый запрос содержит большое количество параметров или в запросе есть другие особенности. Самый простой способ создать эксплойт CSRF - использовать специальные генераторы.

Механизмы доставки для атак с подделкой межсайтовых запросов по существу такие же, как и для отраженных XSS. Как правило, злоумышленник размещает вредоносный HTML-код на контролируемом им веб-сайте, а затем побуждает жертв посетить этот веб-сайт. Это может быть сделано путем подачи пользователю ссылки на веб-сайт через электронную почту или сообщение в социальных сетях. Или, если атака проводится на популярный веб-сайт (например, в комментарии пользователя), они могут просто ждать, пока пользователи посетят этот веб-сайт.

Необходимо обратить внимание, что некоторые простые эксплойты CSRF используют метод GET и могут быть полностью автономными с помощью одного URL-адреса на уязвимом веб-сайте. В этой ситуации злоумышленнику может не потребоваться использовать внешний сайт, и он может напрямую передать жертвам вредоносный URL-адрес в уязвимом домене.

Принцип, лежащий в основе ограничений клиент-сервер, заключается в разделении ответственности. Отделение проблем пользовательского интерфейса от проблем хранения данных улучшает переносимость пользовательских интерфейсов на нескольких платформах. Соответственно и систему защиты стоит строить на стороне сервера. Зачастую, это токены доступа, например формата JWT (рисунок 2).

Рисунок 2. Структура токена

Подписанный JWT известен как JWS. Цель подписи - позволить одной или нескольким сторонам установить подлинность JWT. Подлинность в этом контексте означает, что данные, содержащиеся в JWT, не были подделаны. Другими словами, любая сторона, которая может выполнить проверку подписи, может полагаться на содержимое, предоставляемое JWT.

Одним из распространенных способов шифрования JWT является RSA, широко используемый алгоритм асимметричного шифрования (с открытым ключом). Чтобы зашифровать JWT для получателя, вам необходимо знать его открытый ключ. Но, по мере необходимости, возможно использование других методов шифрования. В этом и заключается плюсы подхода и гибкость подобных систем. Например, число раундов алгоритма «Кузнечик» существенно меньше, чем в алгоритме AES. Данный шифр имеет также большую производительность, а наличие регистров большей длины позволяет еще больше оптимизировать пакетное шифрование.

Таким образом, мы можем использовать любой (например, отечественный) алгоритм с симметричным ключом, чтобы шифровать передаваемые данные. Изменять данный алгоритм, дорабатывать, улучшать производительность на свое усмотрения, не выходя за рамки стандартов. Это позволит сделать систему защиты уникальной на уровне защиты передаваемых данных, исключит их прочтение и компрометацию даже при перехвате.

Список литературы:

1. Information technology — Service management — Part 10: Concepts and vocabulary: ISO/IEC 20000-10:2018(en). — Technical Committee ISO/IEC JTC 1, 2018. — 28p.
2. Яворски Питер. Ловушка для багов. Полевое руководство по веб-хакингу. — СПб.: Питер, 2020. — 272 с.: ил.
3. ГОСТ 34.12-2018. «Информационная технология. Криптографическая защита информации. Блочные шифры»
4. Брюс Шнайер, Прикладная криптография / Б. Шнайер – М.: Изд-во Триумф, 2012 г. – 815 с.
5. E.Peyrot, «The JWT Handbook», Auth0 Inc, 2016