- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Исходные данные:
Есть страница page.html, на которой JavaScript запрашивает XML-документ.
Есть data.xml - документ, либо скрипт, генерирующий документ.
Вопрос:
как сделать так, чтобы data.xml выдавался в ответ на запрос только со страницы page.html ?
Неверные ответы:
1. Проверять при выдаче документа REFERER. Не подходит, потому что слишком легко подделывается
2. Внедрять какой-то ключ (session_id например) в page.html, а при выдаче документа сверять ключи. Не подходит, потому что можно посмотреть ключ и сделать запрос с ним.
psylosss,
Наводящий вопрос:
какие данные нельзя подменить в заголовке ХТТП запроса?
dkameleon, да вроде как все можно. Значит, какой-то ключ все же должен быть (в сессии). Но как его использовать? Просто передавать его в открытом виде нельзя
psylosss,
о! тогда по каким уникальным не подделанным данным ты предлагаешь определить страницу?
единственная вещь, которую на сколько мне известно, не просто подделать в сокетах - это порт и айпишник, с которого было открыто соединение.
Далее идёт простая пересылка даных:
REQUEST ----------->
RESPONSE <----------
CLOSE ------------->
CLOSE <-------------
или в таком дуже.
все данные, передаваемые в REQUEST пользователь может, и формирует произвольным образом.
Можно узнать, в чём вообще заключается проблема, если вдруг кто-то решит сделать посторонний запрос?
Нет, IP и порт не подходят. Они же будут меняться от запроса к запросу.
Видимо, нужен все же ключ. Может быть, его шифровать как-то...
поправьте если не так. но по этому поводу думал и пришел к выводу что никак (поскольку запрос на page тоже можно подделать), если только
не использовать https.
Архитектура клиент-сервер подразумевает, что сервер ничего не знает о клиенте, а посему, клиент в любом случае должен передавать какой-либо идентификатор. Как вариант, вставлять в page.html ключ в виде хэша (например md5), состоящего из sessionId и имени хэндлера (data.xml). На стороне сервера легко будет проверить, были ли данные запрошены со страницы page.html. Даже если "подсмотреть" этот ключ, использовать его с другой страницы будет невозможно.
Архитектура клиент-сервер подразумевает, что сервер ничего не знает о клиенте, а посему, клиент в любом случае должен передавать какой-либо идентификатор. Как вариант, вставлять в page.html ключ в виде хэша (например md5), состоящего из sessionId и имени хэндлера (data.xml). На стороне сервера легко будет проверить, были ли данные запрошены со страницы page.html. Даже если "подсмотреть" этот ключ, использовать его с другой страницы будет невозможно.
а что мешает сначала запросить page (и узнав код) дальше использовать data.xml?
если только
не использовать https.
Даже если использовать, то подделать можно ещё до шифрования :)
мда. Неужели неразрешимая задача? В первый раз с такой сталкиваюсь в вебе...
Даже если использовать, то подделать можно ещё до шифрования :)
Да точно. Получается примерно так - если любой клиент может использовать page.htm, то любой сможет и xml использовать.
Остается только отфильтровывать неугодные ИП.