nevi
@nevi
old school internet worm

Как защитить сайт от SQL-инъекций? Атакуют, заливают шеллы и всякую гадость. Нужен сканер

Есть сайтик, добрый и для людей. Кому-то он помешал или в чем дело, не знаю, но повадились его «ломать». Дырок, видимо, в нем немало (а может и не много, кто знает), строили сайтик «молдоване-строители» с free-lance.ru которые толком работу-то не сделали, кое-как. Но как-то жил сайтик до поры до времени.

Один толковый знакомый подсказал одну страничку, где скрипт был уязвим для SQL-инъекций. Не было проверки на целочисленность параметра, передаваемого в GET-запросе. Вроде такого код:

if($_REQUEST[xid])
$id = $_REQUEST[xid];

Закрыл приведением к int.

Вопрос такой. Страничек оч много, порой кода очень много. Как найти все подобные ошибки на сайте? Существуют ли какие-то сканеры для поиска такого рода уязвимостей? Опасаюсь я, что это может быть далеко не единственный скрипт с такими «дырами».

Или как быть еще?

Если есть специалисты, то будьте добры — отпишите в личку.
  • Вопрос задан
  • 9299 просмотров
Пригласить эксперта
Ответы на вопрос 12
AmdY
@AmdY
PHP и прочие вебштучки
Для начала стоит начать с просмотра кода, в приведённом коде как минимум два нотиса в случае отсутствия переменной и использования константы вместо строки.
Вам нужен не сканер. а человек, который проведёт аудит кода. Он и инструмент подходящий знает и логические ошибки может выловить.
Ответ написан
Wott
@Wott
Открываем редактор и ищем $_REQUEST или $_GET или $_POST — где нашли там и уязвимость
Ответ написан
@Ajex
Все — никак. Самый лучший способ изначально организовать логику работы так, чтобы все обработка переменных происходила по одинаковым принципам во всех модулях.
Когда на каждой странице своя проверка, очень велика вероятность, что что-то забудете и пропустите.
Также, думаю, не само собой разумеющееся, что для обращения к БД не стоит работать напрямую, а использовать специальные фрейморки, в которых заложен дополнительный слой проверок. Например PDO или аналоги.
Для поиска уязвимостей есть специальные сканеры, например Acunetix, havij… вот тут неплохой обзор habrahabr.ru/post/125317/
Однако ни один сканер не найдет все уязвимости, ибо они могут быть совершенно не очевидными.

К примеру, даже если вы сюда воткнете проверку, это не защитит от уязвимости при включенных register_globals
if($_REQUEST[xid]) $id = (int)$_REQUEST[xid];
ибо переменную id можно просто передать в параметрах, а про xid просто напросто «забыть». Тогда в $id уже можно будет передать что угодно.
Т.е. правильный код в данном случае будет каким-то таким
if (!isset($_REQUEST[xid])) {die(); } $id = (int)$_REQUEST[xid];
Ответ написан
FloppyFormator
@FloppyFormator
Если это популярная CMS, разумно обновить её до последней версии. А если сайт самописный, то либо атакуют те, кто знает код, либо уязвимости действительно легко найти, и даже несложный аудит поможет выявить какое-то их количество.
Ответ написан
@egorinsk
Правильное, но невыгодное финансово решение: не нанимать быдлокодеров и переделать сайт.

Быстрое и дешевое решение: написать/прикрутить фильтр, который не будет пропускать запросы со словами SELECT, where, JOIN, UNION (в любом регистре), script, onload, onerror, onmouseover (и все остальные JS-события), object, applet, iframe, frame и так далее. Список слов ищите в интернете. Если ваши посетители, например. общаются на русском, очевидно, такие слова они вряд ли используют.

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

Также, если вы умеете администрировать linux, можно на сервере засунуть веб-сервер и сервер БД в отдельные контейнеры и изолировать их (или даже selinux включить). Плюс зафаерволлить намертво. Это вообще идеальнй вариант — даже если ваш сайт представляет один большой бекдор, взломщик не сможет получить из него никакой выгоды. Если правильно настроить сервер, фаерволл и изоляцию, для написания кода можно нанимать хоть школьников.
Ответ написан
KonstRuctor
@KonstRuctor
программист, дизайнер, фотограф, журналист
Я тоже за ручной труд. Если вы разобрались в проблеме, просмотрите весь код на подобные штуки самостоятельно, как рекомендует Wott. Разумеется, раз программе оставит такие вещи в коде, там может быть все что угодно. Это раз. Если и еще одна стороны медали, о которой важно помнить. А именно – программер мог сделать бэкдор намеренно, и теперь он или его пособники этим пользуются. Аудит кода вам просто необходим, на сайт можно залить много всякой гадости, доказывай потом что это не ты уводишь гугл-аккаунты…
Ответ написан
mgyk
@mgyk
Как временное решение попробуйте поставить mod_security в апаче www.modsecurity.org/projects/modsecurity. Проблему это не решит полностью, но закроет и будет логгировать очевидные дыры.
Ответ написан
@Monaxxx
Если заливают шеллы, проверити все формы с соответствующим тегом для заливки файлов

<input type="file" />

Посмотрите как там обрабатывается файл, если ли ограничения, если нет, по организуйте.
И потихонечку проверяйте файл за файлом, на входные данные и организуйте соответствующую обработку этих данных.

Но если это все накладно, адаптируйте какой нить движок (CMS,CMF,FW) под вашу базу, руководствуясь важность избавится об багов и затрат на адаптацию движка.
Ответ написан
newpdv
@newpdv
Web-devekioer
Вы можете сами пройтись по коду?

Ищите $_GET $_POST $_REQUEST и фильтруйте.

Для чисел (int)… или intval(...)
Для строк htmlspecialchars(..., ENT_QUOTES)
Ответ написан
> Как найти все подобные ошибки на сайте?
Просматривать исходный код запросов, пробовать инъектить все скрипты по методологии OWASP, использовать готовые инструменты вроде sqlmap.

> Существуют ли какие-то сканеры для поиска такого рода уязвимостей?
Да, существуют: acunetix.com, detectify.com, metascan.ru
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы