Защита скрипта

[ForJest]

Фанат
Я вижу здесь принципиально новую идею - фильтрование запросов к странице используя реги. Чем эта идея плоха?
Я не вижу ничего ущербного - просто другой подход.

-~{}~ 10.01.05 13:56:

И самое что интересное я не увидел в этом топике конструктивной критики.

-~{}~ 10.01.05 14:01:

Не пойму - что не так с его защитой? Она выполняет свою роль - ограничивает набор данных, которые ожидаются скриптом.

 

[4m@t!c]

ForJest
Это, как в рекламе "первое лезвие бреет чисто, второе безупречно чисто". Тогда нафиг первое лезвие?
Конструктивная критика была у SelenIT.

 

[ForJest]

4m@t!c
Там нет критики. Там лишь - используйте intval, кавычки, etc.
В данном варианте защиты я не вижу необходимости использовать intval, соответственно возникает вопрос - "нафиг второе лезвие"?

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

 

[4m@t!c]

Недостатки? Да сам автор треда и сказал

Это разрешает тока определенные запросы делать
т.е. напрмер load.php?mod=Catalog&file=viewfile&lid=2326&rel=1
load.php?mod=Catalog&file=viewfile&lid=28533
что-то типо этого не пройдет
load.php?mod=Catalog&file=viewfile&lid=28533&fix=goot
т.е. будет редирект на load.php?mod=Catalog

Т.е. для частного случая может и выход, но вот гибкости никакой. SelenIT обозначил стандартное решение - уже изобретенный велосипед - экранирование, замена htmlspecialchar() и др. соотвествующие манипуляции. как результат не надо ломать голову для каждой приходящей урлы, коих может быть тысячи.

 

[PiratusXP]

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

-~{}~ 10.01.05 16:48:

Как я понимаю из этого кода он фильтрует все и пропускает тока то что необходимо

 

[SelenIT]

По-моему, конструктивная критика была у vladaxа и neko. Сами по себе входные данные - это просто данные и ничего более. Опасность могут представлять не сами данные, а их использование - в частности, бездумная подстановка их в запрос. Ахиллесова пята данного скрипта - именно там, и вполне может проявиться, если в один прекрасный день автор захочет добавлять данные не через урл, а, скажем, через аплоуд файла.

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

 

[ForJest]

SelenIT
Понимаешь этот скрипт как мне кажется предназначен для показа информации, а не для её добавления или изменения.

Я просто так и не понял за что на него набросились. Это решение как мне кажется результат оптимизации. Если кто-то не состоянии его понять или оценить, может быть не стоит оставлять бесполезные замечания, лишь отдалённо касающиеся темы топика?


PiratusXP
не забудь [m]exit[/m] поставить . Да ты правильно понимаешь

 

[Фанат]

откуда такая уверенность, что только ты все правильно понял, а остальные - лохи?

 

[SelenIT]

ForJest

Использование регулярок для фильтрации ввода, конечно, как метод ничуть не хуже intval и т.п. (хотя для данного примера ИМХО intval и регулярка "только цифры" равнозначны). Но - когда автор понимает, зачем он это делает и что от чего он этим защищает. А реплики наподобие

А это улавливает все POST данные и не поволяет выполниться скрипту
...
Ну как зачем? Чтоб не позволить вывести скрипт из строя, т.е. не передать ему ложные данные... Одним словом чтоб не взломать
...
Вот это пройдет без защиты: mod=Catalog&file=viewfile&lid=22'%20UNION%20...

на мой взгляд такого понимания не демонстрируют.

Опять же - если это скрипт для показа, зачем "защищать" его от POST-данных, которые в нем вообще не используются?

Имхо, в этом и ответ на вопрос,

за что на него набросились.

 

[ForJest]

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

SelenIT
Очень хорошо - ты по крайней мере согласен что решения равнозначны .
Защита же от $_POST данных хотя и выполнена не лучшим образом может иметь смысл - это всё та же строгая фильтрация - скрипт работать в единственном случае - когда он получил те данные и только те данные которые он ожидает и умеет использовать.

С моей точки зрения это лучшая концепция защиты которую я до сих пор видел.

 

[PiratusXP]

А как можно скрипту передать данные не по GET, POST и инклуду, есть ли еще способы?
ЗЫ скрипт работоет тока в одном режиме выдача данных...

-~{}~ 11.01.05 20:17:

Да еще как можно легко и быстро, а главное правильно, в пределах одного скрипта, закрыть прием POST данных?

 

[neko]

завязать UTP морским узлом

 

[PiratusXP]

Шутки шутками, а все таки? Как ?

 

[ForJest]

PiratusXP
Ещё можно куки использовать

if (!empty($_POST))
{
die('Кто-то хочет нас ВЗЛОМАТЬ!');
}

 

[SelenIT]

ForJest
И все-таки, простите, но смысла фильтрации POST-данных из самого скрипта, особенно если он не работает с POST-данными, я не постигаю. Единственный вред от них, который я могу себе представить - зафлуживание сервера (при куче одновременных запросов с большом объемом пост-данных), но подобная защита от этого не поможет (скорее, пожалуй, лишь поспособствует).

Имхо, если уж отсекать POST-запросы - так делать это на уровне http-сервера, вообще не допуская их до разбора в php... Или я недоучел чего-то важного?