Лекція 2. Цифрова безпека бізнесу та кібер ризики підприємств в умовах цифрової економіки

SQL-ІН’ЄКЦІЇ

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

Що робити?

Уникнути можливості подібних проблем досить просто. Досить просто перевіряти дані розміщені в запитах нескладним оброблювачем. Слід відокремлювати дані від команд і запитів, для цього існує кілька способів:

1.    Використання безпечного API, який виключає застосування інтерпретатора або надає параметризований інтерфейс. Можна використовувати інструменти об'єктно-реляційного відображення (ORM).
2.    Реалізація білих списків на сервері з метою перевірки вхідних даних. Звичайно, даний метод не забезпечить повний захист, оскільки багато програм використовують спецсимволи (наприклад, в текстових областях або API для мобільних додатків).
3.    Слід також запровадити екранування спецсимволов для інших динамічних запитів, використовуючи відповідний інтерпретатору синтаксис. Примітка: елементи SQL структури, такі як назви таблиць або стовпців, не можна екранувати, тому надавані користувачами назви становлять небезпеку. Це часта проблема платформ для створення звітів.
4.    Використовуйте в запитах елементи управління SQL для запобігання витоків даних.

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

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

Що робити?

Серед методів боротьби з XSS можна виділити декілька основних:

1.    Якщо на сайті присутній користувацький вхід, то необхідно виконувати шифрування.
2.    Якщо шифрування виконати не можливо по певним причинам, варто використовувати перевірку введення (валідацію). Вона зазвичай використовує білі списки, а не чорні. Наприклад для того, щоб скласти список усіх шкідливих протоколів необхідно просто внести у список усі безпечні протоколи і заборонити усе що відсутнє у ньому. Це забезпечить захист навіть при появі нових шкідливих протоколів.
3.    Зашифрування HTML на стороні клієнта за допомогою JavaScript. Оскільки JavaScript не має в наявності API для зашифрування HTML необхідно створити його власноруч.
4.    Безпечна обробка даних повинна виконуватися не лише на стороні веб-сервера а й на стороні клієнта
5.    Використання JQuery. Найпоширеніша форма XSS в JQuery - це коли ви передаєте введення користувача селектору JQuery. Веб-розробники часто використовують location.hash і передають його селектору, що спричинить XSS, оскільки JQuery буде представляти HTML. jQuery розпізнав цю проблему і випрацював їх логіку вибору, щоб перевірити, чи починається введення з хеша. Тепер jQuery візуалізує HTML лише у тому випадку, якщо перший символ є <. Якщо ви передаєте недовірені дані селектору JQuery, переконайтесь, що ви правильно вимкніть значення за допомогою функції jsEscape, наведеної вище.
6.    Використання PHP. У PHP є вбудована функція для шифрування сутностей, відомих як htmlentities. Необхідно викликати цю функцію, щоб уникнути введення даних у контексті HTML.
7.    Використання CSP (Content Security Policy). CSP є останньою лінією захисту від міжсайтового скриптингу. Якщо захист від xss не спрацював по певним причинам використовується політика безпеки для пом’якшення xss, обмежевши можливості зловмисника. CSP дозволяє керувати різними речами, наприклад, чи можна завантажувати зовнішні сценарії та чи виконуватимуться вбудовані сценарії. Для розгортання CSP потрібно включити заголовок відповіді HTTP під назвою Content- Security-Policy зі значенням, що містить вашу політику.