¿Debo restringir el origen en una aplicación API?

Encontré un blog . Desde allí, el comodín no suena peligroso a menos que el sitio utilice la red del cliente como un tipo de medida de seguridad.

Puedo imaginar a alguien tratando de acceder a una VPN, por ejemplo, a través del navegador de la víctima. Requeriría mucho conocimiento interno, pero si el atacante es un ex empleado, por ejemplo, puede que tenga ese conocimiento, también puede usar contactos internos y engañarlos para que abran una página web maliciosa para ejecutar el ataque.

¿Qué es la política del mismo origen?

De Mozilla :

  

La política del mismo origen restringe la forma en que un documento o script se carga desde   un origen puede interactuar con un recurso de otro origen. Es un   Mecanismo de seguridad crítico para aislar potencialmente maliciosos.   documentos.

Todos los navegadores modernos hacen esto.

¿Por qué lo tenemos?

Esto evita que un atacante engañe a un usuario para que cargue una URL maliciosa en el cliente y haga algo como transferir dinero al atacante porque un navegador simplemente ejecuta el código que ve.

Consulte la información de OWASP en CSRF . Específicamente, en los ejemplos y "¿Cómo funciona el ataque?"

¿Qué es el intercambio de recursos entre orígenes?

De Mozilla :

  

El Intercambio de Recursos de Origen Cruzado (CORS) es un mecanismo que utiliza   encabezados HTTP adicionales para permitir que un agente de usuario obtenga permiso para acceder   recursos seleccionados de un servidor en un origen diferente (dominio) que   el sitio actualmente en uso.

Para resumir, un MECANISMO DE PASO DE SEGURIDAD.

¿Por qué las personas necesitan CORS?

Porque la gente todavía piensa que AJAX es genial. Broma. Como alternativa, podría decirse que los desarrolladores siguen utilizando un modelo asíncrono del lado del cliente para cargar datos en sus aplicaciones.

EDIT Añadido según el comentario

¿Por qué restringir este dominio de origen si el encabezado Access-Control-Allow-Credentials se establece en falso (o falta)?

Probablemente lo sepa, pero Access-Control-Allow-Credentials solo controla si el cliente / servidor acepta las credenciales que se exponen al sitio.

Según sus respuestas, su API no requiere credenciales, por lo que este indicador es irrelevante, pero ¿debería usar CORS con un comodín '*' o devolver el origen o debería restringir el origen?

Probablemente haya una gran cantidad de texto rojo en Internet, pero si su API es abierta / pública, usar el comodín o hacer eco en el origen está bien.

Si su API es más específica de la organización, es mejor incluir en la lista blanca los dominios que la usarían, verificarla y devolver el origen en la lista blanca. Estas son solo buenas prácticas de seguridad.

Aunque no lo inhabilitaría

Parece que tiene un poco de confusión sobre cómo funciona CORS y cuándo es aplicable, en particular debido a esto de su pregunta:

  

Otra pregunta es si hay algún problema de seguridad al permitir   comodín * todos los dominios para acceder a la API? No me importa si el usuario lo usa.   curl, o tiene su propio script o ha creado una IU personalizada para esta API.   ¿Por qué debería poner restricciones?

Lo que debe tener en cuenta es que CORS y las solicitudes de OPCIÓN previas al vuelo solo son importantes para los navegadores. Si alguien está creando su propia API y utilizando CURL u otras solicitudes de servidor a servidor, nunca habrá una solicitud previa al vuelo y cualquier encabezado Access-Control-Allow-Origin será ignorado por completo.

Sin embargo, si intenta realizar una solicitud ajax desde un navegador a través de javascript, entonces el navegador aplicará CORS: enviará una solicitud de OPCIÓN antes del vuelo (si es necesario) y descartará la respuesta si todo sucede. no echa un vistazo.

También tenga en cuenta que CORS protege contra las lecturas, no las escrituras. Si realiza una solicitud POST a través de javascript / ajax, la solicitud aún se enviará al servidor: la aplicación de javascript que realiza la llamada simplemente no podrá leer la respuesta si la comprobación de CORS no se valida.

Tu propia respuesta es la razón por la que probablemente quieras usar CORS (aunque definitivamente hay momentos en los que es posible que desees permitir todos los orígenes). Recuerde que todas las solicitudes del navegador también vienen con cookies adjuntas. Como resultado, si su aplicación se autentica a través de cookies y si se permite cualquier origen, en teoría, cualquier persona puede poner javascript en cualquier sitio que haga llamadas a la API en nombre de usuarios autenticados.

Como ejemplo, imagine que Amazon tiene una llamada a la API que se realiza a través de javascript cuando hace clic en el botón "Comprar con un clic" en la página de destino del producto (para referencia, tal llamada a la API ciertamente existe). Imagine además que las credenciales de autenticación se administran a través de cookies (posiblemente verdaderas) y que un atacante pasó algún tiempo para averiguar la estructura de la llamada a la API (lo cual no es imposible, ya que el código Javascript siempre está disponible para inspección).

Ingrese usted (el atacante). Usted está vendiendo una bolsa de tierra en Amazon por $ 200. Nadie está comprando su producto. Entonces, escribe algo de javascript que llama al punto final de Amazon para ejecutar la compra con un solo clic en tu bolsa de basura. Sin embargo, no quieres comprarlo tú mismo, así que en lugar de eso, creas un sitio web con videos de gatos que se vuelve muy popular (después de todo, ¿a quién no le gustan los gatos?). En ese sitio web, usted pone su javascript que llama automáticamente la compra de una página con un clic en una bolsa de basura. Ahora, cada vez que alguien visita su sitio web mientras también está conectado a Amazon, inmediatamente compra su bolsa de basura sin tomar ninguna medida. Sus pedidos comienzan a llegar y Amazon tiene un gran lío en sus manos debido a su falta de seguridad.

Puede que este no sea el mejor ejemplo de por qué tener un origen abierto puede morderlo, pero espero que se lo explique. Nuevamente, ciertamente hay algunas llamadas a la API para las cuales un origen abierto es perfectamente razonable. Un buen ejemplo es la mayoría de las aplicaciones de redes sociales: twitter / facebook / etc específicamente proporciona javascript que está destinado a ejecutarse en otros sitios web para que pueda bajar fácilmente un feed de twitter reciente. A cambio, tienen sus propios aros por los que debes saltar para autenticar tus llamadas a la API. Así que definitivamente hay razones por las que quieres abrir tu API. Sin embargo, también hay razones por las que no. En cualquier caso, esto solo importa para las llamadas a la API en el navegador. Curl y otras solicitudes HTTP "directas" ignoran CORS de forma conjunta.