Ответы пользователя по тегу SQL-инъекции
  • Инъекция sql, по Вашему мнению лучшая защита?

    @FanatPHP
    Чебуратор тега PHP
    Правила очень простые

    1. Все данные подставляем в запрос только через плейсхолдеры
    2.идентификаторы и ключевые слова подставляем только из белого списка, прописанного в нашем коде.
    Ответ написан
  • Как выглядит и работает фильтрация PHP POST & GET?

    @FanatPHP
    Чебуратор тега PHP
    Как выглядит и работает фильтрация PHP POST & GET?

    Никак.
    Я понимаю, что это утверждение не укладывается голове у человека, изучавшего пхп по видеокурсам, но это факт.
    Сами по себе НТТР запросы POST & GET никакой угрозы не несут и как-то заранее фильтровать их не надо.

    Фильтровать вообще надо не по принципу "откуда", а по принципу "куда".
    Данные надо форматировать в зависимости от того, куда они пойдут, а не откуда они пришли. SQL запросу абсолтно фиолетово, откуда взялась кавычка в данных - из GET, файла на диске, или из другой базы данных. Данные для SQL надо правильно форматировать не потому что они пришли из GET, а потому что они идут в SQL.
    (При этом надо также понимать, что SQL запрос и база данных - это не одно и тоже. Базе тоже по барабану, что в ней лежит. Любое форматирование мы делаем только для SQL запроса, а в базе данные снова должны быть как есть).

    Я думал, что будут удаляться все кавычки и теги,а по факту они остаются.

    Если бы все думали, как ты, то ты бы не смог задать свой вопрос на Тостере. Потому что без кавычек и тегов он превратился бы в бессмыслицу. Как и куча любых других вопросов.
    Разумеется, "мусор" надо не удалять, а форматировать. Потому что это "мусор" только для SQL, а для человека это нужная информация, которая помогает читать текст.

    Не использовать же для этого регулярки?

    Нет, разумеется.
    Использовать регулярки будет так же глупо, как и твою функцию.

    Для того, чтобы поместить переменную в SQL запрос, надо использовать подстановки в подготовленных выражениях. Запомни это предложение. Оно важнее всего, что ты до сих пор успел узнать про пхп. Хорошоенько запомни, ты должен это знать лучше, чем зовут маму с папой. И никогда не отступать от этого правила. Не важно - нужна тебе защита от SQL инъекций или не нужна, из POST-а ли пришли данные, или Господь бог тебе их надиктовал на горе Синайской - все равно всегда и везде только через подстановки.

    Поэтому.
    1. Выкидываешь свою функцию на помойку. Единственное слово, которое там имеет там хоть какой-то смысл - это trim(). Ну так ты можешь вызывать её напрямую.
    2. Судя по уровню кода и вопроса, для работы с бд ты используешь убогую mysqli. Поэтому забудь вообще про mysqli_query(), а все запросы, в которых используется хотя бы одна переменная, выполняешь только так
    $stmt = $conn->prepare("INSERT INTO tablitsa (login_name,email) VALUES (?,?)");
    $stmt->bind_param("ss", $login, $email);
    $stmt->execute();

    Подробнее можешь почитать в интернете.
    3. При выводе пользовательских данных в HTML, используешь функцию htmlspecialchars(). Надеюсь, к этому моменту ты уже понял главную мысль - важно не откуда пришли данные, а куда. Идут в хтмл? Отлично, форматируем их для хтмл.
    Ответ написан
  • MySQL. В чем разница функций?

    @FanatPHP
    Чебуратор тега PHP
    Разница очень простая.

    Функция mysqli_real_scape_string не предназначена для защиты против возможных sql-инъекций. И применять ее в таком качестве - прямой путь заполучить инъекцию.
    В то время как одно из назначений функции mysqli_stmt_bind_param - это предотвращение sql-инъекций, поэтому применять её для этой цели можно и нужно.
    Ответ написан
  • Что почитать по составлению безопасных sql запросов?

    @FanatPHP
    Чебуратор тега PHP
    Базовые принципы на то и базовые, что не меняются со временем. Я бы только переформулировал немного по-другому,
    • Данные подставляем в запрос только через плейсхолдеры
    • Все остальное - только после проверки через белые списки

    И еще бы добавил что эти правила должны соблюдаться безусловно, в 100% процентов случаев, без рассуждений типа "вот эти данные у нас безопасны, их можно не защищать".

    Если же говорить о тенденциях, то с чистым SQL сейчас никто практически не работает. 95% запросов выполняются через ORM. Т.е. вместо
    $stmt = $pdo->prepare("SELECT * FROM user where id = ?");
    $stmt->execute([$id]);
    $user = $stmt->fetch();

    пишем просто
    $user = User::find($id);
    при этом защита уже вшита у ORM внутри и думать о ней не надо

    Ну а если надо сделать более сложный запрос, то опять же, есть развитые Квери билдеры, у которых защита также уже встроена. И только в редчайших случаях нужно писать чистый SQL, и только тогда нужно вспоминать про ручную защиту от инъекций.
    Ответ написан
  • Имеет ли смысл фильтровать пользовательский ввод для предупреждения SQL-инъекций?

    @FanatPHP
    Чебуратор тега PHP
    Нет.

    Всякие идеи о подобной "фильтрации" следует выкинуть навсегда из головы.

    Апдейт.
    Ну вот, учитывая PS, мы получаем, что первый вопрос ("для предупреждения инъекций") уже не имеет смысла. остается "алерт в админке". поверь мне - твои розовые фантазии о работе сайтов не имеют ничего общего с действительностью. Малолетние придурки бомбардируют сайты на предмет тупых уязвимостей постоянно. Один набор шаблонов поиска phpmyadmin состоит из сотни паттернов. Твой "алерт" на посещаемом сайте будет верещать постоянно. И без МАЛЕЙШЕГО смысла.
    Ответ написан
  • Поможет ли такой php-код защититься от sql-инъекций и XSS, какие в нём есть уязвимости?

    @FanatPHP
    Чебуратор тега PHP
    Все что делает этот идиотский код - это портит входящие данные.
    Я даже не знаю, стоит ли объяснять. Ведь 100500 раз уже объясняли.

    Но самый, конечно ад - это ответы.

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

    Тем, кто предлагает отрезать кавычки от quote, надо самим что-нибудь отрезать.

    И это неловкое чувство, когда 2015 году слышишь самую заветную мантру мадагаскарских гамадрилов: "mysql_real_escape_string зашышает от ынъекцый!". Стоит, блин, такой "устаревший", но еще крепкий архангел с пылающим мечом, и разит супостата прямо в темечко - вот так представляет себе принцип работы этой функции средний пользователь похапе.
    Ответ написан
  • Какие статьи читать о применении sql inj в контексте php?

    @FanatPHP
    Чебуратор тега PHP
    Что вопрос, что ответы - ад.
    Ресурс движется в правильном направлении.
    Ответ написан