SQL Injection - приведение типов излишне, есть кавычки

[xbs]

SQL Injection - приведение типов излишне, есть кавычки

Что еще нужно против SQL инъекции, кроме кавычек и mysqli_escape_string()?

Пример:
$query = "select ...... where id = '" . mysqli_escape_string($dbhandler, $id) . '";

Почему, когда поднимают эту тему, всегда вспоминают про приведение типов? Ну, будет там в запросе: SELECT * FROM users WHERE id='62\' or 1=1', таки что? mysql5 его выполнит, а если какой старый mysql не выполнит, так не велика беда

 

[Alexandre]

я делаю так

$query = "select ...... where id = '" . (int)$id;

 

[Фанат]

$query = "select ...... where id = 25 LIMIT '" . mysqli_escape_string($dbhandler, $id) . '";
и выполни этот запрос

-~{}~ 26.05.09 19:38:

а если какой старый mysql не выполнит, так не велика беда

с какой это радости не выполнит?

 

[xbs]

Автор оригинала: vovanium
Я у себя по логам вижу, как часто всякие кулхацкеры пытаются ввести левые данные, зачем для таких людей пытаться правильно вывести контент, их контент в принципе не интересует, раз они вводят всякую фигню

Выходит у тебя логи по HTTP запросам, если ты фильтруешь хаки приведением типов и такие SQL запросы у тебя не появляются и не светятся?
Но раз кавычки и mysqli_escape_string() уже позволяют избежать инъекции, разве в этом нет преимущества, если ты можешь в одном месте (напр., в функции, где происходит mysqli_escape_string()) ОПЕРАТИВНО локализовывать инъекцию, вычислить хакера, подать сигнал и принять меры с нарушителем спокойствия.
Тебе не надо заниматься этим со всеми данными пришедшими от пользователя, или же выборочно с данными, которые предназначены для БД. Этот момент находиться в одном месте и приведение типов портит его.

-~{}~ 27.05.09 04:46:

*****
Насчет того, что помещать в LIMIT, согласен. Данные для работы с выборкой формируются отдельно. Главный вопрос, есть ли какие-либо проблемы с тем, что я описал, когда кроме кавычек и mysqli_escape_string() больше ничего не используется (там где обращения к непосредственным данным БД)?

 

[zerkms]

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

 

[xbs]

Автор оригинала: vovanium
xbs

Интересно как ты что-то оперативно найдешь, если ты тупо все запросы отправляешь в БД.

Я уже написал в том посте, например, в функции, которая занимается фильтрацией данных можно установить флаг проблемного SQL запроса, позже, когда он будет сформирован, его протоколируешь.

Автор оригинала: vovanium
xbs
Вот в этом главная ошибка, проверять нужно все что пришло от пользователя

1. У тебя всегда появляются данные, которые не нужно загружать в БД, к ним применяется другая стратегия защиты.
2. Мой код будет только в одном месте, он будет связан исключительно с проблемными данными, которые помещаются в БД

 

[Фанат]

xbs

Но раз кавычки и mysqli_escape_string() уже позволяют избежать инъекции,

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

Насчет того, что помещать в LIMIT, согласен. Данные для работы с выборкой формируются отдельно.

Не понял. А $id - не данные? Откуда я знаю, что у тебя там отдельно готовится. Ты задал вопрос - я на него ответил.

есть ли какие-либо проблемы с тем, что я описал, когда кроме кавычек и mysqli_escape_string() больше ничего не используется

не понял. о чем речь? приведи пример того, что используется кроме.

-~{}~ 27.05.09 16:45:

Я извиняюсь, но все-таки вынес обсуждение проверять-не проверять в отдельную тему
http://phpclub.ru/talk/showthread.php?s=&threadid=114609

 

[xbs]

Я пришел к выводу, делать так.
Приведение к типу происходит в getter'ax u setter'ax.
public function getLoggedIn() {
return (bool)$this->is_logged_in;
}

public function setLoggedIn($is_logged_in) {
$this->is_logged_in = (bool)$is_logged_in;
}

Все обращения внутри класса к свойствам через getter u setter, включая SQL

От кавычек для числовых данных отказываюсь: .... where id = " . $this->getId();
Кавычки для идентификаторов - это типа фича mysql, которой не существует в общепринятом стандарте SQL?

 

[dimagolov]

xbs, а зачем у тебя 2 раза преобразование? в начале в setLoggedIn, а потом в getLoggedIn?

ты для каждой переменной делаешь пару getter/setter?

 

[Фанат]

кавычки для идентификаторов здесь мимо кассы.

 

[dimagolov]

кавычки для идентификаторов здесь мимо кассы.

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

 

[Фанат]

да какая разница, что он там тулит.

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

 

[dimagolov]

а у операторов и вовсе никаких кавычек нет.

он очевидно имел в виду пользовательские идентификаторы

 

[Фанат]

ну а я о чем? операторы-то тоже пользовательские бывают