SECSYM: Security Symposium IV

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!