我正在使用一个ISAPI重写过滤器来过滤漂亮的URL。在这些问题上,我没有从开发人员那里得到太多帮助。我希望通过理解这个转储文件,这样我就可以在代码中找到有问题的区域并自己重新构建它我对C不是很熟悉,但可以到处转转我需要用调试符号来构建这个来从转储中获取有用的东西吗? In w3wp__PID__3760__Date__06_23_2009__ Time_01_29_55PM__916__Second_Chance_Exception_C00000FD.dmp the assembly instruction at IsapiRewrite4!pcre_exec+12f9 in C:\IIRF1.2.15R5\IsapiRewrite4.dll has caused a stack overflow exception (0xC00000FD) when trying to write to memory location 0x00fc2be8 on thread 5
这些堆栈溢出异常正在我们的实时生产web服务器上发生,因此我无法使用调试模式单步执行此代码。正在发生的是我的应用程序池进程(w3wp.exe)正在接收此错误事件:
为应用程序池“dotNET pool”提供服务的进程与万维网发布服务发生致命通信错误进程id为“6924”。数据字段包含错误号。
有人能帮我弄明白这些数据吗?它是来自IIS调试诊断工具的转储如何解释它并找到异常的来源?它似乎是第三方PCRE正则表达式库中的一个异常。WARNING - DebugDiag was not able to locate debug symbols for IsapiRewrite4.dll, so the information below may be incomplete.
Type of Analysis Performed Crash Analysis
Machine Name WEB
Operating System Windows Server 2003 Service Pack 2
Number Of Processors 4
Process ID 8056
Process Image c:\WINDOWS\system32\inetsrv\w3wp.exe
System Up-Time 0 day(s) 09:26:25
Process Up-Time 0 day(s) 02:17:00
Thread 4 - System ID 6624
Entry point w3tp!THREAD_MANAGER::ThreadManagerThread
Create time 6/23/2009 11:12:56 AM
Time spent in user mode 0 Days 0:0:40.906
Time spent in kernel mode 0 Days 0:0:6.312
Function Arg 1 Arg 2 Arg 3 Source
IsapiRewrite4!pcre_exec+12f9 08166a27 01b6741f 081669b8
IsapiRewrite4!pcre_exec+2779 08166a27 01b6746b 081669b8
IsapiRewrite4!pcre_exec+1660 08166a26 01b6741f 081669b8
IsapiRewrite4!pcre_exec+2779 08166a26 01b6746b 081669b8
IsapiRewrite4!pcre_exec+1660 08166a25 01b6741f 081669b8
IsapiRewrite4!pcre_exec+2779 08166a25 01b6746b 081669b8
IsapiRewrite4!pcre_exec+1660 08166a24 01b6741f 081669b8
IsapiRewrite4!pcre_exec+2779 08166a24 01b6746b 081669b8
IsapiRewrite4!pcre_exec+1660 08166a23 01b6741f 081669b8
IsapiRewrite4!pcre_exec+2779 08166a23 01b6746b 081669b8
IsapiRewrite4!pcre_exec+1660 08166a22 01b6741f 081669b8
[...snip...]
[original_url]/Forum+Result:+%E8%F1%EF%EE%EB%FC%E7%EE%E2%E0%ED+%ED%E8 %EA%ED%E5%E9%EC+%22Rifsadasy%22;%EF%E8%EA%F2%EE%EA%EE%E4+%E4%E5%F8%E8 %F4%F0%EE%E2%E0%ED;%E7%E0%F0%E5%E3%E8%F1%F2%F0%E8%F0%EE%E2%E0%EB%E8%F1 %FC+100%25+%28%E2%EA%EB%FE%F7%E5%ED+%F0%E5%E6%E8%EC+%F2%EE%EB%FC%EA%EE +%F0%E5%E3%E8%F1%F2%F0%E0%F6%E8%E8%29;
此调试过程的更新
我相信我已经找到了罪魁祸首,在调整了I I s调试诊断工具以提供更多信息之后,我发现URL如下它看起来类似于SQL注入攻击,但我不认为是SQL注入。èñïîëüçîâàí+íèêíåéì+"Rifsadasy";ïèêòîêîä+äåøèôðîâàí;çàðåãèñòðèðîâàëèñü+100%+(âêëþ÷åí+ðåæèì+òîëüêî+ðåãèñòðàöèè);
有人见过这种袭击吗?他们知道是什么吗?
我试过用HEX,Base64和其他一些方法来解码,但除了这个ASCII文本之外,我什么都没有想到:
最佳答案
我认为堆栈溢出不是由于重写器中的错误造成的这是由于过滤器配置中使用的模式中的错误造成的。
实际上,创建一个无休止循环的正则表达式是很容易的,而且PCRE和IIRF都没有办法防止这种情况。也可以在重写规则中创建逻辑循环,以便无休止地重定向或重写同样,过滤器也没办法阻止你射中自己的脚。你得小心点。这些风险存在于使用依赖于任何组件或任何模块化正则表达式引擎的任何子查询时。
堆栈溢出发生在pcre_exec中,这是执行正则表达式的地方这是一个退化的情况,但应该在配置中处理。先前的规则应该过滤掉这些无效的案例。这是a post about using a rewriting filter as a security barrier。
尽早经常测试。有人认为,由于过滤规则只是“配置”,不需要严格的测试一般来说,这不是一个安全的假设像对待任何代码模块一样对待IIRF规则。你只是在用另一种语言。
关于c - IIRF(C程序,ISAPI)中的堆栈溢出,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/1040067/