OWASP Top 10 частина 2: Cryptographic Failures

Криптографічні помилки – це недоліки в реалізації криптографії, які можуть призвести до витоку або компрометації даних.

1. Використання застарілих алгоритмів

• Опис: Використання застарілих або небезпечних криптографічних алгоритмів або протоколів.

• Приклад: Використання MD5 для хешування паролів замість більш сучасних алгоритмів, таких як bcrypt або Argon2, що може призвести до легкого злому хешів.

2. Недостатнє шифрування даних

• Опис: Неправильне або недостатнє шифрування чутливих даних.

• Приклад: Зберігання паролів в простому текстовому форматі або використання слабких ключів шифрування, що робить дані доступними для зловмисників.

3. Ненадійне зберігання ключів

• Опис: Зберігання криптографічних ключів у ненадійних місцях або без належного захисту.

• Приклад: Зберігання криптографічних ключів у коді додатка або конфігураційних файлах, доступних для зловмисників.

4. Слабке управління сеансами

• Опис: Ненадійне управління сеансами, яке дозволяє зловмисникам перехоплювати або підробляти сеанси користувачів.

• Приклад: Використання передбачуваних або недостатньо складних сесійних ідентифікаторів, які можуть бути легко вгадані або підроблені.

Encoding, Encryption, Hashing

 Blue team. HTML Entities

HTML entities – це спеціальні символи, які використовуються для заміни небезпечних або резервованих символів у HTML-коді, щоб запобігти їх неправильній інтерпретації браузером.

Приклад:

• Оригінальний код: <script>alert(‘XSS’);</script>

• Закодований: &lt;script&gt;alert(‘XSS’);&lt;/script&gt;

HTML-код у браузері інтерпретується як текст, а не як виконавчий код, що запобігає XSS-атакам.

Red team

Якщо вебсайт некоректно обробляє HTML-код і не проводить належне кодування введених даних, зловмисник може скористатися XSS-атакою (Cross-Site Scripting) для виконання JavaScript-коду на клієнтській стороні. Це може дозволити йому викрасти сесії користувачів, вставити шкідливі скрипти або змінити дані на сторінці.

Приклад:

Зловмисник вводить: <script>alert(‘XSS’);</script> у форму введення, і якщо дані не закодовані належним чином, цей скрипт буде виконаний у браузері іншого користувача.

Blue team

URL кодування (також відоме як процентне кодування) використовується для забезпечення передачі спеціальних символів у URL-адресах. Це потрібно, щоб уникнути конфліктів зі спеціальними символами, які мають значення в URLструктурі.

Приклад:

• Оригінальний текст: lorem with !@#$%^

• Закодований: lorem+with+%21%40%23%24%25%5E

Спеціальні символи кодуються у форматі %XX, де XX – це шістнадцяткове значення ASCII коду символу.

Red team

Зловмисники можуть використати URL-кодування для обходу фільтрів веб-додатків. Наприклад, якщо сервер фільтрує небезпечні символи, такі як < і >, зловмисник може закодувати їх у %3C і %3E і ввести шкідливий код.

Приклад:

URL кодування може бути використане для обходу фільтрів SQL-ін’єкцій або XSS-атак. Зловмисник може закодувати шкідливий SQL-запит або JavaScript-код і ввести його у форму на сайті, який не перевіряє та не розкодовує ці дані належним чином.

Blue team

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

Приклад:

• Оригінальний текст: this is original text

• Закодований: dGhpcyBpcyBvcmlnaW5hbCB0ZXh0

Base64 кодує дані у вигляді тексту, який можна передавати через текстові протоколи.

Red team

Перспектива Red Team:

Зловмисники        можуть       використовувати Base64        для    приховування шкідливого коду або даних у невидимому для користувача форматі, що ускладнює виявлення атаки.

Приклад:

Зловмисник може закодувати шкідливий JavaScript-код у Base64 і вбудувати його у веб-сторінку або електронний лист. Після декодування цей код може виконатися і завдати шкоди системі користувача.

 HTTP/HTTPS

Blue team

Як працює HTTP:

• Клієнт (наприклад, браузер) відправляє HTTP-запит до веб-сервера з проханням надати певний ресурс (наприклад, веб-сторінку).

• Сервер відповідає на запит, надсилаючи назад ресурс, який може бути HTML-файлом, зображенням, або іншим типом даних.

Red team

HTTP – небезпечний протокол, оскільки передає дані у відкритому вигляді, без шифрування. Це дає можливість зловмисникам перехопити інформацію під час атаки типу “людина посередині” (MITM). Такий доступ дозволяє їм отримати конфіденційні дані, зокрема паролі, сесійні токени та іншу важливу інформацію.

Приклад:

• MITM-атака: Зловмисник може використовувати мережевий сніфер, наприклад, Wireshark, для перехоплення трафіку HTTP і читання переданих даних, наприклад, логінів і паролів.

• Session Hijacking: Використовуючи перехоплені дані, такі як сесійні куки, зловмисник може захопити сесію користувача і отримати доступ до його облікового запису.

Blue team

HTTPS – це безпечна версія HTTP, яка застосовує шифрування для забезпечення конфіденційності, цілісності та аутентичності даних, що передаються. Для захисту даних HTTPS використовує протокол TLS (Transport Layer Security) або його попередника SSL (Secure Sockets Layer).

Як працює HTTPS:

• При використанні HTTPS, всі дані між клієнтом і сервером шифруються, що захищає їх від перехоплення і модифікації.

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

Red team

Перспектива Red Team:

HTTPS не є повністю захищеним. Хоча HTTPS шифрує дані, це не захищає від інших типів атак. Наприклад, якщо сервер неправильно налаштований, зловмисники можуть виконати атаки типу SSL-stripping або використовувати вразливості в реалізації TLS/SSL.

Приклад:

• SSL-Stripping: Зловмисник перехоплює трафік і замінює HTTPS на HTTP під час запиту. Користувач бачить звичайну HTTP-сторінку, думаючи, що вона захищена, а всі дані передаються у відкритому вигляді.

• Атаки на TLS: Вразливості у старих версіях SSL/TLS, таких як POODLE, можуть бути використані для розшифрування даних або здійснення інших атак на конфіденційність.

Зберігання конфіденційних даних

 Blue team

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

Приклад шифрування:

Red team

Приклад:

• Атака на недостатньо надійний пароль: Якщо пароль або фраза ключа є слабкими, зловмисник може здійснити атаку перебором (brute-force) і отримати доступ до даних. Наприклад, використовуючи такі інструменти, як Hashcat, можна автоматизувати підбір ключа.

• Атака на IV: Якщо ініціалізаційний вектор (IV) занадто короткий або повторюється, зловмисник може спробувати розшифрувати дані за допомогою атак на шифротекст (ciphertext attacks).

Blue team

Зберігання паролів з використанням хешування. Паролі повинні зберігатися у вигляді хешу, а не у відкритому вигляді, щоб забезпечити їхній захист у разі витоку бази даних.

 Приклад хешування пароля:

Red team

Атака на хеш: Якщо хеші паролів зберігаються без належного додаткового захисту, зловмисники можуть скористатися такими методами, як Rainbow Tables або brute-force атаки, щоб розкрити паролі.

Приклад:

• Слабке хешування: Якщо використовується слабкий або застарілий алгоритм хешування (наприклад, MD5 або SHA1), зловмисники можуть швидко розкрити паролі.

• Атака на сіль (salt): Якщо хешування здійснюється без додавання солі (random salt), зловмисник може використовувати попередньо обчислені таблиці (Rainbow Tables) для розкриття хешів.