Защита информации при передаче данных – SearchInform

Защита информации при передаче данных - SearchInform Электронная цифровая подпись

Введение в xml signatures

XML Signatures – цифровые подписи, спроектированные для применения в XML-транзакциях.
Стандарт описывает схему для хранения результатов операции цифрового подписания
примененного к любым (чаще XML) данным. Подобно не-XML-подписям (например, PKCS)

, XML-подписи
поддерживают аутентификацию, целостность данных и неотрекаемость от подписания
данных. Однако, в отличие от не-XML-подписей, XML-подписи были спроектированы для
использования в интернете и на основе XML.

Главная особенность XML Signatures – возможность подписания лишь части данных XML вместо
всего документа. Это особенно значимо, когда один XML-документ может иметь долгую
историю, в которой различные его части оформляются в разное время разными
исполнителями, и каждый подписывает лишь важную для себя часть.

Эта гибкость также
критична в случаях, когда необходимо обеспечить целостность определенных частей XML-документа,
но оставить открытой возможность изменения других частей. Представьте, например,
подписанную XML-форму, присланную пользователю для заполнения.

XML-подпись может подтверждать более одного типа ресурсов. Например, одна XML-подпись
может покрывать текстовые данные (HTML), бинарные данные (JPG), XML-шифрованные данные и
определенную секцию XML-документа.

  • Быть URI в XML-подписи;
  • Находиться внутри того же узла, где находится XML-подпись (на этом же уровне);
  • Зависеть от подписи (XML-подпись является родителем);
  • Иметь подпись в качестве потомка (XML-подпись является дочерним узлом).

Введение в шифрование открытым ключом

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

Читайте также:  Как осуществить проверку плагина «КриптоПро ЭЦП Browser plug-in»?

Это достигается путем
изменения данных на основе алгоритма, описываемого парой чисел – так называемых
открытого и закрытого ключа. Каждый участник такого обмена данными имеет такую пару
ключей.

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

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

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

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

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

Чтобы проверка подписи имела какое-то значение, проверяющему необходима уверенность,
что открытый ключ принадлежит именно отправителю сообщения (в ином случае самозванец
может выдать свой открытый ключ за ключ отправителя).

Читайте также:  6_55MCIKG10OC710I9L5UAS81000 - Портал услуг Федеральной службы государственной регистрации, кадастра и картографии

Большей частью из-за производительных характеристик алгоритма открытого ключа,
кодируется не все тело сообщения, а лишь его малая уникальная проекция, называемая «хешем»
(hash) или «дайджестом» (digest). Так как алгоритм хеширования чрезвычайно чувствителен к
любому изменению тела документа, хеш оригинала позволяет получателю проверить, не был
ли изменен документ (путем сравнения присланного хеша и полученного на основе
полученных данных).

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

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

Axis2 — фреймворк для создания веб-сервисов

За последние несколько лет появилось довольно много фреймворков для разработки веб-сервисов. Одним из самых популярных решений в этой области является Apache Axis2 Framework, модуль Rampart которого содержит реализацию стандарта WS-Security. Этот стандарт и позволяет нам применять XML Encryption и XML Signature в сообщениях SOAP.

Чтобы этот модуль можно было использовать в Axis2 Framework, он должен быть элементом потока обработки сообщений (message flow). Поток обработки сообщений (message flow) — это цепочка модулей, каждый из которых получает входящее SOAP-сообщение (или контекст сообщения), обрабатывает его и передает следующему модулю в цепочке.

Message flow в Apache Axis2
Message flow в Apache Axis2

Обычно поток обработки сообщений в Axis2 состоит из трех модулей: Transport, Security и Dispatch. Модуль Security, как видно из названия, отвечает за безопасность. В процессе обработки зашифрованного сообщения он сначала осуществляет процесс дешифрования, а затем парсит открытый текст с помощью парсера XML и обновляет контекст SOAP-сообщения.

Дешифрованный и проверенный контент передается модулю Dispatch. Как и Message Receiver, каждый модуль в цепочке message flow может прервать процесс обработки сообщения SOAP при возникновении ошибки, после чего процесс обработки прекращается и пользователю сервиса выдается соответствующее сообщение.

