What I Learned – 2019 Week 2

What I Learned – 2019 Week 2

Principle of Least Astonishment

Resources:

I stumbled upon this, and was surprised I have not heard of it yet. The basis of the principle is that user interfaces of any sort (in tech or in real objects) should conform to the common assumptions and expectations of the user, making those interfaces intuitive and pleasant to use. For me, this is something I’ve preached for a long time, but never realized there was an “official” principle for it. This is applicable to more than just a UI, or doorhandles, but also to code structure, naming conventions, project organization…etc ToString() should format something into a string representation of itself, not perform other behaviors, GetStudent() should get a student, not write changes to a database or change the state of a record, the logout button should log you out, a red X typically means close/cancel/delete ….etc

Process Monitor Tool

Resources:

In the process of debugging a permissions issue with IIS I found this handy tool that provides VERY in-depth information about process activity in windows. There isn’t much to say here, but for my use case I was able to narrow down the events to a specific directory and a specific status type, as well as easily exclude processes, statuses, users, paths…etc that I didn’t want to see. I will admit that it’s filtering is very slow, I had ~3million events when I started filtering and it took nearly 7 minutes to exclude all events with the SUCCESS status from the view, which is ridiculously slow given that it’s all in memory. Other than that, it works as expected.

 

IIS User Account & Permissions

 

Problem:

There is a client application with a dev environment that doesn’t run that I’ve been tasked with fixing. This environment uses IIS 6 as the webserver, and Visual Studio for the actual development/building. When navigating to the local site I am presented with the following error:

 

Details:

A key takeaway here is Cannot read configuration file due to insufficient permissions. This is indicating that the user the IIS process runs under does not have the necessary NTFS permissions to access the configuration. The user for this is IIS_USERS, which needs Read, Execute, and List permissions on your web directory. Do note that if this is a domain device, you will need to change the principle location when trying to add this user to the Permissions Entry for the directory.

Once this was done, I went to reload the page and was presented with yet another error An error occurred while accessing the resources required to serve this request. You might not have permission to view the requested resources.:

Turns out that there is another user that needs access to the directory IUSR. After adding a PermissionEntry for this user I was able to access the site as expected.

 

Summary:

In summary, there are two local user that IIS uses that need Read, Execute, and List permissions for the web directory:

  • IIS_USERS
  • IUSR

IIS and Security Authorization

Resources:

Version: 8.x

I recently had an issue where a log file (log.txt) for a clients legacy web application was publicly accessible, anyone on the internet could find and read the constantly changing log file. This is of course a security nightmare if the log file contains sensitive information. The quick fix was to remove the “Everyone” rx NTFS permissions for the file, so it cannot be accessed by anyone. This is a bit hacky, and not easy to track and maintain, so the next thing to do is to ensure that sensitive files are restricted through the aspnet filter. Since the log file gets happily served up by IIS without going through any sort of authorization stage.

The way I’m familiar with is to utilize the <authorization> element in the web.config:

Despite many forums, StackOverflow, and even the Microsoft docs saying this is how you do it, it didn’t work. It turns out I need to add a Handler Mapping for the text file, this is a multistep process:

  1. Open IIS Manager and go to your site
  2. Open “Handler Mappings”
  3. Find an existing *.aspx mapping, probably called PageHandlerFactory-ISAPI
  4. Retrieve the path of isapi.dll from an existing *.aspx mapping. The x86 vs x64 doesn’t matter as far as I know
  5. Create a new Managed Handler for *.txt files and use the previously retrieved path for the Type: field
  6. Add the above <authorization> code to the web.config

 

1 & 2: Open IIS Manager and go to your site & Open “Handler Mappings”

3: Find an existing *.aspx mapping, probably called PageHandlerFactory-ISAPI

4: Retrieve the path of isapi.dll from an existing *.aspx mapping

5: Create a new Managed Handler for *.txt files

 

When this is all said and done, accessing that file should either show a 401 unauthorized error or a 302 found and  redirect the user to the login page of the site to authenticate, and if they are logged in it should redirect them to the home page when they try to access the file. I did not dig in deeper into the details of how this portion of the configuration works, as it was not in the time budget.

Tools

DnsDiag

This is a command line tool that lets you perform various DNS functions to determine if your DNS requests are being hijacked or misrouted. I originally found this when I was suspicious of my ISP hijacking DNS requests, as DNSSEC data was always missing or invalid, causing Unbound to fail to resolve requests since I keep it in strict DNSSEC mode.

Other Articles

Leave a Reply

Your email address will not be published. Required fields are marked *