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

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

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

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

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

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

Не лучше ли выбрать самописные сайты?

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

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

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

Лайфхаки от Webit

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

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

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

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

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