Статья про анти sql-inj

чтобы нельзя было провести инъекцию......из под ковычек не выйти

 

А разве без этой штуки можно? подумай хорошенько )

 

я не про твой способ говорил а про свой, где я указал что простого magic quotes on будет достаточно с обрамленныеми параметрами. Если числа не обрамлять, тогда инъекция возможна.

 

а если тебе попадется нормально настроенный хостинг? или с новой версией пхп(в ближайшем будущем)?

Что, переписывать будешь?

 

ini_set();

Я сомневаюсь, что это будет в ближайшем. Ну 2-3 хостера поставят новую версию, остальные врядли.

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

 

С каждым нерезусовым словом в топе согласен :d

 

k1b0rg, воот: у тебя каждое неправильное решение/костыль тащит за собой еше гору костылей, и они нарастают как снежный ком.

А теперь посмотри на альтернативу(которая, кстати легче): писать правильно.

 

Почему же нет?!
Данный код позволяет мне получать чистые данные, на моем сайте в основном передаются только числа и текст... все остальное лишнее и я это убираю...

 

потому что вместо 10 строчек можно обойтись одной.

 

blaga. Нет не по этому. У него совсем неправильно.

GHostly_FOX, данные у тебя не "чистые", как ты выразился, а испорченные. Теряем информацию при твоей "обработке".

 

int и intval() ограничены -2147483648 до 2147483648

а числа большие этому, предлагаешь уже строкой брать? тогда ты пролетишь mysql_real_escape_string тебе не поможет, взломают так что ноги согнутся...




$id=is_numeric($_GET['id'])?$_GET['id']:0;

тебя опять эта запись не устроит? )) is_numeric возьмет любое число)

 

k1b0rg, спасибо, посмеялся.

А теперь немного подумай. Головой.
Предположим, в движке обрабатываем ее как:
1) ...как строку. Тогда причем int/intval() ?
2) ...как число. Тогда туда и не должны попасть такие значения, а int/intval() обрежет только неправильные.

 

nerezus молодца! реальн клево отписал! я даж посмеялся! хоть не впадлу читать было, т.к. не много)))

а ваше я обычно все параметры передоваемые в запрос беру в ' ' а в самих параметрах экранирую ' и всегото!))

 

ну дык так и надо делать правильно.
mysql_escape_string поможет правильно передать любую строку в базу данных, а intval поможет передать число

 

а не прощи ли сделать

PHP:

 $str=str_replace("'","\'",$str);


 

Конечно нет.
запрос можно испортить.
А эта функция экранирует еще и другие символы.

 

Я уже писал в подобной теме. Зачем создавать громоздкие функции для экранирования запрещенных символов, если все уже давно придумано за нас.

вот пример безопасного кода:

Code:

<?php
$val = (int)$_GET['val'];
$val = mysql_escape_string($val);
$q = mysql_query("SELECT id,name,etc FROM table WHERE val = '$val'");
if (!$q)
{
	echo '<br>Неверное значение переменной $val';
}
	else
{
while ($a = mysql_fetch_array($q))
{
	$id = $a['id'];
	$name = $a['name'];
	$etc = $a['etc'];
	$name = htmlspecialchars($name);
	$etc = htmlspecialchars($etc);
	// вывод результата
}
}
?>

вот.

 

Почти верно.
Почему почти?
$val = isset($_GET['val']) ? (int)$_GET['val'] : 0;

 

от инекции да. все верно.
>>но это не секурити-дырка.
бебе от инекции да, но секурити тк можно получить раскрытие пути. чем не бага.

 

ZaCo, а если у меня еррор_репортенг по нулям?