Безпека Web-сервісів, Інтернет і інші мережі, Security & Hack, статті

Білал Сіддікуі (Bilal Siddiqui)
Переклад: Intersoft Lab

У попередній статті обговорювалися питання безпеки Web-сервісів в додатках, що застосовуються в електронній комерції за схемою B2B. У ній також були згадані XML-стандарти безпеки, що розробляються міжнародними організаціями W3C і OASIS.

У цій статті розглядаються три XML-стандарту безпеки: “Підпис XML” (XML Signatures), “Шифрування XML” (XML Encryption) і “Безпека Web-сервісів” (Web Services Security) – які регламентують наступну функціональність при передачі SOAP-повідомлень: налаштовувану аутентифікацію, цілісність повідомлень і конфіденційність. Можна бути впевненим, що ці три специфікації “заткнуть дірку” в SOAP-сервері, про яку розповідалося в попередній статті. А в наступній статті на прикладі створення, обміну та обробки XML-повідомлень в брандмауерах XML буде показано, як “закладається ця діра”.

Основні поняття криптографії

При обговоренні цілісності повідомлень, аутентифікації користувачів та конфіденційності використовуються деякі базові поняття: ключі, криптографія, підписи та сертифікати. Нижче коротко викладено основи криптографії. За більш детальною інформацією звертайтеся до розділу Ресурси, де міститься посилання на довідник по криптографії, який можна безкоштовно скачати.

Асиметрична криптографія

Поширена криптографічний методика полягає в застосуванні пари ключів: відкритого і закритого. Спочатку використовується відповідний криптографічний алгоритм генерації пари відкритий-закритий ключ. Відкритий ключ може бути відкритий для використання будь-якій особі, з яким необхідно встановити безпечну передачу повідомлень. Закритий ключ тримається в секреті і нікому не відкривається. Відкритий ключ застосовується для шифрування повідомлень, а відповідний закритий ключ для їх розшифровки.

Для того, щоб відправити конфіденційне повідомлення відправникові необхідний відкритий ключ. З його допомогою це повідомлення шифрується, а потім відсилається. Одержувач цього повідомлення розшифровує його за допомогою закритого ключа. В цьому випадку ніхто, крім власника закритого ключа, не може дешифрувати повідомлення. Така технологія відома як асиметричне шифрування. Пари відкритих-закритих ключів також іноді називають асиметричними ключами.

Симетрична криптографія

Існує ще один метод криптографії – так звана симетрична криптографія. При симетричній криптографії для шифрування і дешифрування використовується один і той же ключ. В цьому випадку цей секретний ключ – симетричний ключ – Є загальним для двох учасників обміну повідомленнями. З точки зору обчислень симетрична криптографія вимагає менше витрат у порівнянні з асиметричною. Саме тому асиметрична криптографія звичайно застосовується тільки для передачі загальної конфіденційної інформації. Як тільки обмінюються повідомленнями боку її отримують, вони можуть перейти до використання симетричної криптографії.

Дайджести повідомлень

Дайджести повідомлень – це ще одне поняття, яким оперують при захищеної передачі повідомлень по Інтернет. Алгоритми дайджестів схожі з хеш-функціями: вони читають (“переварюють”) дані для обчислення значення хеш-функції, званого дайджестом повідомлення. Дайджест повідомлення залежить від даних і алгоритму дайджесту. Значення дайджесту може використовуватися для перевірки цілісності повідомлення; тобто для забезпечення незмінності даних під час їх передачі відправником одержувачу. Відправник посилає дайджест повідомлення разом з цим повідомленням. Після отримання повідомлення одержувач заново виробляє обчислення дайджесту. Якщо у повідомлення були внесені зміни, це значення буде іншим, і це буде свідчити про те, що повідомлення було змінено.

Однак, що робити, якщо і повідомлення, і дайджест змінені? Такий тип модифікацій неможливо встановити на стороні одержувача. Тому одних алгоритмів дайджестів повідомлення недостатньо для забезпечення цілісності повідомлень – для вирішення зазначеної проблеми необхідні цифрові підписи.

Цифрові підписи

Ключі також використовуються для створення та перевірки цифрових підписів. Алгоритм дайджесту можна застосовувати для обчислення значення дайджесту повідомлення, а потім за допомогою закритого ключа по цьому значенню згенерувати цифровий підпис. Одержувач цього повідомлення спочатку перевірить цілісність значення хеш-функції, повторивши обчислення дайджесту. Потім він використовує відкритий ключ відправника повідомлення для перевірки підпису. Якщо значення дайджесту було змінено, цей підпис не буде підтверджена на стороні одержувача. Якщо ж перевірка значення дайджесту та підписи призведе до позитивного результату, можна зробити наступний висновок:

Сертифікати

У найзагальнішому вигляді цифрові сертифікати – це структура даних, яка містить дві інформаційних частини:

