Определите, была ли атака SQL-инъекцией, путем анализа журналов доступа или HTTP-параметров. PHP сайты

0

Как и большинство программистов, я стараюсь максимально точно программировать свои приложения, но это мы знаем, что не гарантирует безопасность на 100%. Поэтому я считаю, что также целесообразно иметь методы мониторинга, если мы можем подвергнуться нападению. Так что это мой вопрос.

(Мои сайты сделаны с PHP и MySQL)

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

  • Анализ журналов доступа/ошибок. Кто-нибудь есть или знает сценарий, который адекватно анализирует журналы доступа (apache) для обнаружения возможных атак? И сообщите администратору автоматически со всеми подробностями.

  • Анализ параметров HTTP в реальном времени. Это будет скрипт, который анализирует в реальном времени содержимое, переданное GET/POSt, и уведомляет (например, по электронной почте) администратору веб-сайта

Например, я не очень разбираюсь в атаках SQLi, но я думаю, что это обычное для строк "SELECT", "UINON",... (Others?), Чтобы появляться в строках запроса и параметрах.

Таким образом, мы можем проанализировать атаку и посмотреть, удастся она или нет, а затем предпринять последующие действия.

Спасибо за внимание!

Отредактировано:

Я создал простую систему для анализа файлов доступа Apache access_log и передачи результатов по электронной почте. Что подробно описано в этом вопросе:
Linux bash для итерации файлов apache access_log и отправки почты

Кроме того, еще один использует AWK. Единственный ресурс, который я нашел, связан с этим:
https://www.unix.com/shell-programming-and-scripting/248420-sql-injection-detection.html
(Но я не смог сделать это в моем случае)

  • 0
    Хорошая новость: вы изобрели что-то, что стоит кучу денег. Плохая новость: другие тоже, и они делают кучу денег. :) Вы можете найти продукты для анализа журналов безопасности, а также среди многих смежных технологий есть RASP или WAF .
  • 0
    Меня постоянно «атакуют» подобным образом ... но я никогда не получаю потенциальных злоумышленников, потому что просто нет оправдания написанию кода, уязвимого для SQL-инъекций. Нулевой допуск для конкатенации / интерполяции строк в запросах, включая экранирование и дезинфекцию. Нулевой допуск для включения поддержки нескольких запросов. Всегда и везде используйте подготовленные операторы, и SQLi становится тем, о чем должны беспокоиться другие люди, а не вы. К настоящему моменту проблема должна была быть отнесена к академическим интересам.
Показать ещё 2 комментария
Теги:
security
sql-injection

2 ответа

2

О, парень.

Хорошо, с чего начать?

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

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

Прежде всего, не забудьте фильтровать переменные. Никогда не доверяйте всему, что приходит из браузера. ЭТО ВСЕ ПОДТВЕРЖДАЮ. Это означает фильтрацию всего, что считается супер-глобальным, GET POST, REQUEST и т.д. Я бы даже не доверял сессиям, честно говоря. Отфильтруйте все. Подробнее об этом можно узнать здесь: http://php.net/manual/en/function.filter-var.php

Что-то еще, о чем нужно подумать, это загрузка файлов. Плохие парни любят загружать файлы и захватывать ваш сервер. Наиболее распространенным методом является использование файлов, замаскированных под изображения. Вы захотите переделать все изображения, которые входят. GD Works, но мне нравится Imagick лучше, лично, больше вариантов. Подробнее об этом здесь: http://php.net/manual/en/book.imagick.php. Вы также захотите убедиться, что ваш сайт не может загружать изображения или любые другие типы файлов со страниц, которые вы явно не обозначают форму или загружают страницы. Вы были бы шокированы тем, как часто я вижу сайты, которые могут загружаться из индекса, это безумие.

Другой метод, который вы можете развернуть для этого, - это использовать ваш php ini для установки глобального include и открыть любой файл в массиве $ _FILES, который входит. Откройте первый миллион пробелов в файле и сканируйте его для зарезервированных слов PHP, и unix shell scripting. Если вы найдете его, убить загрузку, выйти или умереть, что бы вы там ни делали.

У Apache есть настройка для судебных журналов. Судебные журналы будут захватывать все материалы GET и POST, но проблема с ним и причина, по которой он не отображается по умолчанию, заключается в том, что ваш журнал становится большим и быстрым. Вы можете прочитать здесь: https://httpd.apache.org/docs/2.4/mod/mod_log_forensic.html

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

Но вы хотите проверить уязвимости SQL, особенно если вы пишете код с нуля. Есть несколько достаточно плагинов для Chrome, которые упрощают ручное тестирование.

Хакбар: https://chrome.google.com/webstore/detail/hackbar/ejljggkpbkchhfcplgpaegmbfhenekdc?utm_source=chrome-ntp-icon

HackTab: https://chrome.google.com/webstore/detail/hack-tab-web-security-tes/nipgnhajbnocidffkedmkbclbihbalag?utm_source=chrome-ntp-icon

Для Firefox есть скрипт https://addons.mozilla.org/en-US/firefox/addon/scrippy/?src=search

Надеюсь, это поможет. Удачи.

Поделиться
  • 0
    Sites that score well with SEO are more likely to be hacked than sites that do not. More users means more exposure. Большинство атак совершаются роботами, которые ищут все виды уязвимостей, информацию о веб-сайте и т. Д. Таким образом, все веб-сайты являются объективными, но мы можем использовать эти атаки в качестве аудита безопасности. Это мы ждем уведомлений и проверяем, что могло произойти в атаке. Большое спасибо за все эти замечания по безопасности. Без сомнения, имеет большое значение.
  • 0
    Право на. Спасибо.
0

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

Самая большая трата времени.

ЛЮБОЙ сайт получает "атакует" 100% времени. Есть свободно доступные сценарии, которые позволяют любому глупому школьнику сканировать весь интернет, случайно исследуя сайты. Вы будете скучать уже на следующий день после очистки этих журналов вашей системы обнаружения.

На вашем месте я бы инвестировал в защиту. Другие векторы, чем вы могли придумать. Для примера все недавние нарушения, которые я был свидетелем, были выполнены путем кражи паролей ftp, хранящихся на ПК для веб-мастеров. И я могу заверить вас, что существует гораздо больше векторов атак, чем тупое внедрение SQL. Это простейшая вещь для защиты от нее, с двумя простыми правилами:

  • Любой литерал переменных данных (т.е. Строка или число) должен быть заменен параметром, тогда как фактическое значение должно быть отправлено в запрос отдельно через процесс bind/execute.
  • Все остальные части запроса, которые добавляются через переменную, должны быть явно пропущены через жесткий список допустимых значений.
Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню