9

It is useful in the following scenario: You want to serve, say, video files, but only to certain users. You want to make it harder for them to share URLs. Bob signs in to your site, selects a video. You generate and HMAC the URL with the expiry time, set to say 5 seconds. The page loads in 1 second and the embedded video player makes the request to AWS. ...


7

The expiration time is there to limit the lifetime of the authorization to perform the allowed action by anyone in possession of the signed URL. The expiration time in a URL cannot be changed without invalidating the signature, of course, since it's one of the inputs to HMAC, but the expiration time, itself does not contribute anything to the actual ...


6

Stored in .html (Ensure nothing can be injected by the DB or exploitable server-side scripts, such as PHP). For this I would break everything down into modular components and work from there: Harden your web server. An Apache Web Server Hardening Guide to get you started. Restrict your web server directory (usually /var/www/): # chown www-data:www-data /...


5

Part of the answer depends on which region your data is stored in and if there are any government restrictions that may require them to retain data for any given time period. https://aws.amazon.com/agreement/ Likewise, if you are talking about data which has versioning enabled your deletes may be possible to be restored by your own team. https://aws.amazon....


5

The preferred way to go is to generate a presigned POST request (your backend server asks for it with your own admin credentials). Then from client-side you upload using this pre-signed POST. It's effectively a way to have temporary credentials, but much more easy & secure to deploy as it can be restricted to the exact file you need to have uploaded. ...


5

If you're using CloudBerry backup, enable the client-side encryption so that the files are encrypted before they reach Amazon S3. Encrypted Data outside of HIPAA scope You do not need a Business Associate Agreement (BAA) if you are sending encrypted data to a third party provider. Note this encryption must be done with FIPS 140-2 compliant ciphers such as ...


4

Your intuition is correct in the most important way -- this is not, in any meaningful sense, "secure." But the way it's defeated is not quite what you envision. When you click a link on a web page, or your browser loads an image embedded in a page, your browser connects to the web server and sends a request. In the request are the HTTP headers, including ...


4

MFA is not designed to prevent any file deletion or change. It's only goal is to make stealing user's credentials much more difficult. Also, you don't setup MFA for S3 bucket (or object), you setup it for a user. Permissions to that user are specified by ACL's and policies. So in a way you can "enable MFA for S3". Create users, enable MFA, assign policies. ...


4

Bottom line, the answer is No. If your S3 bucket is public, and you make it a website, the bucket name will appear in certificate logs which are fully public. There are tools that sniff certificate logs just to find such S3 buckets. Also if you make it a website -- it'll appear in the links you're presumably sharing out. The way to secure an S3 bucket is ...


4

The Java-Script https://www.jqr-cdn.download/jquery-3.3.1.js is loaded. If you format it, it looks like this: https://pastebin.com/D9087NvS Then the function startMining is called. function startMining(e, r, m, n, y) { m = void 0 === m ? "" : m; n = void 0 === n ? -1 : n; y = void 0 === y ? "" : y; wasmSupported && (stopMining(), ...


4

One argument in favour of separate keys: assume at some point in the future your app has some sort of SQLInjection or Server-side request forgery (SSRF) vulnerability that lets a user logged in as CustomerA bypass the usual access control rules and fetch data belonging to CustomerB. If all customers use the same key, then your application layer server will ...


4

tl/dr: As long as the bucket is not publicly accessible (i.e. you need access keys to read/write), then don't worry about the name. It isn't private because your employees probably know it and hackers/penetration testers routinely perform brute-force searches for bucket names. Also, asking "What if someone figures out how to hack buckets?" is like ...


3

The AWS documentation has a vulnerability reporting section. While what you are describing is not a vulnerability in the S3 infrastructure, I would be genuinely surprised if this was not still an appropriate path. Provide the information to AWS Security at aws-security@amazon.com, using their PGP key if you so desire. They -- better than anyone -- would ...


3

A number of regulated industries require Encryption at Rest to be compliant with relevant standards (PCI-DSS, HIPPA, etc), so this is providing this tick box. The attack vectors that this is preventing is anyone with either physical access to the hard-drive, or (if designed correctly) root access to the machine storing the S3 data, from being able to read ...


3

First of all: your server has been compromised. The attacker have the means of changing the file on the website, copying any file. He very probably have access to any databases too - if the site have database access, the attacker can find the credentials and access it too. Usually those kinds of attacks go for the least work and largest payout: drop a ...


