|
| |
|
|
| |
для: tvv123456
(25.02.2010 в 00:25)
| | | А вот, кстати, пример уязвимости, придумал:
<?php
$a = " \\";
$b = ", b = (SELECT password FROM users WHERE user_id = 1) WHERE id = 2/*";
$sql = "UPDATE table SET a = '{$a}', b = '{$b}' WHERE id = 1";
echo $sql;
?>
|
UPDATE table SET a = ' \', b = ', b = (SELECT password FROM users WHERE user_id = 1) WHERE id = 2/*' WHERE id = 1
|
Обе строки, как предполагается, передаются от пользователя. Они обе вообще не содержат апострофов, но уязвимость есть.
Но это чисто ради интереса, опять же. Уязвимости -- лишь побочный эффект от неправильной обработки данных, притом не единственный. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(25.02.2010 в 12:59)
| | | Так я и говорю "залепил по привычке" - камень преткновения.
Кроме того, я с некоторых про отвергаю сам термин "экранированные данные" .
Данные, в моем представлении могут быть либо сырыми, либо оформленными в виде литеральной строки. То, что во втором случае придется заняться экранированием - вторично. | |
| |
|
|
| |
|
|
| |
для: Trianon
(25.02.2010 в 11:41)
| | | >Если да - она возникнет, когда определение этой функции изменят.
Дело не в этом, синоним или нет. Я использую обертку, кто то нет - не суть.
Дело в чем там было - обнаружилась дырка в одном скрипте, меня попросили посмотреть. Функция была довольно внушительна и вот такое
<?
$value = "'". mysql_real_escape_string($value) ."'";
|
стояло в начале. А запрос в конце.
А автор при обработке тупо пропустил одну переменную.
Я и не заметил этих строк в начале функции. А так как точно знал, что данные в одно из полей попадают неэранированными, залепил в запросе всем строковым полям по привычке тоже самое. Подумав что обработки нет вовсе. В результате то поле, которое было дырявым, стало работать нормально. А остальные нет, так как там оказались экранированные бэкслэши.
И самое обидное, что это не синтаксическая ошибка - её хватились спустя некоторое время.
По этому я и сказал, что уютнее это делать в самом запросе, а не отдельно. | |
| |
|
|
| |
|
|
| |
для: Николай2357
(24.02.2010 в 18:39)
| | | Я не это имел ввиду, а это:
<?
"...... = '". s_slash($value) ."'......."
s_slash - синоним mysql_real_escape_string() ?
Если нет - дыра налицо.
Если да - она возникнет, когда определение этой функции изменят. | |
| |
|
|
| |
|
|
| |
для: tvv123456
(25.02.2010 в 00:25)
| | | Для начала, раз в базе торчат бэкслэши, прочитайте внимательно этот топик. В самом начале есть про магические кавычки - наверняка они у Вас включены.
Отключите их.
Потом попробуйте выполнить запрос с обработкой (не фильтрацией!!!!!! это не тот термин) литеральных констант (проще строковыхъ значений) функцией mysql_real_escape_string().
И посмотрите, что будет находиться в базе.
Надеюсь пропадет желание извращать изобретать то, что сто лет как придумано. | |
| |
|
|
| |
|
|
| |
для: Trianon
(24.02.2010 в 23:48)
| | | там что-то с амерсандом было
а вчем зедсь проблема?
Ну правда
Я вообще ничего не шарю в php обьясните пожалуйста | |
| |
|
|
| |
|
|
| |
для: Trianon
(24.02.2010 в 23:48)
| | | реально ребята а какая здесь уязвимость
смотрела 21 задачу
но все-таки у tvv123456 вроде свежий взгляд на решение проблемы | |
| |
|
|
| |
|
|
| |
для: tvv123456
(24.02.2010 в 23:29)
| | | Где дыра, можно понаблюдать, решая задачу 21, придуманную специально для этого. | |
| |
|
|
| |
|
|
| |
для: Тень&
(24.02.2010 в 23:36)
| | | Вы тут уже говорите об XSS? действительно сложно понять
Ну как я понял заэкранируете вы весь запрос и попытаетесь там вставить свой и пото мзакрыть апостроф но ведь с этого(о боже ) будет ошибочка. | |
| |
|
|
| |
|
|
| |
для: tvv123456
(24.02.2010 в 23:29)
| | | А даже если бы и не было дыры, то что? Допустим на секунду, что можно обрушить запрос (хоть явной уязвимости тут не наблюдается), если подставить в конец бекслеш. Ну и что? Ты тут же найдёшь HTML-представление бекслеша -- и вуаля. Опять вроде бы всё работает. Ты так и будешь переводить все "опасные" (о боже) символы в их HTML-представления. То есть вместо SQL-экранирования ты подставляешь просто HTML-экранированную строку. Задумайся как тебе "повезло": HTML-представление вида { не содержит ни одного "опасного" (о боже) символа.
Так и поступай. Вперед. Все учатся на ошибках. | |
| |
|
|
|
