Безопасность сайта на текущий момент является довольно серьезной задачей как для владельцев Интернет-ресурса, так и для его разработчиков. По мере роста популярности всемирной паутины, его применение существенно расширилось. Помимо поиска информации, в нем также осуществляется общение между людьми, шоппинг, развлечения, исследовательская деятельность и многое другое. Проверки уязвимостей позволяют предотвратить распространение вредоносных программ и спама, что дает возможность обезопасить пользователей от негативного воздействия.
При этом, важно понимать, что от угрозы взлома не защищен никто от крупных межнациональных ресурсов до небольших локальных блогов. Это приводит к необходимости принятия определенных мер для обеспечения защиты, как своих личных данных, так и конфиденциальной информации, оборот которой необходим для нормального функционирования сервиса.
У злоумышленников существует множество способов взлома веб-сайтов для размещения на них вредоносного ПО, необходимого, для хищения конфиденциальных сведений или уничтожения важной для функционирования сайта информации.
Многие пользователи считают, что их веб-ресурс настолько мал, что никто не станет даже пытаться его взломать. Какой смысл, если есть более «крупная рыба»? Однако, такая мысль – это заблуждение, причем весьма опасное.
В виду того, что многие владельцы веб-сайтов, не обращали внимание на обеспечение актуальной защиты, многие интернет-ресурсы оказались под угрозой взлома. Причем, речь идет не о мелочах, которые решаются простой заменой пароля. Уровень угроз куда выше и может нанести непоправимый вред инфраструктуре портала и его непосредственным пользователям.
Среди наиболее существенных опасностей стоит выделить:
· Внесение вредного кода в тело сайта, который в скрытом режиме заражает устройства пользователей ПО. Зачастую найти и удалить его после внедрения бывает крайне сложно.
· Порча критических страниц или замещение их на нелегальные сайты с запрещенным контентом.
· Потеря опубликованных на веб-портале материалов.
· Кража конфиденциальной информации владельца и/или пользователей веб-ресурса с целью несанкционированного использования или перепродажи. Наиболее часто это касается платежных данных от банковских карт, логинов, паролей и паспортных данных, которые необходимы для совершения ряда транзакций.
· Получение доступа к иным интернет-сайтам, расположенным на том же физическом сервере.
· Блокировка интернет-сайта в сео-системах Google при обнаружении вредоносных программ в коде. Это ведет к существенному снижению трафика, проходящего через портал, а также падение количества уникальных посетителей.
· Изменение данных администратора, что исключает возможность доступа к управлению и редактированию ресурсов
1. Сайт dentistway.ru
Задача
При попытке отправить заявку со страницы (https://dentistway.ru/about/) ничего не заполнив получаем 500 ошибку сервера. Это ошибка на серверной стороне, что не очень хорошо, но что хуже в ответе выдаются подробности:
Скрываем подробный путь, которую выдает сервер при получении ошибки, чтобы злоумышленник не имел представление об использующихся компонентах на сайте, и не знал путь от корня до хостинга.
2. Сайт afmikrokredit.ru
2.1. Задача
Репозиторий Git не закрыт от прямого доступа с браузера. По-хорошему на при попытке доступа с браузера на /.git/* надо отдавать 403. На скрине безобидная попытка посмотреть доступен ли вообще Git по http.
Видим, что он доступен. Это проблема, потому что существуют инструменты, позволяющие в такой конфигурации выкачать Git репозиторий - это даст злоумышленнику возможность заполучить исходный код. А это в лучшем случае предоставит ему white box для дальнейших атак, в худшем ещё и даст логины-пароли
Решение
Настроили при попытке доступа с браузера на /.git/* отдавать код 403
2.2. Задача
Заход по ip http://5.200.48.91/ (от личного кабинета https://pay.aksf.ru/) от личного кабинета показывает только что настроеный Nginx.
Заход по https://pay.aksf.ru/robots.txt показывает довольно старую версию nginx (nginx/1.14.0 (Ubuntu)). Это создаёт впечталение слабой настройки серверной части софта, это может спровоцировать злоумышленника к дальнейшим исследованиям уязвимостей и взлому.
Решение
Была обновлена версия Nginx, также после срыто из доступы просмотре версии Nginx
3. Сайт avtokach.ru
Задача
На странице «заказ сформирован» присутствует XSS уязвимость.
В данном примере, при переходе по ссылке в алерте отобразятся куки пользователя. Настоящий злоумышленник бы не отображал их, а переслал себе - значений кук session, u_id достаточно, чтобы авторизоваться под пользователем. Это уязвимость XSS. XSS позволяет злоумышленнику выполнять произвольный js код в браузере пользователя, перешедшего по ссылке.
Решение
Был проведен комплекс мер, по предотвращению XSS уязвимость
· Настроены фильтры и экранизация параметров входа, вводимых через формы авторизации.
· Отрегулирована автозамена специальных символов, чтобы разграничить обычный текст от кода.
· На страницах помещена кодировка перед полями посетителей.
· Настроены ограничения домена и возможности приёма cookie-файлов с помощью протокола SSL и атрибута HttpOnly.
4. Сайт belydom.ru
Задача
На странице https://belydom.ru/personal/change-password/? Присутствует уязвимость.
В форму выводятся скрытыми остальные поля пользователя, не предназначенные для редактирования. Изменил логин и почту. При отправке формы изменения сохранились. Для иллюстрации проблемы были поменяны почта и логин с «bostin.laike@meshfor.com» на
«bostin.laike_changed_login@meshfor.com». злоумышленник бы переименовывал бы в что-то связанное с почтой сайта. С учётом того, что при регистрации происходит авторизация без проверки почты это не большая проблема. Большая проблема может быть, если удастся аналогичным образом поменять ID пользователя - в самом страшном случае так можно угнать учётную запись дефолтного администратора Битрикса
Решение
При регистрации была добавлена обязательная проверка почты
5. Сайт bright-life.ru
Задача
Был создан новый пользователь с почтой fesqhuawgygqvmfqtn@cazlg.com — тут же авторизовало, без перехода по ссылке из письма. Был проосмотрен личный кабинет. После этого — проверка доступа в админку Wordpress /wp-admin/. По ссылке был открыт доступ, и более того, была предложена возможность обновить базу данных.
Отсутствие контроля за пользователями является существенной проблемой
Решение
Был настроен контроль доступа пользователей в админ-панель сайта.
6. Сайт composit-tech.ru
Задача
На многих страницах сайта был доступен шаблон с правилами для разработчиков в публичном доступе. Правила для разработчиков не должны быть в публичном неавторизованном доступе. Правильно было бы или убрать, или хотя бы закрыть за авторизацией. Публично доступная информация для разработчиков создаёт образ сайта без квалифицированного разработчика, что может сподвигнуть злоумышленников на поиск и эксплуатацию уязвимостей
Решение
Публично доступная информация для разработчиков была скрыта за авторизацией, и более недоступна для открытого доступа.