Здравствуйте! Изучаю безопасность. Я так понял, что проблемы могут возникнуть в трех случаях: 1) В БД могут отправить вредный код через форму на сайте (если она есть). 2) Через адресную строку могут в массиве GET отправить что нибудь... 3) Взломать сервер и наделать дел на сервере и в том числе с нашим сайтом (это проблемы сервера). Я прав или что то упустил?
А разве этот вопрос в раздел php? Упустил, во-первых 1) и 2) не очень корректно разделены. Через форму запрос можно отправить не только ПОСТ но и ГЕТ. Пункт 2) я бы отдельно вообще не выносил. А как насчёт отправить данные собственным скриптом (не обязательно даже на ПХП). И Чтобы ничего не упустить, просто посмотрите на существующие виды уязвимостей. Их там не 3, а побольше будет. Ваша классификация "взломать сервер и наделать дел" - как то уж чересчур широко звучит. А первыми двумя пунктами нельзя разве взломать и наделать? --- Добавлено --- И если уж указали "взломать сервер", то где в этих пунктах находятся атаки на клиент? Через форму можно ломать как сервер, так и атаковать клиента, внедряя например активный XSS --- Добавлено --- В общем классификация неверна в принципе
Если отправляем данные собственным скриптом, то как этот скрипт обрабатывается если, допустим, нет файла обработчика или же в файле обработчике используются конкретные значения переменных а все остальное игнорируется? --- Добавлено --- Вот сколько смотрю классификацию уязвимостей, везде каша, все в кучу и ничего конкретного. --- Добавлено --- Давайте разберем по полочкам все?
Почему это нет файла обработчика? Мы ведь в скрипте указываем путь к этому файлу и указываем метод ГЕТ или ПОСТ. А ещё можем вручную определить любые заголовки, куки и т.д. Если там используются "конкретные значения переменных" - то это уже какие-то ваши фильтры. А значит, и через форму и тот же юрл что-то внедрить будет сложнее (не только через скрипт) или даже невозможно.
Ну да, отправляю данные через форму, функцией удаляю все тэги и т.п. - по идее угроз с этой стороны никаких больше нет?
ну смотря что вы имеете в виду под "и.т.п.". Где-то на форуме я уже встречал каких методов достаточно, а каких недостаточно для того, чтобы обеспечить безопасность при получении скриптом данных. Даже кажется были ссылки на классы собственного производства, которые "чистят" входные данные. --- Добавлено --- Если вы сейчас пытаетесь самостоятельно обеспечить безопасность своего ресурса, то вам нужно брать и разбираться в каждой уязвимости по уже давно существующим классификациям и согласно им закрывать все дыры. Все зависит от того как и на чем постороен ваш ресурс, имеется в виду: 1) полностью рукописный код 2) с применением фреймворка 3) с применением CMS. Первый случай наиболее уязвим.
Стоп более уязвим CMS, а потом уже остальное. На CMS базы делают уязвимостей где любой может зайти и читать. Далее рукописный код может быть на фреймворке или без. В этом случае если не допустили часто встречаемые ошибки. То более устойчивее будет. Так как боты проходятся по спискам и фиксируют. Для защиты формы и обработчика, попробуй использовать _csrf. Далее уже остаются уязвимости которые будут выявлены при прямой атаке, тоесть когда у человека есть цель ломануть именно твой сайт.
Да ладно, а в рукописном варианте без фреймворка разве не сможет просто зайти и читать? В CMS используемые плагины/модули/компоненты уже имеют какие-то проверки (хоть и возможно с дырами). А в рукописном варианте эти проверки ещё нужно написать. И если человек делает это впервые, как похоже и есть в данном случае, то я сомневаюсь, что он обеспечит большую защищённость приложения, чем та, что уже есть в CMS.
Я говорю о том что сайт с CMS попробуют ломать раньше чем сайт на прямую. и чаше будет подвергаться взломам. Вот даже пример приведу. Имею N порядок серверов и сайтов на обслуживание. Стоят свои стучалки, разные фичи, где то даже инкапсула. Каждый день я получаю на почту хорошую кучу алертов о попытках взлома. Так вот все идет по этапно. 1)Прогоняют сайт на определение какая cms на сайте. Собирают список. 2)По собраному списку уже прогоняют уязвимости для самого движка ->список 2.1)Прогоняют еще по уязвимым плагинам, есть они нету, если такой плагин есть(даже если не уязвим, но раньше был) -> в список 3)Уже по списку 2 спискам выше (2, 2.1) прогоняют на сами уязвимости, + на уязвимости git. 4)В итоге имеют базу уязвимых сайтов и делают свои дела. В случае Если самопис, на 1 из выше пунктов идет облом и сайт не попадает в список. Конечно если боту не сказали сканируй все post get формы, запросы. И то если ты их защитил хоть как то, уже в список не попадаешь. Значит остается цельно-направленная атака, я не говорю о том что не взломают, я говорю о том что шансов быть не замеченным больше. А если проект уже крупный что "хорошие" люди обратили на вас внимание, тут уже нужен специалист в разработке. Во блин мини-курс по взлому. защите сайта, хотя для многих это не секрет.
Ну это все в общих чертах. Давайте разберем только метод ПОСТ и ГЕТ. В чем здесь может быть проблема? Только в том, что через форму могут отправить код, который вставится в базу, и при выводе из базы на страничку этот код сработает и что то сделает. Я так понимаю в случае с этими методами больше нет никаких проблем, только то, что код сохранится в БД!?
Описанный вами кейс - это всего-лишь пример активного xss. Кроме него есть ещё много всего, что можно сделать при помощи той же формы. Например, sql-иньекция. Она не сохраняется в бд, но может вытащить из нее данные, или повредить их. Теоретически можно через форму даже выполнить php-код. Это RCE уязвимость. Я же написал выше, почитайте классификацию уязвимостей. Все эти вопросы отпадут само собой (и появятся новые)
sql-иньекция может навредить в том случае, если передаваемые данные как то попадают в БД, либо записываются, либо сравниваются с другими данными из БД. Ну а если принял я логин и пароль, затем никуда эти данные не вставляя вытащил из БД другие логины и пароли и сравниваю их, что может произойти в этом случае? Кто нибудь может написать простой пример как иньекция может вытащить данные из БД или повредить их?
Давайте конкретный пример формы с конкретным примером запроса, через который скрипт обращается к бд. А вообще, если вы только читаете данные из бд, то вы их не можете повредить. Но возможность стащить данные - это тоже уязвимость.
Во блин... Вы понимаете, что то, как можно стащить напрямую зависит от конкретной реализации php-кода и самого запроса? Давайте свой скрипт, который общается с базой. --- Добавлено --- В общих чертах напишу, дальше сами: 1) узнать имя текущей бд: database() 2) затем вы можете запихнуть инъекцию, которая из базы information_schema для уже известной бд вытащит все имена ваших таблиц 3) зная имя таблицы через information_schema узнаете имена всех ее столбцов 4) зная столбец читаете его содержимое, например логины и пароли. В некоторых случаях нужно применять group_concat(). Все это можно делать как через форму, так и через юрл. Дальше вам нужно загуглить и почитать по крайней мере инфу о тех функциях, которые я указал. Это одна из реализаций, все зависит от ситуации.
Код (Text): <?php session_start(); include './user/connect.php'; include './func/connect_select.php'; if (isset($_POST['nameRed']) && isset($_POST['passRed']) && isset($_POST['subRed']) && $_POST['subRed'] == 'Вход') { $name = strip_tags($_POST['nameRed']); // Удаляет все NULL-байты, HTML и PHP теги $name = str_replace(' ', '', $name); // Удаляет все пробелы $pass = strip_tags($_POST['passRed']); $pass = str_replace(' ', '', $pass); if ($name == '' || $pass == '') { header('Location: ./redactor.php?err=1'); // Одно или оба поля пустые exit; } else { $name = htmlspecialchars($name, ENT_QUOTES); // Форматируем спецсимволы $pass = htmlspecialchars($pass, ENT_QUOTES); } } else { header('Location: ./redactor.php?err=2'); // Ошибка - в массиве POST нет необходимых ключей, вход выполнен не верно exit; } $connect_table = 'redactor'; // Таблица в БД для соединения $connect_page = 'redactor'; // Страница на которую переадресует в случае отсутствия соединения $result = &connect_select($connect_table, $connect_page = 'error', $host, $user, $password, $name_bd); // func/connect_select.php $data = mysqli_fetch_assoc($result); do { if ($data['name'] == $name && $data['password'] == $pass) { $_SESSION['tableRed'] = $data['tableRed']; $_SESSION['name'] = $name; header('Location: ./loader.php'); exit; } } while ($data = mysqli_fetch_assoc($result)); header('Location: ./redactor.php?err=4'); // Имя или пароль не совпадают ?> --- Добавлено --- Как в моем этом говно-коде можно что то сделать?
Тоже самое - ежедневно десятки попыток. Я почти не разбираюсь в хакерстве. Кроме детектирования CMS и стандартные попытки взлома, есть роботы которые пытаются залогинеться или зарегистрироваться (туповато, но всё же). Суть в том, что все подобные запросы приходят с разных ИП (т.е. IP динамические). Хотелось бы знать: Это универсальный ботнет или специализированный ботнет только для моего сайта? Или просто специфичные вирусы шалят? Или ещё что? А по поводу, что более уязвим, CMS или свой код, то полностью согласен, - если высококласный разраб, то свой код надёжнее; если нормальный, то примерно одинаково; если начинающий, то CMS надёжнее.
Специально под ваш сайт, на этот вопрос не могу ответить, так как не знаю историю сайта и его популярности. Думаю что универсальным прогоняют и все.Уж то что он там присутствует это 100% =)
Я тоже так подумал, ибо популярность сайта у плинтуса. Просто хотелось подтверждения догадки. Спасибо.
А я просто порой открываю ацесс-лог, где процентов 70 записей - это бот-долбежка по несуществующим CMS админкам и плагинам, вздыхаю, закрываю. Вот чесслово, освободится время, натравлю fail2ban на это дело. Пусть выпиливает заразу эту. Пф...пф...ПФАХХАХАХАХАХАХАХА. Могу. Через "только читающий гет-запрос" залить вполне себе настоящий php-шелл на сайт, и через него уже что угодно сделать вообще. Как? Если коротко: 1) SELECT мускуля это не функция для выборки только из таблиц. Это функция направления данных на вывод. Запрос, к примеру, PHP: select "ухнихренасебе" from users limit 1,0; Абсолютно валидный. И прекрасно отработает. Текст, разумеется, может быть любой, включая php-код. 2) У селекта есть замечательная директива "into outfile", которая как бы говорит "выведи содержимое результата выборки в файл такой-то". 3) 1+2 = шелл. Но в 95% случаев это будут китайские айпишники. И в ssh тоже китайцы долбятся нонстоп вообще. Но, как сменил порт, перестали долбиться. Это эдакий ботохакерский природный фон в сети. Они даже не сканят порты. Они просто перебирают все айпишники и стучатся на 22 и 80 порты. Где отвечает 80й, начинают простукивать админки.
Да. Как таковую безопасность это не повышает, конечно. Кому надо, тот насканит ssh моментально, но от фонового шума спасает прям на раз.
А если на сайте нету формы и никакие данные не отправляются на сервер, то какие варианты взломать сайт есть?
Дырки в софте на сервере Не корректная конфига приложений. Кривой код на пр. LFI, RMI Дохрена всего может быть...