13

In C++ world there is a variety of ways to make an exploitable vulnerability: buffer overflow, unsafe sting handling, various arithmetic tricks, printf issues, strings not ending with '\0' and many more. Despite most of these problems were solved in java, there are some things to talk about. But is there any list of typical C#-specific coding vulnerabilities? (and not related to .NET platform itself)

Improve this question
5
  • 2
    I think this should be a community wiki. It's a good question, but there is no single answer to it. Commented Mar 3, 2010 at 18:33
  • @Frank: Why? Any 'issue' would be a correct answer. Commented Mar 3, 2010 at 18:36
  • 1
    This is a good question and books have been written on this topic. I think it is a bit broad for stack overflow and most of the answers thus far are overly simplistic. Commented Mar 3, 2010 at 18:50
  • Could you name any book about this and not about general .net security? Commented Mar 3, 2010 at 18:53
  • 1
    @Henk: The fact that you can say "Any 'issue' would be a correct answer" indicates that it should be a CW. Commented Mar 3, 2010 at 20:52

5 Answers 5

Reset to default
6

Here are a few issues you can run into:

  1. If you've got any sort of language interpreter (HTML, JavaScript, and SQL being the big three) then you can still have injection or XSS vulnerabilities.
  2. P/Invoke can cause problems, especially if you're doing any custom marshalling. Even if you're calling a "safe" API through P/Invoke, your marshalling code could contain a bug that corrupts or exposes memory.
  3. If you're doing file access then you need to make sure your files are always in acceptable directories. Be sure to sanitize against bad absolute and relative paths.
  4. Cryptography. Good cryptographic programming is really hard, and .Net's various safety features do nothing against crypto attacks.
Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

+1 Totally correct, but I'm sure this isn't a complete list.
We'll come up with a complete list of vulnerabilities right about the time we solve the Halting problem with brute force. Additionally, point #4 is a large category that could be split into a huge number of smaller vulnerabilities.
these are also not C# vulnerabilities - just general .NET and ASP.NET vulnerabilities.
5

C# is based on .NET and .NET is supposed to be type-safe, which means none of your list of horrors applies to C# or any .NET language.

But then again, C# has an unsafe keyword and after that all bets are off.
It allows real pointers and everything that comes with them.

Improve this answer

Comments

2

Not really. I'm going to make a bold statement here:
There's no such thing as a "C#-specific coding vulnerability that isn't related to the .net platform".

A program written in C++ is compiled directly into a machine executable, so the language compiler is directly responsible for the creation of the executed code, hence the way C++ can be easily capable of "creating an exploitable vulnerability".

A program written in C# however is compiled into IL, which is the only language that the .net platform works with. The .net environment creates a machine executable based on that IL code. Everything that C# can do is merely a subset of what the .net platform is capable of. This is how I can make my bold statement. Anything you could possibly do with C# that created a coding vulnerability would be one of:
1) A bug in the .net platform
or
2) Executing code outside of the .net platform

So the way your question is currently phrased leads me to believe that either you're not fully aware of the huge differences between "writing code in C" and "writing code for the .net platform" or I'm misunderstanding your question. Perhaps a bit of both! 8 )

Hope this helps!

Improve this answer

Comments

0

Probably none from your list of concerns but this is the one to be careful with: void*

Improve this answer

4 Comments

How is void* a coding security issue specific to C#?
@John Saunders: "void*" is valid in C# but it is not recommended, see this: msdn.microsoft.com/en-us/library/y31yhkeb%28VS.80%29.aspx
@Sameh: "In an unsafe context". Stay out of unsafe contexts (like an unsafe block) and you won't have to worry about void*.
The context is called unsafe for a thing. All code in the unsafe context is unsafe.
-1

Don't forget, you can call any C++ from C#. I do it all the time. So all the buffer overrun issues and so on for C++ are relevant for C# as well even if you don't directly call C++ because C# calls C++ to do it's work.
Think about it. And any COM calls and Marshal calls are just as open to attack as normal. In Linux you can use _r routines and in Ver 8 up in VC++ you can use _s routines to lessen then chance of buffer overflow (requires user buffers and/or max sizes). About the only way to stop vulnerabilities is to turn off your computer and read a paper back book (unless it too has a virus).

Improve this answer

1 Comment

You can't just call any C++ from C#, at least not directly. C#, and .Net in general, provide a string type and handle buffers; you don't deal with C string functions, nor do you have to make sure to use the safe variants. This doesn't actually answer the question at all, no C#-specific security issues are noted.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.