Теперь ты наверняка понял, к чему я все это рассказывал и кто виновник уязвимости в Axis2. 🙂

Microsoft crypto api 2.0

Операционная система Microsoft Windows, независимо от версии, довольно сложная система, которая помимо всего прочего занимается вопросами обеспечения безопасности пользовательских и корпоративных данных. В этих задачах традиционно широко используется криптография.

С целью унификации доступа к криптографическим функциям компания Microsoft разработала проприетарный API: Microsoft Crypto API. Широкое распространение приобрела версия Crypto API 2.0. Парадигма Microsoft Crypto API базируется на использовании так называемых криптопровайдеров, или, по-русски, поставщиков криптографии.

Спецификация Crypto API описывает набор функций, которые должна предоставлять библиотека криптопровайдера операционной системе, способы интеграции с ней и спецификации вызовов. Таким образом, производитель СКЗИ, выполняющий правила Crypto API, имеет возможность интеграции своего решения в операционную систему Microsoft Windows, а прикладное программное обеспечение получает доступ криптографическим функциям посредством унифицированного интерфейса.

Дополнительным плюсом является то, что компания Microsoft реализовала над Crypto API довольно большое количество функций, отвечающих за выполнение прикладных задач: работа с сертификатами, формирование различных видов подписи, работа с ключевой информацией и пр. Также Crypto API, как нетрудно догадаться, тесно интегрирован с операционной системой и ее внутренними механизмами.

Но расплатой за удобство становится платформозависимость и необходимость тесной интеграции решения в операционную систему.

В Windows Vista Microsoft представила новую версию криптографического программного интерфейса – Microsoft CNG (Cryptography API: Next Generation). Данный интерфейс базируется уже не на поставщиках криптографии, а на поставщиках алгоритмов и поставщиках хранилищ ключевой информации.

Xml encryption

Технология XML Encryption, стандартизованная W3C в 2002 году, в настоящее время широко используется в различных XML Framework’ах (этот стандарт поддерживают .NET, Apache Axis2, JBOSS и т. д.). Сегодня она активно применяется для защиты коммуникаций между веб-сервисами в продуктах многих компаний, в частности Microsoft и Red Hat.

На техническом уровне спецификация XML Encryption точно описывает синтаксис криптографических алгоритмов, разработанных для произвольных XML-структурированных данных, — шифрования, дешифрования и восстановления измененной части XML-документа — и порядок их применения.

Стандарт не определяет никаких новых криптографических алгоритмов, а предписывает использовать уже существующие. В случае блочных шифров стандарт не оставляет нам другого выбора, кроме AES и 3DES в режиме CBC. Далее я буду все описывать на примере шифра AES (хотя для понимания сути уязвимости это не принципиально, главное — режим CBC).

Веб-службы

Веб-служба — это метод взаимодействия между двумя электронными устройствами через сеть передачи данных. W3C определяет web-service как программную систему, спроектированную для поддержки интероперабельности machine-to-machine-взаимодействия. Интероперабельность подразумевает открытость интерфейсов и способность взаимодействовать с другими продуктами без каких-либо ограничений доступа и реализации. Зачастую интерфейсы взаимодействия описываются на специальном языке WSDL (Web Services Description Language), в основе которого лежит XML. Веб-сервисы представляют собой наборы инструментов, к наиболее популярным способам использования которых относятся RPC (Remote procedure calls, основная единица взаимодействия — вызов удаленной функции или метода), SOA (Service-oriented architecture, основная единица взаимодействия — сообщение) и REST (Representational state transfer). В последнем случае основными единицами взаимодействия являются операции типа GET, POST, PUT, DELETE и т. д. в протоколах типа HTTP, которые не поддерживают состояния.

Xsd-схема

XSDXS

chema

D

efinition) — это описание вашего XML. Как он должен выглядеть, что в нем должно быть? Это ТЗ, написанное на языке машины — ведь схему мы пишем… Тоже в формате XML! Получается XML, который описывает другой XML.

Фишка в том, что проверку по схеме можно делегировать машине. И разработчику даже не надо расписывать каждую проверку. Достаточно сказать «вот схема, проверяй по ней».

Если мы создаем SOAP-метод, то указываем в схеме:

