Проблема з веб-додатками полягає в тому, що вони відкрито піддаються впливу мільярдів користувачів Інтернету, багато з яких захочуть порушити заходи безпеки з будь-яких причин.
На початку існування Інтернету одним із найпоширеніших методів атаки була проста груба сила. Ці атаки зазвичай здійснювали боти – або люди, які мали багато вільного часу – які пробували безліч комбінацій імен користувачів і паролів, поки не знайшли ту, яка надала б доступ до цільової програми.
Атаки грубої сили більше не становлять загрози завдяки політиці паролів, обмеженим спробам входу та капчі. Але кіберзлочинці люблять відкривати нові експлойти та використовувати їх для здійснення нових типів атак. Давно вони виявили, що текстові поля в програмах або веб-сторінках можна використати, ввівши або вставивши в них неочікуваний текст, який змусить програму робити те, чого вона не повинна була робити. Таким чином на сцену вийшли так звані ін’єкційні атаки.
Ін’єкційні атаки можна використовувати не лише для входу в програму, не знаючи імені користувача та пароля, але й для розкриття приватної, конфіденційної чи конфіденційної інформації або навіть для викрадення всього сервера. Ось чому ці атаки становлять загрозу не лише для веб-додатків, але й для користувачів, чиї дані зберігаються в цих додатках, а в гіршому випадку – для інших підключених додатків і служб.
Введення коду
Впровадження коду є одним із найпоширеніших видів атак через впровадження. Якщо зловмисники знають мову програмування, структуру, базу даних або операційну систему, яку використовує веб-додаток, вони можуть вставити код за допомогою полів введення тексту, щоб змусити веб-сервер робити те, що вони хочуть.
Ці типи ін’єкційних атак можливі в програмах, які не перевіряють вхідні дані. Якщо поле введення тексту дозволяє користувачам вводити все, що їм заманеться, то програму потенційно можна використовувати. Щоб запобігти цим атакам, програмі потрібно максимально обмежити вхід користувачам.
Наприклад, потрібно обмежити обсяг очікуваних даних, перевірити формат даних перед їх прийняттям і обмежити набір дозволених символів.
Уразливості впровадження коду можна легко знайти, просто перевіривши введення тексту веб-програми з різними типами вмісту. Якщо вразливості виявлені, їх помірно важко використовувати. Але коли зловмиснику вдається використати одну з цих вразливостей, вплив може включати втрату конфіденційності, цілісності, доступності або функціональності програми.
SQL ін’єкція
Подібно до впровадження коду, ця атака вставляє сценарій SQL – мову, яка використовується більшістю баз даних для виконання операцій запиту – у поле введення тексту. Сценарій надсилається до програми, яка виконує його безпосередньо у своїй базі даних. У результаті зловмисник може пройти через екран входу або зробити більш небезпечні дії, як-от читати конфіденційні дані безпосередньо з бази даних, змінювати або знищувати дані бази даних або виконувати операції адміністратора над базою даних.
Програми PHP і ASP схильні до атак SQL-ін’єкцій через застарілі функціональні інтерфейси. Програми J2EE та ASP.Net зазвичай більш захищені від цих атак. Якщо виявлено вразливість SQL-ін’єкції, а її можна легко знайти, масштаби потенційних атак будуть обмежені лише навичками та уявою зловмисника. Таким чином, вплив атаки SQL-ін’єкції, безсумнівно, є високим.
Введення команди
Ці атаки також можливі, в основному через недостатню перевірку вхідних даних. Вони відрізняються від атак із впровадженням коду тим, що зловмисник вставляє системні команди замість фрагментів програмного коду чи сценаріїв. Таким чином, хакеру не потрібно знати мову програмування, на якій створено додаток, або мову, яку використовує база даних. Але їм потрібно знати операційну систему, яку використовує сервер хостингу.
Вставлені системні команди виконуються головною операційною системою з привілеями програми, яка може дозволяти відкривати вміст довільних файлів, що знаходяться на сервері, показувати структуру каталогів сервера, змінювати паролі користувачів, серед іншого .
Цим атакам може запобігти системний адміністратор, обмеживши рівень доступу до системи для веб-додатків, що працюють на сервері.
Міжсайтовий скриптинг
Кожного разу, коли програма вставляє вхідні дані від користувача в створений нею вихід, не перевіряючи та не кодуючи їх, це дає можливість зловмиснику надіслати шкідливий код іншому кінцевому користувачеві. Атаки міжсайтового сценарію (XSS) використовують ці можливості для впровадження шкідливих сценаріїв на надійні веб-сайти, які зрештою надсилаються іншим користувачам програми, які стають жертвами зловмисників.
Браузер жертви виконає шкідливий сценарій, не знаючи, що йому не можна довіряти. Тому браузер надасть йому доступ до маркерів сеансу, файлів cookie або конфіденційної інформації, що зберігається в браузері. Якщо правильно запрограмувати, сценарії можуть навіть переписати вміст файлу HTML.
XSS-атаки можна загалом розділити на дві різні категорії: збережені та відображені.
У збережених атаках XSS шкідливий сценарій постійно знаходиться на цільовому сервері, у форумі повідомлень, у базі даних, у журналі відвідувачів тощо. Жертва отримує його, коли її браузер запитує збережену інформацію. У відображених XSS-атаках шкідливий сценарій відображається у відповіді, яка містить вхідні дані, надіслані на сервер. Це може бути, наприклад, повідомлення про помилку або результат пошуку.
Ін’єкція XPath
Цей тип атаки можливий, коли веб-програма використовує інформацію, надану користувачем, для створення запиту XPath для даних XML. Те, як ці атаки працюють, подібне до SQL-ін’єкцій: зловмисники надсилають програмі неправильну інформацію, щоб дізнатися, як структуровані дані XML, а потім атакують знову, щоб отримати доступ до цих даних.
XPath — це стандартна мова, за допомогою якої, як і SQL, можна вказати атрибути, які потрібно знайти. Щоб виконати запит до XML-даних, веб-програми використовують введені користувачем дані для встановлення шаблону, якому мають відповідати дані. Надсилаючи неправильний вхід, шаблон може перетворитися на операцію, яку зловмисник хоче застосувати до даних.
На відміну від того, що відбувається з SQL, у XPath немає різних версій. Це означає, що впровадження XPath можна виконати в будь-якій веб-програмі, яка використовує дані XML, незалежно від реалізації. Це також означає, що атака може бути автоматизована; отже, на відміну від SQL-ін’єкції, його можна використовувати проти довільної кількості цілей.
Ін’єкція поштової команди
Цей метод атаки можна використовувати для використання серверів електронної пошти та програм, які створюють оператори IMAP або SMTP із неправильно перевіреним введенням користувача. Інколи сервери IMAP і SMTP не мають надійного захисту від атак, як це було б у випадку більшості веб-серверів, і тому можуть бути більш придатними для використання. Входячи через поштовий сервер, зловмисники могли уникнути обмежень, таких як капчі, обмежена кількість запитів тощо.
Щоб використовувати сервер SMTP, зловмисникам потрібен дійсний обліковий запис електронної пошти для надсилання повідомлень із введеними командами. Якщо сервер вразливий, він відповідатиме на запити зловмисників, дозволяючи їм, наприклад, перевизначати обмеження сервера та використовувати його служби для надсилання спаму.
Ін’єкцію IMAP можна здійснювати переважно в програмах веб-пошти, використовуючи функцію читання повідомлень. У цих випадках атаку можна здійснити, просто ввівши в адресний рядок веб-браузера URL-адресу з введеними командами.
Ін’єкція CRLF
Вставка символів повернення каретки та переводу рядка (комбінація, відома як CRLF) у поля введення веб-форми представляє метод атаки, який називається ін’єкція CRLF. Ці невидимі символи вказують на кінець рядка або кінець команди в багатьох традиційних Інтернет-протоколах, таких як HTTP, MIME або NNTP.
Наприклад, вставка CRLF у HTTP-запит, а потім деякий певний HTML-код, може надсилати спеціальні веб-сторінки відвідувачам веб-сайту.
Цю атаку можна здійснити на вразливі веб-програми, які не застосовують належну фільтрацію до введених користувачем даних. Ця вразливість відкриває двері для інших типів ін’єкційних атак, таких як XSS і ін’єкція коду, а також може стати причиною викрадення веб-сайту.
Ін’єкція заголовка хосту
На серверах, на яких розміщено багато веб-сайтів або веб-додатків, заголовок хосту стає необхідним, щоб визначити, який із резидентних веб-сайтів або веб-додатків (кожен із них відомий як віртуальний хост) має обробити вхідний запит. Значення заголовка повідомляє серверу, до якого з віртуальних хостів відправляти запит. Коли сервер отримує недійсний заголовок хоста, він зазвичай передає його першому віртуальному хосту в списку. Це є вразливістю, яку зловмисники можуть використовувати для надсилання довільних заголовків хосту на перший віртуальний хост на сервері.
Маніпуляція заголовком хосту зазвичай пов’язана з додатками PHP, хоча це також можна зробити за допомогою інших технологій веб-розробки. Атаки на заголовок хосту працюють як активатори для інших типів атак, таких як отруєння веб-кешу. Його наслідки можуть включати виконання конфіденційних операцій зловмисниками, наприклад, скидання пароля.
Ін’єкція LDAP
LDAP — це протокол, призначений для полегшення пошуку ресурсів (пристроїв, файлів, інших користувачів) у мережі. Це дуже корисно для інтрамереж, і коли використовується як частина системи єдиного входу, його можна використовувати для зберігання імен користувачів і паролів. Запити LDAP передбачають використання спеціальних керуючих символів, які впливають на його керування. Зловмисники потенційно можуть змінити очікувану поведінку запиту LDAP, якщо вони зможуть вставити в нього керуючі символи.
Знову ж таки, основною проблемою, яка допускає атаки ін’єкцій LDAP, є неправильно підтверджене введення користувача. Якщо текст, який користувач надсилає до програми, використовується як частина запиту LDAP без його дезінфекції, запит може закінчитися отриманням списку всіх користувачів і показом його зловмиснику, просто використовуючи зірочку
у потрібному місці всередині вхідного рядка.
Запобігання ін’єкційним нападам
Як ми бачили в цій статті, усі ін’єкційні атаки спрямовані на сервери та програми з відкритим доступом до будь-якого користувача Інтернету. Відповідальність за запобігання цим атакам розподіляється між розробниками програм і адміністраторами серверів.
Розробники додатків повинні знати про ризики, пов’язані з неправильною перевіркою введених користувачами даних, і ознайомитися з найкращими методами очищення введених даних користувачів з метою запобігання ризикам. Адміністратори серверів повинні періодично перевіряти свої системи, щоб виявити вразливості та якнайшвидше їх усунути. Є багато варіантів виконання цих перевірок, як на вимогу, так і автоматично.