БАЗОВИЙ ЗАХИСТ ДАНИХ НА JAVASCRIPT

захист данних зображення Останні кілька років захист особистих даних користувачів став каменем спотикання для багатьох компаній. Десятки великих компаній у світі страждають від витоків даних щороку. У цій статті фахівці RPC зібрали рекомендації, як базово захистити особисті дані користувачів від витоку. Розберемося, як можна впливати на дані користувача ззовні, і як це запобігти.

МІЖСАЙТОВИЙ СКРИПТИНГ, XSS

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

• Відображена вразливість XSS виникає, коли контент користувача, що передається на сервер, негайно і без змін повертається для відображення в браузері. Будь‐який скрипт у вихідному контенті користувача запуститься при завантаженні нової сторінки. Зловмисник може створити пошукове посилання, яке міститиме шкідливий скрипт і надіслати його іншому користувачеві електронною поштою.

• Збережена вразливість XSS виникає, коли шкідливий скрипт зберігається на сайті, а потім знову відображається без змін.

ЯК ЗАХИСТИТИСЯ ВІД XSS‐АТАК?

Інструменти санітизації. Санітизація ‐ це «очищення» коду від підозрілих чи шкідливих ділянок коду.

Функцію очищення можна написати самостійно, але для продакшну такий варіант недостатній. Рекомендуємо скористатися спеціальною бібліотекою‐санітайзером. Подібні бібліотеки можуть відсікнути код, який вважають небезпечним. Екранування ‐ це заміна спеціальних символів, які браузер може вважати за безпечні теги.

Для реалізації екранування контенту користувача в JavaScript необхідно використовувати:

• encodeURI ‐ щоб кодувати URI‐адресу;

• encodeURIComponent ‐ кодувати частину URI‐адреси, наприклад searchQuery;

• спеціальні бібліотеки для заміни спеціальних символів.

захист сайту зображення Content Security Policy (CSP) ‐ один із найпотужніших способів захисту. Це «білий» список того, що можна використовувати в роботі. Кожна з директив CSP відповідає за тип джерела:

• style‐src ‐ стилі;

• img‐src ‐ ресурс для завантаження картинок;

• script‐src ‐ список джерел, звідки можуть підвантажуватись скрипти;

• Content Security Policy ‐ гарний інструмент захисту, який дає великий простір для роботи через велику кількість можливих налаштувань.

BRUTE FORCE ATTACK

Bruteforce attack ‐ це атака, коли зловмисник отримує дані для входу в систему перебором. Найпростіший приклад ‐ спроба вгадати пароль. Така атака потрібна для того, щоб отримати доступ до системи, перевірити надійність або виявити вразливість.

ЯК ЗАХИСТИТИСЯ ВІД BRUTEFORCE‐АТАК?

Обмеження частоти звернень. Хакеру може знадобитися величезна кількість спроб, щоб вгадати пароль, а ось власнику облікового запису достатньо 1‐2, щоб його згадати. Крім того, обмеження частоти допоможе регулювати вхідний та вихідний трафік.

reCAPTCHA. Це одне з класичних рішень, яке працює тільки для форм авторизації/реєстрації та не дає атакуючого надсилати випадкові запити.

Надійні паролі. Принципово відкидайте слабкі паролі, вимагайте надійних та складних паролів та періодичної зміни паролів.

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

Високий рівень шифрування. Чим вищий ступінь шифрування, тим складніше зламати пароль.

Рандомізовані хеші паролів. У пароль вводяться додаткові випадкові рядки символів, які роблять хеш рандомним.

захист сайту картинка Важливо не лише запобігти вразливості свого коду або захистити інформацію, а й розуміти, як працюють механізми захисту на інших рівнях: передача даних, backend, frontend, база. У статті ми розібрали лише кілька прикладів, як можна впливати на дані ззовні. Є велика кількість варіантів атаки на сайт і багато способів попередити, виявити та захиститись. Розібралися в базових методах захисту даних користувача. Пам'ятайте, що веб‐програма не може довіряти жодним даним з веб‐браузера. Всі дані користувача повинні бути очищені перед відображенням або використовуватися в SQL‐запитах і викликах файлової системи.