Making Your Grass the Greenest

October 6th, 2019

Sometime around November 2005, I stumbled upon Scott Berkun’s Essay #41 – Why I Left Microsoft. At the time, I felt inspired by his courage of leaving an environment where he acquired tenure as a program manager for the Internet Explorer web browser project. In his essay, Scott Berkun writes:

So I chose to leave Microsoft less for reasons of escaping a particular place or group of people, but more to seek out a new set of circumstances to live in. Just like I sought out Microsoft to escape my fears of the post-college emptiness, I looked to leave Microsoft to create not a void, but a new space to grow in: one of my own choosing. I ran to Microsoft to escape my fears of failure. I left Microsoft to define my own idea of success.

Like Berkun, there have been times where I was concerned about becoming a “sad, confused bird of prey, circling the same territory over and over again, never understanding why there was nothing new to find.” I am fortunate enough to consistently find or receive opportunities to overcome new and interesting challenges at my current company. Some projects have been tedious and required little innovation beyond skills gained for certifications. Although such projects did not enhance my technical capability, they developed my patience and persistence. I am now working on a project that requires new programming languages, techniques, and paradigms. I am glad to not be circling the same territory. I am finding excitement in helping my current company expand. Maybe the grass is currently arguably greener at other companies, but I feel there is an opportunity for and the possibility of experiencing the achievement of the greenest grass at my current company. Unless a company is disinterested in growth, with sufficient drive and personal motivation this opportunity can be made available at any company.

Personal Password Policies

September 28th, 2019
Posted in Security | 1 Comment

Need secure passwords that are not completely unintelligible? Devise a personal password policy:

  1. Select three or four words from a dictionary. Consider using adverbial forms, past and present tense of verbs. Consider using singular and plural forms of nouns. Avoid idioms.
  2. Pick a number. Consider inserting leading 0s.
  3. Pick a symbol: !@#$%^&*()-_=+
  4. Assemble the above elements with arbitrary rules, for example:
    1. Capitalize 1st letter of each word and leave others lowercase.
    2. Insert symbol somewhere between words, or before the first or after the last word.
    3. Do the same with the number.

Passwords from the password generator featured on this page are magnitudes stronger than those similar to ‘3l337p@s5w0rD,’ and they are easier to type!

Password Generator

Password:
Length:

Securing Dynamically Generated HTML

September 22nd, 2019
Posted in Security | No Comments

Implementing code that simply displays a user’s IP address as part of an HTML page may be considered easy. Without security considerations, it can be implemented in PHP simply with the following:

    echo "IP: " . $_SERVER['REMOTE_ADDR'];

2011 CWE/SANS Top 25: Monster Mitigations recommends establishing and maintaining “control over all your inputs” and “control over all of your outputs.” Since the IP address is output as part of an HTML page, the code is more securely implemented as follows:

    $ipAddrRemote = $_SERVER['REMOTE_ADDR'];
    if(my_is_ipaddr_valid($ipAddrRemote)) {
      $ipAddrEncoded = my_htmlencode($ipAddrRemote);
      "IP: ${ipAddrEncoded}";
    }

The remote IP address is retrieved from the global $_SERVER variable for validation then use. The validated address is encoded before it is used in the output HTML.

The difficulty of selecting appropriate validation and encoding functions is conveniently abstracted away here by user-defined functions: my_is_ipaddr_valid() and my_htmlencode(). The two code samples above demonstrate differences in effort between naive and secure implementations.

Introducing IAsyncDisposable

September 17th, 2019
Posted in C# | No Comments

Being sometimes required to call a particular method before an object is disposed emits a pungent code smell. In particular recently reviewed code, invoking an asynchronous Flush() method was sometimes necessary before a MyStream object was disposed, because asynchronous methods would be otherwise called from Dispose(), which does not wait for completion of those asynchronous methods.

An exception encountered with the following code sample motivates the workaround described above:

