Захист Web-сервісів з використанням mod

проблемний Домен
Яке ж рішення?
Метод / Інтерфейс виведення балансу рахунку з даних, отриманих від WSDL
Виклик Web-сервісу через HTTP
Малюнок 2. Виклик Web сервісу через HTTP
Вбудовуємо ресурси Web-сервісів в mod_security
Захищаємося від Інших Напрямів Атак
Вид атаки 1: Ін'єкція в буфер з непостійним розміром
Вид Атаки 2: Ін'єкція Мета Символу
Вид Атаки 3: SQL ін'єкція
Вид Атаки 4: SOAP Розкриття дефектних Коду
Висновок

Web-сервіси все частіше стають невід'ємною частиною Web-додатків нового покоління. І вони також уразливі до атак. Природа таких атак точно така ж, як і для звичайних Web-додатків, однак принцип дій різний. Ці атаки можуть привести до витоку інформації; далі, вони сприяють віддаленого виконання команд. Використовуючи WSDL, хакер може визначити точку доступу та доступні інтерфейси Web-сервісів. Інтерфейси ці приймають дані з використанням SOAP по HTTP / HTTPS і без гарного захисту на рівні вихідного коду можуть бути зламані. mod_security працює як Web-модуль сервера Apache, ідеальний для захисту Web-сервісів проти атак, які також включають спеціально оброблені POST запити, що містять SOAP конверти.

Автор Shreeraj Shah

09 червня 2005

Web-сервіси все частіше стають невід'ємною частиною Web-додатків нового покоління. І вони також уразливі до атак. Природа таких атак точно така ж, як і для звичайних Web-додатків, однак принцип дій різний. Ці атаки можуть привести до витоку інформації; далі, вони сприяють віддаленого виконання команд. Використовуючи WSDL, хакер може визначити точку доступу та доступні інтерфейси Web-сервісів. Інтерфейси ці приймають дані з використанням SOAP по HTTP / HTTPS і без гарного захисту на рівні вихідного коду можуть бути зламані. mod_security працює як Web-модуль сервера Apache, ідеальний для захисту Web-сервісів проти атак, які також включають спеціально оброблені POST запити, що містять SOAP конверти.

проблемний Домен

Для атаки Web-сервісів існує чотири основних напрямки:

Ін'єкція в буфер з непостійним розміром
ін'єкція метасимвола
SQL ін'єкція
SOAP розкриття дефектного коду

Зазвичай конфігурації міжмережевих екранів безперешкодно пропускають входить HTTP / HTTPS трафік. Кожна з вищевказаних атак, простіше кажучи, являє собою посилку спеціально обробленого трафіку, виглядає як звичайний трафік, тому він і проходить через міжмережевий екран. У цій статті будуть описані шляхи і засоби поділу легального і злочинного HTTP / HTTPS трафіку, і, в подальшому, блокування зловмисного. Виконання цих дій допоможе різко знизити ймовірність успішного проведення атаки через 80/443 порти.

Яке ж рішення?

Рішень насправді дуже багато, починаючи з установки додаткових перевірок на дані, що вводяться. Один із способів - провести перевірку вмісту кожного, хто входить запиту і порівняти його із заздалегідь визначеними правилами. Це запобіжить проникненню злочинних SOAP запитів в Web-служби на рівні вихідного коду. Mod_security може використовуватися для захисту проти всіх типів нападів в тому випадку, коли ви правильно розгорнули і налаштували його для Web-служб. У цій статті буде докладно розказано - як налаштовувати mod_security для захисту Web-служб.

Після установки Web-служб необхідно провести грамотну захист від різних напрямків атак. Кожен напрямок атак вимагає свого підходу з боку захисту. Як приклад розглянемо фіктивний випадок з банком.

Blue Bank ( www.bluebank.example.com ) Тільки що прийняв Web-сервіси з використанням mod_security. Ці служби надають банкові сервіси через Інтернет для фінансових партнерів і клієнтів (баланс рахунку, грошові перекази, виправлення особистих даних). На малюнку 1 показана архітектура розгортки Web служб Blue Bank'a.

Малюнок 1. Система Web-служб Blue Bank'a

Існує багато способів розгортання Web-служб. У нашому випадку Web-служба запускається на Tomcat / Axis і підключається до Web-серверу Apache. Додатки банківських Web-сервісів написані на Java (з розширенням файлу .jws).

Важливі частини налаштувань Apache і Axis включають в себе Apache httpd.conf, який завантажує Tomcat:

LoadModule jk2_module modules / mod_jk2.so JkSet config.file /usr/local/apache2/conf/workers2.properties

Файл Axis - web.xml, який підтримує AxisServlet для Web сервісів в обробці:

<Servlet-mapping> <servlet-name> AxisServlet </ servlet-name> <url-pattern> *. Jws </ url-pattern> </ servlet-mapping> З того моменту, як вище вказані налаштування вступили в силу, ви можете ставити будь-які Web-служби на свій сервер. Якщо подивитися відповідь сервера на запит банера, то можна побачити наступне: <code> Server: Apache / 2.0.50 (Unix) mod_ssl / 2.0.50 OpenSSL / 0.9.7d mod_jk2 / 2.0.4 </ code>

Цей банер вказує на те, що Web-сервер крутиться на Apache / 2.0.50 (Unix) із запущеним модулем mod_jk2 / 2.0.4. Axis запускається як частина Web-додатки Tomcat і готовий для підняття Web-сервісів. Для забезпечення безпеки на рівні Web- сервісів, Blue Bank завантажив модуль mod_security, що надає можливості програмної фільтрації. Наступний рядок в httpd.conf завантажує модуль безпеки:

<Code> LoadModule security_module modules / mod_security.so </ code>

З встановленим mod_security Blue Bank може додати правила фільтрації в httpd.conf:

<IfModule mod_security.c> # Turn the filtering engine On or Off SecFilterEngine On SecFilterDefaultAction "deny, log, status: 500" SecFilterScanPOST On. . . # Other rules. . . </ IfModule>

Цього цілком достатньо, щоб дозволити системним адміністраторам і розробникам використовувати mod_security для виявлення входять зловмисних HTTP / HTTPS запитів.

Розглянемо приклад Web-сервісу перегляду балансу www.bluebank.example.com/axis/getBalance.jws WSDL- відповідь цього Web сервісу буде приходити з jws?wsdl> www.bluebank.example.com/axis/getBalance.jws?wsdl

Метод / Інтерфейс виведення балансу рахунку з даних, отриманих від WSDL

Ретельно розглянутий WSDL-відповідь є результатом виконання вхідного HTTP запиту. Особливий інтерес тут представляє метод ініціалізації, який бере банківський id і передає стан рахунку назад клієнту через HTTP. Тег операції встановлює методи, які може використовувати клієнт Web-сервісів. Важливі уривки файлу WSDL включають:

<Wsdl: operation name = "getInput"> <wsdlsoap: operation soapAction = "" /> <wsdl: input name = "getInputRequest"> <wsdlsoap: body encodingStyle = http: //schemas.xmlsoap.org/soap/encoding/ namespace = "http: // DefaultNamespace" use = "encoded" /> </ wsdl: input> <wsdl: output name = "getInputResponse"> <wsdlsoap: body encodingStyle = http: //schemas.xmlsoap.org/soap/ encoding / namespace = "http://www.bluebank.example.com/axis/getBalance.jws" use = "encoded" /> </ wsdl: output> <wsdl: message name = "getInputResponse"> <wsdl: part name = "getInputReturn" type = "xsd: string" /> </ wsdl: message> <wsdl: message name = "getInputRequest"> <wsdl: part name = "id" type = "xsd: string" /> </ wsdl: message> Як показано вище, передача id конкретного методу приведе до повернення рядка в вихідних даних. Коли ви посилаєте id банкового рахунку як вхідні дані Web-сервісу, ви отримуєте інформацію про баланс рахунку.

Виклик Web-сервісу через HTTP

Клієнти або партнери Blue Bank, що запитують інформацію про стан рахунку через Інтернет можуть вибрати інформацію реквізиту, пославши правильно зібраний конверт Web-сервісів банку. На малюнку 2 показаний HTTP запит на інформацію про баланс рахунку з id 12123, посланий Web-сервісу.

Малюнок 2. Виклик Web сервісу через HTTP

Існує кілька способів створення SOAP клієнтів, які будуть генерувати SOAP запити правильного формату. Нижче представлений приклад SOAP клієнта з використанням SOAP :: Lite на Perl. Наступний простий код генерує SOAP запит:

#! Perl -w use SOAP :: Lite; print SOAP :: Lite -> service ( 'http://www.bluebank.example.com/axis/getBalance.jws?wsdl') -> getInput ( '12123');

Однак існує ймовірність перехоплення HTTP-запиту за допомогою сніфера, наприклад ethereal . HTTP / SOAP запит, надісланий на www.bluebank.example.com з id 12123 згенерує щось на зразок цього:

POST /axis/getBalance.jws HTTP / 1.0 Content-Type: text / xml; charset = utf-8 SOAPAction: "" Content-Length: 576 Expect: 100-continue Host: www.bluebank.example.com <? xml version = "1.0" encoding = "utf-8"?> <soap: Envelope xmlns : soap = "http://schemas.xmlsoap.org/soap/envelope/" xmlns: soapenc = "http://schemas.xmlsoap.org/soap/encoding/" xmlns: tns = "http: // www. bluebank.example.com/axis/getBalance.jws "xmlns: types =" http://www.bluebank.example.com/axis/getBalance.jws/encodedTypes "xmlns: xsi =" http: //www.w3. org / 2001 / XMLSchema-instance "xmlns: xsd =" http://www.w3.org/2001/XMLSchema "> <soap: Body soap: encodingStyle =" http://schemas.xmlsoap.org/soap/encoding / "> <q1: getInput xmlns: q1 =" http: // DefaultNamespace "> <id xsi: type =" xsd: string "> 12123 </ id> </ q1: getInput> </ soap: Body> </ soap: Envelope> ... HTTP / 1.1 200 OK Date: Mon, 03 Jan 2005 19:24:10 GMT Server: Apache / 2.0.50 (Unix) mod_ssl / 2.0.50 OpenSSL / 0.9.7d mod_jk2 / 2.0.4 Set-Cookie: JSESSIONID = 69C6540CC427A8B064C0795ADDFC20EA; Path = / axis Content-Type: text / xml; charset = utf-8 Connection: close <? Xml version = "1.0" encoding = "UTF-8"?> <Soapenv: Envelope xmlns: soapenv = "http: // schemas.xmlsoap.org/soap/envelope/ "xmlns: xsd =" http://www.w3.org/2001/XMLSchema "xmlns: xsi =" http://www.w3.org/2001/XMLSchema-instance "> <soapenv: Body> <ns1: getInputResponse soapenv: encodingStyle =" http://schemas.xmlsoap.org/soap/encoding/ "xmlns: ns1 =" http: // DefaultNamespace "> <ns1: getInputReturn xsi: type = "xsd: string"> $ 2500. </ ns1: getInputReturn> </ ns1: getInputResponse> </ soapenv: Body> </ soapenv: Envelope>

Вбудовуємо ресурси Web-сервісів в mod_security

Web сервіс Blue Bank'а використовує URL www.bluebank.example.com/axis/getBalance.jws . Необхідно створити набір правил для цього ресурсу. Blue Bank вмонтував цей ресурс в httpd.conf:

<IfModule mod_security.c> SecFilterEngine On SecFilterDefaultAction "deny, log, status: 500" # Other rules # ------- Rules for web services ----------------- --------- <Location /axis/getBalance.jws> SecFilterInheritance Off SecFilterDefaultAction "deny, log, status: 500" SecFilterScanPOST On SecFilterCheckURLEncoding On SecFilterCheckUnicodeEncoding On </ Location> # --------- -------------------------------------------------- ---- </ IfModule>

Наступний блок директиви відноситься до критерію фільтрації для /axis/getBalance.jws. Тут додається необхідна мітка-заповнювач для захисту Web-сервісу. Мітки-заповнювачі знаходяться в блоці <Location>.

# ------- Rules for web services -------------------------- <Location /axis/getBalance.jws> SecFilterInheritance Off SecFilterDefaultAction "deny, log, status: 500" SecFilterScanPOST On SecFilterCheckURLEncoding On SecFilterCheckUnicodeEncoding On </ Location> # ------------------------------ ---------------------------------

Тут знаходяться дві дуже важливі директиви:

SecFilterInheritance Off

