Javascript-форум (https://javascript.ru/forum/)
-   jQuery (https://javascript.ru/forum/jquery/)
-   -   как передать изображение на сервер? (https://javascript.ru/forum/jquery/14958-kak-peredat-izobrazhenie-na-server.html)

Magneto 14.04.2011 22:22

Цитата:

Сообщение от FINoM (Сообщение 100674)
Сервер A (a.com) - поставщик данных
Сервер B (b.com) - один из серверов который имеет право на доступ к данным
Сервер E (e.com) - не имеющий доступа к данным.

Пытаюсь придумать, как реализовать поддержку всех пунктов вместе:
1. Дать возможность пользователю, зашедшему на b.com использовать данные с сервера a.com через ajax
2. Разрешить серверу b.com получать данные на стророне сервера, например с помощью php
3. Запретить пользователю, зашедшему на e.com пользоваться данными, которы поставляет a.com
4. Запретить серверу e.com получение данных со стороны сервера

На самом деле нету никакой проблемы.
Нужно фильтровать запросы по http-заголовкам.

Браузер всегда сообщает адрес страницы с которой был совершен запрос (HTTP referer). И если этот запрос пришел со страницы расположенной на сервере b.com то в ответ возвращаем данные, иначе сообщение об ошибке или на свое усмотрение. Конечно это не позволяет реализовать кроссдоменный AJAX но это вполне подойдет к Script и XhrIframeProxy

В случае когда запросы приходят с серверных скриптов то отфильтровывать их еще проще. Можно фильтровать по IP, также можно придумать собственный заголовок для общения между серверными скриптами расположенными на разных серверах.

FINoM 16.04.2011 02:27

Цитата:

Сообщение от Magneto
Нужно фильтровать запросы по http-заголовкам.

http заголовки всегда можно подменить.
Цитата:

Сообщение от Magneto
Можно фильтровать по IP

Да, но юмор в том, что у клиентов (посетителей) всегда будет "левый" айпи, то есть, злоумышленник, имея некоторый опыт, может легко эмулировать клиента, передавая нужного реферера, юзерагент и т. п.
Цитата:

Сообщение от Magneto
Конечно это не позволяет реализовать кроссдоменный AJAX

Эм... Почему?

Magneto 16.04.2011 02:44

Напоминает: "Смотрю в книгу - вижу фигу".

По IP фильтруем только обращения с других серверов. Причем здесь IP пользователей.

Цитата:

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

FINoM 16.04.2011 03:51

Цитата:

Сообщение от Magneto
По IP фильтруем только обращения с других серверов. Причем здесь IP пользователей.

Это сработает только в случае не использования злоумышленником средств для замены заголосков.
Цитата:

Сообщение от Magneto
Поспешу огорчить, от данной проблемы нету 100% эликсира, всегда есть возможность притвориться браузером и послать нужные заголовки.

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

melky 16.04.2011 12:51

использование $_SESSION , мне кажется, будет хорошей идеей

FINoM 16.04.2011 16:48

Цитата:

Сообщение от melky
использование $_SESSION , мне кажется, будет хорошей идеей

id сессии передаётся в заголовках с обеих сторон. То есть его можно тоже принять и отправить.

melky 16.04.2011 16:58

тогда заюзайте куки,как в вконтакте

коротко: там есть кука, UID (неважно) , коотрая является md5-хешем чего-то , чего-то и IP-адреса

если куку в ВК перехватывают и пытаются залогиниться под ней,
то конечный md5 вашего IP (или что там еще) не совпадает, далее хакера кидает на главную страницу

можно так сделать:

при заходе на страницу отправки файлов юзверю присваивается его UID, в котором хранится md5 IP, соли, USERAGENT`a ( ведь он не будет менять браузер или ОС, когда будет загружать файл)

этот UID будет в куке.

на PHP проверяем всё это , собирая такой же md5 того же списка.

хеш не совпал? какой ужас, пишем , что возникла ошибка. попробуйте повторить ещё

FINoM 16.04.2011 17:10

melky, снова повторюсь, сервер злоумышленника может отсылать куки, юзерагент, ip так же как и клиент.

melky 16.04.2011 17:22

если он будет "злоумышленничать" через прогу, Javascript все равно не будет исполняться

x-yuri 17.04.2011 10:33

Цитата:

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

http://en.wikipedia.org/wiki/WebSock...ting_WebSocket
Цитата:

Chrome also plans to disable the WebSocket if actual exploit code appears before the protocol is revised.
просто уязвимость существует, а как к этому относятся производители браузеров - другой вопрос. Как видим, мнения разделились. Может быть для твоего приложения это не важно, но это может быть важно для кого-то другого

Цитата:

Сообщение от FINoM
Эм.. А какая разница? Используется ведь один протокол, просто там реализация в браузере нативная, а там через флеш.

нет, протоколы разные. И если ты используешь web socket'ы, то есть опасность того, что тебя скомпрометируют. Если ты делаешь fallback в flash, ты не решаешь проблему с уязвимость. Если исопльзуешь только флеш - решаешь, но отказываешься от возможностей web sockets

Цитата:

Сообщение от x-yuri
Или тебя смущает, что javascript не может самопроизвольно получить доступ к любому файлу на клиенсткой машине?

Цитата:

Сообщение от FINoM
Нет. Причем здесь это?

при том, что ты не обходишь политику безопасности, а передаешь файл средствами html, потому что в js такой возможности не было. И кроссдоменный ajax - это тоже скорее всего просто так изначально было реализовано, а потом стало понятно, что не учли

Цитата:

Сообщение от Magneto
Нужно фильтровать запросы по http-заголовкам.

Цитата:

Сообщение от FINoM
http заголовки всегда можно подменить.

ip-адрес - не http-заголовок, если же речь о forwarded-for - то не стоит рассчитывать, что он корректный

Цитата:

Сообщение от FINoM
Поспешу огорчить, от данной проблемы нету 100% эликсира, всегда есть возможность притвориться браузером и послать нужные заголовки.

Цитата:

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

может быть и есть, просто не всегда разумно его использовать. А именно, цифровые сертификаты

Цитата:

Сообщение от FINoM
melky, снова повторюсь, сервер злоумышленника может отсылать куки, юзерагент, ip так же как и клиент.

давай уточним условия? Из твоих слов получается, что злоумышленник может получить куки любого пользователя и перехватить любую информацию. Причем есть два вида злоумышленников: 1) владелец сервера E и 2) владелец браузера, у которого нету доступа ни к A, и ни к B


Часовой пояс GMT +3, время: 16:44.