¿Alguien puede hackear mi s3 con "AWS-cognito-identity-poolID" que está codificado?

8

Primero, codifiqué mis aws "accessKey" y "securityKey" en el archivo JS del lado del cliente, pero era muy inseguro, así que leí sobre "aws-cognito" e implementé un nuevo JS de la siguiente manera:

¿Todavía estoy confundido con una cosa que alguien puede hackear en mi s3 con "AWS-cognito-identity-poolID" que está codificado? ¿O cualquier otro paso de seguridad debo tomar ?

Gracias
Jaikey

— Jaikey Sarraf
fuente

Parece que está utilizando el acceso a unuth, lo que significa que cualquier persona que tenga ese ID de identidad puede cargar.

— Ninad Gaikwad

¿Y cómo alguien puede subir con identificación de identidad?

— Jaikey Sarraf

Si lo ha configurado para permitir el acceso a una verdad, cualquiera puede usarlo. Ese es el punto de la verdad.

— Ninad Gaikwad

3

Definición de Hack

No estoy seguro de lo que significa piratear en el contexto de su pregunta.
Supongo que realmente quiere decir "que cualquiera puede hacer algo diferente a cargar un archivo", que incluye eliminar o acceder a objetos dentro de su cubo.

Tu solución

Como Ninad ya mencionó anteriormente, puede usar su enfoque actual habilitando "Habilitar el acceso a identidades no autenticadas" [1]. Luego deberá crear dos roles, uno de los cuales es para "usuarios no autenticados". Podrías otorgarle permisos de PutObject a la función S3. Esto permitiría que todos los que visiten su página carguen objetos en el bucket de S3. Creo que eso es lo que pretende y está bien desde el punto de vista de la seguridad, ya que IdentityPoolId es un valor público (es decir, no confidencial).

Otra solución

Supongo que no necesita usar Amazon Cognito para lograr lo que desea. Probablemente sea suficiente agregar una política de depósito a S3 que otorgue permiso para PutObject a todos.

¿Es esto seguro?

Sin embargo, no recomendaría habilitar el acceso directo de escritura pública a su bucket de S3.
Si alguien abusara de su sitio web enviando correo no deseado a su formulario de carga, incurrirá en cargos S3 por las operaciones de colocación y el almacenamiento de datos.

Sería un mejor enfoque enviar los datos a través de Amazon CloudFront y aplicar un WAF con reglas basadas en la tasa [2] o implementar un servicio personalizado de limitación de la tasa frente a su carga S3. Esto aseguraría que pueda reaccionar adecuadamente ante una actividad maliciosa.

Referencias

[1] https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html
[2] https://aws.amazon.com/about-aws/whats-new/2019/08 / reglas-basadas-en-tasa-baja-umbral-inferior-para-aws /

— Martin Löper
fuente

Hola, gracias, ya que desactivé el acceso público directo de lectura / escritura al depósito S3. También estamos usando WAF. pero quiero permitir que cualquier usuario cargue su CV, también elimine o cambie a S3, pero sin su registro en mi sitio web. Ahora creo una función de IAM y creé una credencial de acceso que era visible en el lado del cliente JS, lo cual era inseguro porque cualquier hacker puede usar esta credencial en AWS-CLI y realizar todas las acciones: leer, escribir, eliminar. Entonces, usando AWS-cognito, también habilitamos CORS en s3 que solo es específico para mi dominio, y aquí comienza mi pregunta: ¿estoy seguro ahora?

— Jaikey Sarraf

2

Sí, s3 bucket es seguro si está utilizando a través de "AWS-Cognito-Identity-Pool" en el lado del cliente, también habilita CORS que permite la acción solo desde un dominio específico que garantiza que si alguien intenta cargar directamente o enumerar bucket, obtendrá "acceso- negado ".

— Jaikey Sarraf
fuente

Sí, es cierto, la seguridad es solo una satisfacción real, hemos hecho lo mejor que podemos. También traté personalmente de poner credenciales en otro script de aws, pero solo funcionó cuando los cargué en el dominio permitido, de lo contrario no funcionará

— Jaikey Sarraf

0

También asegúrese de haber configurado las credenciales de archivo r / w del acceso codificado para que solo pueda leerlo el nodo local y nadie más. Por cierto, la respuesta es siempre un sí, es solo una cuestión de cuánto alguien está dispuesto a comprometerse a "hackear". Siga lo que dijo la gente aquí y estará a salvo

— Damir Olejar
fuente