как передать изображение на сервер?

[Magneto]

Сервер 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]

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

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

Можно фильтровать по IP

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

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

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

[Magneto]

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

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

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

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

[FINoM]

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

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

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

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

[melky]

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

[FINoM]

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

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

[melky]

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

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

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

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

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

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

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

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

[FINoM]

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

[melky]

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

[x-yuri]

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

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.

просто уязвимость существует, а как к этому относятся производители браузеров - другой вопрос. Как видим, мнения разделились. Может быть для твоего приложения это не важно, но это может быть важно для кого-то другого

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

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

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

Нет. Причем здесь это?

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

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

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

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

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

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

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

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

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