这是场景。客户已经拥有一个电子商务网站，他们正在收集送货地址信息和信用卡数据。但是，他们使用SaaS服务进行注册，该服务允许他们轻松地将信用卡表单更改为收集全名和电子邮件（不是信用卡信息）到营销系统中以用于其他目的。因此，他们将一个jQuery代码段从SaaS服务粘贴到他们的页面中，并添加一些＆＃34;数据 - ＆＃34;属性为其表单和表单字段标记，以便SaaS服务知道拦截什么以及SaaS帐户在何处发布数据。
好的，但是出现了安全问题。假设我们在该SaaS系统中有两个独立的客户。一个名为Jack并拥有jack.com，他的账户ID为100001.另一个是Nancy，nancy.com和100002. Jack可以将代码片段添加到他的表单中并添加一些＆＃34;数据 - ＆＃34;属性，但然后搞砸并将其中一个数据属性中的帐户ID设置为100002而不是100001.这意味着南希会突然在她的帐户中看到杰克的数据。不好！当然，修复方法是在Jack的SaaS帐户中设置一些设置，以便他只接受来自jack.com的数据，而Nancy只接受来自nancy.com的数据。
然后发生了潜在的攻击。黑客所要做的就是在自己的服务器上创建一个欺骗页面，在那里他形成类似的JSON，并通过他工作站上的/ etc / hosts文件更改，使它看起来像是他的jack.com。然后，他可以将成千上万的虚假营销表格信息发送到杰克的账户，因为SaaS服务认为它来自jack.com。
我可以在jQuery代码或SaaS服务使用的PHP代码中做些什么，以确保黑客不会像那样欺骗，只有Jack的真实客户数据才会被发送？
已回答的问题
Q1。 ＆＃34;你如何识别杰克和南希？按域名？＆＃34;
A1。杰克有他的域名jack.com。 Nancy拥有自己的域名nancy.com。每个人都使用这种营销SaaS服务，但每个人都在选择他们注册SaaS服务之前已经拥有的电子商务表格。他们在SaaS文档中被告知，＆＃34;只需将scraper.js放在表单页面中，然后将这些数据标记添加到表单标记和html输入，textarea和select标记中，以便scraper.js可以拦截那些表单暂时提交，从该表单收集营销数据（全名和电子邮件，让我们说），然后让该表单提交您已经拥有的工作流程。数据属性将标识要使用的帐户，以及应在SaaS服务中存储此数据的营销活动和子活动。＆＃34;然而，在scQuery的scraper.js中，它将传递JSON中的location.href属性，以便它知道在这个特定实例中使用了什么域 - jack.com或nancy.com。麻烦的是 - location.href可以被黑客欺骗，黑客在他的工作站上为jack.com设置127.0.0.1的/ etc / hosts文件条目，并运行相同JSON代码的副本。
Q2。 ＆＃34;如果您可以使用SaaS.com到jack.com的回调机制怎么办？那么，你的一个数据属性会指定回调函数来从SaaS.com接收数据，然后只有在得到正确的响应时保存数据？＆＃34;
A2。现在这是一个有趣的事情。是的，所以我想在jack.com上放一个额外的PHP页面，它会发出＆＃34; OK＆＃34;。当SaaS.com从jack.com收到JSON数据帖时，它会向jack.com上的第二个PHP回调页面发送一个请求，其中包含file_get_contents（），以确保它不仅获得OK响应，而且还获得IP匹配地址和SSL证书数据。如果两者不同，则很可能该请求是虚假的黑客请求，并且该事务可以被安全记录和拒绝。 （我可以轻松地进行IP地址验证，但我不确定如何在PHP中验证相同的两个SSL证书，如果这甚至是允许的或可能的话。）当然，IP地址可能是欺骗性的。
另一层安全性是，第二个PHP页面可以使用SaaS.com和jack.com之间的公钥/私钥交换通信检查，而不是简单地发出＆＃34; OK＆＃34;。
Q3。 ＆＃34;您为什么要拦截付款信息并通过Javascript发送？＆＃34;
A3。绝对不。从未指定在此问题中发送付款信息。说的就是全名和电子邮件。是的，还需要使用SSL通信以便安全地发送数据。而且，我们必须使用JSONP to get around the CORS problem。
Q4。 ＆＃34;是不是需要jack.com将所有内容保存在数据库中进行验证？如果是这样，为什么还要使用SaaS应用呢？＆＃34;
A4。不。一点也不。看看答案A2。借助该机制，SaaS应用程序可以接收数据，但在发生以下情况之前不会信任它：
它回调jack.com到第二页，并确保它返回的响应与首先发送表单数据的IP地址相同。
它会在第二页进行公钥/私钥交换检查（黑客无法明确欺骗，除非他们有服务器访问权限），以确保IP欺骗不会发生。
Q5。等一下。 A2和A4有问题。初始发送请求的IP地址将来自用户的工作站，而不是服务器。因此，您无法以这种方式验证IP。您必须使用其他机制来验证某人是否在jack.com上填写了该表单，并且它不是来自黑客欺骗jack.com。
A5。你是绝对正确的。忘了我猜我是因为我在另一个项目上有点分心。我不得不多考虑一下。
答案 0 :(得分：1)
TL; DR：如果你正在使用纯粹的客户端集成（只是javascript），那么就无法完全保护请求。
您可以使用非顺序随机UUID作为帐户ID来缓解此问题。例如，如果帐户ID看起来像100001，那么有人可能会尝试使用帐户ID 100002;但是，如果帐户ID看起来像c3f80e491d44cd91664a0459a0777ed01，那么从统计上来说，某人无法将数据发送到未知帐户。
这是在互联网上存储数据的任何形式的问题;如果没有服务器端代码的帮助，我不知道有什么方法。
您可以生成一个包含在json有效负载中的一次性令牌 - 这可以是通过HMAC保护的过时JWT令牌，或者是使用共享密钥加密的设置消息，然后通过共享密钥进行删除SAAS服务器。
如果您要开始涉及服务器端编程，那么这个额外的协商过程就变得有点无关紧要了 - 只要给电子商务网站一个API密钥就更容易了，让他们在收到订单时发布客户信息。