Уязвимости сайтов: какие бывают и как справляться

Абсолютно все сайты и системы сталкиваются с попытками взломов. Предупрежден — значит вооружен. Поэтому специалисты Webit помогают клиентам выстроить защиту и вовремя обновить всю систему. Наш директор производственного департамента Иван Гринкевич решил поделиться некоторыми лайфхаками для защиты ПО и рассказать о самых распространенных уязвимостях.

В первую очередь атака совершается либо на сам сайт в общем, либо на встроенные в него модули. Пройдемся по порядку.

Если говорить про систему и сам сайт, то тот же Битрикс сам старается найти и закрыть бреши в безопасности. Поэтому достаточно вовремя обновлять программное обеспечение, чтобы иметь актуальную защиту. Битрикс организовал обновление так, чтобы его мог провести человек, далекий от разработки. Достаточно зайти в админ панель и нажать необходимую кнопку.

Атака на модули

загружаемых приложений. Недобросовестный разработчик может написать модуль, который якобы полезен для конечного клиента. Пользователь устанавливает себе модуль, ни о чем не подозревая, а потом оказывается, что он фоном отправляет данные злоумышленнику. По сути, в модуле находится вирус, а клиент ставит его добровольно. Можно ли кому-то пожаловаться? Скорее всего, только модераторам приложений.

На Битриксе такая история встречается реже, так как в его магазине более основательная модерация. Но она может иметь место, если клиент обращается к фрилансеру. Если с фрилансером договорились об условиях оплаты не на очень хороших условиях, то он может оставить shell — возможность либо авторизоваться под клиентом, либо ввести какой-то запрос на сайт, после чего выполняются заранее запланированные действия. Поэтому мы советуем аккуратно подходить к выбору подрядчиков, особенно к фрилансерам (но ни в коем случае не демонизируем их).

• Один из распространенных вариантов атаки — это SQL-инъекция.

Часто эта уязвимость прослеживается в формах на сайте. Взломщики пишут SQL-код в поля формы, который при плохой обработке на сервере может открыть доступ к базе.

В фреймворке Битрикса запрещено обращаться к базе. Иногда, когда мы берем проекты на техподдержку, сталкиваемся со случаями, когда разработчики от этого принципа отходят. Они пишут свои коннекторы к базе, плохо их защищают, что приводит к появлению бреши в системе.

• PHP-файл с кодом. Этот вариант возможен, если клиент имеет возможность отправлять файл через форму, например, анкету или смету.

Для такого взлома должно быть соблюдено два условия: отправляемый файл не переименовывается на сервере и он отправляется туда, где к нему можно обратиться через строку браузера.

Злоумышленник прикрепляет PHP-файл со своим заданным именем. Затем отслеживает адрес, куда он направляется. Зная адрес, взломщик напрямую обращается к этому файлу через строку браузера. Код исполняется на сайте и ломает его работу.

Для того, чтобы защититься от подобного взлома, хватает просто переименовывать файлы, отправляемые на сервер.

• Подбор реквизитов доступа. В Битриксе появляется ограничение в виде бана на 10 минут, если наблюдается несколько неправильных попыток ввода. Недоброжелатели научились обходить защиту и несмотря ни на что подбирают логин и пароль, чтобы войти в админ панель. Но часто оказывается, сами менеджеры и администраторы оказывают взломщикам услугу и оставляют какие-то стандартные логины/пароли, по типу admin admin.
• Наличие логических ошибок кода, которое приводит к уязвимости. Код работает не так, как надо, и этим пользуются злоумышленники. Они получают доступ к файлам, к базе или в ту же административную панель путем подбора нехитрых комбинаций, которые они получили на сайте.
• Взломщик, представляясь админом сайта, просит изменить пользователя пароль на заранее заданный.
• Фишинг. Создается подставной веб-сайт, который повторяет по дизайну целевой сайт, а его URL отличается одной буквой. Часто пользуются схожестью букв I (большая i) и l (маленькая L). Пользователь вводит логин\пароль на фейковом сайте, они перехватываются, а затем клиента переводят уже на корректный сайт. Страдают от фишинга больше платежные системы, чем мелкие сайты.
• Межсайтовая подделка запроса. Можно заставить посетителя сайта сделать запрос к уязвимому серверу. Браузер делает этот запрос с текущими cookies пользователя. Данные пользователя могут просто утечь. Не даром говорят, что нельзя ходить по небезопасным сайтам и серверам. Есть условие, что клиент должен быть авторизован на том сервере, куда пытаются отправить запрос. Но у большинства есть авторизация в Сбере или в Тинькоффе, поэтому перенаправить запрос туда проще всего.
• Обнародованные уязвимости CMS. Нередко CMS имеют открытый исходный код, что дает возможность всем пользователям интернета посмотреть его. Используемая версия CMS может содержать ряд уязвимостей, которые могли обнародовать после выпуска нового обновления. Этим могут воспользоваться недоброжелатели, которые будут использовать эти дыры в коде против тех, кто не успел установить последнее обновление.

Самописные сайты защищают только по той причине, потому что злоумышленник не будет понимать, как устроена система сайта. Он не знает стандарты, папки и расположение всех файлов. Но самая большая ошибка самописных сайтов — это просто написать сайт и забыть о его поддержке. Многие забывают об обновлении серверного ПО.

CMS системы постоянно поддерживают, выпускают обновления и следят за этим. С самописным сайтом владелец остается один на один с этим решением и поддерживает его актуальность как может.

Наш дисклеймер: изначально выбор платформы не должен складываться только из критериев безопасности. Ни одна система не достаточно безопасна. Все можно взломать, это доказано взломом Пентагона. А Apple вообще готовы дать награду тому счастливчику, кто найдет уязвимости в их устройствах.

• Webit предоставляет услугу сканирования сайта на уязвимости. Специальным ПО мы прогоняем сайты наших клиентов и ищем бреши в безопасности. Эту процедуру обычно проводим раз в месяц-три. После проверки получаем список уязвимостей, которые появились за время работы над сайтом/период нахождения сайта у нас на поддержке.

Уязвимость может возникнуть не только по вине наших разработчиков, но и после загрузки контента клиентом. Также могут выйти новые исправления безопасности ПО, которые могут вызвать баги в безопасности.

Наша задача — донести до клиента, что нужно обновлять свой сайт, иначе в безопасности будет дыра. В прошлом году мы продвигали тему обновлений очень напористо, так как многие сайты ломали по вине владельцев сайта. Они были слишком ригидными в плане изменений ПО.

• Нужно работать только с сертифицированными разработчиками. Так выше шанс, что в вашем проекте будет меньше некачественного кода, который приведет к уязвимостям. При выборе программиста или агентства обращайте внимание на кейсы в портфолио, популярность и узнаваемость бренда, клиентов, с которыми они работали.
• Если же вы решили не обращаться к сторонним разработчикам, то не экономьте на своих. Не берите в качестве единственных подрядчиков вчерашних стажеров и студентов, так как качество кода и количество дыр будет соответствующим.
  
• Ставьте модули только из проверенных источников, чтобы точно знать, что они прошли модерацию.
  
• Пользователям Windows важно следить за тем, нет ли на их компьютерах вирусов. Бывает, что на сайт загружают контент с зараженного компьютера, тем самым вирус перетекает и на сайт.
  

Проверка сайтов на вирусы и контроль за безопасностью все равно не являются панацеей. В любой непонятной ситуации и при атаках стоит положиться на хороших разработчиков. Даже обновления стоит доверить программистам, так как они могут касаться основания проекта.