Почему для WebSockets нет политики одинакового происхождения? Почему я могу подключиться к ws: // localhost?

Я хотел бы использовать WebSockets для межпроцессного взаимодействия моего приложения (Daemon <-> WebGUI и Daemon <-> FatClient и т. Д.). Во время тестирования я попытался подключиться к моему локально работающему серверу веб-сокетов (ws: // localhost: 1234) через клиент JavaScript WebSocket на websocket.org ( http://www.websocket.org/echo.html ).

У меня вопрос:
почему это возможно? Не реализована ли в браузерах политика перекрестного происхождения (здесь: FF29 в Linux)?

Я спрашиваю, потому что, если websocket.org был злом, он мог бы попытаться связаться с моим локальным WS-сервером и перенаправить каждое сообщение, которое он получает от localhost, на любой другой сервер:

Браузер локального сервера WebSocket Злой веб-сервер
на ws: // localhost: 1234 на http: //evil.tld
        | | |
        | | ------ [GET /] ---------> |
        | | <----- [HTML + EvilJS] ---- |
        | <------ [подключить ws: // ..] ---- | |
        | <---- [немного общения] -> | |
        | | ---- [злой вперед] ----> |
        | | |

Я не тестировал весь вариант использования, но подключение к ws: // localhost из JS, предоставленного websocket.org, определенно работает.

Для решения вопроса "Почему?" Частично причина, по которой браузеры не применяют политику одного и того же происхождения (из которой CORS является ослаблением) для WebSockets, в отличие от вызовов AJAX, заключается в том, что WebSockets были введены после того, как значение запросов между источниками было установлено, и потому что они ' Если SOP изначально не распространяется, историческая причина проверок на стороне клиента CORS неприменима.

Для AJAX, во времена общей политики единого происхождения, серверы никогда не ожидали, что аутентифицированный браузер отправит запрос из другого домена ¹ , и поэтому не нужно было гарантировать, что запрос поступает из надежного места ² , просто проверьте файл cookie сеанса. Более поздние ослабления, такие как CORS, должны были иметь проверки на стороне клиента, чтобы избежать злоупотребления существующими приложениями , нарушая это предположение (эффективно выполняя CSRF-атаку ).

Если бы Интернет изобрели сегодня, зная то, что мы знаем сейчас, для AJAX не потребовались бы ни SOP, ни CORS, и возможно, что вся проверка была бы оставлена ​​на сервере.

WebSockets, являясь более новой технологией, с самого начала предназначены для поддержки междоменных сценариев. Любой, кто пишет серверную логику, должен знать о возможности запросов из разных источников и выполнять необходимую проверку без необходимости жестких мер предосторожности на стороне браузера, как CORS.

¹ Это упрощение. Запросы GET между источниками для ресурсов (включая теги <img>, <link> и <script>) и запросы POST на отправку форм всегда разрешались как фундаментальная функция Интернета. В настоящее время также разрешены вызовы AJAX с разными источниками, запросы которых имеют одинаковые свойства, и их называют простыми запросами с перекрестными источниками . Однако доступ к возвращенным данным из таких запросов в коде не разрешен, если явно не разрешено заголовками CORS сервера. Кроме того, именно эти «простые» запросы POST являются основной причиной того, почему для серверов необходимы токены защиты от CSRF для защиты от вредоносных веб-сайтов.

² На самом деле, безопасный способ проверки источника запроса даже не был доступен, поскольку Refererзаголовок может быть подделан, например, с помощью уязвимости открытого перенаправления. Это также показывает, насколько плохо тогда были изучены уязвимости CSRF.

Оберстет ответил на вопрос . Спасибо! К сожалению, я не могу отметить его как «правильный», потому что это был комментарий. Браузер отправляет заголовок «origin», который может проверяться приложением.

В Java [1]:

@Override
public void onOpen (WebSocket clientSocket, ClientHandshake рукопожатие) {
    Строка clientOrigin = handshake.getFieldValue ("origin");

    if (clientOrigin == null ||! clientOrigin.equals (WEBSOCKET_ALLOWED_ORIGIN_HEADER)) {
        logger.log (Level.WARNING, «Клиент не отправил правильный заголовок источника:» + clientOrigin);        

        clientSocket.close ();
        возвращение;
    }

    // ...
}

[1] с использованием https://github.com/TooTallNate/Java-WebSocket

WebSockets может взаимодействовать между доменами, и они не ограничены SOP (Same Origin Policy).

Та же проблема безопасности, которую вы описали, может возникнуть без WebSockets.

Злой JS может:

• Создайте тег сценария / изображения с URL-адресом evil.tld и поместите данные в строку запроса.
• Создайте тег формы, поместите данные в поля и вызовите действие формы «отправить», выполнив HTTP POST, который может быть перекрестным. AJAX ограничен SOP, но обычный HTTP POST - нет. Проверьте проблему веб-безопасности XSRF.

Если что-то внедряет javascript на вашу страницу или вы получаете вредоносный javascript, ваша безопасность уже нарушена.