Теперь, когда к нам приходит какой-то запрос, он сперва проверяется на корректность по схеме. Если запрос правильный, запускаем метод, отрабатываем бизнес-логику. А она может быть сложной и ресурсоемкой! Например, сделать выборку из многомиллионной базы. Или провести с десяток проверок по разным таблицам базы данных…

Поэтому зачем запускать сложную процедуру, если запрос заведом «плохой»? И выдавать ошибку через 5 минут, а не сразу? Валидация по схеме помогает быстро отсеять явно невалидные запросы, не нагружая систему.

Более того, похожую защиту ставят и некоторые программы-клиенты для отправки запросов. Например, SOAP Ui умеет проверять ваш запрос на well formed xml, и он просто не отправит его на сервер, если вы облажались. Экономит время на передачу данных, молодец!

А простому пользователю вашего SOAP API схема помогает понять, как составить запрос. Кто такой «простой пользователь»?

  1. Разработчик системы, использующей ваше API — ему надо прописать в коде, что именно отправлять из его системы в вашу.
  2. Тестировщик, которому надо это самое API проверить — ему надо понимать, как формируется запрос.

Да-да, в идеале у нас есть подробное ТЗ, где всё хорошо описано. Но увы и ах, такое есть не всегда. Иногда ТЗ просто нет, а иногда оно устарело. А вот схема не устареет, потому что обновляется при обновлении кода. И она как раз помогает понять, как запрос должен выглядеть.

Итого, как используется схема при разработке SOAP API:


А теперь давайте посмотрим, как схема может выглядеть! Возьмем для примера метод

Атрибуты элемента

У элемента могут быть атрибуты — один или несколько. Их мы указываем внутри отрывающегося тега после названия тега через пробел в виде

название_атрибута = «значение атрибута»

Например:

Защита информации при передаче данных - SearchInform

Зачем это нужно? Из атрибутов принимающая API-запрос система понимает, что такое ей вообще пришло.

Например, мы делаем поиск по системе, ищем клиентов с именем Олег. Отправляем простой запрос:

А в ответ получаем целую пачку Олегов! С разными датами рождения, номерами телефонов и другими данными. Допустим, что один из результатов поиска выглядит так:

Давайте разберем эту запись. У нас есть основной элемент

party

У него есть 3 атрибута:

  • type = «PHYSICAL» — тип возвращаемых данных. Нужен, если система умеет работать с разными типами: ФЛ, ЮЛ, ИП. Тогда благодаря этому атрибуту мы понимаем, с чем именно имеем дело и какие поля у нас будут внутри. А они будут отличаться! У физика это может быть ФИО, дата рождения ИНН, а у юр лица — название компании, ОГРН и КПП
  • sourceSystem = «AL» — исходная система. Возможно, нас интересуют только физ лица из одной системы, будем делать отсев по этому атрибуту.
  • rawId = «2» — идентификатор в исходной системе. Он нужен, если мы шлем запрос на обновление клиента, а не на поиск. Как понять, кого обновлять? По связке sourceSystem rawId!

Защита информации при передаче данных - SearchInform

Внутри party есть элементы field.

У элементов field есть атрибут name. Значение атрибута — название поля: имя, дата рождения, тип или номер телефона. Так мы понимаем, что скрывается под конкретным field.

Это удобно с точки зрения поддержки, когда у вас коробочный продукт и 10 заказчиков. У каждого заказчика будет свой набор полей: у кого-то в системе есть ИНН, у кого-то нету, одному важна дата рождения, другому нет, и т.д.

Но, несмотря на разницу моделей, у всех заказчиков будет одна XSD-схема (которая описывает запрос и ответ):

— есть элемент party;— у него есть элементы field;— у каждого элемента field есть атрибут name, в котором хранится название поля.

А вот конкретные названия полей уже можно не описывать в XSD. Их уже «смотрите в ТЗ». Конечно, когда заказчик один или вы делаете ПО для себя или «вообще для всех», удобнее использовать именованные поля — то есть «говорящие» теги. Какие плюшки у этого подхода:

— При чтении XSD сразу видны реальные поля. ТЗ может устареть, а код будет актуален.— Запрос легко дернуть вручную в SOAP Ui — он сразу создаст все нужные поля, нужно только значениями заполнить. Это удобно тестировщику заказчик иногда так тестирует, ему тоже хорошо.

