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

Question

[Дмитрий]

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

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

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

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

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

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

Если есть специалисты, то будьте добры — отпишите в личку.

Answer 1

[Вячеслав Плиско]

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

Answer 2

[Wott]

Открываем редактор и ищем $_REQUEST или $_GET или $_POST — где нашли там и уязвимость

Answer 3

[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];

Comments

[Алексей]

Правильный код в любом случае будет

$id = (int) $_REQUEST["xid"];

[Ajex]

Не всегда. Просто если не задан xid, $id будет равна нолю, что не всегда приемлемо. Проверка на существование переменной нужна, но в том контексте как приведено в оригинале, существует опасность того, что подсунут инъекцию.

[charon]

я бы так проверил:

$id = is_number($_REQUEST["xid"]) ? $_REQUEST["xid"] : false;

[charon]

ну а чтобы вообще суперстильно:

$id = filter_input(INPUT_GET, 'xid', FILTER_VALIDATE_INT);

PS: INPUT_REQUEST не бывает, придётся таки узнать каким методом данные попадают в скрипт

Answer 4

[lubezniy]

А что за хостинг? На них тоже дыры бывают.

Answer 5

[FloppyFormator]

Если это популярная CMS, разумно обновить её до последней версии. А если сайт самописный, то либо атакуют те, кто знает код, либо уязвимости действительно легко найти, и даже несложный аудит поможет выявить какое-то их количество.

Answer 6

[egorinsk]

Правильное, но невыгодное финансово решение: не нанимать быдлокодеров и переделать сайт.

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

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

Также, если вы умеете администрировать linux, можно на сервере засунуть веб-сервер и сервер БД в отдельные контейнеры и изолировать их (или даже selinux включить). Плюс зафаерволлить намертво. Это вообще идеальнй вариант — даже если ваш сайт представляет один большой бекдор, взломщик не сможет получить из него никакой выгоды. Если правильно настроить сервер, фаерволл и изоляцию, для написания кода можно нанимать хоть школьников.

Answer 7

[LuckyStarr]

Посмотрите Acunetix Web Vulnerability Scanner, есть Trial.

Answer 8

[Константин Биржаков]

Я тоже за ручной труд. Если вы разобрались в проблеме, просмотрите весь код на подобные штуки самостоятельно, как рекомендует Wott. Разумеется, раз программе оставит такие вещи в коде, там может быть все что угодно. Это раз. Если и еще одна стороны медали, о которой важно помнить. А именно – программер мог сделать бэкдор намеренно, и теперь он или его пособники этим пользуются. Аудит кода вам просто необходим, на сайт можно залить много всякой гадости, доказывай потом что это не ты уводишь гугл-аккаунты…

Answer 9

[mgyk]

Как временное решение попробуйте поставить mod_security в апаче www.modsecurity.org/projects/modsecurity. Проблему это не решит полностью, но закроет и будет логгировать очевидные дыры.

Answer 10

[Monaxxx]

Если заливают шеллы, проверити все формы с соответствующим тегом для заливки файлов

<input type="file" />

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

Но если это все накладно, адаптируйте какой нить движок (CMS,CMF,FW) под вашу базу, руководствуясь важность избавится об багов и затрат на адаптацию движка.

Answer 11

[Денис]

Вы можете сами пройтись по коду?

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

Для чисел (int)… или intval(...)
Для строк htmlspecialchars(..., ENT_QUOTES)

Answer 12

[Аноним Анонимов]

> Как найти все подобные ошибки на сайте?
Просматривать исходный код запросов, пробовать инъектить все скрипты по методологии OWASP, использовать готовые инструменты вроде sqlmap.

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