Ця директива відключає інші правила і дає порожній простір для нового набору правил, які дозволяють вводити тільки шлях.

SecFilterScanPOST On

Для виклику процедур Web сервісів використовується метод POST. Отже, наступна директива, яку слід задіяти - SecFilterScanPost - для включення POST фільтрації.

Виконавши ці дії, Blue Bank встановив захист в формі mod_security. Крім того, mod_security знає що потрібно охороняти - id, який посилають клієнти Web-сервісу в SOAP конверті.

Захищаємося від Інших Напрямів Атак

Насамперед для захисту від усіх вхідних злочинних запитів, Blue Bank'у потрібно перехопити значення id, щоб застерегти клієнта від введення невірного значення. SOAP запит використовує XML тег для передачі інформації id у внутрішній код Web сервісу. Тег виглядає приблизно наступним чином:

<Q1: getInput xmlns: q1 = "http: // DefaultNamespace"> <id xsi: type = "xsd: string"> 12123 </ id> </ q1: getInput>

Щоб відфільтрувати запит, mod_security повинен якось прочитати значення, асоційоване з тегом; в нашому випадку це 12123. В mod_security є кілька можливостей для перехоплення значення, переданого з POST запитом. Один з методів - це використання заготовленого фільтра:

Виділена лінія перехоплює запит, зроблений на id. POST_PAYLOAD перехоплює блок даних POST і намагається порівняти його з правильною маскою (<\ s * id [^>] *>). Ця маска регулярного виразу підтверджує, що існує тег для id. Тільки після цього процес піде далі за рештою перевірок (через ланцюгової директиви). Іншими словами, якщо тег id існує, mod_security переходить до наступної перевірки.

Якщо в POST запиті міститься id, то сервер зможе обробити інформацію. Однак зловмисник може модифікувати певне значення, щоб провести ін'єкцію. Існує чотири основних методів атак.

Вид атаки 1: Ін'єкція в буфер з непостійним розміром

Однією з основних небезпек при передачі великого буфера в змінну є те, що великий буфер може викликати збій в роботі програми і / або виконати довільний код під час роботи. Правило, представлене нижче захищає змінну id від даного типу атаки:

Ця директива дозволяє приймати в буфер тільки перші п'ять символів. Використовується маска введення <\ s * id [^>] *>. {6} </ \ s * id \ s *>. Щоб переконатися в тому, що описаний вище блок директив працює, Blue Bank може послати два запити, один - відповідний встановленої довжині; інший - перевищує її.

У випадку, наведеному вище, буфер з п'яти символів був пропущений і сервер надіслав відповідь зі значенням $ 2500. Нижче показаний запит і відповідь сервера на id 121234 (шість символів):

POST /axis/getBlalance.jws HTTP / 1.0 Content-Type: text / xml; charset = utf-8 SOAPAction: "" Content-Length: 577 Expect: 100-continue Host: www.bluebank.example.com <? xml version = "1.0" encoding = "utf-8"?> <soap: Envelope xmlns : soap = "http://schemas.xmlsoap.org/soap/envelope/" xmlns: soapenc = "http://schemas.xmlsoap.org/soap/encoding/" xmlns: tns = "http: // www. bluebank.example.com/axis/getBalance.jws "xmlns: types =" http://www.bluebank.example.com/axis/getBalance.jws/encodedTypes "xmlns: xsi =" http: //www.w3. org / 2001 / XMLSchema-instance "xmlns: xsd =" http://www.w3.org/2001/XMLSchema "> <soap: Body soap: encodingStyle =" http://schemas.xmlsoap.org/soap/encoding / "> <q1: getInput xmlns: q1 =" http: // DefaultNamespace "> <id xsi: type =" xsd: string "> 121234 </ id> </ q1: getInput> </ soap: Body> </ soap: Envelope> ... HTTP / 1.1 500 Internal Server Error Date: Mon, 03 Jan 2005 22:00:33 GMT Server: Apache / 2.0.50 (Unix) mod_ssl / 2.0.50 OpenSSL / 0.9.7d mod_jk2 / 2.0 .4 Content-Length: 657 Connection: close Content-Type: text / html; charset = iso-8859-1 <! DOCTYPE HTML PUBLIC "- // IETF // DTD HTML 2.0 // EN"> <html xmlns: v = "urn: schemas-microsoft-com: vml" xmlns: o = "urn : schemas-microsoft-com: office: office "xmlns =" http://www.w3.org/TR/REC-html40 "> <head> <title> 500 Internal Server Error </ title> </ head> < body> <h1> Internal Server Error </ h1> <p> The server encountered an internal error or misconfiguration and was unable to complete your request. </ p> <p> Please contact the server administrator, [email protected] and inform them of the time the error occurred, and anything you might have done that may have caused the error. </ p> <p> More information about this error may be available in the server error log. </ p> <hr / > <address> Apache / 2.0.50 (Unix) mod_ssl / 2.0.50 OpenSSL / 0.9.7d mod_jk2 / 2.0.4 Server at 192.168.7.50 Port 80 </ address> </ body> </ html>