В общем, любой подход имеет право на существование. Надо смотреть по проекту, что будет удобнее именно вам. У меня в примере неговорящие названия элементов — все как один будут field. А вот по атрибутам уже можно понять, что это такое.

Помимо элементов field в party есть элемент attribute. Не путайте xml-нотацию и бизнес-прочтение:

У элемента attribute есть атрибуты:

Такая вот XML-ка получилась. Причем упрощенная. В реальных системах, где хранятся физ лица, данных сильно больше: штук 20 полей самого физ лица, несколько адресов, телефонов, емейл-адресов…

Но прочитать даже огромную XML не составит труда, если вы знаете, что где. И если она отформатирована — вложенные элементы сдвинуты вправо, остальные на одном уровне. Без форматирования будет тяжеловато…

А так всё просто — у нас есть элементы, заключенные в теги. Внутри тегов — название элемента. Если после названия идет что-то через пробел: это атрибуты элемента.

Восстановление открытого текста

Ну вот, теперь все готово для того, чтобы описать алгоритм восстановления открытого текста из шифрованного. Этот шифрованный текст может содержать произвольное число блоков. Мы будем представлять его как массив C=(IV, C[1], … , C[d]), на первом месте в котором стоит вектор инициализации. Самое время еще раз вспомнить, что в режиме CBC вектором инициализации для блока С[i] является блок C[i-1].

Для простоты считаем, что открытый текст состоит только из символов ASCII (то есть в тексте нет ни одного символа из расширенной секции UTF-8). В отличие от случая, описанного в простом примере, здесь «правильно сформированным» шифротекстом является такой шифротекст, открытый текст которого состоит из символов группы B и имеет однобайтное дополнение, то есть последний его байт равен 0x01 (это допущение введено для более простого изложения идеи атаки).

Алгоритм восстановления открытого текста включает в себя две процедуры. Первая (FindIV) подготавливает шифротекст к проведению атаки. Она принимает на вход С = (IV, C[1], … , C[d]) и номер блока i, а возвращает «правильно сформированный» блок шифртекста с новым вектором инициализации C=(iv, C[i]).

Здесь все практически так же, как в описанном выше простом примере. Вторая процедура (FindXbyte) принимает на вход «правильно сформированный» блок шифрованного текста (полученный при помощи FindIV) и возвращает j-й байт X[i][j] промежуточного блока открытого текста X[i] = AES_DEC(k, C[i]). Используя эти процедуры, опишем в псевдокоде алгоритм восстановления открытого текста.

Input: C=(C[0] = IV, C[1], ..., C[d])
Output: M=(M[1], ..., M[d])

for i = 1 to d do
iv = FindIV(C, i)
for j = 1 to 16

X[i][j] = FindXbyte(C[i], iv, j)
end for
X[i] = (X[i][1], ..., X[i][16])
M[i] = X[i] xor C[i-1]
end for
return (M[1], ..., M[d])

Алгоритм прост и не нуждается в подробном разъяснении. Скажу лишь только, что получить открытый текст M таким способом возможно благодаря режиму CBC (смотри на картинку, и все станет ясно). Остается только рассказать тебе об устройстве двух загадочных функций: FindIV и FindXbyte.

Глоссарий

PKCS (Public Key Cryptography Standards) – набор стандартов, разработанных лабораторией RSA Data Security.
Эти стандарты были разработаны для обеспечения совместимости между различными
реализациями алгоритмов криптографии с открытым ключом, поставляемыми различными
разработчиками устройств и программного обеспечения.

PKI (Public key infrastructure) – (дословно: инфраструктура открытых ключей). Система цифровых
сертификатов, сертификации авторства и регистрации авторства, позволяющая проверить,
аутентифицировать и подтвердить авторство обеих сторон, участвующих в электронной
транзакции (обмене информацией).SSL (Secure Socket Layer) – протокол доступа, защищающий информацию от посторонних пользователей.

SSL (Secure Socket Layer) – протокол доступа, защищающий информацию от посторонних
пользователей.

