Авторские статьи Пишем Php скрипты без багов

не канает

 

Имхо лучше всего завести отдельный массив и в него модули складывать, а потом проверять через in_array()

Ну или поставить рестрикты (запреты), об этом вроде бы писали выше, не читал.

 

А не легче ли

PHP:

if(file_exists('modules/'.$_GET['mod'].'.php')) {
  include('modules/'.$_GET['mod'].'.php');
 }

 

Может быть уже сказано (просто лень все читать) но функция addslashes просто акуительно спасает от иньекций... просто пропиши все вносимие переменные и все...

 

n1†R0x, всегда так и делал
Йа фспомнел
$_GET['mod'] = str_replace('.',null,$_GET['mod']);

 

Y.Dmitriy, не городи чепухи... Она экранирует только кавычки, слеши и нулевые байты... Если на хосте крутится более-менее продвинутая БД (MySQL 5.X, Oracle и т.д.), то обход экранирования кавычек элементарно организуется через CHAR(...,...,...) или шестнадцатиричное представление - 0x7573657273.

 

Если запрос в браузере например id=1
То я юзаю

PHP:

preg_replace('|[^0-9]|',NULL,$_GET['id']);

 

NOmeR1, зачем так много? Можно просто intval($_GET['id']) или ваще $id = (int)$_GET['id']

 

Не легче, нельзя забывать про отключенный magic_quotes кое-где и про нуллбайт.

 

ай врунишка!

 

А я с вами не согласен, в полном объеме =\
Если к передаваемой в запрос SQL переменной применяется функция из класса экранирования кавычек, то как правило в самом запросе параметр из этой переменной обрамляется кавычками, например:

PHP:

...
$res = mysql_query("SELECT * FROM 'news' WHERE 'id'='".$id."'");
...


в результате применение функции SQL - CHAR(...,...,...) или шестнадцатиричного представления для обхода экранирования кавычек, ничего не даст!
Пример сформированного запроса:

Code:

SELECT * FROM 'news' WHERE 'id'= 'CHAR(....)' или '0x.......'

надеюсь вы понимаете, что он не отработает, т.к. MySQL воспримет 'CHAR(....)' или '0x.......' как простые строковые данные, а не функцию.
При этом применение экранирования кавычек в случае, когда параметр (целочисленного типа) не обрамляется кавычками, не имеет смысла для защиты от SQL инъекции, а всего лишь усложняет использование конструкций load_file и into outfile.

 

[53x]Shadow, совершенно с вами согласен, коллега! Вот это нормальная дискуссия, не то что "...заебато экранирует..."! Насчёт нашей проблемы - вот, вы пишете:

Это, конечно, оно так и есть! В мускле, например... Но, возможно, что программист забыл заключить данный параметр в кавычку (каждый третий ресурс в сети режет кавычки, но при этом не обрамляет кавычками само значение запроса), или, скажем, в Oracle недопустимо использовать для целочисленных полей выражение типа some_id='5', и вот именно в таких местах может пролезть злоумышленник со своим запросом... Поэтому все целочисленные параметры должны преобразовываться с помощью intval, а строковые с помощью регулярных выражений!

Благодарю за приятный разговор!

 

ну вот помогу и скрипты пойдут без багов =( а даже еще на самую вшивенькую яхту не накопил =\ так что вот так.