Thursday, September 18, 2008

ASPNET user account folder and files

Did you ever thought about the folder and files created by Windows XP for the ASPNET user account?

"The ASPNET user account is an internal account and no one is able to log using this identity"

This is the most common answer for my question. And yes, the answer is true. At least it touches the most important part. But there's more.

You see, since Windows XP invokes ASP.NET processes using ASPNET account, it also automatically creates a user folder with typical structure (Application Data, Cookies, My Documents etc.) for this account.

And here comes the strange part: the folder structure for the ASPNET user account is created under "Documents and Settings" but instead of username as a folder name, the machinename/username is used.

Suppose now that your machine's name is XYZ and you use a user account named XYZ. Guess what - you'll see ASPNET user local folder inside your own user folder.

Something tells me that this is not quite right. I should not be able to peek into other user's files but since the folder sits inside my own local folder, I am able to browse it with no restrictions.

I would say that this is rather insecure, no matter if it can be easily misused or not.

Tuesday, September 9, 2008

The "cookie" property of mshtml.IHtmlDocument2 does not work anymore

In one of our applications we host the Internet Explorer ActiveX control in a window and manually create parameters for navigation (including the body and http headers). To correctly inject the ASP.NET session id cookie into such requests (the page we navigate to comes from the ASP.NET server) we have to be able to somehow inject the ASP.NET_SessionId cookie into the navigation context.

The application was written two (or three) years ago, and we've been injecting the cookie using the cookie property of the mshtml.IHtmlDocument2 interface.

/* we've retrieving the reference to the document */
mshtml.IHtmlDocument2 doc = ...; 
 
/* and we've been setting the aspnet session id cookie */
doc.cookie = ...;

This worked like a charm, up to this year - the application is heavily used but only in september (it's responsible for gathering and processing some data available in september and then the data is passed to another appliaction) and this year we've been surprised to see that the cookie property does not work (at least in Internet Explorer 7). Both accessors (set and get) seem to have no effect and you always get the null value from the getter.


Pretty annoying. I guess it's somehow related to security issues but surely it broke the backward compatibility, at least for us.


The solution is to use another method which can inject cookies into the http processing chain:



/* injects cookies into the http processing for
   current process */
[DllImport("wininet.dll")]
public static extern bool InternetSetCookie( 
    [MarshalAs(UnmanagedType.LPStr)]
    string Url,
    [MarshalAs(UnmanagedType.LPStr)]
    string CookieName,
    [MarshalAs(UnmanagedType.LPStr)]
    string CookieData
    );
 
...
    /* first inject the cookie */
    InternetSetCookie(
        "url",
        "ASP.NET_SessionId",
        "theaspnetcookievalue_nomatterhowyougetit" );
 
    /* then navigate */
    webBrowser1.Navigate( "url" );
  
    /* the cookie is correctly set for the navigation.
       although you STILL cannot see it using mshtml.IHtmlDocument2.cookie,
       the http debugger reveals that it's really there 
    */

Wednesday, September 3, 2008

SmtpClient exception - An invalid character was found in the mail header

This hit me today as I tried to move a configuration section to another configuration file. It seems that the SmtpClient class does not like non-english letters in email header.

MailMessage mail = new MailMessage();
 
mail.From = new MailAddress( 
    "noreply@noreply.com", 
    "ąęłóżśńć", // <- the cause of the exception
    Encoding.UTF8 ); 

What's really scary is that the code above actually works - the exception occured only when the subject name was read from the configuration file!


After an intense struggle, I've found the solution. Just add



mail.SubjectEncoding = Encoding.UTF8;
somewhere around. It works, at least for me.