Kann sich jemand mit "AWS-cognito-identity-poolID", das fest codiert ist, in mein s3 hacken?

8

Zuerst habe ich meine aws "accessKey" und "securityKey" in der clientseitigen JS-Datei fest codiert, aber es war sehr unsicher, also habe ich über "aws-cognito" gelesen und neue JS auf folgende Weise implementiert:

Trotzdem bin ich verwirrt mit einer Sache, die jemand mit "AWS-cognito-identity-poolID", die fest codiert ist, in mein s3 hacken kann? Oder andere Sicherheitsmaßnahmen, die ich ergreifen sollte ?

Danke,
Jaikey

— Jaikey Sarraf
quelle

Es sieht so aus, als würden Sie einen unechten Zugriff verwenden, was bedeutet, dass jeder, der diese Identitäts-ID hat, hochladen kann.

— Ninad Gaikwad

Und wie kann jemand mit Identitäts-ID hochladen?

— Jaikey Sarraf

Wenn Sie es so eingerichtet haben, dass ein unbefugter Zugriff möglich ist, kann es jeder verwenden. Das ist der Punkt der Unauth.

— Ninad Gaikwad

3

Definition von Hack

Ich bin mir nicht sicher, was Hacking im Kontext Ihrer Frage bedeutet.
Ich gehe davon aus, dass Sie tatsächlich meinen, "dass jeder etwas anderes tun kann als eine Datei hochzuladen", einschließlich des Löschens oder Zugriffs auf Objekte in Ihrem Bucket.

Ihre Lösung

Wie bereits oben erwähnt, können Sie Ihren aktuellen Ansatz verwenden, indem Sie "Zugriff auf nicht authentifizierte Identitäten aktivieren" aktivieren [1]. Sie müssen dann zwei Rollen erstellen, von denen eine für "nicht authentifizierte Benutzer" bestimmt ist. Sie können diese Rolle PutObject-Berechtigungen für den S3-Bucket erteilen. Auf diese Weise kann jeder, der Ihre Seite besucht, Objekte in den S3-Bucket hochladen. Ich denke, das ist, was Sie beabsichtigen, und es ist aus Sicherheitsgründen in Ordnung, da die IdentityPoolId ein öffentlicher Wert ist (dh nicht vertraulich).

Eine andere Lösung

Ich denke, Sie müssen Amazon Cognito nicht verwenden, um das zu erreichen, was Sie wollen. Es ist wahrscheinlich ausreichend, S3 eine Bucket-Richtlinie hinzuzufügen , die allen die Berechtigung für PutObject erteilt .

Ist das sicher?

Ich würde jedoch nicht empfehlen, den direkten öffentlichen Schreibzugriff auf Ihren S3-Bucket zu aktivieren .
Wenn jemand Ihre Website durch Spammen Ihres Upload-Formulars missbraucht, fallen S3-Gebühren für Put-Vorgänge und Datenspeicherung an.

Es wäre besser, die Daten über Amazon CloudFront zu senden und eine WAF mit ratenbasierten Regeln [2] anzuwenden oder einen benutzerdefinierten Ratenbegrenzungsdienst vor Ihrem S3-Upload zu implementieren. Dies würde sicherstellen, dass Sie angemessen auf böswillige Aktivitäten reagieren können.

Verweise

[1] https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html
[2] https://aws.amazon.com/about-aws/whats-new/2019/08 / Unterer Schwellenwert für Aws-Waf-Rate-basierte Regeln /

— Martin Löper
quelle

Hallo, danke, da ich den direkten öffentlichen Lese- / Schreibzugriff auf den S3-Bucket bereits deaktiviert habe. Auch wir benutzen WAF. aber ich möchte jedem Benutzer erlauben, seinen Lebenslauf hochzuladen, auch zu löschen oder zu S3 zu wechseln, aber ohne seine Registrierung auf meiner Website. Jetzt erstelle ich eine IAM-Rolle und erstelle einen Zugriffsnachweis, der auf der clientseitigen JS sichtbar war. Dies war unsicher, da jeder Hacker diesen Berechtigungsnachweis in AWS-CLI verwenden und alle Aktionen ausführen kann: Lesen, Schreiben, Löschen. Wir verwenden also AWS-cognito und haben CORS auf s3 aktiviert, das nur für meine Domain spezifisch ist. Hier beginnt meine Frage, ob ich jetzt sicher bin.

— Jaikey Sarraf

2

Ja, der s3-Bucket ist sicher, wenn Sie ihn auf Client-Seite über "AWS-Cognito-Identity-Pool" verwenden. Aktivieren Sie auch CORS, das nur Aktionen von einer bestimmten Domain aus zulässt, um sicherzustellen, dass jemand "direkten Upload oder Listen-Bucket" erhält. verweigert ".

— Jaikey Sarraf
quelle

Ja, das stimmt, Sicherheit ist in Wirklichkeit nur eine Befriedigung. Wir haben das Beste gemacht, was wir können. Ich habe auch persönlich versucht, Anmeldeinformationen in ein anderes aws-Skript

— einzufügen,

0

Stellen Sie außerdem sicher, dass Sie die Datei-R / W-Anmeldeinformationen des fest codierten Zugriffs so festgelegt haben, dass sie nur vom lokalen Knoten und von niemand anderem gelesen werden können. Übrigens ist die Antwort immer ein Ja, es ist nur eine Frage, wie sehr jemand bereit ist, sich auf "Hack" einzulassen. Folgen Sie dem, was die Leute hier gesagt haben, und Sie sind in Sicherheit.

— Damir Olejar
quelle