Web应用程序和记录锁定

在一个容忍度足够低，或需要精确度使得一些避免锁定的更新可以接受的系统中，只需要一个小型UDP图表来回取得到并保持一个锁定。

我们能够以真正廉价的方式，在服务器开放的时候，通过telnet连接到一个特殊的端口作为控制通道，来保持一个连接。更好的是，这种控制通道可以用在除记录锁定以外的许多任务中，包括许多数据完整性任务。但遗憾的是，这是一个Web应用程序，因此我们把它排除在外。

更糟糕的是，攻击一个锁定记录的系统相当容易。假设我们这样设计一个系统，让锁定每10秒更新一次，如果锁定10分钟内没有得到更新，服务器就考虑释放锁定。

毕竟，许多用户的无线网络相当不可靠，家里的宽带连接也不是很好；你必须为他们留有一些余地，否则他们在连接不太可靠的情况下永远不能保持一个锁定。最好是让一个记录锁定足够长的时间，而不是时间不够。

因此在这个系统中，理论上，黑客只需要每9分49秒更新锁定，让一个记录保持不确定锁定状态。如果一直重复这个操作，更新锁定，只需用几分钟到几个小时时间，在这个端口上使用最小的带宽，就可以让应用程序中的每条记录被锁定，每次锁定更新都会在数据库中引发相应的灾难。

很难确定应用程序服务器是否会在数据库服务器前崩溃，或者这种情况会持续足够长的时间，从而形成一次拒绝服务攻击。

一个技术并不熟练的攻击者（经过初步的搜索后）只要用很短的时间就可用Perl这类语言编写出这个代码；如果他用fetch和awk作为一段Nix shell脚本把它拼凑在一起，可能用的时间要长一些。如果这个恶意用户十分卑鄙，他还可以将它与一些抓取组件结合，迅速发现一些可以劫持的新记录。

正是这种事情让我夜不能眠（确实，写这篇文章时，我已过了就寝时间）。每次我想到一个使这种系统更加稳健的新方法，我又发现系统中的另一个漏洞和错误。哦，让系统勉强可靠相当容易。在一个“勉强可靠”的情形中，如果有人在打开记录后更改了记录，你只需忽略锁定情况，拒绝用户的更新。这可能相当容易。

但这样做并不能让人接受。而且，Web正在替代那些拥有处理这种问题的常见、已知和获得认可的系统的客户端/服务器和大型主机系统。这意味着Web应用程序必须至少和它们替代或与其竞争的系统一样能够正常运行。

我不会牺牲一组互斥、信号量和监视器来交换HTTP。但我需要解决这个问题。如果你认为多线程是一个头痛的话题，考虑如果要在HTTP上进行线程管理会出现什么情况。因此，如果大家有任何看法或建议，我完全接受任何观点。

责任编辑：德东

查看本文国际来源