Безпека веб-сервісів (WS) за допомогою прикладу SOAP

⚡ Розумний підсумок

Безпека веб-сервісів (WS) – це стандарт, який захищає дані, що обмінюються під час виклику веб-сервісу SOAP. У цьому ресурсі пояснюються загрози безпеці та контрзаходи, стандарти WS-Security, створення безпечного веб-сервісу з обліковими даними та найкращі практики безпеки веб-сервісів.

  • 🔐 Основний стандарт: WS-Security додає рівень безпеки до SOAP, визначаючи, як облікові дані та ключі шифрування передаються всередині заголовка SOAP.
  • 🌐 Обмеження HTTPS: HTTPS/SSL захищає трафік "точка-точка", але в багатосерверних потоках лише WS-Security захищає повідомлення від початку до кінця.
  • 🎫 Токени облікових даних: Облікові дані передаються за допомогою UsernameToken для імені користувача та пароля або BinarySecurityToken для сертифікатів Kerberos або X.509.
  • 🛠️ Приклад безпечної збірки: Веб-сервіс .Net ASMX додає клас AuthHeader, щоб заголовок SOAP містив ім'я користувача та пароль для автентифікації.
  • 📋 Кращі практики: Запити на аудит та журнали, tracпід час бізнес-операцій, належним чином автентифікуйтеся та ніколи не зберігайте та не реєструйте конфіденційні облікові дані.

Безпека веб-сервісів WS

Що таке WS Security?

WS Security – це стандарт, що стосується безпеки під час обміну даними в рамках веб-сервісу. Це ключова особливість SOAP, яка робить його дуже популярним для створення веб-сервісів.

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

Загрози безпеці та протидія

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

Одним із заходів безпеки, доступних для HTTP, є протокол HTTPS. HTTPS – це безпечний спосіб зв’язку між клієнтом і сервером через Інтернет. HTTPS використовує Secure Sockets Layer або SSL для безпечного зв’язку. Як клієнт, так і сервер матимуть цифровий сертифікат, щоб ідентифікувати себе як справжніх, коли відбувається будь-яке спілкування між клієнтом і сервером.

Загрози безпеці та контрзаходи HTTPS

Під час стандартного HTTPS-зв'язку між клієнтом і сервером відбуваються такі кроки:

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

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

Загрози безпеці та контрзаходи для кількох серверів

Саме тут SOAP вступає в дію, щоб подолати такі перешкоди, використовуючи специфікацію WS Security. Згідно з цією специфікацією, всі дані, пов'язані з безпекою, визначені в елементі заголовка SOAP. Елемент заголовка може містити наступну інформацію:

  1. Якщо повідомлення в тілі SOAP було підписано будь-яким ключем безпеки, цей ключ можна визначити в елементі заголовка.
  2. Якщо будь-який елемент у тілі SOAP зашифрований, заголовок міститиме необхідні ключі шифрування, щоб повідомлення можна було розшифрувати, коли воно досягне пункту призначення.

У середовищі з кількома серверами вищезгадана техніка SOAP-автентифікації допомагає наступним чином:

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

У наступних темах ми побачимо, як можна використовувати стандарт WS Security для SOAP.

Стандарти безпеки веб-служб

Як обговорювалося в попередньому розділі, стандарт WS-Security зосереджений на включенні визначення безпеки до заголовка SOAP. Облікові дані в заголовку SOAP керуються двома способами.

По-перше, він визначає спеціальний елемент під назвою UsernameToken. Він використовується для передачі імені користувача та пароля веб-сервісу. Інший спосіб – використовувати бінарний токен через BinarySecurityToken. Це використовується в ситуаціях, коли використовуються такі методи шифрування, як Kerberos або X.509.

На діаграмі нижче показано, як працює модель безпеки в WS Security.

Робочий процес стандартів безпеки веб-сервісів

Нижче наведено кроки, які виконуються у вищезгаданому робочому процесі:

  1. Запит може бути надісланий від клієнта веб-сервісу до служби маркерів безпеки. Цей сервіс може бути проміжним веб-сервісом, спеціально створеним для надання імен користувачів/паролів або сертифікатів фактичному веб-сервісу SOAP.
  2. Потім маркер безпеки передається клієнту веб-служби.
  3. Потім клієнт веб-сервісу викликає веб-сервіс, але цього разу переконується, що токен безпеки вбудований у повідомлення SOAP.
  4. Потім веб-служба розуміє повідомлення SOAP із маркером автентифікації, а потім може зв’язатися зі службою маркерів безпеки, щоб перевірити, чи маркер безпеки автентичний чи ні.

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

<xs:element name="UsernameToken">
   <xs:complexType>
      <xs:sequence>
         <xs:element ref="Username"/>
         <xs:element ref="Password" minOccurs="0"/>
      </xs:sequence>
      <xs:attribute name="Id" type="xs:ID"/>
   </xs:complexType>
