 |
|
|
|
Защита веб-служб. РНР-реализация
Защита веб-служб. РНР-реализация Веб-службы с каждым днем находят все большее применение как в публичных, так и в корпоративных системах. Как правило, такие системы требуют аутентификацию клиента и криптозащиту данных. Но у конечного пользователя не всегда есть возможность организовать обмен данных по SSL-каналу. В этом случае защиту веб-служб можно построить в соответствии со спецификацией WS-Security, с помощью Open Source-библиотеки – xmlsec. Старые песни о главном Использование веб-службы во многих внутрикорпоративных информационных системах и финансовых сервисах требуют как персонализацию доступа, так и криптозащиту передаваемой информации. Увы, при разработке группы спецификаций веб-служб консорциум W3С ориентировался прежде всего на их публичное использование, и по этой причине вопросы безопасности веб-служб изначально не рассматривались как приоритетные. Традиционный подход к защите передаваемых данных в WEB предполагает организацию защищенного SSL-канала, и доступ к веб-службе организуется по протоколу HTTPS (поддерживающее шифрование данных расширение протокола HTTP). Специфика этого протокола требует наличия на сервере специального SSL-сертификата, фактически привязанного к одному конкретному IP-адресу. Такое решение не всегда удобно, прежде всего в том случае, когда нам необходимо реализовать несколько различных защищенных каналов на одном веб-ресурсе. Потребность в предоставлении конфиденциальной информации посредствам веб-служб росла, и требовалась разработка соответствующих спецификаций. Организация продвижения стандартов структурированной информации – OASIS (the Organization for the Advancement of Structured Information Standards) – разработала новый набор спецификаций по защите веб-служб, обобщив накопленный опыт и учитывая имеющиеся недостатки. Группой OASIS были предложены два подхода: SAML [5] и WS-Security [1]. SAML (Security Assertion Markup Language) – это язык разметки заявлений системы безопасности. Он осуществляет описание функций безопасности, относящихся к аутентификации и авторизации. SAML используется поверх существующей инфраструктуры систем безопасности. Спецификация WS-Security, напротив, описывает форматы закрытия данных и цифровой подписи SAOP-собщений. Развертывание веб-служб на базе спецификации WS-Security намного проще, и этот стандарт получил более широкое распространение. Спецификация WS-Security была разработана на базе так называемой технологии проталкивания открытых ключей. Обычно при организации инфраструктуры открытых ключей (Public Key Infrastructure) используется один из двух подходов: создание механизмов запроса подлинности сертификата у Удостоверяющего центра, так называемое «вытягивание», или присоединение к исходному сообщению Сертификата подлинности, то есть «проталкивание» Сертификата. Сегодня количество защищенных веб-служб постоянно увеличивается. Существует множество реализаций соответствующих библиотек для Java-платформы. Очередной всплеск активности в разработке защищенных веб-сервисов наметился и после выхода NET-Studio 2005, включающей в себя библиотеку пространства имен Microsoft.Web.Servises.Security. Пришла пора и РНР. Песнь песней, или Что говорят нам спецификации Спецификация WS-Security позволяет организовать защиту SOAP-сообщения вне зависимости от транспортного протокола. В основе WS-Security лежат спецификации:
Перейдем к примерам. В соответствии со спецификацией SOAP [1] все SOAP-сообщение делится на две части: заголовок и тело сообщения. Заголовок содержит всю служебную информацию и обрамлен тегами <Header>. Тело сообщения содержит наши данные. Тело сообщения обрамляется тегами <Body>. В листинге 1 изображен «конверт» SOAP-сообщения, выделенный черным цветом. Листинг 1. Место WS-Security в SOAP-сообщении <Envelope> <Header> <wse:Security> <ds:Signature> . . . </ds:Signature> </wse:Security> </Header> <Body> <data>...</data> </Body> </Envelope> Для примера взяты данные, которые содержатся в тегах <data>...</data> и для наглядности выделены красным цветом. Как было уже упомянуто, теги <data> помещены в тело SOAP-сообщения. В заголовок помещается вся информация спецификации WS-Security. Определим для этой спецификации пространство имен wse. Корневым элементом WS-Security является тег <wse:Security>. Данный элемент в листинге 1 выделен темно-зеленым цветом. Вся информация, которая имеет отношение к цифровой подписи, определена в спецификации XML Signature, префикс пространства имен ds. В листинге 1 и далее по тексту все теги этого пространства имен изображены синим цветом. Корневым тегом пространства имён XML Signature является тег <ds:Signature>. Тег является дочерним по отношению к тегу <wse:Security>. В случае если необходимо закрыть SOAP-сообщение, то все данные в соответствии со спецификацией SOAP должны находиться в теле сообщения, а вся служебная информация в заголовке сообщения. Закрытые данные будут представлены тегами <en EncryptedData>, а вся связанная с закрытием информация – ключи, ссылки и прочее должны быть расположены в элементе <wes:Security> (см. листинг 2). Листинг 2. Криптозащита SOAP-сообщения <Envelope> <Header> <wse:Security> <en:ReferenceList> <en:Data Reference URI="#bodyID"/> <en:ReferenceList> </wse:Security> <Header> <Body Id="bodyID" > <en:EncryptedData > < en:Encryption Method … /> <ds:KeyInfo >… <\dsKeyInfo> < en:CipherData> < en CipherValue>SFD0BZGwZY8KTbL... </ en:CipherValue> < en:CipherData> <en:EncryptedData > </Body> </Envelope> Рассмотрим пример формирования цифровой подписи SOAP-сообщения. В листинге 3 показан шаблон, т.е каркас структуры сообщения, без данных криптопреобразования подписанного SOAP-сообщения. Далее, в процессе подписания SOAP-сообщения должен будет заполниться контент элементов тегов <ds:DigectValue>, <ds:SignatureValue> и <ds:X509Certificate>. В соответствии со спецификацией XML Signature подписываемые данные должны находиться в корне документа. Если они находятся не в корне, то атрибут URI элемента <ds:Reference> указывает на адрес положения корневого элемента подписываемых данных. Это может быть как внешний документ, т.е. его адрес может быть как внешним, например http://hostname/path/document или file://path/document, так и внутренней ссылкой, например, выражением xpointer или просто указателем на элемент, имеющий ссылочный атрибут Id. Если идет ссылка, через атрибут Id, то для внутренней ссылки необходимо перед значением атрибута Id указать символ #. Так как мы используем подпись SOAP-сообщения, то значение атрибута URI элемента <ds:Reference> иметь внутреннюю ссылку через атрибут Id. Значение ссылочного атрибута Id равно Body, соответственно значение атрибута URI элемента <ds:Reference> будет #Body. Листинг 3. Криптошаблон защищенного SOAP-сообщения <Envelope> <Header> <wse:Security> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="... " /> <ds:SignatureMethod Algorithm="... " /> <ds:Reference URI="Body"> <ds:Transform> <ds:Transform Algorithm="... " /> </ds:Transform> <ds:DigestMethod Algorithm="... " /> <ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue /> <ds:KeyInfo> <ds:X509Data> <ds: X509Certificate> </ds:X509Data> </ds:KeyInfo> </ds:Signature> </wse:Security> </Header> <Body Id="#BodyId"> <data>...</data> </Body> </Envelope> Как было отмечено, контент (закодирован как Binary64) части элементов заполняется после обработки шаблона (см. листинг 3) криптопроцессором:
Результат обработки показан в листинге 4. Листинг 4. Результат цифровой подписи XML-Документа (спецификация XML-Signature) <Envelope> <Header> <wse:Security> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="... " /> <ds:SignatureMethod Algorithm="... " /> <ds:Reference URI="#Body"> <ds:Transforms>...</ds:Transforms> <ds:DigestMethod Algorithm="... " /> <ds:DigestValue >HjY8ilZAIEM2tBbPn5mYO1ieIX4=<ds:DigestValue > </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> SIaj/6KY3C1SmDXU2++Gm31U1xTadFp04WhJ/ajq8/l4ncAi2 BgfsJFbxrL+q7GKSKN9kfQ+UpN9+iD5fWmuavXEHe4Gw6R ... .................................................. ... hWYJ4ewZJ4hM4JjbFqZO+OEzDRSbw3DkmuBA/mtlx+3t13 5hqoMdVmtth/eTb64dsPdl9r 3k1ACVX9f8aHfQQdJOmLFQ== <ds:SignatureValue> <ds:KeyInfo > <ds:X509Data> <ds:X509Certificate> MIIE3zCCBEigAwIBAgIBBTANBgkqhkiG9w0BAQQ owgb8xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEw ... ........................................... ... Zm9ybmlhMT0wOwYDVQQKEzRYTUwgU2VjdXJp dHkgTGlicmFyeSAoaHR0cDovL3d3dy5hbGVrc2V5L== </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo > </ds:Signature> </wse:Security> </Header> <Body Id="Body"> <data>...</data> </Body> </Envelope> Однако в соответствии с рекомендациями спецификации WS-Security все данные о ключах и сертификатах рекомендует выносить в элемент <wse:BinarySecurityToken> пространства имен WS-Security. Данный элемент в соответствии со спецификацией WS-Security является дочерним элементом <wse:Security>. Для определения месторасположения и состава данных, которые «должны» содержаться в элементе <ds:KeyInfo>, используются элементы <wse:Reference> и <wse:SecurityTokenReference>. Элемент <wse:Reference> аналогично элементу <ds:Reference> содержит атрибут URI, который содержит локальный адрес ссылки. Алгоритм формирования атрибута URI аналогичен алгоритму формирования атрибута URI элемента. Итак, последний шаг – это приведение полученного результата в соответствие со Спецификацией WS-Security. Для этого необходимо содержание элемента <ds:X509Certificate> перенести в элемент <wse:BinarySecurityToken>, а сам элемент <ds:X509Data> вместе с дочерним элементом <ds:X509Certificate> удалить. Это показано в листинге 5. Листинг 5. Приведение XML-Signature к WS-Security <Header> <wse:Security> <wse:BinarySecurityToken EncodungType="wse:Base64Binary" Value Type="wse:X509v3" Id="KeyToken"> gPC6vbTV50fxaXO/ZvOb6osvWmJpQBlJIOxRBcs2nS Y8MTqPgAa02gtaLQ6Thmpx1rc6VHuraLuIcsQ2BLu9 ............................................ REYvU2LtjCZfnBntDgvygJ1bzHCR8SxjzIAfHRsxpv== </wse:BinarySecurityToken > <ds:Signature> <ds:SignedInfo>. . .</ds:SignedInfo> <ds:SignatureValue>. . .</ds:SignatureValue> <ds:KeyInfo > <wse:SecurityTokenReference> <wse:Reference URI="#KeyToken"> </wse:SecurityTokenReference> <ds:X509Data> <ds:X509Certificate> gPC6vbTV50fxaXO/ZvOb6osvWmJpQBlJIOxRBcs2nS Y8MTqPgAa02gtaLQ6Thmpx1rc6VHuraLuIcsQ2BLu9 ............................................ REYvU2LtjCZfnBntDgvygJ1bzHCR8SxjzIAfHRsxpv== </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo > </ds:Signature> </wse:Security> </Header> Подлежащий удалению контент в листинге 5 отображен серым цветом. В элемент <ds:KeyInfo> добавляются элементы <wse:Reference> и <wse:SecurityTokenReference>, а атрибут URI элемента <wse:Reference> должен будет указывать на локальный ссылочный адрес, через Id элемента <wse:BinarySecurityToken>. С песней по жизни, или Хватит теории – ближе к делу Для реализации спецификации WS-Security на практике у нас есть несколько возможных путей. Реализация средствами РНР алгоритма подписи SAOP-сообщения, используя расширения mcrypt и OpenSSL. Данный вариант хорош, но слишком трудоемок. А нет ли путей решения, использующих уже готовые механизмы? Как вариант можно портировать готовые библиотеки классов .NET или JAVA. Данный вариант требует трудозатрат на изучение не простого API соответствующих классов .NET и JAVA. Можно использовать оболочку php-swig (www.swig.org) и портировать необходимые функции библиотек libxmlsec (www.aleksey.com/xmlsechttp) или xml-security-с (http://xml.apache.org/security). Однако данный вариант, аналогично предыдущему, требует значительных трудозатрат на изучение API С-функций. Наиболее простым решением будет использование утилиты командной строки xmlsec, которая входит в дистрибутив библиотеки libxmlsec. Рассмотрим предложенный вариант более подробно. Для использования утилиты командной строки xmlsec необходимо установить библиотеку libxmlsec (официальный сайт – http://aleksey.com/xmlsec). Установка под *NIX-платформы может осуществляется как из источников, так и из портов (FreeBSD) или RPM (Linux), для Windows есть бинарные библиотеки. Для развертывания библиотеки libxmlsec требуются дополнительные библиотеки:
Это необходимо учитывать тем, кто собирается устанавливать libxmlsec из источников. Алгоритм формирования цифровой подписи SOAP-сообщения представляет собой три основных шага:
Формирование шаблона. Шаблон должен соответствовать структуре XML-документа, указанного в листинге 3. Шаблон может быть сформирован либо как DOM-документ, либо загружен из файла, это на усмотрение разработчика. Нам необходимо подписываемое сообщение, а точнее, данные XML-документа, импортировать в тело SOAP-сообщения. В листинге 6 приведен пример формирования подписываемого шаблона: Листинг 6. Пример кода формирования шаблона с подписываемым XML-документом 01 $doc = new DOMDocument(); 02 $doc->loadXML( $dataTxt); 03 04 $tpl = new DOMDocument(); 05 $tpl->loadXML( $xml); 06 07 $root = $doc->documentElement; 08 $data =$tpl->importNode($root, true); 09 10 $body0 = $tpl->getElementsByTagName("Body"); 11 $body = $body0->item(0); 12 $body->appendChild( $data ); Строки 1, 2 загружают данные для документа, которые должны быть включены в тело SOAP-сообщения (внутрь элемента <Body>). Строки 4, 5 загружают шаблон SOAP-сообщения, который должен соответствовать шаблону в листинге 3 с пустым элементом <Body/>. Строки 7-12 реализуют импорт тела документа $doc в дочерний элемент <Body/> шаблона $tpl. Подпись шаблона осуществляется утилитой командной строки xmlsec. Следует отметить, что Windows и UNIX-версии будут немного отличаться. Во-первых, утилита командной строки в UNIX-версии называется xmlsec1, а в Windows версии – xmlsec. Так же в Windows-версии немного иначе работают механизмы перенаправления ввода-вывода. Далее будем рассматривать реализацию UNIX-версии. Первоначально необходимо записать наш шаблон во временный файл, а потом сформировать и выполнить соответствующую командную строку: Листинг 7. Пример кода формирования подготовки данных для их цифровой подписи (XML-Signature) 01 $temp_path = "/home/akalend/tmp"; 02 $prefix = "in"; 03 $tmpfname = tempnam($temp_path , $prefix ); 04 $tpl->save($tmpfname); 05 06 $key="/home/akalend/xmlsec/rsakey.pem"; 07 $certFile="/home/akalend/xmlsec/rsacert.pem"; 08 09 $cmd="xmlsec1 --sign --privkey-pem $key,$certFile --id-attr:id body $tmpfname 2>&1"; В приведенном коде строки 1-4 формируют промежуточный файл нашего шаблона в директории $temp_path. Строки 6, 7 определяют полные имена файлов – закрытый ключ (rsakey.pem) и сертификат подлинности (rsacert.pem). Строка 9 – формирование команды для выполнения в командном режиме. Утилита xmlsec1 имеет следующие параметры:
Так как для подписи используется внутренняя ссылка (id="body"), то из-за специфики реализации работы с указателями xpointer() в libxml необходимо явно указывать на ссылающийся элемент. В связи с этим используется параметр --id-attr:id Body (ссылка осуществлена посредством атрибута id элемента <Body id="body">). Как альтернативу можно использовать DTD-объявления. В нашем примере при выполнении в режиме командной строки осуществляется перенаправление stderr в поток стандарного вывода. В этом случае и результат, и ошибка будут в потоке стандартного вывода. Осуществим выполнение команды и получение результата через popen(): Листинг 8. Пример кода формирования цифровой подписи XML-документа (XML-Signature) 01 $p = popen( $cmd, 'r'); 02 $readStream = ""; 03 while( !feof($p) ) 04 $readStream .= fread($p , 8192); 05 pclose($p); 06 07 if( strpos($readStream, "<?xml version=\"1.0 \"") === false ) 08 die("error:" . $readStream); 09 $doc->loadXML( $ readStream ); Строки 1-5 осуществляют выполнение командным процессором строки $cmd. Строки 7, 8 осуществляют грубую проверку – является ли входной документ XML-документом или это сообщение об ошибке. Принципиально такой проверки вполне достаточно. Как вариант можно использовать два промежуточных файла $tmpfname_in и $tmpfname_out. Тогда в командной строке добавится параметр --output $tmpfname_out. Строка 9 загружает данные из переменой в XMLDocument для дальнейшей обработки. Приведение к спецификации WS-Security осуществляется путем переноса содержания узла XMLNode <X509Certificate> в узел <BinarySecurityToken id="bst"> и удаление узла <X509Data>. Листинг 9. Пример кода переноса данных из узла <X509Data> в узел <BinarySecurityToken> 01 $x509cert = $doc-> getElementsByTagName("X509Certificate") -> item(0); 02 $bst = $doc -> getElementsByTagName("BinarySecurityToken") -> item(0); 03 $bst ->NodeValue = $ x509cert-> NodeValue; 04 05 $KeyInfo = $x509cert -> parentNode -> parentNode; 06 $KeyInfo->removeChild($x509cert -> parentNode ); Строки 1, 2 осуществляют выделение узлов <X509Certificate> и <BinarySecurityToken>, а строка 3 – присвоение содержания одного узла другому. Строки 5, 6 выполняют уничтожение узла <X509Data> и его потомков. Сколько песен еще недопето, или Что и как можно еще реализовать Говоря о защите SOAP-сообщения, необходимо упомянуть об алгоритме проверки подписи SOAP-сообщения:
Приведение подписанного SOAP-сообщения к требованиям Спецификации W3C XML Signature заключается в создании дочернего узла <X509Data><X509Certificate> для узла <KeyInfo> и присвоение ему содержания узла <BinarySecurityToken id="bst">. Это реализуется кодом, аналогичныму приведенным в листинге 8. Формирование временного файла – аналогично коду в листинге 6, строки 1-4. Проверка цифровой подписи XML-сообщения утилитой xmlsec осуществляется командной строкой: $cmd="xmlsec1 --verify --trusted-pem $certFile --id-attr:id body $tmpfname 2>&1"; Необходимо осуществить анализ результата. Если подпись соответствует, то будет выведен следующий результат:
В случае измененного текста сообщения:
В случае измененного дайджеста подписи или сертификата:
Если рассматривать криптозащиту SOAP-сообщения, то алгоритм закрытия SOAP-сообщения аналогичен алгоритму цифровой подписи SOAP-сообщения:
Если используется алгоритм rsa-oaep-mgf1p и используется прилагаемый сертификат, то значение узла /KeyInfo/EncryptedKey/KeyInfo/X509Data/X509Certificate должно быть перенесено в содержание узла <BinarySecurityToken id="bstenc">, а вместо него дочерним узлом /KeyInfo/EncryptedKey/KeyInfo станет узел BinarySecurityReference/Reference, который должен иметь значение атрибута URI="#bstenc" (указатель на узел <BinarySecurityToken>) Аналог кода – листинг 8. В этом случае командная строка должна принять следующий вид: $cmd = "xmlsec1 encrypt --binary-data $tmpfnameDoc --privkey-pem $key,$certFile --session-key des-192 $tmpfnameTpl 2>&1" Значение ключа --session-key des-192 сообщает утилите xmlsec, что необходимо осуществлять шифрование сессионным ключом des-192. Аналог кода – листинг 7. Для дешифрования SOAP-сообщения используется алгоритм, аналогичный алгоритму проверки цифровой подписи. Первоначально приводим к требованиям спецификации W3c XML Encryption, а далее вызываем утилиту xmlsec и анализируем результат. Если нет ошибок, то выделяем «расшифрованное тело» SOAP-сообщения. Командная строка для дешифрования: $cmd = "xmlsec1 dencrypt --pubkey-cert-pem $certFile $tmpfnameDoc 2>&1"; Рассматривая алгоритмы защиты SOAP-сообщений, мы опустили из рассмотрения транспорт. Если в качестве транспорта используется HTTP-протокол, то наилучшим вариантом будет использование библиотеки curl. Раз словечко, два словечко – будет песенка, или Вместо заключения Одним из недостатков Open Source, если это не инвестиционный проект крупных фирм, таких как IBM или Microsoft, является инертность по отношению к новым технологиям. Это объясняется тем, что большинство разработчиков Open Source, как правило, занимаются своими проектами вне рабочего времени, или в Open Source отдается уже готовая разработка проекта какой-нибудь фирмы, после чего ее развитие сильно замедляется. Из этого правила есть исключения, и некоторые фирмы (например, Yahoo) уделяют немалое внимание Open Source, выделяя своим сотрудникам часть времени на развитие подобных проектов. К сожалению, вышеописанный недостаток присущ и libxmlsec, и ее развитие происходит не так активно, как хотелось бы. К настоящему времени мною написаны некоторые функции по реализации шаблонов WS-Security, но до включения их в библиотеку дело пока не дошло. Функции находятся на этапе альфа-тестирования. Open Source сообществу разработчиков libxmlsec также был предложен вариант изменения некоторых основных функций ядра, но эти функции играют важную роль, и их изменение затруднительно и нуждается в широком тестировании. Поэтому, очевидно, более правильное решение – это написание новых базовых функций, чем я параллельно и занимаюсь. Также мною, в соавторстве с Робом Ричардсоном (Rob Richards), реализован PHP-интерфейс к libxmlsec (модуль php_xmlsec) и небольшая часть интерфейса к WS-Security. Модуль прошел альфа-тестирование и готов для промышленной реализации. Он использует часть функций, которые в будущем должны войти в libxmlsec, поэтому логично дождаться включения новых шаблонных функций в libxmlsec, а уже потом включать модуль в PECL. Для желающих познакомиться с модулем – его описание и исходные тексты с примерами можно найти по адресу www.edocs.phpclub.net/xmlsec. Если давать краткую характеристику этому модулю, то он призван заменить собой PHP-код в листинге 6. Модуль реализует спецификации: XML Signature и XML Encryption. Как показала практика использования модуля php_xmlsec и общение в форумах большинство программистов интересует практическая сторона применения, связанная с защитой веб-служб. Поэтому в настоящее время начата работа над новым расширением (модуль php_wssecurity). Но опять же разработка модуля php_wssecurity возможна только после доработки части шаблонных функций libxmlsec, реализующих шаблоны в соответствии со спецификацией Web Services Security.
|
Александр КалендаревКомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
