Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757

Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Форумы портала PHP.SU :: Версия для печати :: вопрос по mysqli_stmt_bind_param
Форумы портала PHP.SU » » Вопросы новичков » вопрос по mysqli_stmt_bind_param

Страниц (3): [1] 2 3 »
 

1. arimanecro - 30 Сентября, 2014 - 12:45:41 - перейти к сообщению
Я так и не понял, в чем выражается безопасность данной функции?

Вот мой пример:

PHP:
скопировать код в буфер обмена
  1.  
  2. if(isset($_POST['login'])) {
  3.         $login = $_POST['login'];
  4.         $query = "INSERT INTO users(login) VALUES (?)";
  5.  
  6. if (!$stmt = mysqli_prepare($connection, $query))
  7. echo 'false';
  8. mysqli_stmt_bind_param($stmt, "s", $login);
  9. echo 'true';
  10.  


если я введу в переменную логина
CODE (javascript):
скопировать код в буфер обмена
  1. <script>alert('test');</script>
, то он его выведит как скрипт, тоже самое и с хтмл тэгами.
Из этого следует, что переменные по любому надо обрабатывать mysqli_escape_real_string, так тогда какой смысл mysqli_stmt_bind_param? Какую безопасность данная функция, тогда обеспечивает?
2. DelphinPRO - 30 Сентября, 2014 - 12:49:58 - перейти к сообщению
mysqli_escape_real_string не спасет тебя от XSS. также запишется html код.
3. arimanecro - 30 Сентября, 2014 - 12:59:00 - перейти к сообщению
хорошо, пускай переменные будут пропущены через strip_tags, htmlentities e.t.c
Если эти ф-ии справляются с XSS, тогда в чем смысл mysqli_stmt_bind_param?
4. DelphinPRO - 30 Сентября, 2014 - 15:03:36 - перейти к сообщению
arimanecro пишет:
Если эти ф-ии справляются с XSS, тогда в чем смысл mysqli_stmt_bind_param?

Как будто у хакеров только XSS на вооружении Улыбка

Данная функция привязывает переменную к параметрам подготовленного запроса.
При этом вы указываете тип переменной, и ее значение будет соответствующим образом экранировано в запросе, что исключит возможность атаки типа "SQL-injection".
(Добавление)
Кроме того, подготовленные запросы выгодно использовать при выполнении одного и того же запроса несколько раз с разными входными данными. Один раз привязали переменную потом в цикле меняете ее и выполняете запросы. (ну это так, грубый пример).
5. arimanecro - 30 Сентября, 2014 - 15:46:46 - перейти к сообщению
Цитата:
Данная функция привязывает переменную к параметрам подготовленного запроса.


эээ...не совсем понял? а что, переменная может и не привязаться как-то? Улыбка

и второй вопрос...если я использовал, например для логина функцию htmlentities, то уже нет смысла в догонку использовать mysqli_escape_real_string? ведь они обе экранируют кавычки и тогда в mysqli_escape_real_string нет надобности? Смущён
6. DelphinPRO - 30 Сентября, 2014 - 17:21:00 - перейти к сообщению
arimanecro пишет:
эээ...не совсем понял? а что, переменная может и не привязаться как-то?

Да, бывают переменные сами по себе, свои собственные (с)

Даю вам ссылку на официальный мануал по php - http://ru2.php.net/manual/ru/index.php
Там есть ответы на ваши вопросы. В том числе, какие функции что экранируют
7. arimanecro - 01 Октября, 2014 - 09:29:37 - перейти к сообщению
Цитата:
Даю вам ссылку на официальный мануал по php


Ну никада бы там не догадался искать ответы Улыбка

Если человек спрашивает на форуме, значит ему непонятно разяснение офиц.источников
8. Мелкий - 01 Октября, 2014 - 09:47:05 - перейти к сообщению
arimanecro пишет:
в чем выражается безопасность данной функции?

В том, что mysql никогда не перепутает, где запрос, а где данные. Ни для каких входных данных не перепутает.
Потому что данные в запрос не подставляются вообще, они и на уровне пакетов данных идут отдельно от запроса.

При чём тут XSS и прочие дыры, не имеющие никакого отношения к СУБД - я не понимаю.
Обратиться к базе, используя внешние данные - используйте препарированные запросы и никогда не конкатенируйте данные и запрос.
Надо вывести в HTML - используйте htmlspecialchars
Надо вывести в JS - json_encode
Надо вывести в CSV - используйте подобающую обработку данных, fputcsv.
Надо вывести ещё черти-куда - используйте то, что для этого черти-куда предназначено.
9. arimanecro - 02 Октября, 2014 - 16:28:33 - перейти к сообщению
Более ли менее разобрался Закатив глазки

но после обработки mysqli_escape_real_string, в БД заносится слэш O\'ireally.
Сразу говорю, у меня версия 5.4, поэтому магические кавычки как бы не причем Ниндзя
10. Sail - 02 Октября, 2014 - 16:33:39 - перейти к сообщению
arimanecro пишет:
в БД заносится слэш O\'ireally

htmlentities() поможет в этой беде.
11. Мелкий - 02 Октября, 2014 - 16:58:29 - перейти к сообщению
arimanecro пишет:
но после обработки mysqli_escape_real_string, в БД заносится слэш O\'ireally.

Т.е. вы используете препарированный запрос и escape? Зачем?
12. arimanecro - 02 Октября, 2014 - 17:27:38 - перейти к сообщению
Цитата:
htmlentities() поможет в этой беде.


а при чем тут это?
ну будет у меня в БД вместо слэша O&#092ireally

Цитата:
Т.е. вы используете препарированный запрос и escape? Зачем?


эээ..ну да? а что препарированный запрос разве ещё и экранирует?

Я заношу в БД, способом который предлагает курс Специалиста(думаю все его смотрели или хотя бы слышали), а именно, создается функция для обработки переменных post:

function clear_str($var) {
global $connection;
return mysqli_real_escape_string($connection, strip_tags(trim($var)));
}

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

$query = "INSERT INTO users (name, username, password, email) VALUES(?, ?, ?, ?)";
if(!$stmt = mysqli_prepare($connection, $query))
echo 'error prepare';
mysqli_stmt_bind_param($stmt, 'ssss', $name, $login, $pass, $email);
mysqli_stmt_execute($stmt);
mysqli_stmt_close($stmt);

Только он(преподаватель) при занесении в БД не использует нигде в названиях кавычки, поэтому и не спалил видимо эту ошибку
13. MiksIr - 02 Октября, 2014 - 17:35:15 - перейти к сообщению
Экранирование нужно, что бы парсер строки всего SQL запроса в базе данных определил - где строчка данных внутри строки SQL заканчивается.
В случае биндинга это и так понятно, ибо строчка данных передается отдельно, а значит никакое экранирование не нужно.
14. Мелкий - 02 Октября, 2014 - 17:38:54 - перейти к сообщению
arimanecro пишет:
а что препарированный запрос разве ещё и экранирует?

Вы понимаете, для чего экранирование вообще нужно?

Так вот, препарированный запрос данные в текст запроса не подставляет вообще. Они даже бинарно на СУБД идут отдельно. Что передали, именно то СУБД и получила, без риска заблудиться, что тут было текстом запроса, а что - данными.
15. arimanecro - 02 Октября, 2014 - 17:51:07 - перейти к сообщению
MiksIr, Мелкий -- спасибо за разъяснение, хоть и туманно, но более ли менее понятно...

Цитата:
Вы понимаете, для чего экранирование вообще нужно?


вроде понимаю Улыбка

1) для того, чтобы кавычка была действительно символом кавычки, а не хтмл сущностью
2) для выполнения роли SQL-инъекции

==========

Убрал из ф-ии mysqli_real_escape_string, оставив только return strip_tags(trim($var)); и все нормально заработало.

Вытекает след.вопрос: если препарированный запрос так удобен и безопасен, то почему не откажутся от mysqli_real_escape_string?

 

Powered by ExBB FM 1.0 RC1