SECSYM: Security Symposium IV

SECSYM: Security Symposium IV

  • Comments 4

Managed code is safer code! The following function is a C# analogue of a previous fragment:

   private void CopyStuff(string data)
   {
      char[] buffer = new char[128];
      data.CopyTo(0, buffer, 0, data.Length);
      // do other stuff
   }

If the output buffer is too small in the above scenario, the CLR will simply throw an exception.

Does that mean that all input can be trusted in managed code? Certainly not. For example, ASP.NET provides some built-in protection against cross-site scripting attacks: if you entered some JavaScript code into a textbox, with code in a button to display the text in a label, and ran this, ASP.NET would throw an exception. The mitigations are not absolute, however. The Page directive includes an option ValidateRequest="False" which switches this off, for instance. As ever, you should verify all input data before trusting it. Remember the defender's dilemma: you might not have thought of all the potential attack scenarios.

Another example of where you need to be careful in managed code is remoting, which has no built-in authentication or encryption support. One solution is to use HTTP channel to leverage the built-in sinks. SQL injection attacks are problematic in many applications too: using stored procedures with parameters and validating the input data are both approaches to deal with the problem.

One esoteric problem is the Turkish İ problem. Turkish has four letter Is: I, İ, ı and i. In Turkish, UC("file") == "FİLE". This introduces some subtle bugs, such as the following:

   // Do not allow file:// URLs
   if (url.ToUpper().Left(4) == "FILE") return ERROR;
   getStuff(url);

This shows how hard it is to validate input data!

Page 1 of 1 (4 items)