</xs:element>

Коли повідомлення SOAP фактично передається між клієнтами та сервером, частина повідомлення, яка містить облікові дані користувача, може виглядати так, як показано вище. Ім'я елемента wsse — це спеціальне ім'я елемента, визначене для SOAP, і означає, що він містить інформацію на основі безпеки.

Як створювати безпечні веб-сервіси

Тепер розглянемо приклад безпеки веб-сервісу SOAP. Ми створимо систему безпеки веб-сервісу на прикладі, продемонстрованому раніше в розділі про SOAP, і додамо до неї рівень безпеки.

У нашому прикладі ми створимо простий веб-сервіс, який використовуватиметься для повернення рядка до програми, що викликає веб-сервіс. Але цього разу, коли веб-сервіс викликається, облікові дані необхідно надати сервісу, що його викликає. Давайте виконаємо наведені нижче кроки, щоб створити наш веб-сервіс SOAP та додати до нього визначення безпеки.

Крок 1) Першим кроком є ​​створення порожнього Asp.Net Веб-додаток. У Visual Studio 2013 клацніть пункт меню Файл->Новий проект.

Створення нового проекту Secure Web Services

Після того, як ви клацнете опцію «Новий проект», Visual Studio відкриє ще одне діалогове вікно для вибору типу проекту та надання необхідних деталей проекту. Це пояснюється в наступному кроці.

Крок 2) На цьому етапі

  1. Переконайтеся, що ви спочатку вибрали C# Веб-шаблон для веб-застосунку ASP.NET. Проект має бути такого типу, щоб можна було створити проект веб-сервісів. Вибравши цей параметр, Visual Studio виконає необхідні кроки для додавання потрібних файлів, необхідних для будь-якого веб-застосунку.
  2. Дайте назву своєму проекту, яка в нашому випадку була дана як "вебсервіс.asmx«.» Потім обов’язково вкажіть місце, де будуть зберігатися файли проєкту.

Деталі проекту «Створення безпечних веб-сервісів»

Після завершення ви побачите створений файл проекту у вашому провіднику рішень у Visual Studio 2013.

Створення оглядача рішень для безпечних веб-сервісів

Крок 3) На цьому кроці ми додамо файл веб-сервісу до нашого проєкту.

  1. Спочатку клацніть правою кнопкою миші на файлі проекту, як показано нижче.

Створення проекту Secure Web Services, клацніть правою кнопкою миші

  1. Після того, як ви клацнете правою кнопкою миші на файлі проекту, у вас буде можливість вибрати опцію «Додати->Веб-сервіс (ASMX)», щоб додати файл веб-сервісу. Просто вкажіть назву Tutorial Service для файлу назви веб-сервісу.

Створення безпечних веб-сервісів, додавання веб-сервісу

Після виконання вищезазначеного кроку відкриється діалогове вікно, в якому можна ввести назву файлу веб-сервісу. Тому в діалоговому вікні нижче введіть назву TutorialService як назву файлу.

Діалогове вікно назви створення безпечних веб-сервісів

Крок 4) Додайте наведений нижче код до asmx-файлу Tutorial Service. Наведений нижче фрагмент коду використовується для додавання спеціального класу, який використовуватиметься для зміни заголовка SOAP під час генерації повідомлення SOAP. Оскільки тепер ми хочемо додати облікові дані безпеки до заголовка SOAP, цей крок є обов’язковим.

Створення коду AuthHeader для безпечних веб-сервісів

      return "This is a Guru99 Web Service";
   }

   public class AuthHeader : SoapHeader
   {
      public string UserName;
      public string Password;
   }
}

Code Пояснення:

  1. Зараз ми створюємо окремий клас під назвою AuthHeader який є типу Клас SoapHeaderЩоразу, коли ви хочете змінити те, що передається в заголовку SOAP, потрібно створити клас, який використовує вбудований клас SoapHeader з .Net. Налаштувавши заголовок SOAP, ми тепер маємо можливість передавати «Ім'я користувача» та «Пароль» під час виклику веб-сервісу.
  2. Потім ми визначаємо змінні «Ім’я користувача» та «Пароль», які мають тип string. Вони використовуватимуться для зберігання значень імені користувача та пароля, які передаються веб-службі.

Крок 5) Наступним кроком до нього потрібно додати наступний код Файл TutorialService.asmxЦей код фактично визначає функцію нашого веб-сервісу. Ця функція повертає рядок «Це Guru99 «Веб-сервіс» клієнту. Але цього разу рядок буде повернуто лише в тому випадку, якщо клієнтська програма передасть облікові дані веб-сервісу.

