不是安全专家，我希望你能为我澄清一些事情。
我正在构建一个用户可以“交易”虚拟商品的应用。我正在用Django构建它以防万一你感兴趣。
示例场景：
Alice （UserID=1）的 good-A 具有特定值（x）。其中 good-A 基本上是“tradable items”DB中具有属性（ID, Name, Desc, Value, Owner）的数据库条目。 good-A 的所有者是 Alice 。现在，如果 Alice 想要 good-A 给 Bob （UserID=2），她会更改“Owner”属性 good-A 给Bob的UserID=2。
这意味着。为了获得Alice所提出的所有项目的总价值，我创建了一个询问“accumulate the Value values of all items in the tradable items database having the Owner=1”
因此，所有用户的所有商品都存储在一个数据库中。是否存在安全问题（恶意）用户可以将不属于他们的可交易项目的所有者属性更改为他们自己的项目？
我知道这取决于具体的实施情况，但也许你会看到这个计划中的一个缺陷...
所以...这是实现这种情况的好方法吗？或者你有更好的想法吗？
答案 0 :(得分：2)
从技术角度来看，堵塞每一个泄漏点。默认拒绝。
从业务风险的角度来看，假设您的技术工作效率仅为99％，并采取措施进行缓解。
1）记录每笔交易。如果安全漏洞打开，只要你还有你的日志，你就可以返回并撤消所造成的任何损害。大多数欺诈都将利用前端漏洞。
2）定期进行数据库备份。如果安全漏洞打开，您也可能会丢失数据库日志。你会想要那些可以追溯到很久的备份
3）每次获取/转移项目时向用户发送电子邮件。 BCC你自己 - 这会在两个不同的系统上创建2个交易日志的冗余副本（一个在电子邮件中，一个在数据库中） - 现在他们也必须破解你的电子邮件服务器才能逃脱欺诈。如果1失败，您可以从中恢复。它还可以让您的用户找到问题。
4）对于高价值交易，特别是转换为现金，添加人工授权。让他们每天进行两次批量交易 - 但是当转移通常在每小时20-30个范围内并且突然5000个 - 计算机没有时，人们就知道出了问题。人类在启发式方面比计算机好得多，一次性使用它们并确保没有任何可疑之处。
答案 1 :(得分：1)
你是对的，因为它完全取决于你的实现。安全问题取决于您实际让用户如何更改项目的所有权。如果您有一个简单的表单，向您显示用户拥有的所有项目，并且他们选择一个并更改所有者，则页面将重新加载，并且他们不再需要该项目进行修改。它也是一种查询方式。如果UserA请求更改ItemA的所有权但它们不是所有者，则您将失败该请求。
实际上，客户端无法更改不属于他们的项目，只要您只显示他们拥有的项目，并且只能更改他们最初拥有的项目的所有权。
修改的
作为安全问题的情况的例子是，您公开客户端可以通过javascript与之通信的REST API，并允许他们自由修改他们在PUT请求数据中指定的任何项ID。 / p>