URI (Uniform Resource Identifier) — единообразный идентификатор ресурса. URI — это короткая
последовательность символов, идентифицирующая абстрактный или физический ресурс.
Ранее назывался Universal Resource Identifier — универсальный идентификатор ресурса.

XML (eXtensible Markup Language) — рекомендованный Консорциумом
Всемирной паутины язык разметки, фактически представляющий собой свод общих
синтаксических правил. XML предназначен для хранения структурированных данных (взамен
существующих файлов баз данных), для обмена информацией между программами, а также для
создания на его основе более специализированных языков разметки (например, XHTML), иногда
называемых словарями. XML является упрощённым подмножеством языка SGML.

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

Например, Secure Sockets Layer (SSL) предоставляет защищенный обмен точными данными между
браузером и Web-сервером, но как только данные получаются сервером, они перестают быть
защищенными. Фактически, SSL защищает данные только во время их транспортировки от
клиента к серверу, или, иначе говоря, тогда, когда их редко атакуют.

Как вы считаете, что
выберет хакер: перехват транспортируемых данных для получения доступа к кредитной
карте одного человека или внедрение в конечную базу данных, содержащую данные о
тысячах кредиток?

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

Не менее чем защита конфиденциальности данных важна их долговременная
аутентификация (кем они посланы?), целостность данных (менялись ли данные во время
транспортировки?) и поддержка неотрекаемости (может отправитель отказаться от своей
подписи?); другими словами, функциональность, которую существующие технологии (например,
SSL, аутентификация по имени/паролю) обособленно не предоставляют.

Общепризнанным
способом удовлетворения этих требований для обмена данными является использование
цифровых сертификатов для шифрования и подписания данных. Краткое введение в эту
концепцию изложено ниже.

Термин «инфраструктура открытых ключей» используется для
описания процессов, политик и стандартов, который управляет выдачей, поддержкой и
отзывом сертификатов, открытых и закрытых ключей, которые требуются для выполнения
операций шифрования и подписания.

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

Например, во многих сценариях движения XML-документа
между участниками, где цифровая подпись играет роль согласия или отказа, каждый
участник может пожелать подписать только ту часть, где у них есть ответственность и
берут на себя эту ответственность.

Две новых технологии, созданных для достижения поставленных задач и использующих все
преимущества особенностей формата XML – XML-подпись (XML Signature) и XML-шифрование (XML Encryption). XML
Signature – результат совместной работы между World Wide Web Consortium (W3C) и Internet Engineering Task Force (IETF), а XML
Encryption разработана усилиями W3C.

Значение элемента

Значение элемента хранится между открывающим и закрывающим тегами. Это может быть число, строка, или даже вложенные теги!

Вот у нас есть тег «query». Он обозначает запрос, который мы отправляем в подсказки.

Внутри — значение запроса.

Это как если бы мы вбили строку «Виктор Иван» в GUI (графическом интерфейсе пользователя):

Пользователю лишняя обвязка не нужна, ему нужна красивая формочка. А вот системе надо как-то передать, что «пользователь ввел именно это». Как показать ей, где начинается и заканчивается переданное значение? Для этого и используются теги.

Система видит тег «query» и понимает, что внутри него «строка, по которой нужно вернуть подсказки».

Параметр count = 7 обозначает, сколько подсказок вернуть в ответе. Если тыкать подсказки на демо-форме Дадаты, нам вернется 7 подсказок. Это потому, что туда вшито как раз значение count = 7. А вот если обратиться к документации метода, count можно выбрать от 1 до 20.

Откройте консоль разработчика через f12, вкладку Network, и посмотрите, какой запрос отправляется на сервер. Там будет значение count = 7.

Защита информации при передаче данных - SearchInform

См также:
Что тестировщику надо знать про панель разработчика — подробнее о том, как использовать консоль.

Обратите внимание:

Но оба значения идут

без

кавычек. В XML нам нет нужды брать строковое значение в кавычки (а вот в JSON это сделать придется).

Матчасть

Известно, что блочный шифр преобразует блок открытого текста (обычно длиной 16 байт, то есть 128 бит) в блок шифрованного текста. Если данные занимают больше одного блока, приходится использовать алгоритмы, самым популярным из которых на сегодня является CBC.

