Проблеми със сигурността на уебсайта
Откъде растат краката
Помислете за типична история на „изоставен“ сайт.
Определена фирма поръчва уеб сайт от малко уеб студио (или от фрийлансър). Изпълнителят успешно разработва за нея уебсайт до ключ на някаква популярна или, по-тъжно, самонаписана CMS, и след приключване на работата прехвърля сайта на компанията собственик за администриране. Естествено, разработчикът обяснява на собственика на ресурса как да качва нови снимки, да актуализира цените, да променя текста на страниците, да посочва нови данни за контакт и т.н. И дори всичко това се прави под формата на ръководство за потребителя. И след известно време, което се нарича "волята на съдбата", разработчикът на сайта изчезва и "корпоративното представителство" остава "изоставено".
Например, за целите на допълнителни (фонови) печалби, обиден уеб администратор може тихо да постави в шаблоните на сайта код за продажба на връзки или мобилно пренасочване към WAP партньор. В първия случай собственикът на сайта ще види след известно време връзките на други хора в долния колонтитул или страничната лента на страницата, а във втория случай някои посетители, които отварят сайта от мобилни устройства, ще бъдат пренасочени към сайт, който продава медийно съдържание чрез SMS. Процентът от продажбите и приходите от продажба на връзки ще бъдат пасивен доход за нечестен уеб администратор и за известно време собственикът на сайта дори няма да подозира, че сайтът му е паразитиран.
Колко дълго, колко кратко, но историята на небрежния уебмастър свършва, сбогуват се с него и сайтът отново остава "изоставен". Въз основа на предишен негативен опит от работа с фрийлансър, собственикът на сайта следващия път се обръща към уеб студио, чиято основна задача е компетентно да приеме сайта за поддръжка, да извърши одит, да премахне „отметките“ на нечестни уеб администратори и да предотврати появата им в бъдеще.
С изключение„Отметките“ за сайтове, разработени преди много време (нека ги наречем „използвани сайтове“ за простота) имат друг сериозен проблем със сигурността: уязвимости в скриптовете и в резултат на това хакване и заразяване със злонамерен код. Тъй като нямаше кой да актуализира "двигателя" на сайта, такива проекти работят върху стари версии на CMS и скриптове с голям брой уязвимости, които се използват успешно от хакери.
За да бъде хакнат един сайт, изобщо не е необходимо той да е популярен. Достатъчно е да се появи в резултатите от търсенето за някои заявки. В хода на масова атака, насочена към определена уязвимост, сайтът ще се появи в селекцията и ще бъде хакнат автоматично заедно с няколкостотин други сайтове, работещи на същата уязвима версия на CMS (между другото, уязвимостта може да е не само и не толкова в ядрото на CMS, но в плъгини и разширения).
Разбира се, идеалният вариант на етапа на приемане на сайт за поддръжка е да се включат специалисти по „сигурност“ за одит на сайта, но ако в екипа има опитни уеб разработчици, по-голямата част от работата можете да свършите сами.
И така, нека разгледаме проблемите със сигурността на сайта, които може да срещне поддръжката на нов сайт.
Проблеми със сигурността на използвания сайт
На какво първо трябва да обърне внимание нов администратор на ресурси, който получава сайт за поддръжка?
Връзки за нежелана поща (връзки с черна шапка за SEO)
На всички (или някои) страници на сайта има връзки към ресурси на други хора, които собственикът на сайта не е публикувал. Връзките могат да бъдат разположени в долния колонтитул на сайта, в страничната лента или в кода на страницата, но не са видими за посетителя на сайта (защото са поставени в невидим слой).
Източникът на появата на връзки може да бъде кодът на обмена на връзки,който е вграден в шаблони или скриптове (sape код, trustlink, linkfeed и др.). Освен това при разработването на сайта могат да се използват безплатни шаблони или нелицензирани плъгини, в които често се въвеждат както статични връзки, така и код за зареждане на блок от връзки от отдалечен сървър. Ако този проблем бъде открит на сайта, трябва да намерите кода, който вгражда връзки към страници, и да го премахнете. В повечето случаи задачата се решава чрез търсене на файлове. Между другото, кодът на връзката може да бъде не само във файлове, но и в база данни.
Можете да търсите външни връзки с помощта на SEO услуги, които показват външни връзки на страници, с помощта на устройства за грабване на съдържание (Teleport, Xenu Link Sleuth), а също и чрез анализиране на изходния код на страниците. В допълнение, използването на специализиран скенер за злонамерен софтуер, като AI-BOLIT, също търси инжектиране на връзки в кода.
Уеб обвивки, задни вратички, зареждащи устройства
За да управлявате сайта през мрежата, е достатъчно да качите на хостинга т. нар. web shell - основният инструмент на хакера.
Backdoorе малък хакерски скрипт или част от код, инжектиран в един от CMS скриптовете. Целта на задната врата е да предостави на хакера „задна врата“, чрез която може да изпълни произволен код или да изтегли уеб обвивка и след това да получи контрол над компрометиран сайт или сървър.
"Програма за качване"(Програма за качване) е друга опция за задна врата, която ви позволява да качите произволен файл на сървъра. Естествено, хакерът се интересува предимно от изтегляне на инструменти за хакване (уеб обвивки, тунели, програми за спам и др.). „Зареждащото устройство“ е доста трудно за откриване, тъй като това е малък скрипт с код, който се намира и в легитимните скриптове за качване на файлове на сървъра (например вкачване на CMS формуляри). Следователно, дори след като е намерил файла „loader“, неопитен уеб администратор може да не му придаде значение. Пример за зареждане:
За търсене на хакерски скриптове е ефективно да използвате скенера за злонамерен софтуер AI-BOLIT (http://revisium.com/ai/), който е „наточен“ за откриване на зловреден код в PHP/Perl/shell скриптове.
Уязвимости
Безопасно е да се каже, че повечето динамични сайтове, реализирани в PHP, ASP и CGI скриптове, имат уязвимости. Ако сайтът работи на популярна CMS, която не е актуализирана дълго време или е написана от неопитен уеб разработчик, тогава този сайт е изложен на риск и най-вероятно вече е бил (или скоро ще бъде) хакнат по време на масови атаки чрез известни „дупки“. Няма значение какъв е трафикът на сайта и колко е популярен. За да се намали вероятността от хакване, CMS на сайта трябва да се актуализира до най-новата налична версия възможно най-скоро, всички съществуващи корекции за сигурност трябва да бъдат инсталирани на него и за предпочитане трябва да се извърши процедурата за втвърдяване на CMS („циментиране“ или „замразяване“ на сайта), което ще забрани неоторизирани промени в сайта. Освен това е необходимо да сканирате сайта за хакерски скриптове, уеб обвивки и задни врати, за да го проверите за компрометиране и да гарантирате сигурността на сайта в бъдеще.
За да търсите уязвимости в сайта, можете да използвате специализиран софтуер (Acunetix Web Vulnerability Scanner, XSpider, Nikto, Metasploit Framework, sqlmap и други пентестър инструменти), а за популярните CMS и модули проверете уязвимостите, като използвате базата данни http://www.cvedetails.com
Мобилно пренасочване или търсене
Пренасочването е неразрешено пренасочване на посетител към трета странаресурс. Пример: посетител отваря заразен сайт в мобилен браузър и се пренасочва към ресурс за възрастни или WAP портал, където му се предлага абонамент за медийно съдържание чрез SMS.
Причината за мобилно пренасочване може да бъде част от код, вмъкнат от нападател в шаблон, скрипт или база данни на уебсайт. В повечето случаи, за да проверите надеждно вашите сайтове за мобилно пренасочване, е достатъчно да свържете мобилното си устройство към мобилен интернет чрез 3G/LTE мрежа и да отворите сайта в мобилен браузър.
Въпросът за откриването и премахването на мобилни пренасочвания беше обсъден подробно в нашия доклад на конференцията на Yandex: https://events.yandex.ru/lib/talks/2673/
Най-типичната грешка на собственик на сайт е да повери целия достъп от сайта на фрийлансър и да забрави за него. Сред обикновените мениджъри на съдържание и уеб разработчици само малък процент са запознати с предпазните мерки или така наречената „хигиена на безопасността“ при работа със сайта. Ето защо много често поддръжката на сайта от специалисти на трети страни (мениджъри на съдържанието, администратори, уеб администратори) е причина за хакване на сайтове.
Защо се случва това? Всичко е просто: наетите специалисти разполагат с „ключовете от апартамента, в който са парите“, но поради слабата информираност за сигурността и защитата на обекта, тези ключове са буквално скрити под килима на входната врата. И хакерите знаят това и активно го използват.
Нека изброим най-типичните "пробивки" на специалисти и собственици на сайтове, водещи до компрометиране или заразяване на ресурси:
Компютърът на FTP уеб администратора може да е заразен с троянски кон, който прихваща FTP трафик и краде пароли, или шпионски софтуер, който извлича пароли от FTP клиент. В резултат на това паролатасе оказва с хакер и след известно време бот прониква в хостинга и заразява файлове със злонамерен код.
Уеб разработчикът може да получи достъп до интернет чрез отворени мрежи (в кафене, в парк, в метрото и през други отворени WI-FI точки), без да използва VPN, в резултат на което достъпът до хостинг и административния панел на сайта е компрометиран, а кореспонденцията със собственика на сайта, съдържаща поверителна информация, е прихваната от нападател (сега всеки студент може да направи това с помощта на снифър за трафик в безразборен режим или специализирани приложения като Intercepter-NG).
Сега разбирате защо не трябва да се доверявате на изпълнител (няма значение дали е уеб студио или фрийлансър) и защо трябва да промените всички пароли веднага след приключване на работата със сайта.
Стари административниимейли
Например, ако възникне конфликт между клиента и изпълнителя, изпълнителят, използвайки възможността, може да промени целия достъп до хостинга и сайта и да започне да изнудва собственика. Съгласете се, ситуацията не е от най-приятните. Освен това, ако хостингът или домейнът са регистрирани на изпълнителя, клиентът може напълно да загуби сайта. Такива случаи не са рядкост.
Замяна на данни за плащане и данни за контакт
Деактивирана функционалност
Ако сайтът е разработен преди много време, тогава най-вероятно част от функционалността ще спре да работи. Може да има няколко причини: това е прехвърлянето на хостера към по-нова версия на PHP, с която старата версия на CMS не е съвместима, и възможното хакване / заразяване на сайта със зловреден код и неправилни действия на администратора на сайта, водещи до грешки в работата (например повреда на шаблони).
Затова при приемане на обект за поддръжка е препоръчително дафункционално тестване и идентифициране на всички грешки в работата, които трябва да бъдат докладвани на собственика на сайта.
Приемането на сайт за поддръжка е процедура, която изисква подробен анализ: необходимо е да се провери както сигурността, така и функционалността на ресурса, в противен случай, заедно с нов клиент, можете да получите нови проблеми.
За удобство ето контролен списък за новоизпечения администратор на сайта. Ето какво трябва да направите веднага след получаване на сайта за поддръжка (поддръжка):
Извършете одит на сигурността на сайта: сканирайте сайта за злонамерен код, вируси, хакерски факти. Излекувайте сайта, ако е необходимо, и инсталирайте защита срещу хакване.
Актуализирайте CMS и скриптове до най-новите версии, инсталирайте всички необходими пачове за сигурност.
Проверете всички основни сценарии на потребителско поведение, извършете функционално тестване на потребителски и административни секции.
Настройте система за наблюдение на сайта, за да откриете своевременно проблеми в работата или хакване
Настройте система за архивиране на сайта
Настройте система за регистриране (разрешете уеб сървър, FTP и регистрационни файлове на пощенски сървър с архивиране, задайте максималните възможни периоди на ротация)
Разработете правила за безопасна работа със сайта за персонала, обслужващ ресурса, и го подредете под формата на бележка.
Както можете да видите, "използваните" сайтове имат достатъчно проблеми. Въпреки това, ако знаете къде да очаквате проблеми, внимателно проверете всички основни елементи, диагностицирайте и коригирайте проблемите своевременно, тогава по-нататъшната поддръжка на ресурса ще бъде проста и няма да изисква значителни ресурси.