Сертифікати, які видають відповідні органи, надаються окремим особам або організаціям і включають дві необхідних частини: особистість власника і відкритий ключ. Такі органи також підписують сертифікат, використовуючи свій власний закритий ключ – будь-яка зацікавлена ​​сторона може переконатися в цілісності сертифікату, перевіривши цю підпис.

Забезпечення цілісності даних і користувальницької аутентифікації за допомогою підписів XML:

Специфікація підпису XML – “Цифровий підпис XML” (XMLDS) – яка була розроблена спільними зусиллями організації W3C і IETF, має статус Рекомендації W3C. Цей документ визначає правила обробки і синтаксис, призначені для пакування в XML-формат даних про цілісність повідомлення, його аутентифікації і користувальницької аутентифікації.

Повернемося до прикладу з попередньої статті – в ньому мова йшла про взаємодію між туроператором і його партнерами (готелями). Припустимо, що туроператор хоче викликати метод GetSpecialDiscountedBookingForPartners Web-сервісу свого партнера. Цей метод надає послугу інтерактивного резервування місць в готелі за спеціальною ціною (зі знижкою). Причому побачити цю знижку можуть тільки бізнес партнери, а не споживачі.

Викликаючи метод SOAP GetSpecialDiscountedBookingForPartners, Туроператор включає в нього інформацію про цілісність повідомлення та користувальницької аутентифікації. При отриманні цього виклику брандмауеру XML готелю буде потрібно переглянути SOAP-повідомлення, щоб повірити, що:

Якщо виконані ці дві умови, брандмауер XML дозволяє запитуючої стороні перейти до SOAP-серверу. На малюнку 1 показ процес користувальницької аутентифікації:

  1. Туроператор направляє в Web-сервіс готелю SOAP-запит про виклик методу. Цей запит включає всю інформацію, що відноситься до забезпечення безпеки (призначена для користувача аутентифікація і призначена для користувача аутентифікація).
  2. Web-сервіс готелю захищений брандмауером XML, який приймає всі запити, що направляються в цей SOAP-сервер. брандмауер XML перевіряє, ідентично чи отримане повідомлення тому, що запитуюча сторона збиралася відправити.
  3. Якщо цілісність повідомлення не порушена, брандмауер XML зчитує ідентифікаційну інформацію запитуючої сторони з цього SOAP-запиту і перевіряє, чи є цей користувач бізнес партнером.
  4. Якщо запитуюча сторона є бізнес партнером, брандмауер XML дозволяє запитуючої стороні перейти до SOAP-серверу.

Рис. 1. Процес користувальницької аутентифікації з використанням брандмауера XML

Лістинг 1 – це простий SOAP-запит, який передає в Web-сервіс готелю виклик методу GetSpecialDiscountedBookingForPartners. У цьому SOAP-запиті відсутні будь-які дані про цілісність повідомлення або користувальницької аутентифікації. Лістинг 1 – це початкова точка демонстрації застосування специфікації “Цифровий підпис XML”.

Лістинг 1


<?xml version=”1.0”?>
<SOAP-ENV:Envelope
    xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”>
    <SOAP-ENV:Body>
        <s:GetSpecialDiscountedBookingForPartners
            xmlns:s=“http://www.MyHotel.com/partnerservice/”>
                
<!--Parameters passed with the method call-->
        
</s:GetSpecialDiscountedBookingForPartners>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

SOAP в даному випадку використовується як приклад XML-формату, щоб продемонструвати “Цифровий підпис XML”, яка не є специфічною для SOAP. Тому її можна застосовувати, щоб вставляти підписи і профілі повідомлення в будь-який екземпляр XML: SOAP або який-небудь інший.

У наступному прикладі теги цифрового підпису XML будуть вставлені в заголовок SOAP. Цифровий підпис – це гнучка технологія, вона допускає включення таких тегів в будь-яке місце XML-файла. Насправді існують три типи підписів XML: містить в конверт (enveloping), укладається в конверт (enveloped) І відособлена (detached). Якщо підпис XML обертає дані, що підлягають підписанню, кажуть, що це містить у конверт підпис. Якщо ж дані, що підлягають підписанню, обертають цей підпис (наприклад, підпис XML стає елементом даних XML, які підписуються), то цей підпис називається укладається в конверт. Нарешті, якщо підпис і дані, що підлягають підписанню, зберігаються роздільно – підписується елемент і елемент підписи є елементами одного рівня – такий підпис прийнято вважати відокремленої. У прикладі, який в цій статті ілюструє застосування специфікації “Цифровий підпис XML”, використовуються відокремлені підпису.

Формування цифрового підпису XML: основні чотири кроки