Принцип его работы легко понять из первой иллюстрации. Для первого блока открытого текста случайно выбирается вектор инициализации (IV), а затем над этим вектором и первым блоком открытого текста выполняется операция XOR, результат которой шифруется с помощью блочного алгоритма.

//Шифрование

C[0] = AES_ENC(k, IV xor M[0]);
C[i] = AES_ENC(k, C[i-1] xor M[i]);

//Дешифрование

M[0] = AES_DEC(k, C[0]) xor IV;
M[i] = AES_DEC(k, C[i]) xor C[i-1];

Здесь k — ключ, С — шифротекст, М — открытый текст, IV — вектор инициализации (синхропосылка).

Стандарт не только предписывает использовать режим шифрования CBC, но и определяет схему дополнения данных до полного блока.

Режим CBC (шифрование и дешифрование)
Режим CBC (шифрование и дешифрование)

Суть этой схемы, в которой также нет ничего сложного, такова: неполный блок с помощью произвольных значений дополняется до полного, а в его последний байт вписывается количество этих произвольных значений. Так, если последний блок содержит всего три байта, то мы добавляем 12 произвольных байт и один байт со значением 0x05.

Ошибки в системе безопасности в axis2

Что такое оракулы?

В современной криптографии есть направление Provable Security, которое подразумевает анализ исследуемой системы при активном воздействии на нее. Предполагается, что злоумышленник имеет возможность посылать запрос и анализировать полученный ответ, затем создавать новый запрос на основе полученной информации, опять получать ответ и т. д. Под оракулом понимают то, что отвечает на запросы злоумышленника (сервер, просто комп, смарт-карту, СКЗИ, шифровальщик и др.). В нашем сегодняшнем примере в качестве оракула выступает сервер с веб-сервисом, то есть мы посылаем сервису запрос на обработку данных, а он возвращает либо ошибку, либо результат обработки данных. Axis2, в свою очередь, — это фреймворк для создания веб-сервисов. Недавно была новость про Padding Oracle Attack, где в качестве оракула выступало приложение (веб-сервис, сайт на ASP.NET), созданное с использованием .net.

В качестве оракула у нас будет выступать сервер с веб-сервисом, созданным с использованием Axis2. Поначалу нам нужно понять, какие сообщения об ошибках безопасности выдает сервер, так как тогда мы сможем отличить ответ true от ответа false нашего оракула.

При возникновении ошибки безопасности сервис передает нам security fault. Причины генерации security fault можно разделить на две категории: 1. Ошибка дешифрования Такая ошибка возникает при некорректном дополнении последнего блока. Помнишь, я говорил, что последний байт каждого сообщения содержит число, равное количеству дополненных байтов?

Так вот, этот последний байт может принимать значения от 0x01 до 0x10, в противном случае мы получаем сообщение об ошибке. 2. Ошибка парсинга данных Эта ошибка может возникнуть по двум причинам. Первая — открытый текст содержит «запрещенные» символы, то есть символы с кодами ASCII от 0x00 до 0x1F (за исключением 0x09, 0x0A, 0x0D — пробела, конца строки и возврата каретки).

В обоих случаях мы получаем одинаковое сообщение об ошибке и различить эти два случая между собой лишь по сообщению не можем.

Как и в приведенном ранее простом примере, разобьем всю нашу таблицу ASCII на две группы символов (все внимание на четвертый рисунок). Группа A содержит запрещенные для формата XML символы плюс два «зарезервированных» символа «&» и «<», ну а группа B включает в себя все остальные символы.

Таблица ASCII с делением символов на группы
Таблица ASCII с делением символов на группы

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

Конечно, этот блок должен быть правильно «обернут» в SOAP-сообщение, но здесь мы этим пренебрегаем. Итак, оракул возвращает true, если сервер в ответ на SOAP(AESENCCBC(k, (IV, C))) передает нам security fault, и возвращает false в противном случае.

Как я уже говорил, сервер не выдаст security fault, если на стороне сервера сообщение имеет правильное дополнение до полного блока, то есть открытый текст M имеет верную XML-структуру:

PAD(M) == (IV xor AES_DEC(k, C))

Здесь должны выполняться следующие условия: 1. M, содержащий XML-тег , обязательно должен содержать и закрывающий тег . 2. Если M содержит символ амперсанда «&», то он должен служить началом существующей escape-последовательности, например «&gt». 3. M не должен содержать символы из определенной нами группы B.