using System;
using System.IO;
using System.Threading;
using System.Threading.Tasks;
class MyService : IDisposable
{
  private MemoryStream ms;
  public MyService(MyStream myStream)
  {
    ms = myStream.GetStream();
  }
  public async Task WriteAsync(string s)
  {
    byte[] buf = System.Text.Encoding.ASCII.GetBytes(s);
    await ms.WriteAsync(buf, 0, s.Length);
  }
  public async Task Flush()
  {
    try
    {
      await Task.Delay(50);
      int length = (int)ms.Length;
      byte[] buf = new byte[length];
      ms.Seek(0, System.IO.SeekOrigin.Begin);
      await ms.ReadAsync(buf, 0, length);
      foreach (byte b in buf)
        Console.Write((char)b);
      Console.WriteLine("");
    }
    catch (Exception ex)
    {
      Console.WriteLine(ex.ToString());
    }
    Program.Done();
  }
  public async void Dispose()
  {
    await Flush();
  }
}
class MyStream : IDisposable
{
  MemoryStream ms = new MemoryStream();
  public MemoryStream GetStream()
  {
    return ms;
  }
  public void Dispose()
  {
    ms.Close();
  }
}
class Program
{
  private static EventWaitHandle ewh = 
    new EventWaitHandle(false, EventResetMode.ManualReset);
  public static void Done()
  {
    ewh.Set();
  }
  public static async void Run()
  {
    using (var myStream = new MyStream())
    {
      using (var myService = new MyService(myStream))
      {
        await myService.WriteAsync("success");
      }
    }
  }
  public static void Main(string[] args)
  {
    Run();
    ewh.WaitOne();
  }
}

Calling async methods from Dispose(), which is non-async or async void, potentially causes the following exception:

    System.ObjectDisposedException: Cannot access a closed
    Stream.
        at System.IO.MemoryStream.get_Length()
        at MyService.Flush() in ...\Program.cs:line 22

The exception is caused by Flush() accessing the Length property of a MemoryStream object that has already been disposed. Although the lifetime of myStream is expected to encompass that of myService, the Flush() method is not actually performed until after the myStream object is invalidated by MyStream.Dispose().

MyService.Dispose() does not wait for Flush() to complete even though “async” is added to the MyService.Dispose() method signature and await is used on the Flush() call.1

Also, async void is “generally discouraged for code other than event handlers.”2

A workaround implemented in recently reviewed source code removed the Flush() call from the Dispose() method and introduced an IsFlushBeforeDisposeRequired() method. Then, all instances of the following code snippet:

    using (var myService = new MyService(myStream))
    {
      await myService.WriteAsync("success");
    }

were updated to the following:

    using (var myService = new MyService(myStream))
    {
      await myService.WriteAsync("success");
      if (myService.IsFlushBeforeDisposeRequired())
        await myService.Flush();
    }

Having to repeatedly check whether to call Flush() wherever MyService is disposed stinks! Simply calling Flush(), even if it is empty for derived classes of MyService also stinks!

System.IAsyncDisposable, introduced in .NET Standard 2.1 and .NET Core 3.0, addresses these code smells. async functions can be safely called from DisposeAsync(), which is a method of IAsyncDisposable, and boilerplate cleanup code can be avoided in using-blocks.

The following code is the above code updated to use IAsyncDisposable and works as expected by outputting “success” rather than an exception message:

using System;
using System.IO;
using System.Threading;
using System.Threading.Tasks;
class MyService : IAsyncDisposable
{
  private MemoryStream ms;
  public MyService(MyStream myStream)
  {
    ms = myStream.GetStream();
  }
  public async Task WriteAsync(string s)
  {
    byte[] buf = System.Text.Encoding.ASCII.GetBytes(s);
    await ms.WriteAsync(buf, 0, s.Length);
  }
  public async Task Flush()
  {
    try
    {
      await Task.Delay(50);
      int length = (int)ms.Length;
      byte[] buf = new byte[length];
      ms.Seek(0, System.IO.SeekOrigin.Begin);
      await ms.ReadAsync(buf, 0, length);
      foreach (byte b in buf)
        Console.Write((char)b);
      Console.WriteLine("");
    }
    catch (Exception ex)
    {
      Console.WriteLine(ex.ToString());
    }
    Program.Done();
  }
  public async ValueTask DisposeAsync()
  {
    await Flush();
  }
}
class MyStream : IDisposable
{
  MemoryStream ms = new MemoryStream();
  public MemoryStream GetStream()
  {
    return ms;
  }
  public void Dispose()
  {
    ms.Close();
  }
}
class Program
{
  private static EventWaitHandle ewh = 
    new EventWaitHandle(false, EventResetMode.ManualReset);
  public static void Done()
  {
    ewh.Set();
  }
  public static async void Run()
  {
    using (var myStream = new MyStream())
    {
      await using (var myService = new MyService(myStream))
      {
        await myService.WriteAsync("success");
      }
    }
  }
  public static void Main(string[] args)
  {
    Run();
    ewh.WaitOne();
  }
}

Implementation of the IAsyncDisposable interface, the method signature of DisposeAsync(), and use of await using allows await Flush() to wait for completion before myStream is disposed. The updated code works as expected by outputting “success” instead of an exception message.

250,000 Miles

September 14th, 2019

My 2004 Honda Civic LX Sedan reached 250,000 miles
on August 29, 2019.