Форум MySQL

Как защититься от SQL иньекций???

http://www.phpfaq.ru/slashes

Самой надежной защитой будет, то что вы понимаете что такое sql-запрос. Фильтруйте данные приходящие от пользователя(GET,POST,COOCKIE) И не позволяйте пользователю загрыть ваши кавычки и провести следующий запрос. И обязательно прочитайте статью что вам предоставил предыдущий комментатор, не факт что вы там все поймете, но постарайтесь

Все, что проходит через $_GET, $_POST, $_COOKIE необходимо фильтровать:

<?php     if (!get_magic_quotes_gpc()){         $username = mysql_escape_strng($_POST['username']);//Строковый параметр         $password = mysql_escape_string($_POST['password']);//Снова строка         $id_catalog = intval($_POST['id_catalog']);//Числовой параметр     }     else{         //Включен режим магических кавычек, следовательно, фильтрация не требуется         $username = $_POST['username'];         $password = $_POST['password'];         $id_catalog = $_POST['id_catalog'];     } ?>

Тоже самое с данными, находящимися в $_GET и $_COOKIE

> //Включен режим магических кавычек, следовательно, фильтрация не требуется

А потом люди начитаются такого, и начинают в эту чушь верить.
Посмотрели бы чтоли задачу на инъекцию в разделе "задачи"

intval(); поставьте за if (!get_magic_quotes_gpc()){. Он к "магическим" кавычкам отношения не имеет

>intval(); поставьте за if (!get_magic_quotes_gpc()){.

Это как?

<?php      $id_catalog = intval($_POST['id_catalog']);//Числовой параметр      if (!get_magic_quotes_gpc()){          $username = mysql_escape_strng($_POST['username']);//Строковый параметр          $password = mysql_escape_string($_POST['password']);//Снова строка          }      else{          //Включен режим магических кавычек, следовательно, фильтрация не требуется          $username = $_POST['username'];          $password = $_POST['password'];      }  ?>

Это непринципиальный момент.

Привет хакерам :))00

//Включен режим магических кавычек, следовательно, фильтрация не требуется          $username = $_POST['username'];          $password = $_POST['password'];

есть два варианта:
1

.htaccess # отключение магических кавычек  php_flag magic_quotes_gpc Off

2

<? function s_slash($value) {     if( is_array($value) ){$value = array_map('s_slash', $value);}     elseif ( !empty($value) && is_string($value) ){ $value = stripslashes($value); }     return trim($value); } if (get_magic_quotes_gpc())     {         $_GET     =!empty($_GET) ? s_slash($_GET) : NULL;         $_POST    =!empty($_POST) ? s_slash($_POST) : NULL;         $_COOKIE =!empty($_COOKIE) ? s_slash($_COOKIE): NULL;         $_REQUEST =!empty($_REQUEST) ? s_slash($_REQUEST) : NULL;     }

Работа БД с переменным:
$username = mysql_escape_strng($_POST['username']);//Строковый параметр
$id = intval($_POST['id']); //числовой

>Работа БД с переменным:

слегка поправлю

<? $s_username = "'".mysql_escape_strng($username)."'"; // Строковый параметр SQL-запроса $id = ((int)$id]); // целочисленный параметр SQL-запроса

(int) вместо intval() - непринципиально ( не смотря на то, что скорости у них отличаются на 2 порядка. )
А остальные моменты - таки да.

Как я недавно попался на такую запись... Поставил апострофы еще и в запросе.
Все таки мне кажется их по месту лучше.

Апострофы нельзя ставить поодиночке и без либо константного либо экранированного нутра.
Я не представляю записи, которая эту догму (в хорошем смысле) интенсивнее вынуждала бы проводить на автомате.

Заметьте, при использовании плейсхолдеров никаких апострофов нет.

Я к тому, что рисуя что-то вроде " .... '$param' ..." , Вы автоматически подвергаете скрипт риску SQL-инъекции - достаточно изменить $param строкой выше.
В моем варианте такое произойти не сможет, хоть тресни.

>Я к тому, что рисуя что-то вроде " .... '$param' ..." ,

Я не это имел ввиду, а это:

<? "...... = '". s_slash($value) ."'......."

Дело вкуса конечно, мне почему то уютнее, когда по месту видно, что происходит с данными.
Вот я и влепил по привычке.

Я не это имел ввиду, а это:
<?
"...... = '". s_slash($value) ."'......."

s_slash - синоним mysql_real_escape_string() ?
Если нет - дыра налицо.
Если да - она возникнет, когда определение этой функции изменят.

>Если да - она возникнет, когда определение этой функции изменят.
Дело не в этом, синоним или нет. Я использую обертку, кто то нет - не суть.

Дело в чем там было - обнаружилась дырка в одном скрипте, меня попросили посмотреть. Функция была довольно внушительна и вот такое

<? $value = "'". mysql_real_escape_string($value)  ."'";

стояло в начале. А запрос в конце.
А автор при обработке тупо пропустил одну переменную.
Я и не заметил этих строк в начале функции. А так как точно знал, что данные в одно из полей попадают неэранированными, залепил в запросе всем строковым полям по привычке тоже самое. Подумав что обработки нет вовсе. В результате то поле, которое было дырявым, стало работать нормально. А остальные нет, так как там оказались экранированные бэкслэши.
И самое обидное, что это не синтаксическая ошибка - её хватились спустя некоторое время.

По этому я и сказал, что уютнее это делать в самом запросе, а не отдельно.

Так я и говорю "залепил по привычке" - камень преткновения.

Кроме того, я с некоторых про отвергаю сам термин "экранированные данные" .
Данные, в моем представлении могут быть либо сырыми, либо оформленными в виде литеральной строки. То, что во втором случае придется заняться экранированием - вторично.

А меня вот один вопрос интересует:
Когда мы используем mysql_escape_strng нам приходиться в дальнейшем при извлечения из базы избавляться от ненужных слешей.
Можно вроде сделать вот так:

<? $text = strreplace("'","&#039;",$_POST['text']); // то есть заменяем апостроф на спец символ // а дальше уже нормально генерим запрос $sql = "INSERT INTO table (text) values ('$text')"; // то есть нам не удасться провести второй запрос. mysql_query($sql,$db);

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

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

не приходится. В том весь и фокус))) Слэши нужны только для транспортировки, в базе их нет.

