Понимаю, что тема уже набила оскомину, но время идет, возможно появилось какое то действенное решение. Скажу сразу, что я прочитал про "сессионные ключи", "проверки на сокеты", "запись куков" - но все это элементарно обходится cURL . Неужели нет какого то надежного механизма защиты от сторонних обращений к .php с "чужих" доменов? Рад буду ссылке на какую то толковую статью, где подробно расписано "для чайников". Мой проект крутится на выделенном серваке под Win Server 2019, т.е. могу настроить всё что угодно - вопрос что и как =) ================================ 1. Реализовывать регистрацию ОЧЕНЬ бы не хотелось - это отваживает больше половины новых пользователей. 2. Во всех подобных темах находится человек, который спрашивает - "а зачем вам это?". Вообще то, если бы было не нужно, то наверное бы и не спрашивали... Но я на всякий случай напишу =) Есть проект(сайт), который реализует обработку фотографий неким "уникальным алгоритмом". Соответственно на .php POST запросом с моего сайта (от клиента) передается фотография, а в ответ приходит обработанное изображение. "Злоумышленник" обращается к моему .php при помощи cURL, имитируя POST (где может указать любой домен, заголовок, сессию, куки и т.д.) и использует мой алгоритм на халяву. А мне это очень не нравится.
К сожалению да, обходится. И никак на 100% не защититься. Можно частоту обращений контроллировать. А вопрос, как ты контролируешь, что была оплата? Может просто с этой стороны усилить?
Это бесплатный сервис. Если бы была оплата, а это считай "регистрация" - тогда проверку сделать просто. Но у меня эта часть бесплатная, для привлечения юзеров, а с нее идет отсылка на платные "продвинутые" услуги. Именно поэтому я и не хотел бы вводить всякого рода "регистрации" - хочется дать пользователям обкатать алгоритм, а потом уже, по настоящему заинтересованные - переходят на часть, где регистрации и оплаты. Проблема в том, что и бесплатная часть достаточно хороша, чтобы ее использовали "пираты"...
CURL – это не с доменов. Попробуйте блокировать по IP. У «злоумышленника» может не хватить ума и ресурсов это обойти. Вообще универсальный вариант противодействия автоматическим «атакам» – вариативная полоса препятствий, когда «неожиданно» всплывает то одна защита, то другая, то третья. Но на это нужны ресурсы, чтобы постоянно быть на шаг впереди «злоумышленника».
Тогда на ум приходит только ограничение частоты вызовов с одного айпи. К примеру, не больше 10 в секунду/минуту и т.п.
Это можно сделать при помощи токенов типа CSRF или аналогичных. На обработчик вешаете проверку токена, пришедшего в теле запроса. Если токен не совпадает, значит он сгенерирован не на вашем сайте, и отклоняется. Задача в принципе не сложная. Если у Вас используется какой то фреймворк типа Laravel, Yii и т.п., то там уже есть система токенов CSRF, и просто используйте ее. Ежели свой код, то нужно написать свой токенайзер, что в принципе не сложно. Можно работать с сессиями, а можно и в БД хранить одноразовые токены.
Забыл написать, должен быть двойной запрос. После первого мы получаем ответ с токеном, вставляем его во второй запрос и отправляем обработчику. Обработчик видит что запрос с токеном, сверяет его и true/false Если я все верно понял, то это должно помочь. Если я не до конца понял задачу, то нужно подумать еще.
Если бы был, файлопомойки б до сих пор процветали. Упростите регистрацию до приемлемого минимума и не мучайтесь.
В описании использования этого способа защиты постоянно фигурируют какие то "смешные" скрытые поля - это как, типа у злоумышленника нет в браузере кнопки "посмотреть код станицы"? Что мешает "злоумышленнику" посмотреть код сайта, и сделать точно такой же запрос CSRF-токена? оО --- Добавлено --- На сколько я понимаю, cURL можно отправлять прямо с клиента, т.е. IP будут разные...
В свете вышеизложенного, мне кажется, что наиболее действенным будет кодирование ключа на стороне клиента при помощи "запутанного" JS с множеством ложных путей выполнения зависящих от времени и т.п., на разбор работы которого просто потребуется масса усилий квалифицированного программиста.
Изучите этот вопрос детальнее а не поверхностно, и не будет таких вопросов. Смысл в том, что на сервере выдается токен на текущий запрос (пишется в $_SERVER['token'] к примеру или БД), и при следующем обращении токен сравнивается с выданным ранее. Если все ок, то обработчик TRUE и токен перевыпускается на новый. И так по кругу. В случае с CURL вероятно придется как то привязаться к текущей сессии операции и ее передавать вместе с CURL, чтобы потом к ней обратиться и свериться. CSRF - это атака схожего типа, так как позволяет с удаленной страницы через форму управлять обработчиком вашего сайта. Только у Вас вместо формы используется CURL
Подобная "защита" стоит на автомобильных ключах - следующий токен подтверждается предыдущим... но достаточно один раз включить "глушилку" , чтобы проверка не сработала, и сигнализация вынуждена "сбросить" цепочку ключей. Смысла в такой защите для меня "0", т.к. работает она, как вы верно заметили, только в пределах одной сессии. Т.е. раз cURL с доступными на гитхабе "надстройками" может полностью эмулировать браузер, то никакие сессии защитой не являются... вообще, все эти защиты не от несанкционированного обращения к скриптам, а скорее от перехвата/подмены данных по дороге...
Любые данные, не имеющие интелектуального вмешательства, взламываются / парсятся. Google прекрасно это усвоил.
Можно не слишком запутанный. А разные, загружаемые «случайным образом». Причем так, чтобы нельзя было определить алгоритм косвенным образом (по объему коду, по бинарнику с кодом). P.S. JS-машины тоже существуют, но на это надо тратиться.
Глушилка тут ничего не сделает. Изучите детально CSRF атаку/защитные меры. Очень много схожего. Если нет желания, то это Ваше право. На данный момент токены для такого типа атак являются давно проверенным средством. Мне кажется идти проверенными решениями будет легче, хотя можете поэкспериментировать с собственными мерами защиты.
Простите, это как? Токен на 1 запрос дается. К следующему запросу он уже другой, даже если сессия та же.
причем тут несколько запросов ? Токен у тебя сохраняется в теле формы/куки и спарсить ее с документа, не составит труда.
Для этого должен быть XSS эксплойт. При этом еще нужно успеть применить токен до того, как его применит реальный юзер. На чистом сайте толку от парсинга не будет никакого.
Остановись. Не в ту степь уехал. Теперь будут два вопроса: Причем тут несколько запросов ? Причем тут "успеть пока юзер не заюзал" ?
Куча материалов есть по теме. Довольно подробно изложено во многих. По п. 1 - это потому что через CURL а не через HTML, так как нужно сгенерировать, получить и передать в ответе. Без HTML на это нужно 2 запроса. Ведь первый запрос приходит без токена, а нам нужно отправить с токеном, а он генерируется на сервере. В случае же с HTML при генерации формы сразу же вставляется сгенерированный токен, и форма отправляется сразу с готовым токеном за 1 запрос при отправке формы. По п. 2 - гуглите XSS и CSRF, и станет понятно о чем я. Если коротко, то когда XSS перехватил сессию и токен, то тут диллема - если юзер первый подтвердит форму, то CSRF-атака в этот заход не сработает, а если XSS успел отработать и отправить данные через свою структуру на обработчик сайта, то тогда атака удастся. При этом юзер увидит что на сайте какая то проблема, так как не сработает обработчик потому что его токен уже отработал и удален. Я предложил сделать не полностью как CSRF, а на его основе. Думаю разница должна быть ясна. В случае CURL нет HTML, и поэтому нужно как то это решать. А так принцип тот же - одноразовые токены. Я надеюсь понятно изложил? Если есть вопросы, то я
Я сейчас повнимательнее прочитал что нужно топикстартеру, и понимаю что он грузит фото через обычную HTML-форму на свой сайт. А злоумышленник уже через CURL хочет заюзать его API нахаляву. Т.е. в этом случае просто стандартная защита CSRF без всяких CURL-токенов спасет его. Самая обычная CSRF-защита в чистом ее виде. Все входящие POST должны проверяться на токен. Днем немного в запаре подумал что и топикстартер юзает через CURL, отсюда и решение предлагал для CURL-запросов. В любом случае все решение крутится вокруг CSRF. Если внес небольшой сумбур - прошу прощения. Кроме того ,если на сайте есть XSS, то не спасет эта защита если эксплойт будет юзать эту дыру. Поэтому нужно и XSS защиту сразу нормальную.