Какой самый простой способ безопасно обойти предварительные запросы CORS? - PullRequest
Новая
       32

Какой самый простой способ безопасно обойти предварительные запросы CORS?

0 голосов
/ 16 октября 2019

Я знаком с CORS. Я верю, что понимаю его назначение и действие. Я понимаю, как "простые запросы" можно использовать, чтобы избежать предварительных запросов. Я знаю, что могу также использовать Access-Control-Max-Age, чтобы избежать их.

Тем не менее, я создаю систему, в которой участвуют аутентифицированные пользователи, которые потенциально могут POST / PUT / PATCHING большое количество бинарных запросов к * 1006. * разные URL , которые изменяют состояние сервера. Эти модификации необходимо распространять на других пользователей с минимально возможной задержкой. Я также хочу поддерживать доступ из сторонних приложений на разных доменах. Конечная цель очень похожа на то, что делает Google с их Drive API .

Удвоение RTT для большого процента запросов очень нежелательно. Что мне действительно нужно, так это что-то вроде CORS, но вместо предварительной проверки он просто отклоняет запросы от доменов, которые не входят в белый список. Таким образом, одобренные домены никогда не испытывают дополнительной задержки [0].

Я предложил следующие возможные решения:

1. Используйте WebSockets

PROS:

  • Полный контроль

CONS:

  • Более сложный.
  • Придется заново изобретать большую часть HTTP
  • . Можно все еще получить кеширование, используя HTTP для GET, но тогда мой API раздроблен на 2 протокола.

2. Используйте POST с Content-Type: text/plain для каждого запроса, используйте параметры запроса для параметризации запроса (так что мой сервер понимает создание против удаления и т. Д.) И интерпретируйте тело как двоичный файл.

PROS:

  • Полностью обходит CORS. Вместо того, чтобы требовать предварительную проверку, если источник не находится в белом списке, я могу просто отклонить запрос.

  • Простой

CONS:

  • Необходимо реализовать собственную проверку домена, чтобы избежать случайных сайтов, делающих запросы от имени прошедших проверку пользователей, в первую очередь IE для CORS.
  • Невозможно использовать пользовательскийзаголовки или заголовок авторизации, поэтому токены авторизации могут быть только в файлах cookie или в параметрах URL.

3. Используйте POST с Content-Type: multipart/form-data, одна часть FormData может быть JSON, который параметризует запрос, тогда другая часть будет двоичной полезной нагрузкой.

PROS:

  • Менее хакерской, т.е. не лжет о том, что такое Content-Type.
  • Все еще обходит CORS
  • URL, не загроможденный параметрами из моего протокола

CONS:

  • Тот же CONS, что и у опции 1
  • Более сложный, чем у опции 1

Я также нашел пару других предложений в этой ветке Hacker News , а именно:

https://github.com/jpillora/xdomain

https://github.com/krakenjs/fetch-robot

Но это не очевидно, если посмотреть на них, как они работают, или если они действительно решат мою проблему. И они кажутся довольно хакерскими (iframes-проксирование запросов и т. Д.).

Есть предложения?

[0] Кстати, почему CORS не был спроектирован таким образом?

...