Перший крок – це створення елемента Signature. З часом цей елемент буде обертати всі інші елементи цифрового підпису XML. У лістингу 2 точно таке ж тіло як і у лістингу 1, єдина відмінність між ними полягає в тому, що Лістинг 2 містить оголошення простору імен цифрового підпису XML (http://www.w3.org/2000/09/xmldsig #) і заголовок SOAP. Цей заголовок SOAP обертає елемент Signature.

Лістинг 2


<?xml version=”1.0”?>
<SOAP-ENV:Envelope
    xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
    xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”>

    <SOAP-ENV:Header>
        <ds:Signature>
             <ds:SignedInfo>
             </ds:SignedInfo>
             <ds:SignatureValue>
             </ds:SignatureValue>
             <ds:KeyInfo>
             </ds:KeyInfo>
        </ds:Signature>
    </SOAP-ENV:Header>

    <SOAP-ENV:Body>
        <s:GetSpecialDiscountedBookingForPartners
            xmlns:s=“http://www.MyHotel.com/partnerservice/”>
                
<!--Parameters passed with the method call-->
        
</s:GetSpecialDiscountedBookingForPartners>
    </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Елемент Signature в Лістингу 2 містить три дочірніх елементи: SignedInfo, SignatureValue і KeyInfo.

Цей елемент є єдиним загортання елементом для інших тегів цифрового підпису XML. У наступних кроках: 2, 3 і 4 – ми створимо дочірні вузли для цих трьох нащадків Signature (SignedInfo, SignatureValue і KeyInfo).

Другий крок – створення дочірніх вузлів елемента SignedInfo. Лістинг 3 – результат включення дочірніх вузлів SignedInfo в Лістинг 2. Закінчена структура елемента SignedInfo – Детальна ілюстрація того, як створюється підпис XML – елемент SignedInfo має декілька нащадків, кожен з яких містить кілька біт інформації, призначення якої буде розкрито нижче.

Лістинг 3


<?xml version=”1.0”?>
<SOAP-ENV:Envelope
    xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
    xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”>

    <SOAP-ENV:Header>
        <ds:Signature>
             <ds:SignedInfo>
                 
<ds:CanonicalizationMethod
                     
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                 
<ds:SignatureMethod
                     
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                 
<ds:Reference URI="#GetSpecialDiscountedBookingForPartners">
                     
<ds:Transforms>
                         
<ds:Transform
                             
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                     
</ds:Transforms>
                     
<ds:DigestMethod
                         
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                     
<ds:DigestValue>
                         
BIUddkjKKo2...
                     
</ds:DigestValue>
                 
</ds:Reference>
             </ds:SignedInfo>
             <ds:SignatureValue>
             </ds:SignatureValue>
             <ds:KeyInfo>
             </ds:KeyInfo>
        </ds:Signature>
    </SOAP-ENV:Header>

    <SOAP-ENV:Body>
        <s:GetSpecialDiscountedBookingForPartners
            xmlns:s=“http://www.MyHotel.com/partnerservice/”
            ID="GetSpecialDiscountedBookingForPartners">
                
<!--Parameters passed with the method call-->
        
</s:GetSpecialDiscountedBookingForPartners>
    </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

CanonicalizationMethod – Це обов’язковий елемент, який ідентифікує алгоритм канонізації, що застосовується до елемента SignedInfo до створення підпису.

Алгоритми канонізації надзвичайно важливі при підписанні XML, оскільки алгоритми дайджестів повідомлень інтерпретують XML як потік двійкових даних. Два різних потоку можуть представляти один і той же ресурс. Наприклад, якщо змінити послідовність атрибутів в елементі XML, результуючий XML-файл є логічно еквівалентної версією вихідного XML-файла. Однак, ці два логічно еквівалентних файлу будуть містять різні потоки даних і створюють різні дайджести.

Алгоритми канонізації призначені для генерації двійкових потоків для логічно еквівалентних даних XML. Щоб бути впевненим, що логічно еквівалентні XML-документи створюють один і той же дайджест (І однакову підпис), необхідно канонізувати ресурс XML до створення дайджесту потоку даних.

Елемент CanonicalizationMethod в Лістингу 3 містить атрибут Algorithm, Значенням якого є рядок URI (http://www.w3.org/2001/10/xml-exc-c14n#). Цей рядок URI вказує алгоритм, описаний специфікацією W3C – “Виняткова канонізація XML” (Exclusive XML Canonicalization). Подробиці канонізації XML виходять за рамки цієї статті. Детальна інформація про канонізацію може бути знайдена в статтях, посилання на які наведені в розділі Ресурси.

На даному етапі просто створюється елемент CanonicalizationMethod – А алгоритм канонізації поки не використовується. Він буде застосовується до елементу SignedInfo після того, як будуть сформовані всі його нащадки.

Наступний нащадок елемента SignedInfo – Це елемент SignatureMethod, Атрибут Algorithm якого вказує алгоритм, використовуваний для створення криптографічного підпису.

Третій нащадок елемента SignedInfo – Елемент Reference. У елемента SignedInfo повинен бути хоча б один елемент Reference. Цей елемент використовується для зберігання інформації, яка включає:

  1. Вказівка ​​даних, які підлягають підписанню. Для цього використовується атрибут URI елемента Reference. Підписувані дані можуть бути як всередині XML-документа, так і поза ним. Якщо дані і підпис знаходяться в одному і тому ж XML-документі, для їх вказівки використовується ідентифікатор фрагмента у вигляді значення атрибута URI елемента Reference. Так, в Лістингу 3 значення атрибута URI вказує на елемент GetSpecialDiscountedBookingForPartners. Якщо ж дані є зовнішніми по відношенню до файлу з цифровим підписом XML, посилатися на них необхідно за допомогою URI як значення атрибуту URI елемента Reference.
    Цифровий підпис XML дозволяє виконувати ряд операцій над даними раніше, ніж профілювати і підписувати їх. Наприклад, до того, як підписувати дані, їх можна канонізувати, або до їх профілювання до них можна застосувати будь-які перетворення XSL. Так, якщо дані про ціни представлені в табличній формі, їх можна перетворити, отримавши звичайний рахунок-фактуру. Для цього можна скористатися перетворенням XSL як шаблоном цього рахунку. Це означає, що буде підписуватися весь рахунок, а не тільки необроблені дані, включені у файл з цифровим підписом XML.
    Елемент Transforms містить інформацію про те, які операції виконуються на даних до їх підписання. У елемента Transforms в Лістингу 3 є один дочірній елемент Transform. Таких елементів може бути будь-яка кількість.
    Кожен елемент Transform вказує алгоритм перетворення. Якщо перетворювати дані до їх підписання, необхідно включити вказівку про те, що було зроблено, додавши елемент Transform. Завдяки цьому одержувач підписаного файлу зможе виконати таке ж перетворення до того, як спробувати перевірити підпис. У нашому прикладі була виконана тільки одна операція – алгоритм канонізації, зазначений за допомогою атрибута Algorithm елемента Transform.
    У тому випадку якщо елемент Transforms містить більше одного елемента Transform, Необхідно враховувати їх порядок проходження. Перетворення виконуються в тому порядку, в якому вони з’являються в елементі Transforms. Всі вони проводяться до профілювання даних. Отже, вихідні дані останнього елемента Transform є вхідними даними для алгоритму профілю повідомлення.
  2. Алгоритм, який використовується для створення дайджесту. Специфікація “Цифровий підпис XML” рекомендує використовувати алгоритм профілю SHA-1. Ця інформація знаходиться в елементі DigestMethod, Нащадку елемента Reference – У значенні його атрибута Algorithm (http://www.w3.org/2000/09/xmldsig#sha1).
  3. Значення дайджесту. Елемент DigestValue в Лістингу 3 містить дійсне значення дайджесту, отримане застосуванням алгоритму дайджесту до канонічної формі елемента GetSpecialDiscountedBookingForPartners. Необхідно відзначити, що бінарні дані в необробленому вигляді (такі як потік, створений алгоритмами дайджесту повідомлення, підписи та шифрування) не можуть бути загорнуті в розмітку XML – це може ускладнити розбір XML. Перш ніж обертати їх в розмітку XML, такі дані представляються в кодуванні base-64. В результаті, зашифровані дані не містять бітів, які могли б конфліктувати з правилами обробки XML.

Після того, як SignedInfo і його дочірні елементи сформовані, необхідно провести канонізацію всього елемента SignedInfo за алгоритмом, зазначеному в елементі CanonicalizationMethod. Після цього слід отримати значення дайджесту і обернути це значення в елемент SignatureValue, Як показано в лістингу 4. Під час підписання канонічна форма елемента SignedInfo використовується в якості даних, що підлягають підписанню. У неї входять всі дочірні елементи елемента SignedInfo.

Лістинг 4


<?xml version=”1.0”?>
<SOAP-ENV:Envelope
    xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
    xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”>

    <SOAP-ENV:Header>
        <ds:Signature>
             <ds:SignedInfo>
                 
<ds:CanonicalizationMethod
                     
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                 
<ds:SignatureMethod
                     
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                 
<ds:Reference URI="#GetSpecialDiscountedBookingForPartners">
                     
<ds:Transforms>
                         
<ds:Transform
                             
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                     
</ds:Transforms>
                     
<ds:DigestMethod
                         
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                     
<ds:DigestValue>
                         
BIUddkjKKo2...
                     
</ds:DigestValue>
                 
</ds:Reference>
             </ds:SignedInfo>
             <ds:SignatureValue>
                 halHJghyf765....
             </ds:SignatureValue>
             <ds:KeyInfo>
             </ds:KeyInfo>
        </ds:Signature>
    </SOAP-ENV:Header>

    <SOAP-ENV:Body>
        <s:GetSpecialDiscountedBookingForPartners
            xmlns:s=“http://www.MyHotel.com/partnerservice/”
            ID="GetSpecialDiscountedBookingForPartners">
                
<!--Parameters passed with the method call-->
        
</s:GetSpecialDiscountedBookingForPartners>
    </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Необхідно відзначити, що структура SignedInfo містить посилання на підписувані дані (атрибут URI елемента Reference), Значення дайджесту та ім’я методу підпису, а також інші біти інформації. Отже, підписання структури SignedInfo фактично означає підписання дайджесту даних разом із самою посиланням на ці дані.

В Лістингу 2 у елемента Signature є ще один дочірній елемент по імені KeyInfo. Четвертий крок – створення його нащадків. В Лістингу 5 елемент KeyInfo містить дочірній елемент KeyName. Цей елемент KeyName є ідентифікатором ключа, який використовується для перевірки підпису. KeyName – Це просто “заповнювач” для ідентифікаторів ключа. Специфікація “Цифровий підпис XML” не визначає механізм, який співвідносить ідентифікатор з дійсною парою ключів, використовуваних для підписання. Проектування механізму ідентифікації ключа – завдання додатків, що реалізують “Цифровий підпис XML”. Наприклад, ідентифікатор ключа в Лістингу 5 (MyKeyIdentifier) Може ідентифікувати загальний секретний ключ (симетричний ключ), яким вже обмінювалися туроператор і готель.

Лістинг 5


<?xml version=”1.0”?>
<SOAP-ENV:Envelope
    xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
    xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”>

    <SOAP-ENV:Header>
        <ds:Signature>
             <ds:SignedInfo>
                 
<ds:CanonicalizationMethod
                     
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                 
<ds:SignatureMethod
                     
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                 
<ds:Reference URI="#GetSpecialDiscountedBookingForPartners">
                     
<ds:Transforms>
                         
<ds:Transform
                             
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                     
</ds:Transforms>
                     
<ds:DigestMethod
                         
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                     
<ds:DigestValue>
                         
BIUddkjKKo2...
                     
</ds:DigestValue>
                 
</ds:Reference>
             </ds:SignedInfo>
             <ds:SignatureValue>
                 halHJghyf765....
             </ds:SignatureValue>
             <ds:KeyInfo>
                 <ds:KeyName>MyKeyIdentifier</ds:KeyName>
             </ds:KeyInfo>
        </ds:Signature>
    </SOAP-ENV:Header>

    <SOAP-ENV:Body>
        <s:GetSpecialDiscountedBookingForPartners
            xmlns:s=“http://www.MyHotel.com/partnerservice/”
            ID="GetSpecialDiscountedBookingForPartners">
                
<!--Parameters passed with the method call-->
        
</s:GetSpecialDiscountedBookingForPartners>
    </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Крім того, елемент KeyInfo – Необов’язковий: його можна як включати, так і не включати в підпис. Цей елемент є необов’язковим, тому що при підписанні, можливо, може не знадобитися включати інформацію про ключ в файл з цифровим підписом XML. Елемент KeyInfo може також використовуватися для шифрування XML, про що буде розказано в наступному розділі.

Ці чотири кроки – проста демонстрація застосування специфікації “Цифровий підпис XML”. Лістинг 5 – повне SOAP-повідомлення, яке в своєму заголовку несе дані про цілісність повідомлення та користувальницької аутентифікації.

Розглянемо, як обробляється заголовок повідомлення, представленого в Лістингу 5, на стороні Web-сервісу готелю.

Перевірка цифрового підпису XML

Процедура перевірки проста і логічно може бути виведена з методики формування цифрового підпису XML, розглянутої вище. Вона розпадається на три етапи.

По-перше, необхідно канонізувати елемент SignedInfo. Нагадаємо, що елемент CanonicalizationMethod встановлює алгоритм канонізації. Тому слід скористатися цією канонічної формою елемента SignedInfo для решти процесу перевірки.

По-друге, необхідно проконтролювати цілісність повідомлення, перевіривши дайджест, який знаходиться в елементі Reference, Сформованому раніше, на кроці 2. При перевірці дайджесту потрібно мати інформацію, яка включає:

  1. Дані, за якими побудований дайджест. Слід разименовивать атрибут Reference елемента, щоб отримати ці дані.
  2. Будь-які трансформації, які можуть застосовуватися до цих даних до запуску алгоритму профілю. В елементі Transforms міститься ця інформація. Перш ніж отримувати дайджест даних, необхідно застосувати до них ті ж трансформації.
  3. Алгоритм дайджесту. Ця інформація знаходиться в значенні атрибуту Algorithm елемента DigestMethod. Необхідно застосувати цей дайджест повідомлення і перевірити, не чи відрізняється значення дайджесту від тієї, що міститься в елементі DigestValue.

Якщо перевірка дайджесту призводить до негативного результату, то процес перевірки закінчується і вважається незадовільним.

Якщо з’ясовується, що з величиною профілю все в порядку, настає черга третього етапу – перевірки підпису. Для перевірки підпису необхідний ключ підписала сторони (відкритий або загальний секретний). Інформацію про ключ можна отримати з елемента KeyInfo, Якщо він присутній (або якщо додатком вже відома така інформація). Як тільки ключ, використовуваний при перевірці підпису, відомий, потрібно прочитати метод підпису, який застосовувався при створенні цієї підпису. Атрибут Algorithm елемента SignatureMethod містить цю інформацію. Після чого слід скористатися канонічної формою елемента SignedInfo і ключем, щоб підтвердити величину підпису.

При реалізації специфікації “Цифровий підпис XML” можна створювати заголовки SOAP для генерації підписаних SOAP-повідомлень. Брандмауер XML, що знаходиться на стороні одержувача, обробляє цей заголовок SOAP, щоб перевірити підписи перш ніж переслати запит на SOAP-сервер. Даний процес представлений на малюнку 1. Завдання забезпечення безпеки може бути досягнуто таким чином:

Таким чином, торкаючись нашого прикладу, можна бути впевненим, що запит про резервування за спеціальною ціною зі знижкою був оправлений дійсно партнером, і що ці дані не були змінені, поки вони передавались. Тим не менш, можливо ситуація, коли дані, передані по Інтернету, можуть бути переглянуті хакерами. Розглянемо, як ця проблема може бути вирішена за допомогою специфікації “Шифрування XML”.

Шифрування XML

Специфікація шифрування XML задовольняє вимогам конфіденційності XML-повідомлень. Ця специфікація дозволяє реалізувати наступну функціональність:

Шифрування цілого XML-файла

Давайте почнемо з шифрування цілого XML-файла. Лістинг 6 – це приклад такого зашифрованого файлу. При цьому вихідний XML-документ не показаний, оскільки він не потрібен, так як шифрування XML-файла своїм результатом має таку ж XML-структуру – за винятком зашифрованою величини, укладеної в елементі CipherValue.

Лістинг 6


<?xml version='1.0'?>
<EncryptedData
    xmlns="http://www.w3.org/2001/04/xmlenc#"
    MimeType="text/xml">
    <EncryptionMethod
        Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:KeyName>MyKeyIdentifier</ds:KeyName>
    </ds:KeyInfo>
    <CipherData>
      <CipherValue>B457V645B45........</CipherValue>
    </CipherData>
</EncryptedData>

Кореневий елемент EncryptedData несе зашифровані дані разом з такою необхідною інформацією, як алгоритм, використовуваний для шифрування. Цей елемент містить оголошення простору імен шифрування XML (http://www.w3.org/2001/04/xmlenc#) І атрибут MimeType, Значення якого дорівнює text/xml. З цього атрибуту одержувач цього зашифрованого XML-файла може зрозуміти, що XML-файл був зашифрований, щоб створити структуру EncryptedData.

Перший нащадок кореневого елемента – елемент EncryptionMethod. Цей елемент містить атрибут Algorithm, Який визначає алгоритм, використаний при шифруванні. Його значення дорівнює http://www.w3.org/2001/04/xmlenc#3des-cbc, Що визначає алгоритм потрійний DES (Data Encryption Standard, Стандарт шифрування даних).

Елемент ds:KeyInfo той же самий, що і той, який використовувався при застосуванні специфікації “Цифровий підпис XML”. Необхідно відзначити, що цей елемент був запозичений з простору імен цифрового підпису XML.

Елемент EncryptedData містить ще один дочірній елемент – CipherData, У якого в свою чергу є дочірній елемент CipherValue. Цей елемент CipherValue несе зашифроване зміст (зашифровану версію XML-документа). Таким чином, результатом шифрування XML-файла є вміст елемента CipherValue.

Шифрування окремого елемента

Як було сказано вище, структура EncryptedData несе зашифровані дані разом з необхідною інформацією. В основі шифрування одиночного елемента XML-файла лежить аналогічний підхід. Розглянемо Лістинг 7, в якому зашифрований елемент GetSpecialDiscountedBookingForPartners з лістингу 1 отримано простою заміною елементом EncryptedData.

Лістинг 7


<?xml version=”1.0”?>
<SOAP-ENV:Envelope
    xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”>
    <SOAP-ENV:Body>
        <xenc:EncryptedData
            
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
            
Type="http://www.w3.org/2001/04/xmlenc#Element">
            
<xenc:EncryptionMethod
                
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
            
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                
<ds:KeyName>MyKeyIdentifier</ds:KeyName>
            
</ds:KeyInfo>
            
<xenc:CipherData>
                  
<xenc:CipherValue>B457V645B45........</xenc:CipherValue>
             </xenc:CipherData>
        </xenc:EncryptedData>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Порівняємо елемент EncryptedData з лістингу 6 з елементом EncryptedData з лістингу 7. Неважко бачити, що є одна відмінність: замість атрибута MimeType Лістингу 6 в Лістингу 7 з’явився атрибут Type. Значення цього атрибута дорівнює http:///www.w3.org/2001/04/xmlenc#Element, Що означає, що зашифрований XML-елемент.

Таким чином, при шифруванні елемента XML-файла слід використовувати ідентифікатор http:///www.w3.org/2001/04/xmlenc#Element в якості значення атрибута Type. У цьому випадку одержувач зашифрованого XML-файла буде знати, що зашифровані дані повинні інтерпретуватися як XML-елемент в розшифрованої простий текстовій формі.

Шифрування змісту елемента

Розглянемо Лістинг 8, в якому зашифровано тільки зміст елемента GetSpecialDiscountedBookingForPartners – Для цього цей зміст було замінено структурою EncryptedData. Цей прийом схожий на шифрування елемента (див. Лістинг 7). Відмінність полягає в тому, що на цей раз значення атрибута Type тега EncryptedData одно http://www.w3.org/2001/04/xmlenc#Content. Це значення говорить про те, що зашифровані дані повинні інтерпретуватися як зміст елемента.

Лістинг 8


<?xml version=”1.0”?>
<SOAP-ENV:Envelope
    xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”>
    <SOAP-ENV:Body>
        <s:GetSpecialDiscountedBookingForPartners
            xmlns:s=“http://www.MyHotel.com/partnerservice/”
            ID="GetSpecialDiscountedBookingForPartners">
            <xenc:EncryptedData
                
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
                
Type="http://www.w3.org/2001/04/xmlenc#Content">
                
<xenc:EncryptionMethod
                    
Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
                
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                    
<ds:KeyName>MyKeyIdentifier</ds:KeyName>
                
</ds:KeyInfo>
                
<xenc:CipherData>
                      
<xenc:CipherValue>B457V645B45........</xenc:CipherValue>
                </xenc:CipherData>
            </xenc:EncryptedData>
        
</s:GetSpecialDiscountedBookingForPartners>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Обробка шифрування XML

Розглянемо, як брандмауер XML працює з поняттями шифрування. Брандмауер отримує Лістинг 7 або 8 (SOAP-повідомлення з зашифрованими елементами або змістом) і, перш ніж переслати SOAP-серверу розшифрований запит SOAP-повідомлення, перетворює їх вміст у дешифрованих форму.

Одержувач зашифрованого XML-файла (наприклад, в нашому випадку брандмауер XML готелю) розшифровує цей XML-файл, виконуючи таку послідовність дій:

  1. Витягує зашифроване зміст елемента CypherValue.
  2. Зчитує значення атрибута алгоритму елемента EncryptionMethod.
  3. Зчитує значення атрибута Type елемента EncryptedData.
  4. Отримує інформацію про ключ з елемента ds:KeyInfo.
  5. Використовує отриману інформацію для створення простого текстового (розшифрованого) файлу.

Введення в безпеку Web-сервісів

Виникає питання, яким чином брандмауер XML використовує підпису та шифрування XML для захисту SOAP-серверів? Адже незважаючи на те, що можливості цих двох технологій були продемонстровані на численних прикладах, необхідно з’ясувати, як застосовувати ці дві специфікації при використанні брандмауера XML для захисту SOAP-серверів, особливо якщо врахувати жодна з них не є специфічною для SOAP. Спробуємо зрозуміти, чому вся інформація, що стосується підпису, була поміщена в заголовок SOAP, а не в тіло SOAP.

Специфікація консорціуму OASIS “Безпека Web-сервісів” докладно визначає, як застосовувати технології підпису та шифрування XML при обміні SOAP-повідомленнями. Цей стандарт отримує елементи низького рівня з розглянутих вище специфікацій (“Цифровий підпис XML” і “Шифрування XML”) і задає високорівнева синтаксис для обгортання в SOAP-повідомленнях інформації про безпеку.

Специфікація “Безпека Web-сервісів” описує механізм безпечного обміну SOAP-повідомленнями. Вона забезпечує наступну функціональність:

  1. Цілісність повідомлення.
  2. Налаштовувану аутентифікацію.
  3. Конфіденційність.

Розглянемо Лістинг 9 – це SOAP-повідомлення, яке несе інформацію про безпеку згідно синтаксису специфікації “Безпека Web-сервісів”. Лістинг 9 – цей той же самий SOAP-запит GetSpecialDiscountedBookingForPartners, Який неодноразово наводився в цій статті. Однак на цей раз заголовок запиту передає інформацію про цифровий підпис відповідно до розглянутої специфікацією.

Лістинг 9


<?xml version="1.0" encoding="utf-8"?>
<SOAP:Envelope
    xmlns:SOAP="http://www.w3.org/2001/12/soap-envelope"
    xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/xx/secext"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <SOAP:Header>
        <wsse:Security>
            <wsse:BinarySecurityToken
                ValueType="wsse:X509v3"
                EncodingType="wsse:Base64Binary"
                wsu:Id="MyTourOperatorCertificate">
                   LKSAJDFLKASJDlkjlkj243kj;lkjLKJ...
            </wsse:BinarySecurityToken>
            <ds:Signature>
                <ds:SignedInfo>
                    <ds:CanonicalizationMethod 
                        Algorithm="http://www.w3.org/2001/10/xml -exc-c14n# "/>
                    <ds:SignatureMethod
                        Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                    <ds:Reference URI="#myDiscountRequestBody">
                        <ds:Transforms>
                            <ds:Transform
                                Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                        </ds:Transforms>
                        <ds:DigestMethod
                            Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                        <ds:DigestValue>BSDFHJYK21f...</ds:DigestValue>
                    </ds:Reference>
                </ds:SignedInfo>
                <ds:SignatureValue>
                    GKLKAJFLASKJ52kjKJKLJ345KKKJ...
                </ds:SignatureValue>
                <ds:KeyInfo>
                    <wsse:SecurityTokenReference>
                        <wsse:Reference URI="#MyTourOperatorCertificate"/>
                    </wsse:SecurityTokenReference>
                </ds:KeyInfo>
            </ds:Signature>
        </wsse:Security>
    </SOAP:Header>
    <SOAP-ENV:Body>
        <s:GetSpecialDiscountedBookingForPartners
            xmlns:s=“http://www.MyHotel.com/partnerservice/”
            ID="myDiscountRequestBody">
                
<!--Parameters passed with the method call-->
        
</s:GetSpecialDiscountedBookingForPartners>
    </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Щоб краще зрозуміти синтаксис специфікації “Безпека Web-сервісів”, розглянемо Лістинг 9:

  1. Елемент SOAP:Envelope містить оголошення просторів імен для SOAP, “Безпека Web-сервісів” і “Цифровий підпис XML”.
  2. У елемента SOAP:Header є тільки один дочірній елемент (wsse:Security), Який є обгорткою для всієї інформації про безпеку. У елемента wsse: Security два дочірніх елементи: wsse:BinarySecurityToken і ds:Signature.
  3. Елемент wsse:BinarySecurityToken містить маркер доступу (security token). Маркер доступу подібний пропуску, що видається службою безпеки, або посвідченням особи, яке необхідно пред’явити при вході в область обмеженого доступу. Нижче описані основні типи маркерів доступу.
    Найбільш популярний і широко використовуваний маркер доступу – це пара логін-пароль, як та, що застосовується при перевірці електронної пошти.
    Пара логін-пароль – це маркер доступу, призначений для людини. Існують маркери доступу, які мають бінарну форму (і, отже, можуть бути нечитабельним). Такі маркери називаються бінарними маркерами доступу. Наприклад, сертифікат X509 (дуже популярний формат цифрових сертифікатів, розроблений Міжнародним союзом електрозв’язку – сектору телекомунікацій (International Telecommunications Union – Telecommunications sector, ITU-T)) – це бінарний маркер доступу.
    Атрибут ValueType елемента wsse:BinarySecurityToken містить інформацію про те, який тип бінарного маркера доступу загорнутий в елемент wsse:BinarySecurityToken. В Лістингу 9 значення цього атрибута дорівнює wsse:X509v3, Що означає сертифікат X509.
    Атрибут EncodingType елемента wsse:BinarySecurityToken показує, яка кодування у бінарного маркера доступу. Як уже зазначалося вище, бінарні дані не можуть бути загорнуті в формат XML. Отже, вони повинні бути перетворені в даний формат (як правило, вони представляються у кодуванні base-64). Сертифікат X509 обгорнутий в елемент wsse:BinarySecurityToken як зміст цього елемента.
  4. Елемент ds:Signature точно такий же як і той, що був розглянутий раніше в розділі про підписи XML. Необхідно звернути увагу на наступні два моменти:
    • Значення атрибута URI (#myDiscountRequestBody) Елемента Reference є ідентифікатором фрагмента, який вказує на елемент SOAP:Body. Це означає, що елемент SOAP:Body – Це той елемент, який вже був підписаний і обгорнутий в теги цифрового підпису XML.
    • У елемента ds:KeyInfo є елемент wsse:SecurityTokenReference, Який містить посилання на маркери доступу. В нашому випадку у нього є дочірній елемент wsse:Reference, Атрибут URI якого вказує на елемент wsse:BinarySecurityToken, Розглянутий в пункті 3 цього розділу. Це означає, що відкритий ключ у сертифікаті X509 (те, що обертає елемент wsse:BinarySecurityToken) Використовується для перевірки підпису.

Розглянутий приклад дуже простий, він знайомить з підписаними повідомленнями захищених Web-сервісів. У третій і четвертій статтях цього циклу будуть детально розглянуті питання безпеки XML: різні типи маркерів доступу, які можуть використовуватися з “Безпекою Web-сервісів”, та в разі застосування специфікації “Шифрування XML” в повідомленнях захищених Web-сервісів.

У наступній статті буде представлений Мова розмітки тверджень безпеки (Security Assertions Markup Language, SAML), який дозволяє додаткам Web-сервісів спільно використовувати інформацію про користувача аутентифікації. Цей обмін аутентифікаційні даними зазвичай називається одиночним пред’явленням пароля (single sign-on). SAML може бути використаний як маркер доступу в додатках захищених Web-сервісів. У наступній статті буде пояснено чому, коли і як.

Ресурси

Оригінальний текст статті можна подивитися тут:

Web Services Security, Part 2

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*