存储在 .html 中（确保数据库或可利用的服务器端脚本（例如 PHP）不会注入任何内容）。

为此，我会将所有内容分解为模块化组件并从那里开始工作：

• 强化您的网络服务器。帮助您入门的Apache Web 服务器强化指南。

• 限制您的网络服务器目录（通常/var/www/）：

  • # chown www-data:www-data /var/www/ -R
  • # chmod 555 /var/www/ -R
    • 大多数人建议使用# chmod 750，我同意，但不要在不必要时授予写入权限。
• 强化您的 PHP 客户端
  • OWASP PHP 配置备忘单
  • 虽然不全面，但它是一个开始的地方。
  • PHP 配置强化归结为相同的想法“如果您不需要访问权限（执行、读取和/或写入），请不要授予访问权限”
• 确保无法直接加载 PHP 文件。例如浏览器客户端不能请求example.com/login.php，而是必须通过example.com/login.html它执行一个动作。
  • 一种方法是指示Web 服务器不提供带有 *.php 扩展名的文件。
  • 或者，可以指示 PHP 脚本处理不允许直接访问。防止直接访问 PHP 文件的 5 种方法
• 缓解 PHP 引发 SQL 注入攻击。
  • 如何防止 PHP 中的 SQL 注入？
  • PHP htmlspecialchars() 函数
    • 该htmlspecialchars()函数将一些预定义的字符转换为 HTML 实体。例如，在解析为 SQL（卫生）之前转换预定义的转义字符。
• 对您的硬件和数据库（每秒哈希率）使用适当的安全密码哈希算法和盐。就我个人而言，我喜欢 Argon2id。

文件只包含 HTML/CSS 和一些 vanilla JS。JS 除外，包括来自支付提供商。（没有大量无法轻松检查缺陷的 JS 库，也没有可能包含恶意代码的依赖项）。

没有什么可以添加的，这是一个很好的模型，避免使用库可以确保您在编写所有内容时审查代码。虽然，对此持保留态度，为什么不鼓励编写自己的加密？. 我会建议何时可以在 CSS 或 JavaScript 中实现要求，例如选择 CSS 图像幻灯片或 CSS 悬停选择器，而不是尽可能使用 JavaScript。

在此页面上加载 iFrame（信息不会发布到我们的网站）

我无法预见这是一个问题，因为您将使用 HTTPS 并将使用您拥有的域。但是，不建议这样做是不对的。为什么 iframe 被认为是危险的和安全风险？以及你不应该使用 iframe 的 3 个原因

我喜欢在客户端加载更多信息的想法。使用 ProtonMail 不仅可以提高客户端的安全性，还可以减少服务器资源。

从 JS 中的 GET 请求中检索付款金额。

为什么不使用 POST 请求？

由于几个原因，POST 比 GET 更安全。

GET 参数通过 URL 传递。这意味着参数存储在服务器日志和浏览器历史记录中。使用 GET 时，也可以很容易地更改提交到服务器的数据，因为它就在地址栏中可供使用。

比较两者之间的安全性时的问题是，POST 可能会阻止临时用户，但不会阻止恶意用户。伪造 POST 请求很容易，不应该完全信任。

GET 最大的安全问题不是最终用户的恶意，而是第三方向最终用户发送链接。我不能通过电子邮件向您发送一个强制 POST 请求的链接，但我肯定可以向您发送一个带有恶意 GET 请求的链接。即：http ://www.example.com/changepassword.php?newpass=Welcome123

GET 与 POST 哪个更安全？

将令牌（从 JS 中的 iFrame 接收）发送回功能网站。

为什么？HTML 支持iFrame。

托管在单独的 AWS S3 上。

关于 AWS S3 的任何事情我都可能会犯错误，因为我还是这个系统的新手。仅为免责声明！

只要 AWS S3 与您的 OpSec 匹配，就可以了。只要确保您对服务器的远程访问在可能的情况下使用强密码和 2FA 来加强。

确保 AWS 账户受 MFA 保护。

如上所述，建议使用双因素身份验证 (2FA)。虽然，如果 MFA 可用，请启用它。

我看到 SSH 僵尸网络有一个 OpenSSH 服务器，同时启用了以下参数：

• 密码认证
• 公钥认证
  • 妥协风险：窃取相应的私钥。
• 谷歌身份验证器
  • 危害风险：窃取设备身份验证器的存储。

除非它妨碍可用性，否则身份验证越强越好。

使用自定义 SSL 证书放置 Cloudfront 以确保页面受到保护。

通过自定义 SSL 证书，我认为您指的是颁发您自己的根 CA 并将签署服务器证书。如果是这样，Jamie Linux 有一篇非常好的文章OpenSSL Certificate Authority，用于配置公钥基础设施 (PKI)。

Amazon CloudFront 似乎是满足您要求的不错选择。

要在您的 Web 服务器上部署 HTTPS，请考虑以下参数：

• TLS 1.2（或更好）
• HSTS
• HSTS 预加载
• RSA 2048（或更好）
  • 如果您能承受性能影响，最好使用 RSA 4096
• AES-128 GCM（或更好）
  • 同样，如果您能承受性能影响，最好使用 AES-256
• 允许（或专门执行）前向保密 (PFS)

使用SSL Labs - 服务器测试检查您的网站

这不是对生成威胁模型的攻击向量的全面审查。但是，我希望它可以提供更广阔的视野。如需进一步阅读，请考虑如何处理受损服务器？.