CORS-localhost как разрешенное происхождение в производстве

иногда при устранении неполадок в производстве было бы удобно иметь возможность поразить наш производственный сервер REST из моей локальной среды разработки. Но меня беспокоит, что добавление localhost для источников небезопасно. Поиски дали противоречивую информацию. Мои опасения обоснованны? Почему или почему нет?

2 ответов


Я предполагаю, что у вас есть

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://localhost

риск заключается в том, что любые службы, работающие на компьютере пользователя, могут эффективно обойти Та Же Политика Происхождения для сайта.

Итак, если у вас есть URL REST, такой как

https://example.com/User/GetUserDetails

вредоносная или скомпрометированная служба, работающая на компьютере пользователя, может сделать этот запрос через браузер пользователя, а затем получить сведения о пользователе, потому что их файл cookie аутентификации будет передан с помощью запрос.

теперь вы можете утверждать, что вредоносная служба, запущенная на компьютере пользователя, может просто захватить файл cookie аутентификации из своего браузера напрямую, а затем сделать сам запрос. Однако, если у сервиса есть свои недостатки (например, XSS), это может позволить другому сайту скомпрометировать пользователя через ваш сервис REST (evil.example.org --XSS-> localhost -CORS-> example.com/User/GetUserDetails).

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

Если вам действительно нужно это сделать, я предлагаю вам специальную учетную запись разработчика для вашей службы REST, которая при доступе добавляет Access-Control-Allow-Origin: https://localhost заголовок только для ваших запросов. Таким образом, вы не подвергаете риску других пользователей, поскольку знаете, что используете только сервер переднего плана только в https://localhost таким образом, вы не можете быть скомпрометированы настройкой open CORS.

другой способ может быть использовать что-то вроде noonewouldusethis2859282.localhost для вашей локальной копии интерфейса. Тогда вы можете смело добавить Access-Control-Allow-Origin: https://noonewouldusethis2859282.localhost заголовок, потому что никто другой не будет использовать это и будет в безопасности от атак CORS.


нет никакой проблемы безопасности с добавлением localhost к вашей настройке CORS в производстве.

добавлять что-то вроде:

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://localhost:3000

теперь браузеру разрешено совершать звонки с localhost: 3000 на ваш сервис, минуя Та Же Политика Происхождения. Теперь любой веб-разработчик может создать веб-страницу со своего локального компьютера для вызова API, что полезно для вашей команды. Однако localhost не является публично маршрутизируемые адреса - Вы не можете поделиться ссылкой на http://localhost:3000. Помните, что CORS-это только мера безопасности для веб-браузеров, совершающих звонки на ваш сайт. Любой человек может вызвать вашу конечную точку через сервер для вызовов сервера (или сценария). Тем не менее, вы должны избежать:

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *

это сделает ваш сайт доступным для каждого веб-сайта. Вместо этого заблокируйте свой Access-Control-Allow-Origin на сайты, которые в этом нуждаются. К сожалению, Access-Control-Allow-Origin принимает только одно значение, поэтому вам нужно обработать хост запросить серверную сторону и вернуть допустимые (подробнее).

аутентификация при вызове конечной точки CORS

когда вы делаете запрос CORS, который требует аутентификации, вы должны добавить Authorization заголовок к вызову, а не передача cookies - fetch делает это по умолчанию. Таким образом, любые вызовы конечной точки CORs будут выполняться через javascript, добавляя токен в заголовок, который он имеет только для этого сеанса. Если вы храните токен через cookie или localstorage обратите внимание, что он доступен только из этого домена (подробнее). Ваша конечная точка производства и localhost не будут иметь одинаковые файлы cookie и общий localstorage.

отключение CORS в Chrome

наконец, вы можете сделать запрос CORS из Chrome на любой сайт, запустив Chrome с --disable-web-security (подробнее).

наконец, Google Chrome позволяет работникам служб работать только на защищенных веб-сайтах и http://localhost. Если вы решите создать local.example.com для разработки вам нужно создать сертификат SSL и выполнить всю конфигурацию на локальном компьютере, чтобы запустить его. Я рекомендую просто использовать http://localhost:XXXX.