как так?
У меня они оказываються в базе
Можете рассказать, как у вас так здорово получаеться(это не сарказм)

Модератор зря наверное удалил 2 последних коммента? Там был совет читать мануал и в ответе я спросил что именно читать. Думаю не справедливо были удалены эти 2 коммента

[поправлено модератором]

Слушайте можно по-русски? Я с английским не очень в ладах. По поводу моей идее есть возражения?


Вот ребята еще темка http://www.softtime.org/forum/read.php?id_forum=3&id_theme=1489 тему эту я не начинал(хоть от моего лица), но тема эта очень интересная и чем больше народу ее глянет тем лучше..Просьба модераторов не удалять те комменты которые в последнем оказаться полезным

>Слушайте можно по-русски? Я с английским не очень в ладах. По поводу моей идее есть возражения?

По поводу Вашей идеи уже сказали, что она несостоятельна.
Экранирующие слэши (в отличие от живых) в базу не попадают.
Я разжевывал этот аспект здесь не один раз, потрудитесь найти, уж коль скоро.

Подскажу. Если в БД у Вас попал слэш - значит сервер его расценил, как живой - следовательно он сам по себе был заэкранирован другим слэшем.
Нетрудно догадаться, почему.

Как я понял: сервер сам должен разбирать где слеш экранирующий а где нет? Но у меня и на денвере и на хостинге слеши попадают в базу.
А идея про спец символы как?

> По поводу моей идее есть возражения?

Да, "идея" в корне неверная, нет понимания механизма экранирования.

Это я так счётчик количество постов увеличиваю.

>> По поводу моей идее есть возражения?
>
>Да, "идея" в корне неверная, нет понимания механизма экранирования.

блин, я про экронирование что нить сказал. Ваш ответ: неверный так как он отходит от общепринятых, но это не ответ. Где уязвимость здесь, а так вы ерунду порите(возможно это делаю и я)

Безопасность тут вообще никаким боком.

>Безопасность тут вообще никаким боком.
как так? если я смогу символом ' закрыть предыдущий запрос и начать новый то как не причем, а вот с &#039; это не пройдет?

Это просто неправильная обработка данных, вот и всё.

Еще раз.
Это нерпавильно.

Писать не помню какое по счету эссе, показывая и доказывая, почему это неправильно очердному неофиту никакого желания нет.
Если Вам интересно, почему так - вы найдете все (или часть) предыдущих.

>Еще раз.
>Это нерпавильно.
не правильно это не факт что это не даст результатов тех каких мы добиваемся, думаете если идти в рамках правил многого можно добиться?
>
>Писать не помню какое по счету эссе, показывая и доказывая, почему это неправильно очердному неофиту никакого желания нет.
>Если Вам интересно, почему так - вы найдете все (или часть) предыдущих.

Ладно я не спорю: мысль изреченная есть ложь
Но можете все таки мне(неофиту) обьяснить где в моей методике есть дыра(именно дыра, а не то что там не соответсвие общепринятым правилам)

А даже если бы и не было дыры, то что? Допустим на секунду, что можно обрушить запрос (хоть явной уязвимости тут не наблюдается), если подставить в конец бекслеш. Ну и что? Ты тут же найдёшь HTML-представление бекслеша -- и вуаля. Опять вроде бы всё работает. Ты так и будешь переводить все "опасные" (о боже) символы в их HTML-представления. То есть вместо SQL-экранирования ты подставляешь просто HTML-экранированную строку. Задумайся как тебе "повезло": HTML-представление вида &#123; не содержит ни одного "опасного" (о боже) символа.

Так и поступай. Вперед. Все учатся на ошибках.

Вы тут уже говорите об XSS? действительно сложно понять
Ну как я понял заэкранируете вы весь запрос и попытаетесь там вставить свой и пото мзакрыть апостроф но ведь с этого(о боже ) будет ошибочка.

Где дыра, можно понаблюдать, решая задачу 21, придуманную специально для этого.

реально ребята а какая здесь уязвимость
смотрела 21 задачу

но все-таки у tvv123456 вроде свежий взгляд на решение проблемы

там что-то с амерсандом было
а вчем зедсь проблема?
Ну правда
Я вообще ничего не шарю в php обьясните пожалуйста

Для начала, раз в базе торчат бэкслэши, прочитайте внимательно этот топик. В самом начале есть про магические кавычки - наверняка они у Вас включены.
Отключите их.
Потом попробуйте выполнить запрос с обработкой (не фильтрацией!!!!!! это не тот термин) литеральных констант (проще строковыхъ значений) функцией mysql_real_escape_string().
И посмотрите, что будет находиться в базе.
Надеюсь пропадет желание извращать изобретать то, что сто лет как придумано.

А вот, кстати, пример уязвимости, придумал:

<?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

Обе строки, как предполагается, передаются от пользователя. Они обе вообще не содержат апострофов, но уязвимость есть.

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