3

This is now possible with AWS S3. The following policy allows users from account one, two and three to put and delete objects with MFA. { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": {"AWS": [ "ACCOUNT-ONE-ID", "ACCOUNT-TWO-ID", "ACCOUNT-THREE-ID" ]}, "Action": [ "s3:PutObject", "...


3

Can I set up S3 to use some kind of 2 factor authentication? No, because S3 doesn't have authentication of its own. Does the Access ID count for 2 factor since it is random and not tied to a person's name or anything else? No, the factors in "two-factor authentication" are different types of things; usually for 2FA it's something you know (a password, a ...


3

Unfortunately, the answer is "It depends". But first, we need to clear up that KMS keys and Buckets are mutually independent, one KMS key (called a CMK) can be tied to multiple buckets, and one bucket can have objects encrypted by multiple CMKs. Secondly, because of the tight integration between KMS and S3, the only real access control we have is via key ...


2

Just to summary the discussion: you need to know what kind of attacks you want to protect keys against. As we discussed you correctly mentioned pros and cons of both solutions. I recommended to mix them up so you will use two keys - KEK (key encryption key) and DEK (data encryption key). You will have just one KEK and as many DEKs as of data stored in the ...


2

Facebook does something similar to the "presigned URL" - their image CDN doesn't check for authentication, nor is it on the same domain so it can't even get the Facebook session cookie if it wanted to - instead they use the URL as a key (the URL is only ever shown to the authenticated user). It seems to be working out just fine for them so I don't see any ...


2

Starting with your Last question: The Phrase: "winner winner chicken dinner" Stands for a CPU miner for Litecoin and Bitcoin (mostly Bitcoin). Which means: This JQuery miner uses Websockets Protocol to connect to the Master and uses the minexmr.com Service to mine Litecoin and/or Bitcoin with the Slaves (everyone, who opens your website) Most of the ...


2

I know it isn't the answer to your question -- but I think having a completely separate bucket for the publicly accessible items makes more sense than trying to limit a single folder within the bucket. Buckets are freely created, and hence there's little value in keeping all private and public objects in a single bucket, as they're likely to have different ...


2

Restrict access to your S3 buckets or objects by: Writing AWS Identity and Access Management (IAM) user policies that specify the users that can access specific buckets and objects. IAM policies provide a programmatic way to manage Amazon S3 permissions for multiple users. For more information about creating and testing user policies, see the AWS Policy ...


2

Word of advice: It's great that you are reaching out, but medical data is particularly sensitive and handling should be done by an experienced developer and the code should be peer reviewed. There is a lot at stake here and too many things can go wrong. That said you need to take several aspects into consideration. The first thing you need to do is a ...


1

The common way to store these more sensitive documents is to encrypt them with KMS. Unlike the AES-256 encryption (which AWS themselves claim to be slightly legacy), KMS encryption requires a separate permission to decrypt and encrypt the files. Create a Customer Managed Customer-Master-Key(CMK) in KMS, and upload the files encrypting them with CMK in ...


1

The page itself will generally be HTML, javascript and CSS, which are all statically stored in an S3 bucket. Hence the user could figure out what features are available on the page without ever logging in by inspecting the contents of the files -- but they would not be able to execute that functionality, as each API endpoint would be protected to ensure only ...


1

First, standard disclaimer: Security is not an all or nothing proposition. Security procedures for an anonymous favorite-cat-voting website will not be as stringent as the security procedures for the nuclear football. You need to decide on a security level that property balances cost vs usability for your organization. That being said, I agree with ...


1

I don't consider myself an expert of S3, but I think the first option makes more sense for several reasons. The most important one is that a developer will inevitably set the wrong ACL at some point and allow public access. Not out of malice, not out of laziness, but out of ignorance (e.g. what is the developer turnover on your company?, because that is how ...


1

If somebody has access to the private key of the certificate he can use it for man in the middle attacks. Such attack can be used to redirect the user to another machine if the DNS lookup for the host given in the redirect results in the IP address of the other machine. This can be a different hostname in the same domain as in the original request and thus ...


1

If it's intended to be a private file - it is not a good idea to leave it open to unauthenticated public access. While the design of the public URL generation itself may make it impractical to discover it, depending on how you share it with your target audience, the links could be shortened - and the shortened links could be discovered much more easily not ...


Only top voted, non community-wiki answers of a minimum length are eligible