Последняя активность
SQL инъекцияПревед уважаемые!
Вот у меня такой вопрос по уязвимостям.
Знает ли кто, можно ли пробить на SQL инъекцию при добавлении в базу, если данные обрабатываются mysql_real_escape_string()
Я пока не нашел путей обхода, но если кто-то знает пример, буду очень благодарен за информацию.
| zick [Off] [#] (27.03.2008 / 22:42)
|
Хм, у меня такой функции в мануале нет..
Я знаю, что реалэскейп не экранирует знак процента % и поэтому нужно быть осторожным с фильтрацией в запросах с оператором LIKE, но в остальных случаях, инъекция невозможна.
З.Ы.
Или я ошибаюсь? гг
Пример, я добавляю в базу текст:
$text = $_POST['text'];
$text = mysql_real_escape_string($text);
mysql_query("insert into `mytable` set `text`='" . $text . "';");
Уязвить базу при таком добавлении невозможно.
| Esi0n [Off] [#] (27.03.2008 / 23:30)
|
Вово таже фигня, тока не база, а табличка НЕ открываецо, не удаляеццо, не чистицо 0_о
| Gemorroj [Off] [#] (28.03.2008 / 15:44)
|
еще момент, эта фильтрация не позволяет выполнить SQL запрос, НО всякие кавычки, слеши и нулл байт так и вносятся в базу, и вот уже занесенными в базу этими символами можно если сильно подумать воспользоваться =)
| Падонагъ [Off] [#] (28.03.2008 / 16:08)
|
ну при выводе эта инфа будет обработана. Или есть какие то способы воспользоваться всякими символами прямо в базе?
| Gemorroj [Off] [#] (28.03.2008 / 16:15)
|
в том-то и дело, что данным получаемым из базы практически всегда 100% доверие. часто ли ты обрабатываешь данные получаемые из базы?
| Падонагъ [Off] [#] (28.03.2008 / 16:25)
|
ну если они хранятся в чистом виде,то будем ессно обрабатывать их как минимум htmlspecialchars()
При работе с новыми проектами, главное не зацикливаться на стандартных штампах гг.
Энштейна как то спросили, как делаются гениальные открытия?
Он ответил:
Есть задача, про которую ВСЕ знают, что ее нельзя решить.
И вдруг находится болван, который этого не знает, садится за задачу, решает ее и таким образом делает открытие! гг
Так и тут, ненадо зацикливаться на стандартных, заезженных штампах.
Давайте разберем все по частям.
1) Данные, которые уже попали в MySQL при хранении безопасны (если их не трогать руками гг)
2) Нам нужно обезопаситься при добавлении данных. Для этого приводим полученные данные к нужному виду (числа - intval(), и др...), а строковые данные прослэшиваем с помощью mysql_real_escape_string()
3) Соответственно, данные у нас хранятся В ТОМ ВИДЕ, как получены (а это хорошо).
4) А уже при выводе данных из базы, мы их и будем обрабатывать нужным нам образом.
Простой пример из практики.
Библиотека в нашем двиге ЗАЕБАЛА ошибками XHTML на некоторых текстах.
При анализе ситуации, я понял, что все дело в фильтрации на входе, когда тэги (если есть в тексте) преобразуются в сущности.
Затем при выводе и разбивке по страницам (резка строки по длине), эта самая сущность тэга может порезаться посередине. И при выводе в браузер получаем хуйню.
В последней версии библиотеки, применено хранение данных в чистом виде (см. выше), при чтении статьи, сначала идет резка по страницам, а уж перед самым выводом в браузер, делается преобразование тегов и спецсимволов в их сущности и проводится дополнительная фильтрация.
Работает как часы, про ошибки XHTML можно забыть

| Gemorroj [Off] [#] (29.03.2008 / 15:33)
|
режь по пробелам или переносам строк =)
| voloshyn [Off] [#] (25.06.2008 / 05:04)
|
у мня тоже была такая проблема была.
| Esi0n [Off] [#] (08.01.2009 / 19:49)
|
Можно закрыть любую дыру если она извесна
Согласен. Только чтобы известить себя об этом, приходится подолгу гонять систему для отлова багов...
| Esi0n [Off] [#] (08.01.2009 / 20:32)
|
Это ж интересно
я вообще не пользуюсь не mysql_real_escape_string() не htmlspecialchars() не пользуюсь! я написал свою функцию замены символов, на html теги
.gif)

Всего: 46
Скачать темуФорум
Новые вверху