Проблеми безпеки сайтів «б
Звідки ростуть ноги
Розглянемо типову історію «кинутого» сайту.
Якась компанія замовляє сайт у невеликій веб-студії (або у фрілансера). Виконавець успішно розробляє їй сайт «під ключ» на якійсь популярній або, що сумніше, самописній CMS, а по закінченні робіт передає сайт на адміністрування компанії-власнику. Звичайно, розробник пояснює власнику ресурсу, як завантажувати нові картинки, оновлювати ціни, змінювати текст на сторінках, вказувати нові контактні дані та ін. І навіть все це оформляє у вигляді посібника користувача. А через деякий час, що називається "волею доль", розробник сайту зникає і "корпоративне представництво" залишається "кинутим".
Наприклад, скривджений веб-майстер з метою додаткового (фонового) заробітку може непомітно розмістити в шаблонах сайту код продажу посилань або мобільний редирект на WAP-партнерку. У першому випадку власник сайту через деякий час побачить чужі посилання у футері або сайдбарі сторінки, а в другому частина відвідувачів, що відкривають сайт з мобільних пристроїв, буде перенаправлятися на сайт, що продає медіа-контент за смс. Відсоток від продажів і дохід від продажних посилань складатиме пасивний дохід нечесному веб-майстру, а власник сайту якийсь час навіть не підозрюватиме про те, що у нього на сайті паразитують.
Чи довго, чи коротко, але історія з недбайливим веб-майстром закінчується, з ним прощаються, і сайт знову залишається «кинутим». Спираючись на минулий негативний досвід роботи з фрілансером, власник сайту наступного разу звертається вже до веб-студії, першочерговим завданням якої є грамотно прийняти сайт на підтримку, виконати аудит, прибрати «закладки» непорядних веб-майстрів і запобігти їх появі надалі.
Крім«закладок» у сайтів, розроблених досить давно (назвемо їх для простоти «сайтами б/у»), є ще одна серйозна проблема безпеки: вразливість у скриптах і, як наслідок, злом та зараження шкідливим кодом. Оскільки «движок» сайту оновлювати не було кому, такі проекти працюють на стародавніх версіях CMS і скриптів з великою кількістю вразливостей, які успішно експлуатуються хакерами.
Щоб сайт зламали не обов'язково, щоб сайт був популярним. Достатньо, щоб він за деякими запитами з'являвся в результатах пошукової видачі. В ході масової атаки, націленої на певну вразливість, сайт з'явиться у вибірці і зламується в автоматичному режимі разом з кількома сотнями інших сайтів, що працюють на тій же вразливій версії CMS (до речі, вразливість може бути не тільки і не стільки в ядрі CMS, скільки в плагінах та розширеннях).
Звичайно, ідеальний варіант на етапі прийому сайту на обслуговування - залучити для проведення аудиту сайту фахівців-«безпеків», але за наявності в команді досвідчених веб-розробників більшу частину роботи можна виконати і самотужки.
Розглянемо проблеми безпеки сайтів, з якими може зіткнутися новий сапорт сайту.
Проблеми безпеки сайтів «б/в»
На що насамперед слід звернути увагу новому адміністратору ресурсу, який отримує сайт на підтримку?
Спам-посилання (black-hat seo посилання)
На всіх сторінках сайту зустрічаються посилання на чужі ресурси, які власник сайту не розміщував. Посилання можуть розташовуватися у футері сайту, в сайдбарі або коді сторінки, але не видно відвідувачу сайту (бо розміщуються в невидимому шарі).
Джерелом появи посилань може бути код біржі посилань,який впроваджений у шаблони або скрипти (код sape, trustlink, linkfeed та ін). Крім того, при розробці сайту могли використовуватися безкоштовні шаблони або неліцензійні плагіни, в яких часто впроваджують як статичні посилання, так і код завантаження блоку посилань з віддаленого сервера. Якщо цю проблему виявлено на сайті, необхідно знайти код, який впроваджує посилання на сторінки та видалити його. Найчастіше завдання вирішується пошуком по файлам. До речі, код посилань може бути не лише у файлах, а й у базі даних.
Шукати зовнішні посилання можна SEO-сервісами, які показують зовнішні посилання на сторінках за допомогою грабберів контенту (Teleport, Xenu Link Sleuth), а також шляхом аналізу вихідного коду сторінок. Крім того, використання спеціалізованого сканера шкідливого коду, наприклад, AI-BOLIT, також шукають впровадження посилань у код.
Веб-шелли, бекдори, «завантажувачі»
Для того, щоб керувати сайтом через веб, достатньо завантажити на хостинг так званий веб-шелл – основний інструмент хакера.
Бекдор— це невеликий скрипт хакера або фрагмент коду, інжектований в один із скриптів CMS. Завдання бекдора - надати хакеру "чорний хід", через який можна виконати довільний код або завантажити веб-шелл, а далі отримати контроль над скомпрометованим сайтом або сервером.
«Завантажувач»(Uploader) - це ще один варіант бекдору, що дозволяє завантажити довільний файл на сервер. Природно, хакера в першу чергу цікавить завантаження інструментів для злому (веб-шелли, тунелери, спам-розсилники та ін). «Завантажувач» досить складно виявити, оскільки він є невеликим скриптом з кодом, що зустрічається і в легітимних скриптах завантаження файлів на сервер (наприклад, вupload формах CMS). Тому навіть виявивши файл «завантажувача» недосвідчений веб-майстер може надати йому значення. Приклад «зашарника»:
Для пошуку скриптів хакерів ефективно скористатися сканером шкідливого коду AI-BOLIT (http://revisium.com/ai/), який «заточений» під детектування шкідливого коду в PHP/Perl/шелл скриптах.
Уразливості
Можна упевнено стверджувати, що в більшості динамічних сайтів, реалізованих на PHP, ASP і скриптах з використанням CGI, є вразливі. Якщо сайт працює на популярній CMS, яка давно не оновлювалася або написана недосвідченим веб-розробником, то цей сайт потрапляє в зону ризику і вже швидше за все був (або незабаром буде) зламаний під час масових атак через відомі «дірки». При цьому не важливо, яка у сайту відвідуваність і наскільки він популярний. Щоб знизити ймовірність злому, CMS сайту необхідно якнайшвидше оновити до останньої доступної версії, на неї необхідно встановити всі існуючі патчі безпеки, і, бажано, виконати процедуру CMS hardening («цементування» або «заморозку» сайту), яка заборонить несанкціоновані зміни на сайт. Крім того, необхідно просканувати сайт на наявність скриптів хакерів, веб-шеллів і бекдорів, щоб перевірити його на компрометацію і гарантувати безпеку сайту в майбутньому.
Для пошуку вразливостей на сайті можна спеціалізованим програмним забезпеченням (Acunetix Web Vulnerability Scanner, XSpider, Nikto, Metasploit Framework, sqlmap та іншими інструментами пентестера), а для популярних CMS та модулів – перевірити вразливості на базі http://www.cvedetails.com. 9>
Мобільний або пошуковий редирект
Редирект - це несанкціонований перенаправлення відвідувача на сторонній.ресурс. Приклад: відвідувач відкриває заражений сайт у мобільному браузері та перенаправляється на ресурс для дорослих або WAP-портал, де йому пропонують підписку на медіа-контент за смс.
Причиною мобільного редиректа може бути фрагмент коду, вставлений зловмисником у шаблон, скрипт чи базу даних сайту. Щоб достовірно перевірити свої сайти на наявність мобільного редиректа, у більшості випадків достатньо підключити мобільний пристрій до мобільного інтернету через мережу 3G/LTE та відкрити сайт у мобільному браузері.
Детально питання виявлення та видалення мобільних редиректів було розглянуто у нашій доповіді на конференції Яндекса: https://events.yandex.ru/lib/talks/2673/
Найбільш типова помилка власника сайту - довірити всі доступи від сайту фрілансер і забути про це. Серед рядових контент-менеджерів та веб-розробників лише малий відсоток обізнаний про техніку безпеки або так звану «гігієну безпеки» під час роботи з сайтом. Тому дуже часто обслуговування сайту саме сторонніми фахівцями (контент-менеджерами, адміністраторами, веб-майстрами) є причиною злому сайтів.
Чому це відбувається? Все просто: у розпорядженні найманих фахівців виявляються «ключи від квартири, де гроші лежать», але через слабку поінформованість про безпеку та захист сайту ці ключі буквально ховаються під килимок біля парадних дверей. А хакери це знають та активно користуються цим.
Перерахуємо найбільш типові «проколи» фахівців та власників сайтів, що призводять до компрометації чи зараження ресурсів:
Комп'ютер веб-майстра, що працює по FTP, може бути заражений троянською програмою, що перехоплює FTP трафік і краде паролі, або шпигунською програмою, яка витягує паролі з FTP-клієнта. В результаті парольвиявляється у хакера, а через деякий час на хостинг проникає бот і заражає файли шкідливим кодом.
Веб-розробник може виходити в інтернет через відкриті мережі (у кафе, в парку, в метро та через інші відкриті WI-FI точки) без використання VPN, внаслідок чого доступи до хостингу та в адміністративну панель сайту виявляються скомпрометованими, а листування з власником сайту, що містить конфіденційну інформацію, перехоплена зловмисником (зараз цим може займатися будь-який школяр використовуючи сніфер трафіку в promiscuous mode або спеціалізовані програми на кшталт Intercepter-NG).
Тепер ви розумієте, чому не варто довіряти підряднику (не має значення це веб-студія або фрілансер), і чому слід негайно після закінчення робіт із сайтом змінювати всі паролі.
Старі адміністративніemail'и
Наприклад, якщо між замовником та виконавцем станеться конфлікт, виконавець, користуючись нагодою, може змінити всі доступи до хостингу та сайту, і почне шантажувати власника. Погодьтеся, ситуація не найприємніша. Більше того, якщо хостинг або домен зареєстрований на виконавця, замовник може втратити сайт повністю. Такі випадки не рідкість.
Підміна платіжних реквізитів та контактних даних
Непрацюючий функціонал
Якщо сайт був розроблений досить давно, то, швидше за все, частина функціональності перестане працювати. Причин може бути кілька: це і перехід хостера на нову версію PHP, з якою не сумісна стара версія CMS, і можливий зламування/зараження сайту шкідливим кодом, і некоректні дії адміністратора сайту, що призводять до помилок у роботі (наприклад, пошкодження шаблонів).
Тому при прийомі сайту на супровід бажано провестифункціональне тестування та виявити всі помилки в роботі, про які повідомити власника сайту.
Прийом сайту на супровід — процедура, яка потребує детального аналізу: необхідно перевірити як безпеку, так і функціональність ресурсу, інакше разом з новим клієнтом можна отримати нові проблеми.
Для зручності наводимо чекліст нового адміністратора сайту. Ось що потрібно зробити одразу після отримання сайту на обслуговування (підтримку):
Виконати аудит безпеки сайту: просканувати сайт на наявність шкідливого коду, вірусів, фактів злому. Вилікувати сайт, якщо необхідно, та встановити захист від злому.
Оновити CMS та скрипти до актуальних версій, встановити всі необхідні патчі безпеки.
Перевірити всі основні сценарії поведінки користувача, виконати функціональне тестування власних та адміністративних розділів.
Налаштувати систему моніторингу сайту для своєчасного виявлення проблем у роботі чи злому
Налаштувати систему резервного копіювання сайту
Налаштувати систему логування (включити логи веб-сервера, FTP та поштового сервера з архівацією, встановити максимально можливі періоди ротації)
Виробити правила безпечної роботи з сайтом для персоналу, який обслуговує ресурс та оформити її як пам'ятку.
Як можна помітити, проблем у сайтів б/у достатньо. Проте якщо знати, звідки чекати біду, акуратно перевірити всі основні елементи, своєчасно діагностувати та усунути проблеми, то подальша підтримка ресурсу буде простою і не вимагатиме значних ресурсів.