Почему нет политики одинакового происхождения для 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 на любой другой сервер:

Local WebSocket Server            Browser            Evil Web Server
at ws://localhost:1234                               at http://evil.tld
        |                            |                       |
        |                            |------[GET /]--------->|
        |                            |<-----[HTML+EvilJS]----|
        |<------[connect ws://..]----|                       |
        |<----[some communication]-->|                       |
        |                            |----[evil forward]---->|
        |                            |                       |

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

ОТВЕТЫ

Ответ 1

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

В Java [1]:

@Override
public void onOpen(WebSocket clientSocket, ClientHandshake handshake) {
    String clientOrigin = handshake.getFieldValue("origin");

    if (clientOrigin == null || !clientOrigin.equals(WEBSOCKET_ALLOWED_ORIGIN_HEADER)) {
        logger.log(Level.WARNING, "Client did not sent correct origin header: " + clientOrigin);        

        clientSocket.close();
        return;
    }

    // ...
}

[1], используя https://github.com/TooTallNate/Java-WebSocket

Ответ 2

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

Изначально, в дни общей политики одиночного происхождения при вызовах AJAX серверы никогда не ожидали получить запрос с подтверждением браузера из другого домена, поэтому не нужно было проверять заголовок Referer для обеспечения запроса происходило из ожидаемого происхождения. Позже релаксации, такие как CORS, должны были проверяться на стороне клиента, чтобы избежать прервать существующие приложения, нарушив их предположения.

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

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

Ответ 3

WebSockets может пересекать доменную связь, и они не ограничены SOP (политика одинакового происхождения).

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

Злой JS может:

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

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