В противном случае возникает ошибка security fault, что позволяет нам использовать оракул точно так же, как и в предыдущем более простом примере.

Элемент ds:keyinfo

На данный момент мы знаем, как сослаться на содержимое, преобразовать и хэшировать
его, и создать подпись, которая покрывает (защищает) это содержимое. Оно защищено от
обратного преобразования: ds:SignatureValue включает ds:

SignedInfo, который содержит ds:References,
в котором находятся значения хэшей данных приложения. Изменение любого из этих
элементов влечет за собой разрушение цепочки математических вычислений, и подпись не
будет достоверной.

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

Как видите, XML DSIG поддерживает разнообразные типы ключей и инфраструктуры ключей, а
WS-Security пошла еще дальше. Мы рассмотрим только простое имя и сертификат X.509. ds:KeyName
стоит использовать при создании специального приложения для закрытой среды:

За проецирование имени во внутреннее хранилище и выбор подходящего ключа отвечает
процесс, проверяющий достоверность подписи. К обычным значениям ds:KeyName относятся
адрес электронной почты или элемент справочника.

Сертификаты X.509 поддерживаются элементом ds:X509Data. Этот элемент позволяет
подписывающей стороне встраивать свой сертификат (в Base64) или любую из нескольких
альтернативных форм идентификации сертификата: имя субъекта, имя пользователя и
серийный номер, идентификатор ключа или что-либо другое.

Подписывающая сторона также
может включить текущую копию Списка отзыва сертификата (Certificate Revocation List – CRL), чтобы
показать, что идентификатор подписывающей стороны был действителен в момент
подписания документа. Фрагмент Схемы, приведенный ниже, показывает различные способы
идентификации сертификата X.509:

Поскольку различные приложения будут сохранять и извлекать сертификаты, используя
различные схемы, цифровые подписи XML часто включают множество имен одного и того же
ключа, встраивая их в один и тот же элемент ds:KeyInfo.

Итого

XML (eXtensible Markup Language) используется для хранения и передачи данных.

Передача данных — это запросы и ответы в API-методах. Если вы отправляете SOAP-запрос, вы априори работаете именно с этим форматом. Потому что SOAP передает данные только в XML. Если вы используете REST, то там возможны варианты — или XML, или JSON.

Хранение данных — это когда XML встречается внутри кода. Его легко понимает как машина, так и человек. В формате XML можно описывать какие-то правила, которые будут применяться к данным, или что-то еще.

Вот пример использования XML в коде open-source проекта folks. Я не знаю, что именно делает JacksonJsonProvider, но могу «прочитать» этот код — есть функционал, который мы будем использовать (featuresToEnable), и есть тот, что нам не нужен(featuresToDisable).

Формат XML подчиняется стандартам. Синтаксически некорректный запрос даже на сервер не уйдет, его еще клиент порежет. Сначала проверка на well formed, потом уже бизнес-логика.

Правила well formed XML:

  1. Есть корневой элемент.
  2. У каждого элемента есть закрывающийся тег.
  3. Теги регистрозависимы!
  4. Соблюдается правильная вложенность элементов.
  5. Атрибуты оформлены в кавычках.

Защита информации при передаче данных - SearchInform

Если вы тестировщик, то при тестировании запросов в формате XML обязательно попробуйте нарушить каждое правило! Да, система должна уметь обрабатывать такие ошибки и возвращать адекватное сообщение об ошибке. Но далеко не всегда она это делает.

А если система публичная и возвращает пустой ответ на некорректный запрос — это плохо. Потому что разработчик другой системы налажает в запросе, а по пустому ответу даже не поймет, где именно. И будет приставать к поддержке: «Что же у меня не так?», кидая информацию по кусочкам и в виде скринов исходного кода. Оно вам надо? Нет? Тогда убедитесь, что система выдает понятное сообщение об ошибке!

См также:

Что такое XMLУчебник по XMLИзучаем XML. Эрик Рэй (книга по XML) Заметки о XML и XLST

Что такое JSON — второй популярный формат

Оцените статью
ЭЦП Эксперт
Добавить комментарий

Adblock
detector