Защита от SQL инъекции

[FSA]

А зачем прямая валидация?
Без нее код будет небезопасным?

Теоретически да, но когда точно знаешь что тебе должно прилететь и это можно проверить, то лучше проверить. Ну например, если ожидаешь номер телефона, то можно лучше проверить, что то, что прилетело именно номер телефона.

 

[Фанат]

Теоретически да, но когда точно знаешь что тебе должно прилететь и это можно проверить, то лучше проверить. Ну например, если ожидаешь номер телефона, то можно лучше проверить, что то, что прилетело именно номер телефона.

А как такая проверка относится к защите от инъекций?

 

[FSA]

А как такая проверка относится к защите от инъекций?

Убедил Никак, просто привычка проверять.

 

[Vorobyov1996]

А зачем прямая валидация?
Без нее код будет небезопасным?

Расскажи как ты обеспечиваешь безопасность?

 

[Фанат]

Убедил Никак, просто привычка проверять.

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

Окей, допустим, про "Подготовленные выражения в PDO" я методом проб и ошибок выяснил, что код

$pdo->prepare("INSERT INTO t VALUES ($var)")->execute();

Ни от чего не защищает, хотя формально выражение и подготваливается.

И научился заменять переменные на плейсхолдеры. С этим ясно.

Но что делать вот с этим предложением про валидацию?
Допустим, у меня не номер телефона. Что мне делать, если я не знаю, как валидировать?
И вот какие мои действия в этом случае? Вариантов данных заведомо бесконечное количество, придумать валидацию для всех нереально.
И если эта валидация имеет отношение к безопасности, как ты говоришь, то получается что я пишу заведомо небезопасный код.

поэтому никогда не надо давать неконкретных советов, примерно как клиент выше - "надо искейпить". Что искейпить, как искейпить - история умалчивает.

Подготовленные выражения тем и хороши, что позволяют в КОНКРЕТНОЙ форме сформулировать правила защиты.

 

[HORO]

Подготовленные выражения тем и хороши, что позволяют в КОНКРЕТНОЙ форме сформулировать правила защиты.

что-то я не понял смыл этой фразы...
В общем-то то вся защита сводится к тому, чтобы не дать юзверю возможности изменять sql запрос...в принципе сделать это можно хоть регулярками, тобишь валидацией конкретной формы...

 

[Hello]

что-то я не понял смыл этой фразы...
В общем-то то вся защита сводится к тому, чтобы не дать юзверю возможности изменять sql запрос...в принципе сделать это можно хоть регулярками, тобишь валидацией конкретной формы...

Очень интересно посмотреть, как будет выглядеть регулярка для бинарных данных

 

[hell0w0rd]

Я не понимаю, что вы тут обсуждаете. Есть единственный правильный способ - данные передавать отдельно от запроса. Для этого есть подготовленные выражения, зачем еще что-то придумывать?

 

[HORO]

Очень интересно посмотреть, как будет выглядеть регулярка для бинарных данных

так они все бинарные )) но если я правильно понял, будет выглядет как экранирование

Я не понимаю, что вы тут обсуждаете. Есть единственный правильный способ - данные передавать отдельно от запроса. Для этого есть подготовленные выражения, зачем еще что-то придумывать?

я тоже. Но данные не передаются в СУБД отдельно от запроса )
И вообще, для начала проще делать array_map("mysqli_real_escape_string",$_POST) и все внуть кавычек пихать

 

[Adelf]

Как же меня бесит эта тупая аватарка и глупые посты, которые она пишет.

 

[Adelf]

@HORO, самое забавное, что ты сразу принял это на свой счет

 

[HORO]

удалил )

 

[Adelf]

@HORO, ну серьезно.

И вообще, для начала проще делать array_map("mysqli_real_escape_string",$_POST) и все внуть кавычек пихать

Ну глупость! Ты предлагаешь массив POST к mysql вообще никак изначально не относящийся, мапить через эту функцию! Просто у тебя нет представления о хорошем коде. И ты лезешь советовать. Постарайся сначала научиться. Тот же laravel о котором ты пишешь... ну хотя бы поглядеть документацию. Там примеры отстойные конечно, но все-равно лучше чем ты пишешь сейчас.

 

[HORO]

так и знал что дело в laravel ))) Чесное слово, нет ничего плохого в том, чтобы мапить $_POST. Ну или его часть, если весь не нужен. Это проще, понятнее, нагляднее и работает нативно

вообще никак изначально не относящийся

куда относящийся? это пример просто

Кстати, как в laravel вот это реализовано?

query("SELECT * FROM tbl WHERE 1".($foo?" AND bar='".mysqli_real_escape_string($bar)."'":""));

 

[Adelf]

@HORO, массив $_POST. Он вообще независимая вещь. Далеко не факт, что он целиком в MySQL пойдет. В нормальных приложениях он через слой бизнес-логики идет. А ты предлагаешь сразу его взять и испортить.

 

[HORO]

блин, да я ничего не предлагаю, я просто пример привел, $_POST нагляднее как бы - типо все данные от юзверя перед запросом экранируются...
и ничего не ломается, я же НЕ написал вот так
$_POST=array_map....

 

[AnrDaemon]

Не надо приводить таких примеров. Никогда.

 

[Adelf]

Кстати, как в laravel вот это реализовано?
query("SELECT * FROM tbl WHERE 1".($foo?" AND bar='".mysqli_real_escape_string($bar)."'":""));

$query = DB::table('tbl');

if($foo)
{
    $query->where('bar', $bar); // $bar экранировать не надо. Оно пойдет туда переменной запроса
}

foreach($query->get() as ...)

Я тебе еще раз настоятельно рекомендую ознакомиться как сделано в популярных решениях. Там весьма неглупые люди придумали удобные вещи.

P.S. https://laravel.com/docs/5.1/queries

 

[HORO]

и как ты прикрутил sql bulder к phpstorm database autocomplete? )
вообще имхо, юзать sql bulder это все равно что использовать smarty вместо native шаблонов

Я тебе еще раз настоятельно рекомендую ознакомиться как сделано в популярных решениях.

рекомендую ознакомиться как это сделано скажем в dbsimple

 

[Hello]

так они все бинарные )) но если я правильно понял, будет выглядет как экранирование

Вот нужно в БД записать публичный ключ, какая для него будет регулярка?