За последние 24 часа нас посетили 9254 программиста и 424 робота. Сейчас ищут 117 программистов ...

Вопрос по безопасности

Тема в разделе "Прочее", создана пользователем Атм_Евгений, 13 сен 2017.

  1. Атм_Евгений

    Атм_Евгений Новичок

    С нами с:
    21 июл 2017
    Сообщения:
    104
    Симпатии:
    4
    Здравствуйте!
    Изучаю безопасность. Я так понял, что проблемы могут возникнуть в трех случаях:
    1) В БД могут отправить вредный код через форму на сайте (если она есть).
    2) Через адресную строку могут в массиве GET отправить что нибудь...
    3) Взломать сервер и наделать дел на сервере и в том числе с нашим сайтом (это проблемы сервера).
    Я прав или что то упустил?
     
  2. Сереганек

    Сереганек Новичок

    С нами с:
    18 янв 2017
    Сообщения:
    141
    Симпатии:
    17
    А разве этот вопрос в раздел php? Упустил, во-первых 1) и 2) не очень корректно разделены. Через форму запрос можно отправить не только ПОСТ но и ГЕТ. Пункт 2) я бы отдельно вообще не выносил. А как насчёт отправить данные собственным скриптом (не обязательно даже на ПХП). И
    Чтобы ничего не упустить, просто посмотрите на существующие виды уязвимостей. Их там не 3, а побольше будет. Ваша классификация "взломать сервер и наделать дел" - как то уж чересчур широко звучит. А первыми двумя пунктами нельзя разве взломать и наделать?
    --- Добавлено ---
    И если уж указали "взломать сервер", то где в этих пунктах находятся атаки на клиент? Через форму можно ломать как сервер, так и атаковать клиента, внедряя например активный XSS
    --- Добавлено ---
    В общем классификация неверна в принципе
     
    Fell-x27 нравится это.
  3. Атм_Евгений

    Атм_Евгений Новичок

    С нами с:
    21 июл 2017
    Сообщения:
    104
    Симпатии:
    4
    Если отправляем данные собственным скриптом, то как этот скрипт обрабатывается если, допустим, нет файла обработчика или же в файле обработчике используются конкретные значения переменных а все остальное игнорируется?
    --- Добавлено ---
    Вот сколько смотрю классификацию уязвимостей, везде каша, все в кучу и ничего конкретного.
    --- Добавлено ---
    Давайте разберем по полочкам все?
     
  4. Сереганек

    Сереганек Новичок

    С нами с:
    18 янв 2017
    Сообщения:
    141
    Симпатии:
    17
    Почему это нет файла обработчика? Мы ведь в скрипте указываем путь к этому файлу и указываем метод ГЕТ или ПОСТ. А ещё можем вручную определить любые заголовки, куки и т.д. Если там используются "конкретные значения переменных" - то это уже какие-то ваши фильтры. А значит, и через форму и тот же юрл что-то внедрить будет сложнее (не только через скрипт) или даже невозможно.
     
  5. Атм_Евгений

    Атм_Евгений Новичок

    С нами с:
    21 июл 2017
    Сообщения:
    104
    Симпатии:
    4
    Ну да, отправляю данные через форму, функцией удаляю все тэги и т.п. - по идее угроз с этой стороны никаких больше нет?
     
  6. Сереганек

    Сереганек Новичок

    С нами с:
    18 янв 2017
    Сообщения:
    141
    Симпатии:
    17
    ну смотря что вы имеете в виду под "и.т.п.". Где-то на форуме я уже встречал каких методов достаточно, а каких недостаточно для того, чтобы обеспечить безопасность при получении скриптом данных. Даже кажется были ссылки на классы собственного производства, которые "чистят" входные данные.
    --- Добавлено ---
    Если вы сейчас пытаетесь самостоятельно обеспечить безопасность своего ресурса, то вам нужно брать и разбираться в каждой уязвимости по уже давно существующим классификациям и согласно им закрывать все дыры. Все зависит от того как и на чем постороен ваш ресурс, имеется в виду: 1) полностью рукописный код 2) с применением фреймворка 3) с применением CMS. Первый случай наиболее уязвим.
     
  7. xaker01

    xaker01 Новичок

    С нами с:
    16 апр 2016
    Сообщения:
    166
    Симпатии:
    28
    Стоп более уязвим CMS, а потом уже остальное. На CMS базы делают уязвимостей где любой может зайти и читать.

    Далее рукописный код может быть на фреймворке или без.
    В этом случае если не допустили часто встречаемые ошибки.
    То более устойчивее будет. Так как боты проходятся по спискам и фиксируют.

    Для защиты формы и обработчика, попробуй использовать _csrf.
    Далее уже остаются уязвимости которые будут выявлены при прямой атаке, тоесть когда у человека есть цель ломануть именно твой сайт.
     
  8. Сереганек

    Сереганек Новичок

    С нами с:
    18 янв 2017
    Сообщения:
    141
    Симпатии:
    17
    Да ладно, а в рукописном варианте без фреймворка разве не сможет просто зайти и читать? В CMS используемые плагины/модули/компоненты уже имеют какие-то проверки (хоть и возможно с дырами). А в рукописном варианте эти проверки ещё нужно написать. И если человек делает это впервые, как похоже и есть в данном случае, то я сомневаюсь, что он обеспечит большую защищённость приложения, чем та, что уже есть в CMS.
     
  9. xaker01

    xaker01 Новичок

    С нами с:
    16 апр 2016
    Сообщения:
    166
    Симпатии:
    28
    Я говорю о том что сайт с CMS попробуют ломать раньше чем сайт на прямую. и чаше будет подвергаться взломам.
    Вот даже пример приведу.
    Имею N порядок серверов и сайтов на обслуживание.
    Стоят свои стучалки, разные фичи, где то даже инкапсула.
    Каждый день я получаю на почту хорошую кучу алертов о попытках взлома.
    Так вот все идет по этапно.
    1)Прогоняют сайт на определение какая cms на сайте. Собирают список.
    2)По собраному списку уже прогоняют уязвимости для самого движка ->список
    2.1)Прогоняют еще по уязвимым плагинам, есть они нету, если такой плагин есть(даже если не уязвим, но раньше был) -> в список
    3)Уже по списку 2 спискам выше (2, 2.1) прогоняют на сами уязвимости, + на уязвимости git.
    4)В итоге имеют базу уязвимых сайтов и делают свои дела.

    В случае Если самопис, на 1 из выше пунктов идет облом и сайт не попадает в список.
    Конечно если боту не сказали сканируй все post get формы, запросы. И то если ты их защитил хоть как то, уже в список не попадаешь.

    Значит остается цельно-направленная атака, я не говорю о том что не взломают, я говорю о том что шансов быть не замеченным больше.
    А если проект уже крупный что "хорошие" люди обратили на вас внимание, тут уже нужен специалист в разработке.

    Во блин мини-курс по взлому. защите сайта, хотя для многих это не секрет.
     
    Сереганек нравится это.
  10. Атм_Евгений

    Атм_Евгений Новичок

    С нами с:
    21 июл 2017
    Сообщения:
    104
    Симпатии:
    4
    Ну это все в общих чертах.

    Давайте разберем только метод ПОСТ и ГЕТ.
    В чем здесь может быть проблема? Только в том, что через форму могут отправить код, который вставится в базу, и при выводе из базы на страничку этот код сработает и что то сделает. Я так понимаю в случае с этими методами больше нет никаких проблем, только то, что код сохранится в БД!?
     
  11. Сереганек

    Сереганек Новичок

    С нами с:
    18 янв 2017
    Сообщения:
    141
    Симпатии:
    17
    Описанный вами кейс - это всего-лишь пример активного xss. Кроме него есть ещё много всего, что можно сделать при помощи той же формы. Например, sql-иньекция. Она не сохраняется в бд, но может вытащить из нее данные, или повредить их. Теоретически можно через форму даже выполнить php-код. Это RCE уязвимость. Я же написал выше, почитайте классификацию уязвимостей. Все эти вопросы отпадут само собой (и появятся новые) :)
     
  12. Атм_Евгений

    Атм_Евгений Новичок

    С нами с:
    21 июл 2017
    Сообщения:
    104
    Симпатии:
    4
    sql-иньекция может навредить в том случае, если передаваемые данные как то попадают в БД, либо записываются, либо сравниваются с другими данными из БД. Ну а если принял я логин и пароль, затем никуда эти данные не вставляя вытащил из БД другие логины и пароли и сравниваю их, что может произойти в этом случае?
    Кто нибудь может написать простой пример как иньекция может вытащить данные из БД или повредить их?
     
  13. Сереганек

    Сереганек Новичок

    С нами с:
    18 янв 2017
    Сообщения:
    141
    Симпатии:
    17
    Давайте конкретный пример формы с конкретным примером запроса, через который скрипт обращается к бд. А вообще, если вы только читаете данные из бд, то вы их не можете повредить. Но возможность стащить данные - это тоже уязвимость.
     
  14. Атм_Евгений

    Атм_Евгений Новичок

    С нами с:
    21 июл 2017
    Сообщения:
    104
    Симпатии:
    4
    Только читаем и не записываем.
    Как можно стащить?
     
  15. Сереганек

    Сереганек Новичок

    С нами с:
    18 янв 2017
    Сообщения:
    141
    Симпатии:
    17
    Во блин... Вы понимаете, что то, как можно стащить напрямую зависит от конкретной реализации php-кода и самого запроса? Давайте свой скрипт, который общается с базой.
    --- Добавлено ---
    В общих чертах напишу, дальше сами:
    1) узнать имя текущей бд: database()
    2) затем вы можете запихнуть инъекцию, которая из базы information_schema для уже известной бд вытащит все имена ваших таблиц
    3) зная имя таблицы через information_schema узнаете имена всех ее столбцов
    4) зная столбец читаете его содержимое, например логины и пароли. В некоторых случаях нужно применять group_concat().
    Все это можно делать как через форму, так и через юрл.
    Дальше вам нужно загуглить и почитать по крайней мере инфу о тех функциях, которые я указал. Это одна из реализаций, все зависит от ситуации.
     
  16. Атм_Евгений

    Атм_Евгений Новичок

    С нами с:
    21 июл 2017
    Сообщения:
    104
    Симпатии:
    4
    Код (Text):
    1. <?php
    2. session_start();
    3. include './user/connect.php';
    4. include './func/connect_select.php';
    5.  
    6. if (isset($_POST['nameRed']) && isset($_POST['passRed']) && isset($_POST['subRed']) && $_POST['subRed'] == 'Вход') {
    7.     $name = strip_tags($_POST['nameRed']); // Удаляет все NULL-байты, HTML и PHP теги
    8.     $name = str_replace(' ', '', $name); // Удаляет все пробелы
    9.     $pass = strip_tags($_POST['passRed']);
    10.     $pass = str_replace(' ', '', $pass);
    11.     if ($name == '' || $pass == '') {
    12.         header('Location: ./redactor.php?err=1'); // Одно или оба поля пустые
    13.         exit;
    14.     }
    15.     else {
    16.         $name = htmlspecialchars($name, ENT_QUOTES); // Форматируем спецсимволы
    17.         $pass = htmlspecialchars($pass, ENT_QUOTES);
    18.     }
    19. }
    20. else {
    21.     header('Location: ./redactor.php?err=2'); // Ошибка - в массиве POST нет необходимых ключей, вход выполнен не верно
    22.     exit;
    23. }
    24. $connect_table = 'redactor'; // Таблица в БД для соединения
    25. $connect_page = 'redactor'; // Страница на которую переадресует в случае отсутствия соединения
    26. $result = &connect_select($connect_table, $connect_page = 'error', $host, $user, $password, $name_bd); // func/connect_select.php
    27. $data = mysqli_fetch_assoc($result);
    28. do {
    29.     if ($data['name'] == $name && $data['password'] == $pass) {
    30.         $_SESSION['tableRed'] = $data['tableRed'];
    31.         $_SESSION['name'] = $name;
    32.         header('Location: ./loader.php');
    33.         exit;
    34.     }
    35. } while ($data = mysqli_fetch_assoc($result));
    36. header('Location: ./redactor.php?err=4'); // Имя или пароль не совпадают
    37.  
    38. ?>
    --- Добавлено ---
    Как в моем этом говно-коде можно что то сделать?
     
  17. Chushkin

    Chushkin Активный пользователь

    С нами с:
    17 дек 2010
    Сообщения:
    880
    Симпатии:
    56
    Адрес:
    Мещёра, Центр, Болото N3
    Тоже самое - ежедневно десятки попыток. :(

    Я почти не разбираюсь в хакерстве.
    Кроме детектирования CMS и стандартные попытки взлома, есть роботы которые пытаются залогинеться или зарегистрироваться (туповато, но всё же). Суть в том, что все подобные запросы приходят с разных ИП (т.е. IP динамические).
    Хотелось бы знать:
    Это универсальный ботнет или специализированный ботнет только для моего сайта?
    Или просто специфичные вирусы шалят?
    Или ещё что?


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

    xaker01 Новичок

    С нами с:
    16 апр 2016
    Сообщения:
    166
    Симпатии:
    28
    Специально под ваш сайт, на этот вопрос не могу ответить, так как не знаю историю сайта и его популярности.
    Думаю что универсальным прогоняют и все.Уж то что он там присутствует это 100% =)
     
  19. Chushkin

    Chushkin Активный пользователь

    С нами с:
    17 дек 2010
    Сообщения:
    880
    Симпатии:
    56
    Адрес:
    Мещёра, Центр, Болото N3
    Я тоже так подумал, ибо популярность сайта у плинтуса. Просто хотелось подтверждения догадки. Спасибо.
     
  20. Fell-x27

    Fell-x27 Суперстар
    Команда форума Модератор

    С нами с:
    25 июл 2013
    Сообщения:
    10.328
    Симпатии:
    1.225
    Адрес:
    :сердА
    А я просто порой открываю ацесс-лог, где процентов 70 записей - это бот-долбежка по несуществующим CMS админкам и плагинам, вздыхаю, закрываю. Вот чесслово, освободится время, натравлю fail2ban на это дело. Пусть выпиливает заразу эту.
    Пф...пф...ПФАХХАХАХАХАХАХАХА. Могу. Через "только читающий гет-запрос" залить вполне себе настоящий php-шелл на сайт, и через него уже что угодно сделать вообще. Как? Если коротко:
    1) SELECT мускуля это не функция для выборки только из таблиц. Это функция направления данных на вывод.
    Запрос, к примеру,
    PHP:
    1. select "ухнихренасебе" from users limit 1,0;
    Абсолютно валидный. И прекрасно отработает. Текст, разумеется, может быть любой, включая php-код.
    2) У селекта есть замечательная директива "into outfile", которая как бы говорит "выведи содержимое результата выборки в файл такой-то".
    3) 1+2 = шелл.
    Но в 95% случаев это будут китайские айпишники. И в ssh тоже китайцы долбятся нонстоп вообще. Но, как сменил порт, перестали долбиться. Это эдакий ботохакерский природный фон в сети. Они даже не сканят порты. Они просто перебирают все айпишники и стучатся на 22 и 80 порты. Где отвечает 80й, начинают простукивать админки.
     
  21. xaker01

    xaker01 Новичок

    С нами с:
    16 апр 2016
    Сообщения:
    166
    Симпатии:
    28
    Верно тоже меняю порты по возможности) Нагрузка на сервер сразу падает =D
     
  22. Fell-x27

    Fell-x27 Суперстар
    Команда форума Модератор

    С нами с:
    25 июл 2013
    Сообщения:
    10.328
    Симпатии:
    1.225
    Адрес:
    :сердА
    Да. Как таковую безопасность это не повышает, конечно. Кому надо, тот насканит ssh моментально, но от фонового шума спасает прям на раз.
     
  23. Атм_Евгений

    Атм_Евгений Новичок

    С нами с:
    21 июл 2017
    Сообщения:
    104
    Симпатии:
    4
    А если на сайте нету формы и никакие данные не отправляются на сервер, то какие варианты взломать сайт есть?
     
  24. Познающий php

    Познающий php Новичок

    С нами с:
    23 мар 2017
    Сообщения:
    314
    Симпатии:
    63
    Если никакие данные на сервер не отправляются, то нахер тебе вообще php? генерировать html?
     
  25. smitt

    smitt Старожил

    С нами с:
    3 янв 2012
    Сообщения:
    2.934
    Симпатии:
    39
    Дырки в софте на сервере:)
    Не корректная конфига приложений. Кривой код на пр. LFI, RMI
    Дохрена всего может быть...