Як перевірити, чи ваша система WordPress захищена від атак XSS
У всьому світі майже 48 відсотків усіх веб-сайтів уразливі до міжсайтового сценарію (XSS). У всьому світі майже рівно 25 відсотків усіх веб-сайтів використовують платформу WordPress.
Звідси випливає, що на діаграмі Венна веб-сайтів, уразливих до XSS, і веб-сайтів, що працюють на платформі WordPress, перекриття повинно бути досить великим.
Це не стукіт на самій платформі. Команда WordPress перетворила безпеку на невід’ємну частину своєї місії та агресивно виправляє вразливості щоразу, коли вони стають відомими. Проте це не заважає людям кодувати незахищені теми чи встановлювати небезпечні плагіни. Ці проблеми є двома основними входами для XSS-атак на сайти WordPress, і в цій статті ми обговоримо, як їх зупинити.
Вступ до міжсайтового сценарію
Спочатку обговоримо, як здійснюються XSS-атаки. Існує більше ніж один тип атак XSS, тому я почну зі спрощеного визначення. Як правило, XSS-атаки починаються з несанкціонованих вхідних даних — форм коментарів, вікон для коментарів, рядків пошуку тощо. Ці атаки дуже відрізняються за складністю. Насправді користувачі WordPress щодня бачать найпростішу форму XSS-атаки: спам-коментарі. Ви розумієте, про що я говорю: «Дякую за чудову статтю. До речі, ось мій сайт, на якому я заробляю 5000 доларів на тиждень, працюючи вдома: www.only-an-idiot-would-click-this-link.co.uk».
Певним чином спам-коментарі є ідеальним прикладом XSS-атаки. Зловмисник руйнує інфраструктуру вашого сайту (поле для коментарів), щоб розмістити свій вміст (зловмисне посилання) на вашому сайті. Хоча це гарний ілюстративний приклад, більш реалістична атака XSS буде набагато тоншою. Створення спам-коментаря займає близько п’яти секунд. XSS-атака — це те, на що справжній хакер витратить трохи більше часу.
Справжній «чорний капелюх» намагатиметься скористатися всіма аспектами вашого сайту, які надсилають дані на сервер, по суті, використовуючи їх як мініатюрний текстовий редактор. Якщо ваші вхідні дані незахищені, це означає, що вони можуть буквально взяти їхній код і змусити вашу програму запустити його та відобразити в браузері користувача (і це може включати ваш браузер). На відміну від спам-коментарів, лише детальне вивчення зміненого коду вашого сайту або аналіз взаємодії веб-сайту може виявити порушення. Як можна собі уявити, кількість неприємних речей, які можуть виникнути внаслідок такого порушення, не має кінця.
Простий вандалізм є відносно поширеним результатом XSS-атак, у результаті чого вашим користувачам показують гротескні зображення або політичну пропаганду замість вашого вмісту. Маркетологи з небагато довгостроковими планами або етичними проблемами використовуватимуть їх для реклами людям проти їхньої волі. Більш тонка та тонка атака може викрасти облікові дані ваших користувачів. Якщо один із них має права адміністратора, будь-яка особиста інформація, яку ви зберігаєте на своєму сайті, може бути готова до захоплення. Крім того, вони можуть використати початкову XSS-атаку як важіль, щоб відкрити ваш сайт і встановити ще більш просунуте зловмисне програмне забезпечення.
Припинення нападів
Якщо ви достатньо розбираєтесь у коді та є одноосібним власником відносно невеликого сайту WordPress, то безпечні методи кодування, ймовірно, будуть найкращим способом захистити ваш сайт від атак міжсайтових сценаріїв. Я включаю це застереження, тому що якщо ви є частиною більшої організації, яка працює зі складнішою програмою, у вас може бути неможливим знайти кожну область, куди зловмисник може ввести код. Сучасні веб-сайти можуть бути величезними за масштабом, і вам, можливо, варто було б найняти досвідченого професіонала та витратити свій час на інші справи, щоб зробити свій веб-сайт ще кращим для читачів.
Ще одне попередження: якщо ви не особливо розбираєтесь у коді й доручаєте комусь іншому створювати для вас сайт, не припускайте, що вони використовували безпечні методи кодування. Відомо, що навіть найдосвідченіші розробники залишають безпеку осторонь або допускають незначні помилки, не попросивши когось іншого перевірити їхню роботу. Інші розробники можуть просто не знати, що вони роблять з точки зору безпеки, а інші все ще замовчують безпеку, щоб заощадити час для себе (незважаючи на брак професіоналізму, коли йдеться про це). Підсумовуючи, переконайтеся, що ви найняли визнаного професіонала, який не зрізує кути, коли йдеться про розробку та захист вашого веб-сайту.
З огляду на це занепокоєння, одна з перших і найпростіших речей, які ви можете зробити, щоб запобігти міжсайтовому сценарію, це перевірка даних користувача.
Припустімо, що на вашому сайті є форма реєстрації, і ця форма просить користувача ввести своє ім’я. Натомість зловмисник може ввести щось на зразок:
<script>CoughUpYourPreciousData();</script>Це може, наприклад, призвести до того, що наступна особа, яка відвідає цю сторінку, надішле копію своїх файлів cookie зловмиснику.
Ви бачите, що в цьому прикладі наведений вище рядок коду зовсім не схожий на чиєсь ім’я. Ваш сервер цього не знає, але за допомогою кількох встановлених параметрів ви можете навчити його. Наприклад, ви можете наказати цьому полю відхиляти спеціальні символи, такі як <>,() і ; (вони не особливо потрібні в розділі коментарів). Ви можете сказати, що в цьому полі ім’я людини, ймовірно, не містить цифр. Якщо ви бажаєте бути трохи драконівськими, ви можете наказати цьому полю відхиляти вхідні дані, довжина яких перевищує п’ятнадцять символів (або ви можете змінити значення на свій розсуд). Виконання цих кроків різко обмежить кількість шкоди, яку зловмисник може завдати певному полю.
Навіть із перевіркою даних можуть існувати форми чи поля, у яких ви не можете реально обмежити тип символів, які використовуються, наприклад у формі контакту чи полі для коментарів. Що ви можете зробити, це очистити дані. Цей процес унеможливлює виконання HTML у заданому полі, перетворюючи все, що можна розпізнати як фрагмент виконуваного коду, на некодовані символи. Наприклад, гіперпосилання не з’явиться там, де воно могло б бути.
Нарешті, є випадки, коли на вашому сайті можуть відображатися дані, небезпечні для користувачів. Скажімо, хтось пише зловмисний коментар на одній із ваших сторінок, який згодом індексується пошуковою функцією вашого сайту. Щоразу, коли один із ваших користувачів виконує пошук, цей шкідливий код виконується, коли їхній браузер завантажує результати пошуку. Цьому запобігає екранування даних, яке гарантує, що коли ваш сайт доставляє дані користувачеві, виконується лише той код, який ви хочете запустити.
Щоб дізнатися більше про перевірку даних, очищення даних і екранування даних, WordPress Codex має чудовий ресурс. Він детально пояснює наведені вище концепції, а також надає більше прикладів, які можна застосовувати універсально.
Інші методи
Великі компанії мають більші веб-сайти; це факт. Можливо, тисячі людей користуються вашим сайтом на день. Можливо, замість стандартних форм і полів є анімації, різні портали, частини, написані на Java і так далі. Навіть якщо ви все це відстежуєте, можливо, в одній із ваших заявок є нульовий день, і ви не маєте можливості захиститися.
У подібній ситуації, якщо у вас є вплив і бюджетні долари для цього, я рекомендую вам інвестувати в брандмауер веб-програм (WAF). Хороший WAF матиме правила кореляції, які автоматично ідентифікують і блокують рядки HTML, які найчастіше асоціюються з атаками впровадження коду. Вони також можуть повідомити вас, коли програми починають викрадати дані, коли вони не повинні або роблять це в незвичайному обсязі, таким чином допомагаючи захистити від атак нульового дня та інших складних загроз. WAF — це не ідеальна куля, але це безцінний інструмент для спеціалістів із безпеки та власників веб-сайтів, які сподіваються захистити складні програми.
Існує також низка плагінів, які мають на меті захистити від атак XSS. Я насправді не рекомендую їх. Замість того, щоб зменшувати ризик, багато з цих плагінів представляють собою ще одну поверхню для атаки, якою може скористатися хакер. Навіть один із найвідоміших і широко використовуваних плагінів безпеки, Akismet, минулого року виявився вразливим до атак XSS . Коли справа доходить до відбиття атак XSS, не покладайтеся на напівзаходи. Розвивайте необхідні навички та використовуйте відповідний набір інструментів для забезпечення безпеки свого веб-сайту.
Інші практичні застосування
Ця інформація може бути дещо складною для непосвячених, але я б не хотів, щоб люди збентежувалися потенційною складністю цієї інформації. У разі XSS-атаки ви можете бути впевнені, що усунення наслідків такої події буде набагато складнішим, ніж внесення змін на ваш веб-сайт. Очищення репутаційних витрат вашого веб-сайту (постійні читачі досить легко втечуть з вашого веб-сайту) стане додатковою проблемою, про яку вам не варто хвилюватися.
Навіть якщо ви запросили когось іншого, хто займатиметься розробкою та безпекою вашого веб-сайту, зробіть усе можливе, щоб принаймні мати змогу реагувати на надзвичайні ситуації та знати, де ваші слабкі місця. Знання того, як перевірити вашу систему, стане життєво важливою навичкою в довгостроковій перспективі та стане основою для інших тем безпеки та проектів розробки веб-сайтів. Все взаємопов’язано в Інтернеті, і хоча атаки XSS можуть залишитися в минулому (яким би малоймовірним це не було), знаючи, що тонкощі вашого веб-сайту ніколи не застаріють.
Заключні думки
Ландшафт безпеки в Інтернеті постійно змінюється. Ви ніколи не можете бути повністю впевнені щодо того, як може виникнути XSS-атака або як вона може бути використана проти вас, але ви повинні зробити це заради себе та своїх читачів, щоб переконатися, що ви робите все, що в ваших силах, щоб зупинити їх. Продовжуйте інформувати себе про цю загрозу та регулярно (я б рекомендував принаймні щомісяця) перевіряти будь-які відповідні події у світі кібербезпеки.
Це також не означає, що ви можете ігнорувати інші загрози. Для безпечного доступу до публічної мережі все ще потрібне використання VPN. Ви не можете нехтувати безпекою будь-якого комп’ютера, який використовуєте для доступу до свого веб-сайту. Інформацію для входу все ще потрібно часто змінювати, щоб захистити її від атак грубої сили. Атаки XSS є жорстокими, але це не єдина загроза, на яку варто звернути увагу.
Вам також може бути доцільно поділитися цією інформацією (або навіть цією статтею) зі своїми колегами та зацікавленими сторонами, щоб поширити опір таким типам атак. Хоча ви, можливо, не зможете багато чого зробити самі, якщо достатньо людей захищає себе належним чином, ми можемо спостерігати загальне зменшення таких типів атак, оскільки хакери намагаються знайти інший спосіб отримання прибутку від бідних користувачів Інтернету.
Чи є у вас якісь думки щодо того, як перевірити XSS-атаки, а також захиститися від них у майбутньому? Чи існують інші стратегії виявлення та видалення, які ви використовуєте для боротьби з цією загрозою? Чи є якісь інструменти, які ви б порадили своїм колегам-читачам? Якщо так, будь ласка, залиште коментар нижче та продовжіть цю важливу розмову зі своїми колегами-читачами.