Сегодня в этой статье мы расскажем, как хакеры проверяют, можно ли взломать ваш сайт.
«Memento mori» в переводе с латыни означает «Помни, что ты смертен». Согласно традиции, эту фразу нашептывали торжествующим римским военачальникам на парадах, чтобы напомнить им, что они по-прежнему склонны ошибаться.
В наши дни, возможно, следует обновить традицию, шепча «вас собираются взломать» в уши администраторам веб-сайтов. Это может быть необходимо, чтобы напомнить им, что независимо от того, какие средства защиты они устанавливают, хакеры всегда ищут новые способы взлома сайтов.
Но какие методы используют хакеры? Ниже мы более подробно рассмотрим, как хакеры веб-сайтов могут атаковать уязвимости на стороне клиента, на стороне сервера или напрямую.
Недостатки безопасности на стороне сервера [Как хакеры проверяют, не взломан ли ваш сайт]
Помимо фишинга и связанных с ним атак на администраторов, хакеры часто пытаются определить тип веб-сервера (например, Tomcat), программное обеспечение веб-сервера (например, node.js) и операционную систему сервера. Это можно сделать, изучив такие факторы, как общий интеллект (например, из комментариев в социальных сетях и технических сайтах), имена сеансовых файлов cookie, исходный код веб-сайта и многое другое.
Как только серверная технология определена, хакеры могут использовать различные методы для использования незакрытых уязвимостей. Небезопасные настройки сервера, такие как небезопасные конфигурации сервера по умолчанию, неограниченный доступ к папкам сервера и открытые порты, использовались для взлома сайтов.
Хакеры часто проверяют небезопасные конфигурации сервера по умолчанию, например, оставляя учетные данные по умолчанию активными. Инструменты сканирования, такие как Grayhat Warfare, часто используются хакерами для поиска содержимого корзины Amazon S3 с небезопасной конфигурацией.
Хакеры могут легко получить открытые порты с помощью инструментов сканирования портов, а после их обнаружения можно использовать различные уязвимости.
Точно так же средства поиска файлов могут найти административные инструменты, к которым можно получить доступ со слабыми паролями или вообще без паролей. Неадекватные ограничения на загрузку файлов в папки сервера также являются благом для хакеров, позволяя им загружать и запускать вредоносное ПО.
Недостатки безопасности на стороне клиента.
Общие уязвимости на стороне клиента включают в себя:
- SQL-инъекция: вставка операторов SQL в запросы, что приводит к несанкционированному выпуску данных или изменению записей базы данных.
- XSS: внедрение вредоносного кода
- CSRF: захват сеанса пользователя
Проект веб-приложений OWASP Top Ten определил, что атаки путем внедрения являются типом угроз номер один.
У хакеров есть легкодоступные инструменты для автоматического тестирования веб-сайтов на наличие этих уязвимостей таким же образом, как и законное пентестирование. Однако в наши дни было бы очень удивительно и небрежно, если бы веб-сайт не имел достаточной защиты от SQL-инъекций и атак CSRF. Однако XSS продолжает создавать угрозы по мере появления новых уязвимостей, особенно по мере того, как веб-сайты (в том числе встроенные в мобильные приложения) становятся более функциональными и сложными. После обнаружения уязвимость может быть быстро использована на сайтах, которые не исправили ее.
Фреймворки и киберугрозы
Нынешняя практика веб-разработки с сильной зависимостью от библиотек с открытым исходным кодом, плагинов и фреймворков является богатым источником уязвимостей, которые могут использовать хакеры. Хакеры прикладывают гораздо больше усилий для исследования уязвимостей библиотек, чем обычный веб-разработчик, и эти ошибки часто обнаруживаются только после того, как они были использованы для успешных взломов.
Распространение серверного JavaScript и усложнение библиотек и фреймворков означает рост числа таких типов эксплойтов. Это часто бывает с открытым исходным кодом, разработка которого прекращена; это означает, что обновления недоступны, а сайты, которые продолжают их использовать, остаются незащищенными.
API и киберугрозы
Веб-сайты, которые используют API для связи с серверными системами, могут быть нацелены на эти API хакерами. В этом случае хакеры будут искать слабую безопасность API, например учетные данные, коды доступа или токены, доступные из строк запроса, переменных и других источников.
Хакеры также будут пытаться получить информацию о внутренней архитектуре системы на основе API, преднамеренно вызывая API с недопустимыми параметрами и отслеживая полученные сообщения об ошибках на предмет утечек информации о системе. Эта информация может быть практически любой, например тип базы данных и конфигурация. Вся эта информация может пригодиться позже, когда появится новая уязвимость.
Прямые кибератаки и токены
Помимо общих попыток взлома клиентских и серверных систем, распространены прямые атаки на учетные записи пользователей и администраторов. В настоящее время хакеры сосредотачиваются на использовании учетных данных (паролей) больше, чем на атаках грубой силы при аутентификации имени пользователя и пароля, а также на попытках манипулировать или повторно использовать токены доступа.
С 61 миллиардом попыток ввода учетных данных за 18 месяцев до июня 2019 года этот метод атаки становится популярным. Вброс учетных данных включает в себя автоматические попытки входа в систему с использованием имен пользователей (или адресов электронной почты) и паролей, полученных в результате взлома на стороне сервера, чтобы попытаться получить доступ к учетным записям пользователей или администраторов.
Маркеры доступа, часто выдаваемые через OAuth2 или OpenID Connect (OIDC), необходимы в современной веб-среде, поскольку они авторизуют запросы на ресурсы, такие как данные учетной записи пользователя, API и другие ресурсы. Эта вездесущность дает хакерам еще одну главную цель — как мы видели, например, во взломе Facebook в 2018 году.
Эти токены чаще всего имеют форму веб-токенов JSON (JWT). Хакеры будут искать уязвимости, такие как XSS, которые позволяют украсть токены из файлов cookie, локального хранилища и переменных JavaScript. Поскольку большинство этих токенов являются носителями, хакеру несложно использовать их после кражи, по крайней мере, до истечения срока их действия.
Точно так же хакеры также попытаются использовать небезопасную обработку подписей токенов, чтобы изменить права доступа к токенам, время истечения срока действия и т. д., не аннулируя подпись. Один простой метод, который пробуют хакеры, — изменить значение алгоритма подписи, хранящееся в заголовке JWT, на «none». В небезопасной реализации код проверки подписи будет игнорировать подпись токена, а это означает, что изменения в содержимом токена не будут пропущены.
Одна последняя мысль
Современная разработка веб-приложений и тактика фишинга открыли возможности для атак настолько, что веб-сайты и веб-приложения очень уязвимы в бесчисленных точках входа.
Но последнее замечание: точно так же, как белки, хакеры думают не так, как вы, и у них нет ограничений на то, что они могут попробовать. Если их попытки приводят к сбою сайта или уничтожению базы данных, для них это не проблема. Если вы думаете, что проверили свой веб-сайт на наличие уязвимостей, вам все равно нужно быть осторожным.
Читайте так-же наши другие статьи!
Продержать автора:
2200 7302 5516 8326