Підручник зі створення безпечних веб-сервісів Код сервісу

public class TutorialService : System.Web.Services.WebService
{
   public AuthHeader Credentials;

   [SoapHeader("Credentials")]

   [WebMethod]
   public string Guru99WebService()
   {

      if (Credentials.UserName.ToLower() != "Guru99" ||
      Credentials.Password.ToLower() != "Guru99Password")
      {
         throw new SoapException("Unauthorized",
         SoapException.ClientFaultCode);
      }
      else
      return "This is a Guru99 Web service";
   }

Code Пояснення:

  1. Тут ми створюємо об’єкт класу AuthHeader, який було створено на попередньому кроці. Цей об'єкт буде передано нашому Guru99Вебсервіс в якому можна уважно вивчити ім’я користувача та пароль.
  2. Атрибут [SoapHeader] тепер використовується, щоб вказати, що під час виклику веб-служби потрібно передати ім’я користувача та пароль.
  3. У цьому блоці коду ми фактично перевіряємо ім'я користувача та пароль, що передаються під час виклику веб-сервісу. Якщо ім'я користувача дорівнює «Guru99”, а пароль дорівнює “Guru99Password», а потім повідомлення «Це GuruКлієнту передається «99 Веб-сервіс». В іншому випадку клієнту буде надіслано повідомлення про помилку, якщо буде передано неправильний ідентифікатор користувача та пароль.

Якщо код виконано успішно, під час запуску коду в браузері буде показано наступний результат.

вихід:

Створення виводу безпечних веб-сервісів

Наведений вище вивід відображається після запуску програми, що означає, що веб-сервіс тепер доступний. Давайте натиснемо на Сервіс Descriptіонна ланка.

Опис сервісу «Створення безпечних веб-сервісів»

З опису служби тепер ви зможете побачити, що ім’я користувача та пароль є елементами WSDL файл. Ці параметри потрібно надіслати під час виклику веб-служби.

Найкращі методи безпеки веб-служб

Нижче наведено міркування безпеки, які слід враховувати під час роботи з веб-сервісами:

  1. Аудит та управління журналами – Використовуйте журнал програм для реєстрації всіх запитів, що надходять до веб-сервісів. Це надає детальний звіт про те, хто викликав веб-сервіс, і може допомогти в аналізі впливу у разі будь-якого порушення безпеки.
  2. Потік викликів до веб-сервісу – Спробуйте звернути увагу на потік викликів у веб-сервісах. За замовчуванням програма може викликати кілька запитів до веб-сервісів з токенами автентифікації, що передаються між цими веб-сервісами. Усі виклики між веб-сервісами необхідно контролювати та реєструвати.
  3. Конфіденційна інформація – Не включайте до записів журналу конфіденційну інформацію, таку як паролі, номери кредитних карток чи будь-яку іншу конфіденційну інформацію. Якщо сталася подія, яка містить будь-яку з цих даних, її необхідно видалити перед веденням журналу.
  4. Track Бізнес Operaвих - Track значущих бізнес-операцій. Наприклад, обладнайте свій застосунок для запису доступу до особливо конфіденційних методів та бізнес-логіки. Візьмемо, наприклад, інтернет-магазинping застосунок. У типовому застосунку є кілька кроків, таких як вибір товарів для придбання, завантаження товарів у кошик, а потім остаточна покупка. Весь цей бізнес-процес має бути tracвизначається веб-сервісом.
  5. Правильна автентифікація – Автентифікація – це механізм, за допомогою якого клієнти можуть встановити свою особу у веб-сервісі, використовуючи певний набір облікових даних, які можуть підтвердити цю особу. Ніколи не слід зберігати облікові дані користувача, і тому, якщо для виклику веб-сервісу використовується WS Security, слід зазначити, що веб-сервіс не повинен зберігати облікові дані, які надсилаються в заголовку SOAP. Вони повинні бути відкинуті веб-сервісом.

Поширені запитання

Штучний інтелект може контролювати трафік веб-сервісів у режимі реального часу, виявляти незвичайні шаблони запитів та позначати ймовірні атаки, такі як ін'єкції або зловживання токенами. Він також може сканувати конфігурації WSDL та SOAP на наявність слабкої автентифікації або відсутнього шифрування.

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

HTTPS шифрує з'єднання між двома точками, тому дані стають доступними, щойно вони досягають проміжного сервера. WS-Security захищає саме SOAP-повідомлення, зберігаючи...ping він захищав від початку до кінця, навіть коли проходить через кілька серверів.

UsernameToken – це елемент WS-Security, розміщений у заголовку SOAP, який містить ім'я користувача та, за бажанням, пароль. Він дозволяє веб-сервісу автентифікувати абонента перед обробкою запиту.

Підсумуйте цей пост за допомогою: