[php]как реализовать получше?
ессессно страница висит в инете, и пользователей может быть до жопы ....
и каждый из них(уникальность смотрим по айпи) не должен повторять запрос реже чем в Х секунд
и каждый из них(уникальность смотрим по айпи) не должен повторять запрос реже чем в Х секунд
в сессии писать timestamp первого ответа и сравнивать со вторым.
хранить где-нибудь ip и время последней критичной (которая не может выполняться чаще, чем раз сколько-то раз за сколько-то времени) операции... Подробнее (где хранить) - зависит от архитектуры программы.
Дисэбилть кнопку, на которую жмёт пользователь 
Малацца. Джаваскриптом дисэйблить. А лучше - VBscript, чтобы все пользователи альтернативных браузеров шли лесом. А при входе на сайт выдавать предупреждение - "Этот сайт предназначен для просмотра с помощью браузера Internet Explorer 6.0 билд 2816 при разрешении 800х600 и размере экрана браузера 652х494. Рекомендуемая ОС - Windows XP SP1 с установленными хотфиксами KB800432 и KB5489543"
какое-то подмножество Джаваскрипта поддерживается всеми браузерами. Только вопрос, пусто ли пересечение)
Глупо.
Такие защиты делаются от автоматического постинга. А скрипту на php/perl/... наплевать на JS.
Такие защиты делаются от автоматического постинга. А скрипту на php/perl/... наплевать на JS.
Посмотри, как это сделано в IPB, phpBB или ещё где.
Вообще, идея проста. Надо где-то хранить ip и при попытке постинга смотреть не появлялся ли такой ip в последние X секунд.
Вообще, идея проста. Надо где-то хранить ip и при попытке постинга смотреть не появлялся ли такой ip в последние X секунд.
1. disable-ить кнопку JavaScript-ом
2. запоминать на сервере ip-ы последних отправлений
3. прописывать в cookie время последнего отправления
поддерживать лучше все три варианта.
клиентам, которые с отключенными cookie и JavaScript-ом - делать доп. задержку даже при первом отправлении.
2. запоминать на сервере ip-ы последних отправлений
3. прописывать в cookie время последнего отправления
поддерживать лучше все три варианта.
клиентам, которые с отключенными cookie и JavaScript-ом - делать доп. задержку даже при первом отправлении.
сессии определенно...
А не кукизы?
куки бесполезны - так как они проверяются на сервере, это не спасает от случайной двойной посылки (в отличии от JavaScript а в виду того, что их легко подделать, не спасут и от умышленной.
> виду того, что их легко подделать
80% хакеров-мазаев так не считает.
ps
тот же ip и то проще подделывать.
80% хакеров-мазаев так не считает.
ps
тот же ip и то проще подделывать.
20% или 1% - не так важно, главное - то неприятностей можно сделать много и не очень сложно.
> виду того, что их легко подделать
80% хакеров-мазаев так не считает.
Что касается ip - не согласен. Сомневаюсь, что провайдеры пропускают левые ip... А вот cookie - если ты пишешь скрипт на php/perl, то тебе в любом случает придётся руками куки реализовывать, а уж что ты в них после этого запихнёшь - не важно. То есть куки спасут лишь от тех, кому лень вообще с куками возиться.
> уж что ты в них после этого запихнёшь - не важно
если cookie - статические, то - да
а если, например, динамические и устанавливаются через JavaScript, то это уже геморр.
если cookie - статические, то - да
а если, например, динамические и устанавливаются через JavaScript, то это уже геморр.
> Что касается ip - не согласен. Сомневаюсь, что провайдеры пропускают левые ip...
Поставить локальный-прокси, вбить в него список внешних проксей и далее хоть тысячу раз нажать кнопку в браузере - может любой школьник
Писать на php может уже далеко не каждый школьник.
Поставить локальный-прокси, вбить в него список внешних проксей и далее хоть тысячу раз нажать кнопку в браузере - может любой школьник
Писать на php может уже далеко не каждый школьник.
понятно, что можно усложнить... Я о другом - можно сделать так, что поломать будет нереально, если не рассматривать ситуации натравливания поломанной сети компьютеров (что уж слишком правда для этого требуется сохранять данные на сервере. Если же право на добавление определяется исключительно запросом (post/get + cookie + прочие поля то в крайнем случае, можно вообще перехватить внешней программой запрос, а потом отослать его ещё несколько раз (это извращение, но возможно)... Поэтому нам в любом случае, или нужно контролировать дублирование на сервере, для чего потребуется сохранять там какую-нибудь информацию, или прибегать к извращениям, которые, к тому же, мало надёжны... Лучше уж сразу делать полноценную защиту, которая при этом не будет доставлять неудобств нормальным пользователям (у меня, например, cookie по умолчанию отключены и при этом достаточно гибка.
> Лучше уж сразу делать полноценную защиту, которая при этом не будет доставлять неудобств нормальным пользователям
Это как?
каким образом ты обойдешь использование проксей?
Это как?
каким образом ты обойдешь использование проксей?
Скажем так, лично по своему опыту - сети прокси использовать не приходилось, а вот фальсифицировать cookie на php - да. Хотя я и не взломщик никакой, и квалификация у меня в этом минимальная.
Поставить локальный-прокси, вбить в него список внешних проксей и далее хоть тысячу раз нажать кнопку в браузере - может любой школьник
Писать на php может уже далеко не каждый школьник.
Защиту от фальсифицированных ip тоже можно сделать - когда скрипт выдаёт пользователю форму, там присутствует поле hidden с каким-то кодом, получаемым, например, как
$val = md5("some super puper password"."ip");
Пользователь не может восстановить этот пароль. Когда сообщение приходит на сервер, сервер смотрит ip, получает $val для этого ip и сравнивает с полученным от пользователя. Если совпадает - то значит получено с того же Ip, которому и была отослана форма, иначе - запрос игнорируется. Тогда для взлома придётся через прокси ещё и скачивать страницу с формой, что уже сложнее. От последнего можно защититься только способами типа "введите число, изображённое на картинке" - но это уже из другой серии.
> Лучше уж сразу делать полноценную защиту
Кстати почти во всех рекомендациях по защите написано - что надо просто вставить как можно больше как можно более разнородных проверок, а не пытаться придумать какую-то хитрую идею.
Каждая лишняя разнородная проверка - усложняет/удорожает обход этой защиты в разы.
Кстати почти во всех рекомендациях по защите написано - что надо просто вставить как можно больше как можно более разнородных проверок, а не пытаться придумать какую-то хитрую идею.
Каждая лишняя разнородная проверка - усложняет/удорожает обход этой защиты в разы.
достаточно давать доступ к форме только зарегенным юзерам, разрешать только одну сессию для одного юзера и хранить там айпи, в этом случае даже айпи не нужен
Как раз сессия + IP даёт имхо самый лучший результат. Сложнее спиздить куки
Оставить комментарий
Arina_Kulikova
есть простенькая страничка с формой.пользователь вводит данные, они обрабатываются и выдается результат.
как сделать так, чтобы пользователь не мог осуществлять запрос через форму чаще, чем раз в Х секунд? то есть вот заполнил он форму и нажал на кнопку; затем опять вводит данные и нажимает на кнопку, и если повторный ввод раньше, чем через Х секунд, то надо вывести "иди на уйх".
у меня есть вариант, но не уверен, что он оптимален.