我们有一个.NET（C＃）Web应用程序，该应用程序使用GUIDS在我们的MS SQL DB中识别特定记录。
这些GUID被生成并注入到DB中，然后用于创建一个响应URL，以供预期的收件人返回我们的应用程序。
我们已经检查并进行了仔细检查，并且所有GUID都完好无损，我们的出站电子邮件过程都很好。
但是，从半规则的基础上，我们在URL中看到了无效的GUID，用户要求的GUID。
最初，我们认为这个间歇性错误是一个恶意的"开车"类型问题，但进一步调查，似乎并非如此。实际上，这个问题是腐败之一。
我们设法跟踪和确定正在发生的事情，但我们仍然不知道如何进行。例如，这是我们的GUID之一，也是用户收到并按照电子邮件致电行动行动的页面请求中看到的同一GUID的损坏版本。
我们的GUID：
A715395B-F235-4C29-88AE-1FCE949E11D
损坏的GUID：
N7153952O-S23563-4P29-88NNR-1NSPR94954R11Q
您可以看到，腐败的GUID在整个过程中都散布着原始GUID的要素，但我们看不到腐败的原因或模式。
我们的URL格式是：
https://www.example.com/page/?guid1=guid1&guid2=guid2
发生腐败时，URL中的两个GUID都被损坏，实际上，参数的顺序被逆转，因此我们看到的URL包含损坏的GUID，看起来像：
https://www.example.com/page/?guid2=corruptGuid2&guid1=corruptGuid1
关于如何以及为什么发生这种情况的所有想法都是最感激的。解决类似的问题的一半是了解它的发生方式和原因，但是现在我们很困惑:-(
编辑：
此外，腐败有一种模式如下：
A -> n
B -> o
C -> p
D -> q
E -> r
F -> s
这代表了45个字符的偏移，但并不能解释我们还拥有的注入字符。
Our GUID: A715395B-F235-4C29-88AE-1AFCE949E11D
Corrupt GUID: n7153952o-s23563-4p29-88nr-1nspr94954r11q
Our GUID: A715395B -F235 -4C29 -88AE -1AFCE949E11D
Converted GUID: A7153952B -F23563 -4C29 -88AE -1AFCE94954E11D
Injected chars: ^ ^^ ^^
因此，这似乎取决于我们的一些客户在其入站邮件服务器上使用的反恶意软件。
这是指向STACKEXCHANGE上的安全帖子的链接，该帖子说明了问题