Посоветуйте, пожалуйста, наиболее надёжную модель получения скриптом вариков, дабы снизить вероятность слома засчёт переполнения. --------------------------------------------------------------------------------------------- Заранее благодарен.
"Засчет переполнения" - это в смысле buffer overflow? AFAIK, его в собственно ПХП вообще не существует как вида.
Debug: InternalError in vp_parser.main() details=maximum recursion depth exceeded in cmp Traceback (most recent call last): File "/var/web/cgi-bin/rpx-dev/vp_parser.py", line 286, in do data=main(st) File "/var/web/cgi-bin/rpx-dev/vp_parser.py", line 580, in main result+=main(nabor,cur_obj,pos) File "/var/web/cgi-bin/rpx-dev/vp_parser.py", line 708, in main data=vph.db.sql(sql_code,"both") File "vp_db.py", line 50, in sql err('Error DB=['+str(self.database)+']\n'+str(detail)+' Немного не в тему, но это сегодня у меня в питоне было.
Мм. что переполняется тогда неясно. была когда-то древнющая бага в апаче (а не в пхп) когда он не умел работать с длинными толи гет толи пост (толи еще какими-то) запросами и получалось на самом деле переполнение буфера, но это не в тему.
ок, вопрос можно поставить шире наиболее уязвимые моменты при передаче данных скрипту, хотя вопрос может быть несколько глуповат - как говориться, ман нам в помощь))
Действительно странный вопрос! Самые общие рекомендации: 1. Не использовать magic_quotes_gpc. Авторы этой функции посчитали php-программистов круглыми идиотами, решив избавить их скрипты от некоторых уязвимостей за счет лишения их адекватной работоспособности. 2. Не использовать переменные одноименные передаваемым в скрипт параметрам (отключать такую возможность FALSEфикацией register_globals или специальной процедурой в начале каждого пхпшного модуля, которая unsetит все эти переменные) и пользоваться массивами $_GET, $_POST, $_REQUEST и т. д. (и их синонимами) 3. Не использовать необъявленые переменные. Например все массивы следует сначала объявить хотя бы как $mass = array() а потом уже заполнять. 4. Ну и конечно понимать хорошенько что ты делашь когда используешь переданные параметры при работе с базой данных, такими функциями как include, eval, preg_replace и т.д.
Когда я делаю форму, данные из которой передаются скрипту, я обычно реализую следующее: 1. Контроль данных на стороне клиента (JS) 2. Контроль НАЛИЧИЯ ВСЕХ необходимых данных на стороне сервера (в противном случае скрипт завершает работу). 3. Проверка переданных переменных (длина и структура) 4. Представление всех необходимых параметров в строковом виде, работа с ними как со строками. 5. magic_quotes - сразу нах. 6. обязательна предварительная обработка полученных данных перед их включением в SQL (проверка длины, вырезание данных, не подходящих под формат, поиск ключевых SQL-слов и их фильтр, вырезание HTML). В этом языке еретиков (похапе) полно функций самого разного назначения. Все, что я написал выше, можно с успехом реализовать коротеньким кодом.
Только для сомнтиельного юзер-френдли. С точки зрения безопасности ничего не дает. Вот это дело не всегда благодарное. Зачастую гораздо рациональнее делать приведение переменной ку нужному виду и пихать переменную куда надо, при этом даже не задумываясь о том что изначально было в параметре. А уж если там была какая-то фигня, то это проблема хакера а не наша. Всеравно на всякие проверки надеяться не стоит. Если это интежер - то intval. Если неотрицательный то еще и abs. Если это поиск в SQL запросе, то просто оформляем его в соответствии со стандартом SQL, а уж что там хотели туда передать нас не волнует. и т.д. Нафиг-нафиг.. Как раз не так. Полная фигня. Никаких проверок и упаси боже вырезаний. SQL придумали не дураки. Экранируя спец. символы (возможно только два варианта - LIKE-стайлэкранирование при поиске и неLIKE-стайл экранирование - во всех прочих случаях) вы просто сформируете правильный запрос и передадите его на сервер. А уж что было в этом запросе вас не волнует. Представьте теперь ваш мега-фильтр как обработчик форм на каком-нибудь скрипт-кидди форуме где все обсуждают SQL-инъекции - потеха-то будет а не дискуссия.
пожалуй, самая опасная вещь - это работа с фс: нужно контроллировать, чтоб никакой лабуды извне не закатали и, самое главное, не было возможности запуска ентой хрени
в любом случае от проффи нет защиты 100%. Если не через этот скрипт сломают, так через другой. Притом не стоит забывать, что защита должны быть адекватной - Если данные стоят 30 рублей, то нет смысла городить защиту суммой в 1000р. Самый простой способ отсеять армию недохакеров - использовать только $_POST и забыть про $_GET. Так же стоит использовать минимально необходимое кол-во переменных, которые получают данные от клиента. И в добавок, разграничение прав доступа. Так как, чем проще система, тем меньше в ней ошибок - этот закон работает уже тысячи лет.
Ненадо никакой навесной защиты. Если ты понимаешь что ты делаешь то никаких ошибок не будет и хакер не пройдет. вернее он не пройдет до тех пор пока не задействует уязвимость какой-то программы, которой вы беспрекословно доверяете (тот же веб-сервер или пхп), ну или пока он не решит долбить вас с помощью грубой силы (досы/брутофорсы) - тут уж без навесной защиты не обойтись.
