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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://en.wikipedia.org/wiki/WebSock...ting_WebSocket
просто уязвимость существует, а как к этому относятся производители браузеров - другой вопрос. Как видим, мнения разделились. Может быть для твоего приложения это не важно, но это может быть важно для кого-то другого

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

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

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

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

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