Почему RPC через HTTP является проблемой безопасности?

Question

Я сейчас читаю на веб-сервисах. Учебное пособие по SOAP http://www.w3schools.com/soap/soap_intro.asp. Следующий абзац с этой страницы:

«Современные приложения обмениваются данными с помощью удаленных вызовов процедур (RPC) между такими объектами, как DCOM и CORBA, но HTTP не был разработан для этого. RPC представляет проблему совместимости и безопасности; брандмауэры и прокси-серверы обычно блокируют этот тип трафика».

Я не понимаю этого. Может кто-нибудь объяснить мне, пожалуйста. Особенно я хочу знать, почему RPC является проблемой безопасности (при аренде через HTTP). Зная, почему именно это проблема совместимости, тоже было бы неплохо.

Answer 1

Дело в том, что «традиционный RPC» иногда использует необычные сетевые протоколы низкого уровня, которые часто блокируются корпоративными брандмауэрами.Поскольку SOAP использует HTTP, его трафик «неотличим» от обычного просмотра веб-страниц, и поэтому не перехватывается этими брандмауэрами.Не слишком уверенный в отношении точки безопасности, я думаю, что они, вероятно, подразумевают, что HTTP может быть легко защищен через HTTPS, а проприетарные протоколы RPC часто этого не делают.Конечно, это зависит от протокола, не все протоколы RPC будут небезопасными, и многие из них могут быть туннелированы через HTTPS.

Answer 2

Что касается совместимости, проблема в том, что не очевидно заставить что-то, использующее DCOM, общаться с чем-то, что использует, например, CORBA.Одной из целей SOAP является обеспечение функциональной совместимости для согласования способов реализации такого рода коммуникаций.(В некоторых случаях возможны некоторые проблемы с совместимостью с SOAP в зависимости от используемых вами инструментов.)

Что касается безопасности, в течение длительного времени были разработаны политики с использованием номеров портов для различения приложений: если вы хотитечтобы заблокировать определенную службу (скажем, NNTP), вы блокируете ее порт на уровне брандмауэра.Это позволяет легко контролировать, какие приложения могут использоваться.То, что делает SOAP поверх HTTP, это выдвигает проблему на уровне выше.Вы больше не можете отличить, какое приложение или служба используется от номера порта на уровне TCP, вместо этого вам придется анализировать содержимое сообщения HTTP и сообщений SOAP, чтобы авторизовать определенные приложения или службы.

SOAP в основном использует HTTP POST для отправки своих сообщений: он использует HTTP как транспортный протокол, тогда как HTTP является передачей протоколом, поэтому не использует HTTP в соответствии с веб-архитектурой(SOAP 2, возможно, пытался улучшить ситуацию).Поскольку сегодня почти всем нужен доступ к сети, почти гарантировано, что порты HTTP не будут заблокированы.Это эффективно с помощью лазейки, если поверх этого не добавлен слой безопасности.При этом, с точки зрения безопасности, есть преимущества в использовании HTTP для связи SOAP, поскольку, например, существует большая гармонизация с точки зрения существующих систем аутентификации HTTP.То, что пытается сделать стек SOAP / WS- *, - это согласование связи "RPC" независимо от платформы.Дело не в том, что «SOAP безопасен» по сравнению с «DCOM / CORBA нет», вам все равно придется использовать его компоненты безопасности, например WS-Security, и вы, возможно, смогли достичь разумного уровня безопасности с помощьюи другие системы тоже.