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:
File to only include HTML/CSS and some vanilla JS. With the exception of JS include from the payment provider. (No abundance of JS libraries that can't be easily checked for flaws also no dependency includes that could include malicious code).
Load iFrame on this page (the information is not getting posted to our site)
I cannot foresee this being a problem as you will be using HTTPS and will be using a domain owned by you. However, it would be amiss to not suggest it. Why are iframes considered dangerous and a security risk? and 3 Reasons You Should Never Use Iframes
I like the idea of loading more information on the client-side. With ProtonMail it not only increases security for the client but also reduces server resources.
Retrieve payment amount from GET request in JS.
Why not use a POST request?
POST is more secure than GET for a couple of reasons.
GET parameters are passed via URL. This means that parameters are
stored in server logs, and browser history. When using GET, it makes
it very easy to alter the data being submitted the the server as well,
as it is right there in the address bar to play with.
The problem when comparing security between the two is that POST may
deter the casual user, but will do nothing to stop someone with
malicious intent. It is very easy to fake POST requests, and shouldn't
be trusted outright.
The biggest security issue with GET is not malicious intent of the
end-user, but by a third party sending a link to the end-user. I
cannot email you a link that will force a POST request, but I most
certainly can send you a link with a malicious GET request. I.E: http://www.example.com/changepassword.php?newpass=Welcome123
GET vs POST which is more secure?
Post token (received from iFrame in JS) back to the functional website.
Why? HTML supports iFrame.
Host on separate AWS S3.
Anything Concerning AWS S3 I may make mistakes, as I am still new to this system. Merely a disclaimer!
So long as AWS S3 matches your OpSec, then this is fine. Just ensure your remote access to the server is hardened with strong passwords and 2FA where possible.
Ensure AWS account is protected with MFA.
As discussed above, using two-factor authentication (2FA) is advisable. Although, if MFA is available enable it.
I have seen SSH botnets have an OpenSSH server with the following parameters below simultaneously enabled:
- Password authentication
- Public key authentication
- Risk of compromise: stealing the corresponding private key.
- Google Authenticator
- Risk of compromise: stealing the device authenticator is stored on.
Unless it impedes usability, the stronger authentication the better.
Place Cloudfront with custom SSL certificate to ensure the page is protected.
By custom SSL certificate I presume you are referring to issuing your own root CA with will sign the server certificate. If so, Jamie Linux has a very good article OpenSSL Certificate Authority, for configuring a public key infrastructure (PKI).
Amazon CloudFront seems like a good option for your requirements.
For deploying HTTPS on your web server consider the following parameters:
- TLS 1.2 (or better)
- HSTS Preloading
- RSA 2048 (or better)
- Preferably if you can afford the performance impact use RSA 4096
- AES-128 GCM (or better)
- Again, preferably if you can afford the performance impact use AES-256
- Allow (or enforce exclusively) forward secrecy (PFS)
Review your website using SSL Labs - Server Test
This is not a comprehensive review of attack vectors to produce a threat model. However, I hope it can serve to give a broader perspective. For further reading consider How do I deal with a compromised server?.