Модуль mod_security відхилив цей запит. Статус 500 говорить про те, що відповідь отримана. Таким чином, запит ніколи не торкнеться рівня Web-сервісів. Blue Bank'у вдалося поострить грамотну захист від переповнення буфера - часто зустрічається і ігнорованої уразливості.

Вид Атаки 2: Ін'єкція Мета Символу

Інша загроза полягає в використанні мета символів (%, ', "). Ці символи можуть стати причиною атаки методом SQL ін'єкції, що приводить до витоку інформації. Наступна стратегія забезпечить стійкість до таких атак.

<Location /axis/getBalance.jws> SecFilterInheritance Off SecFilterDefaultAction "deny, log, status: 500" SecFilterScanPOST On SecFilterCheckURLEncoding On SecFilterCheckUnicodeEncoding On SecFilterSelective POST_PAYLOAD "<\ s * id [^>] *>" chain SecFilterSelective POST_PAYLOAD "<\ s * id [^>] *>. {6} </ \ s * id \ s *> "" deny, status: 500 "SecFilterSelective POST_PAYLOAD" <\ s * id [^>] *>. * [^ a- zA-Z0-9] [^ <] * </ \ s * id \ s *> "" deny, status: 500 "</ Location>

Маска вираження <\ s * id [^>] *>. * [^ A-zA-Z0-9] [^ <] * </ \ s * id \ s *> відхиляє HTTP запит, якщо змінна POST_PAYLOAD містить символи, які не є строковими. Це дуже важлива можливість в модулі mod_security.

Нижче показаний запит і відповідь сервера на id 12'12:

Ця атака теж не вдалася, а mod_security перехопив її.

Вид Атаки 3: SQL ін'єкція

В змінні можна вставляти і SQL оператори. Можливо і об'єднання декількох SQL операторів. Якщо ваше програма не очищає такі вхідні дані, то зловмисники можуть додати SQL оператори до вже існуючих, часто з плачевними наслідками. Blue Bank блокував атаки типу SQL-ін'єкція, додавши наступні директиви:

Виділені жирним рядки перевіряють, чи містяться в запиті слова "select * from...", А якщо знаходить їх, то повертає статус 500, як в попередньому прикладі. Аналогічно ви можете додати SQL оператори, які слід блокувати, оновлювати і т.п.

Вид Атаки 4: SOAP Розкриття дефектних Коду

Один з основних джерел інформації в Web-сервісах - це дефектний код. Викликана на сервері помилка може створити дефектний код. Нижче представлений запит зловмисника і відповідь сервера в результаті підстановки символу «а» замість цілого числа в змінну id:

POST /axis/getBalance.jws HTTP / 1.0 Content-Type: text / xml; charset = utf-8 SOAPAction: "" Content-Length: 569 Expect: 100-continue Host: www.bluebank.example.com <? xml version = "1.0" encoding = "utf-8"?> <soap: Envelope xmlns: soap = "http://schemas.xmlsoap.org/soap/envelope/" xmlns: soapenc = "http: // schemas. xmlsoap.org/soap/encoding/ "xmlns: tns =" http: // www. bluebank.example.com/axis/getBalance.jws "xmlns: types =" http://www.bluebank.example.com/axis /getBalance.jws/encodedTypes "xmlns: xsi =" http: //www.w3. org / 2001 / XMLSchema-instance "xmlns: xsd =" http://www.w3.org/2001/XMLSchema "> <soap : Body soap: encodingStyle = "http://schemas.xmlsoap.org/soap/encoding /"> <q1: getInput xmlns: q1 = "http: // DefaultNamespace"> <id xsi: type = "xsd: string" > a </ id> </ q1: getInput> </ soap: Body> </ soap: Envelope> ... 500 Internal Server Error HTTP / 1.1 500 Internal Server Error Date: Tue, 04 Jan 2005 16:22:14 GMT Server: Apache / 2.0.50 (Unix) mod_ssl / 2.0.50 OpenSSL / 0.9. 7d mod_jk2 / 2.0.4 Set-Cookie: JSESSIONID = 1CAF4CD0ED0F38FB40ECBC7BDAB56C75; Path = / axis Content-Type: text / xml; charset = utf-8 Connection: close <? Xml version = "1.0" encoding = "UTF-8"?> <Soapenv: Envelope xmlns: soapenv = "http: // schemas.xmlsoap.org/soap/envelope/ "xmlns: xsd =" http://www.w3.org/2001/XMLSchema "xmlns: xsi =" http://www.w3.org/2001/XMLSchema-instance "> <soapenv: Body> <soapenv: Fault> <faultcode> soapenv: Server.userException </ faultcode> <faultstring> java.lang.NumberFormatException: For input string:" a "</ faultstring> <detail /> </ soapenv: Fault> </ soapenv: Body> </ soapenv: Envelope>

Як показано у відповіді сервера, дефектний код може розкрити критичну внутрішню інформацію. Це досить вагомий аргумент для створення відповідних фільтрів:

Ця директива сканує вихідний блок даних і приймає певні фільтри.

<Code> SecFilterSelective OUTPUT "faultcode" "deny, status: 500" </ code>

Директива блокує вихідний трафік, що містить дефектні коди. Якщо атакуючий посилає сформований запит з символом «а» в поле цілих чисел, він отримає відповідь, схожий на цей:

HTTP / 1.1 500 Internal Server Error Date: Mon, 03 Jan 2005 22:00:33 GMT Server: Apache / 2.0.50 (Unix) mod_ssl / 2.0.50 OpenSSL / 0.9.7d mod_jk2 / 2.0.4 Content-Length: 657 Connection: close Content-Type: text / html; charset = iso-8859-1 <! DOCTYPE HTML PUBLIC "- // IETF // DTD HTML 2.0 // EN"> <html> <head> <title> 500 Internal Server Error </ title> </ head> <body > <h1> Internal Server Error </ h1> <p> The server encountered an internal error or misconfiguration and was unable to complete your request. </ p> <p> Please contact the server administrator, [email protected] and inform them of the time the error occurred, and anything you might have done that may have caused the error. </ p> <p> More information about this error may be available in the server error log. </ p> <hr /> <address> Apache / 2.0.50 (Unix) mod_ssl / 2.0.50 OpenSSL / 0.9.7d mod_jk2 / 2.0.4 Server at 192.168.7.50 Port 80 </ address> </ body> </ html>

Висновок

mod_security виглядає як ще один продукт в області безпеки, однак має гарне перевагу над іншими вже доступними утилітами. Крім виявлення вторгнень і системи захисту на рівні HTTP, mod_security також має можливості фільтрування POST_PAYLOAD.

Крім того, перевага mod_security полягає в тому, що розробники і Web адміністратори можуть захищати Web-сервіси без виправлення вихідного коли додатків. Він не зробить вихідний код краще; просто тепер організація може підняти ефективну додатковий захист своїх Web-сервісів без необхідності виправлення безлічі рядків коду.

Shreeraj Shah засновник і керівник Net-Square.

Яке ж рішення?
Jws?
Jws?
Com <?
Quot; encoding = "utf-8"?
Set-Cookie: JSESSIONID = 69C6540CC427A8B064C0795ADDFC20EA; Path = / axis Content-Type: text / xml; charset = utf-8 Connection: close <?
Quot; encoding = "UTF-8"?
Com <?
Quot; encoding = "utf-8"?
Set-Cookie: JSESSIONID = 69C6540CC427A8B064C0795ADDFC20EA; Path = / axis Content-Type: text / xml; charset = utf-8 Connection: close <?

Think : Студия веб-дизайна

Захист Web-сервісів з використанням mod_security