views:

1449

answers:

3

Can there be buffer overflow/overrun vulnerabilities in completely managed asp.net web portal.If yes how can this be tested.

+4  A: 

Not unless you exploit the webserver or .NET/ASP.NET stack itself.

Cody Brocious
Can you explain more please.
Pradeep Kumar Mishra
If your code is completely managed, then there's no way to buffer overflow the code that YOU write. But the stack (.NET and such) that you're built on top of is not written in pure managed code, so there's a possibility to exploit those, even if it's small.
Cody Brocious
Thanks a lot for your answer.
Pradeep Kumar Mishra
+4  A: 

In the general case, you don't need to worry about buffer overruns. This is one of the major advantages of managed code, garbage collection being perhaps the other major advantage.

There are a few edge cases that you should be aware of - any time your managed code interacts with unmanaged code (Win32 API calls, COM interop, P/Invoke, etc) there is a potential for buffer overruns in the unmanaged code, based on parameters passed in from managed code.

Also code marked as "unsafe" can directly manipulate memory addresses in such a way as to cause buffer overflow. Most C# code is written without using the "unsafe" keyword, though.

Mark Bessey
+1  A: 

I had a tool (HP Dev Inspect) detect a possible "Possible Parameter Buffer Overflow" within my ASP.NET app and it was because we didn't have a MaxLength="20" in one of our TextBoxes...

Different kind of buffer overflow, well sort of. If your textbox's value is passed unchecked to, oh, say, a SQL parameter, it could wreak havoc--or if it's passed to a function that wasn't expecting the entire text of "Call of Cthulu" for a parameter, it could behave badly.Know that savvy users (such as those using FF's Web Developer extension) can just turn off MaxLength. It's a convenience defense, not something that you should count on.You should always check user input for length if it's going to matter.
Broam