-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Alias и имя поля
- Автор темы kires
- Дата начала
alpine
Новичок
kires
Правила для обеспечения безопасности при работе с базой данных делятся на две группы:
Правила эти делятся на две группы.
1. Все значения полей, которые используются в запросе, дожны быть
- заключены в кавычки
- к ним должна быть применена функция mysql_real_escape_string()
2. Все остальные части запроса, которые меняются в зависимости от выбора пользователя, ни в коем случае не должны подставляться напрямую, а только в виде результатов вычислений.
То есть:
- Если параметр имеет строковый тип, то все возможные значения должны быть прописаны в скрипте заранее. И уже из них выбирается нужное на основании выбора пользователя.
- если параметр является числом, то обязан получаться в результате арифметического выражения.
К примеру, все поля, по которым производится сортировка, должны быть прописаны в массиве, индексами которого являются значения, которые выбирает пользователь.
Цифры для лимита должны быть результатом арифметического выражения, и так далее.
То есть, повторюсь - операторы SQL не должны ни в коем случае попадать в запрос напрямую, а могут только служить исходными данными для выражения, которое и вернёт нужный параметр. То есть, скрипт не должен их ПРОВЕРЯТЬ, и после проверки подставлять. В этом подходе изначально заложена ошибка. а должно быть именно только так, чтобы строка, переданная от пользователя, ни в каком виде не попадала в запрос ввиде оператора.
PS проведем небольшой эксперимент.
Правила для обеспечения безопасности при работе с базой данных делятся на две группы:
Правила эти делятся на две группы.
1. Все значения полей, которые используются в запросе, дожны быть
- заключены в кавычки
- к ним должна быть применена функция mysql_real_escape_string()
2. Все остальные части запроса, которые меняются в зависимости от выбора пользователя, ни в коем случае не должны подставляться напрямую, а только в виде результатов вычислений.
То есть:
- Если параметр имеет строковый тип, то все возможные значения должны быть прописаны в скрипте заранее. И уже из них выбирается нужное на основании выбора пользователя.
- если параметр является числом, то обязан получаться в результате арифметического выражения.
К примеру, все поля, по которым производится сортировка, должны быть прописаны в массиве, индексами которого являются значения, которые выбирает пользователь.
Цифры для лимита должны быть результатом арифметического выражения, и так далее.
То есть, повторюсь - операторы SQL не должны ни в коем случае попадать в запрос напрямую, а могут только служить исходными данными для выражения, которое и вернёт нужный параметр. То есть, скрипт не должен их ПРОВЕРЯТЬ, и после проверки подставлять. В этом подходе изначально заложена ошибка. а должно быть именно только так, чтобы строка, переданная от пользователя, ни в каком виде не попадала в запрос ввиде оператора.
PS проведем небольшой эксперимент.
kires
Новичок
в твоем примере отсортировать можно по номеру столбца, но идея примерно такая.
для наглядности вот что я хочу
1 столбец: имеет заголовок Поле1 а значения его <a href=http://bla-bla.ru/table.php?whre=field1&var=Знач1><b>Знач1</a>
2 столбец: имеет заголовок Поле2 а значения его <a href=http://bla-bla.ru/table.php?whre=field2&var=Знач2><b>Знач2</a>
тебе не кажется, что довольно глуповато сначала заголовки столбцов таблицы ЗАПИСЫВАТЬ в запрос, а потом их из запроса ДОСТАВАТЬ?
почему бы их не писать только один раз - там, где они нужны?
что значит - запросов несколько?
ты пишешь супер-функцию, которая тебе рисует хтмл-таблицу по запросу?
почему бы их не писать только один раз - там, где они нужны?
что значит - запросов несколько?
ты пишешь супер-функцию, которая тебе рисует хтмл-таблицу по запросу?