jeff's WebLog : code

on CoUnmarshalInterface

jeffdav — Tue, 08 Aug 2006 01:46:00 GMT

CoUnmarshalInterface() and CoGetInterfaceAndReleaseStream() are not re-entrancy safe. This has certain implications for objects that attempt to unmarshal interfaces into member variables, as a member of my team recently discovered.

Suppose you have something that looks like this:

class MyObject { public: MyObject() { _pUnk = NULL; } HRESULT DoStuff(IStream *pStream) { ... hr = CoUnmarshalInterface(pStream, IID_IUnknown, (void **)&_pUnk); ... } HRESULT DoOtherStuff() { ... IDispatch pDispatch = NULL; if (_pUnk) { _pUnk->QueryInterface(IID_IDispatch, (void **)&pDispatch); } ... } private: IUnknown _pUnk; };

CoUnmarshalInterface() can make a cross-thread QueryInteface() call, which might cause your object to be re-entered. Before it performs the call, however, it stores an internal object in the out parameter. This value is non-null but still invalid. Thus if DoOtherStuff() is called as a result of re-entrancy, you will crash when you deref _pUnk.

To prevent this, you should unmarshal into a temporary value and then check that the value of the member variable is still NULL before you copy the temporary to the member. If it is no longer NULL, someone else wrote to it and you should Release() the temporary.

pop-up blocker and ActiveX controls, part one: IWebBrowser::Navigate(), IWebBrowser::Navigate2()

jeffdav — Thu, 18 May 2006 00:42:00 GMT

As I mentioned previously, one reason users may continue to experience unwanted pop-up windows while browsing is creative use of ActiveX controls that provide methods that allow web sites to open new browser windows. This series of posts will provide best-practices for ActiveX control implementors.

There are two things to keep in mind while considering this topic. The first is, as always, we are committed to application and site compatibility and thus a lot of the pop-up blocker is opt-in and in the abscence of concrete knowledge that a pop-up is unwanted, our default is often to allow the pop-up. The second thing is there are an incredible number of ways to navigate IE, so this will, necessarily, be part one in a survey of this multitude.

Note: If you are a user (and not an ActiveX control developer), and have found this post in an attempt to track down why you are still seeing unwanted pop-up windows, please refer to this post.

Method: IWebBrowser::Navigate(), IWebBrowser2::Navigate2()
Mitigation: Each of these methods takes a set of BrowserNavConstants in the Flags parameter. Controls (and applications) should pass navNewWindowsManaged if they desire pop-up blocker to be applied. Clues that you want this flag would be such things as you are also passing navOpenInNewWindow or are targeting a frame name via the TargetFrameName parameter and that frame may not exist--in which case a new browser window may be created with that name.

IOleCommandTarget, CGID_MSHTML and ActiveX controls

jeffdav — Sat, 22 Apr 2006 00:02:00 GMT

If you write an application that hosts the WebBrowser Control, and you want the control to do something, you can send commands to mshtml via the IOleCommandTarget interface.

However, if you are an ActiveX control and you want to send CGID_MSHTML commands, you may try something like this:

    ...
    IOleCommandTarget *pCommandTarget = NULL;
    hr = _punkSite->QueryInterface(IID_IOleCommandTarget, (void **)&pCommandTarget);
    if (SUCCEEDED(hr))
    {
        hr = pCommandTarget->Exec(&CGID_MSHTML, IDM_FOO, 0, NULL, NULL);
        pCommandTarget->Release();
    }
    ...

If you have tried this, you will see that it fails for CGID_MSHTML commands. It fails because your control is hosted by an object inside of mshtml.dll that delegates all incoming commands to the nearest DocHostUIHandler. For IE, that is implemented by an object in shdocvw.dll (or ieframe.dll for IE7+). That object does not recognize CGID_MSHTML commands.

In order for your call to be routed correctly, you need to get an object "above" the object that is hosting your control. To do this, you can first ask the client site for an IServiceProvider:

    ...
    IServiceProvider *pServiceProvider = NULL;
    hr = _punkSite->QueryInterface(IID_IServiceProvider, (void **)&pServiceProvider);
    if (SUCCEEDED(hr))
    {
        IOleCommandTarget *pCommandTarget = NULL;
        hr = pServiceProvider->QueryService(SID_SContainerDispatch, IID_IOleCommandTarget, &pCommandTarget);
        if (SUCCEEDED(hr))
        {
            hr = pCommandTarget->Exec(&CGID_MSHTML, IDM_FOO, 0, NULL, NULL);
            pCommandTarget->Release();
        }
        pServiceProvider->Release();
    }

By asking for the ContainerDispatch's command target, you get the correct target for MSHTML commands.

on getting IOleCommandTarget wrong (and a bit in the middle about ActiveX controls)

jeffdav — Tue, 11 Apr 2006 21:32:00 GMT

IOleCommandTarget is very useful. It provides a generic way of sending commands between objects. IE makes extensive use of IOleCommandTarget, both publically and internally. And, like IUnknown, people frequently get it wrong.

Each command is composed of a GUID (Command Group Identifier) and a DWORD (Command Identifier).

First, what is wrong with this code:

HRESULT CFoo::Exec(const GUID *pguidCmdGroup, DWORD nCmdID, DWORD nCmdexecopt, VARIANTARG *pvarargIn, VARIANTARG *pvarargOut)
{
   if (IsEqualGUID(CGID_FooCommands, *pguidCmdGroup))
   {
      ...

The answer is obvious: pguidCmdGroup might be NULL and you crash. Furthermore, pguidCmdGroup is frequently NULL, since NULL is how you specify the standard group.

You might say to yourself, "Self, I don't need to worry about NULL, since I am the only consumer of this particular implementation," and that may be the case. However, if you can be CoCreate()'ed, than it is definitively not the case. Remember, any control on your machine can be instantiated as an ActiveX control. During the ActiveX control instantiation process, mshtml will query your object for certain well-known interfaces, like IObjectSafety, IOleObject, and, you guessed it, IOleCommandTarget. If your control responds to IOleCommandTarget, mshtml will attempt to Exec() standard commands. If you do not guard for NULL, you will cause Internet Explorer (and other hosts) to crash.

The second set of common errors come in the form of returning incorrect error codes. The documentation outlines the rules and you must be careful to implement them. If you recognize the group but not the command, OLECMDERR_E_NOTSUPPORTED is the correct return value. If you do not recognize the group, OLECMDERR_E_UNKNOWNGROUP is correct. There is a special case though, which is when the group is NULL and the command is not supported; in this case the correct return value is OLECMDERR_E_NOTSUPPORTED.

on 64 bit data conversion, comctl32 and reading the documentation

jeffdav — Fri, 07 Apr 2006 00:57:00 GMT

Question: What is wrong with this code?

case WM_DRAWITEM: { LPDRAWITEMSTRUCT pdis = (LPDRAWITEMSTRUCT) lParam; COMBOBOXEXITEM cbexItem = {0}; cbexItem.mask = CBEIF_IMAGE | CBEIF_SELECTEDIMAGE; cbexItem.iItem = pdis->itemID; CallWindowProc(pfnOldWndProc, hwnd, CBEM_GETITEM, 0, (LPARAM)&cbexItem); ... }

Answer: It will break on 64 bit machines.

This is just one example of a well-known issue. ComboBoxEx makes frequent use of -1 when asking for the item in the box. Notice the item we ask the ComboBoxEx for comes from the itemID member of the DRAWITEMSTRUCT. This seems like a perfectly normal thing to do. However, when using data structures such as the ones commonly defined throughout Win32 and ComCtl, data structures that you the programmer did not define, it is important to look closely at the data types in the documentation.

DRAWITEMSTRUCT's itemID member is a UINT, while COMBOBOXEXITEM's iItem member is an INT_PTR. So what happens when -1 is assigned to itemID then you assign that value to iItem?

Well, the UINT value is a 32 bit number on 64 bit machines and will have a value of 0xFFFFFFFF when comctl32 assigns -1. Later, when this is assigned to the INT_PTR value, which is a 64 bit value on 64 bit machines, it will have a value of 0x00000000'FFFFFFFF. This value is handed back to comctl32 in the form of the CBEM_GETITEM message. When comctl32 does a comparison of the INT_PTR value against -1, it will be comparing against 0xFFFFFFFF'FFFFFFFF, and the comparison will fail. Since your combo box probably doesn't have 4294967295 items in it, the CBEM_GETITEM call will fail to return useful information. The corrected code is:

cbexItem.iItem = (INT)pdis->itemID;

The moral of this story, in case you missed it, was know your data types and think carefully about what will happen in the 64 bit case when performing assignments that imply casts.

on IObjectWithSite, IOleObject and ActiveX controls

jeffdav — Tue, 28 Mar 2006 19:45:00 GMT

ActiveX® controls frequently need to communicate with their containing object. For example, a control may want to QueryService for the cached InternetSecurityManager object to decide whether or not to take a particular action. Controls can obtain a pointer to their containing object (also called the object's site) in one of at least two ways.

The typical scenario is Internet Explorer hosts the ActiveX® control inside of an object implemented in mshtml.dll. Controls that need to communicate with their container implement IOleObject and mshtml will call the SetClientSite method with a pointer to itself. Communication can now proceed by querying the given IOleClientSite pointer.

However, there is another scenario that authors of ActiveX® controls must consider. Controls can be dynamically created through script, e.g.:

<script> oAX = new ActiveXObject('MyControl'); </script>

In this case, the control is now being instantiated not by mshtml.dll, but by jscript.dll. Since jscript.dll does not implement any OLE containers, it does not set a client site pointer via IOleObject. It does, however, maintain an IServiceProvider chain to mshtml that can be accessed by an ActiveX® control. The control must implement IObjectWithSite. Now jscript will be able to call SetSite and the control can query the IUnknown pointer for services it requires from its container.

Astute readers may, at this point, notice something funny in the documentation. IObjectWithSite's documentation says, without elaboration: "This interface should only be used when IOleObject is not already in use." This has to be read carefully. Notice the documentation uses the words "...in use," not "...implemented." You should keep track of the two different site pointers and prefer the one obtained from IOleObject. If, however, you find that site is NULL then IOleObject is not being used and it is acceptable to fallback to using the site obtained from IObjectWithSite.

the importance of context

jeffdav — Tue, 11 May 2004 21:07:00 GMT

Almost every navigation in Internet Explorer results in a flurry of security checks. Many of these checks are fairly obvious things, such as checking the URL of the current location (the context URL) and the pending navigation's destination URL to see if their zones/domains/protocols/etc are the same/different/acceptable/etc. Much of my time recently has been spent debugging strange combinations and ways of navigating. I will not bore you with the details; my goal is to emphasize the importance of context. I will mainly speak to the Internet Explorer Pop-up Blocker's dependence on the context URL.

The Pop-up Blocker is dependent on the context URL. When the page attempts to open a new window, mshtml queries the Pop-up Blocker. The Pop-up Blocker looks in the white list to see if this page is exempt from new window management. If, for some reason, the context URL provided is NULL, then obviously it cannot be matched to a domain in the white list.

So let us examine the following:

var oSpan = document.createElement("span");
oSpan.innerHTML = "<a href='http://www.microsoft.com' target='_blank'>Microsoft.com</a>";

When the anchor causes the browser to navigate, it will see the _blank and attempt to open a new window. This attempt will have to be verified by Pop-up Blocker. But the span is not parented to anything, thus it has no context. Elements with no context get the default context, which is about:blank, which confers no rights.

The moral of this story is always remember to parent your dynamically created elements to something in the document:

document.appendChild(oSpan);

Muah.

on calling refresh during onResize

jeffdav — Tue, 20 Apr 2004 19:33:00 GMT

From time to time I have come across web sites that do something like this:

Generally this is done so the page can redo all of the necessary layout calculations for the new size it is being constrained to. This leads to a lot of useless page reloads as the user drags the window around. Really complex pages could have quite a perf impact on the machine.

Of course with XP SP2 there is an additional concern: if the page automatically launches a download, or tries to install an ActiveX control, or automatically launches a pop-up window the information bar will appear at the top of the page. To make room for the information bar, the mshtml window will be resized. With the above HTML, the appearance of the information bar will cause the page to reload. This will start the cycle all over again, leading to infinite page reloading. It is better to have layout methods that can be called directly, instead of being lazy and just refreshing the page.

Another good practice is to not assume that window.open() will always succeed, but instead check the return value for null before using it. If it returns null, your script should handle it. There has always been the possiblity of failure while creating a new window.

Doc links: execCommand onResize window.open

a brief history of setHomePage()

jeffdav — Tue, 13 Apr 2004 22:25:00 GMT

I started working on IE right after IE 5.5 shipped. Since then, there is one little feature which has been the subject of my loving attention from time to time-- setHomePage().

setHomePage() is implemented as a behavior in iepeers.dll. It takes one argument-- the URL you would like to prompt the user to set as their homepage. MSDN claims this functionality has been available since IE 5.0. I do not know who dreamt it up, but on the surface it does not seem unreasonable for a website to be able to prompt the user, and, having recieved the users consent, have the browser set the home page for the user. But, alas, we live in strange times and drive-by hijacking of a users home page seems to be a full on business model.

For a long time the implementation of setHomePage() would simply take the string it was given and display it in single quotes in the dialog box and wait for the user to make a decision. Clever people figured out you could insert \n and \t to format the dialog in strange ways. This allowed them to socially-engineer users into clicking Yes. This was fixed in IE6; we now verify the untrusted input first.

For a long time the default answer for the dialog was Yes. For XP SP2 the default value will change to No.

One especially nefarious method of getting users to answer yes was to use window.createPopup() to cover up and/or change parts of the dialog. For XP SP2 window.createPopup() has a whole new set of constraints-- must not cover dialog boxes, must not try to exist (too far) outside the boundaries of the HTML rendering surface, only one instance allowed at a time, etc.

The biggest change for XP SP2, the one I predict will impact web developers the most, is this: setHomePage() will fail with an access denied error if it is not called within a user initiated context. This means:

will fail with Access Denied. But the following code will work as expected:

<span onClick=”oHomePage.setHomePage(‘http://www.niceguys-b-usasdf.com’);”>Click here to make us your home page!</span>

Personally, I use about:blank as my home page because the browser window opens faster. This is especially important over terminal services!

channel 9

jeffdav — Thu, 08 Apr 2004 20:07:00 GMT

If you have not had a chance to check out channel 9, click on over.

avoiding script injection and other lessons

jeffdav — Fri, 06 Feb 2004 20:43:00 GMT

MSDN has had an article entitled Security Considerations: Dynamic HTML for a while. It is a good article, but it simply says what not to do. Everytime I run across it I promise myself I am going to write something more useful someday, something that says “Don't do this; do this instead.” Today is that day.

Injecting Script

The following is a list of things you should be wary of:

These things are safe to use if and only if you do not allow untrusted input to find its way to them. For example, the following is perfectly safe:

document.writeln('Mysterious hardcoded string #5');

But I doubt the majority of use these functions see are to insert static strings. Frequently they are used to do more useful things. Let us assume you want to display an URL as a link on your page, but that URL can change and it is untrusted input. The simple and insecure way to do this is:

document.write('<a href=“' + szUrl + '“>' + szUrl + '</a>');

Now you have opened yourself up to all the nastiness of script injection. You must, at this point, resist the temptation to write code to 'sanitize' the string before the document.write(). This is very hard to do correctly. You can remove 'invalid' characters and you can subject it to regular expressions and you can do all sorts of clever things. What you must remember is the attacker can view the source code and spend an unbounded amount of time crafting an url that will get past your protection. Things like url escaping and the large variety of valid url syntax will give you quite a headache. If you must insert untrusted input, the following is the safe way to do it:

    var aElement = document.createElement(”A”);
    aElement.innerText = szUrl;
    aElement.href = szUrl;
    urlContainer.appendChild(aElement);

    ...

    <span id=”urlContainer”></span>

All of the bulletted items above can be converted in similar ways. When reviewing your code, ask if you really meant innerText where you used innerHTML. Grep your codebase for “document.write“ and justify the existence of each one. Ones that you cannot get rid of should be converted similar to the example above.

HTML Dialogs

This particular flavor of script injection often manifests itself when web page authors use HTML dialogs. If you see the word dialogArguments [doc link] anywhere in your code, you need to be extra careful to avoid this kind of script injection. You should grep your code for “dialogArguments” and closely examine your usage of it.

Social Engineering

Be careful about displaying untrusted input. You may be able to do it and safely and avoid script injection, but you might still allow clever people to format things such that they can fool casual surfers into doing something bad. I feel bad for not having a concrete example, but the mischievious readers out there will know what I mean. Keep this in mind when designing your web site.

enums and DeleteMenu()

jeffdav — Thu, 13 Nov 2003 04:46:00 GMT

I wanted to add a menu item that had a child menu to one of the menus in the IE menu bar. I always kind of dread adding menu items to IE, because there is a lot of stuff going on there. IE and Explorer share the same frame, and the menu items are different depending on whether the frame is hosting the default shell view ("c:\foo", etc.) or mshtml ("http://www.msn.com", etc). It gets even crazier when you consider we can also host office documents and then we get all their menu commands as well.

Anyway, all I wanted to do was add a little submenu. The first thing I had to do was to create the submenu. All I did was define my base id and an enum for each submenu item. That way I could create an array of bools (not shown) to keep track of which items were on and which items were off and easily access them by id. I inserted each submenu item as ID_MENU_BASE + ID_subitem. It was easy:

    ...

    enum
    {
        ITEM_FOO,
        ITEM_BAR,
        ITEM_BAZ,
        ITEM_ETC,
        ITEM_QUX,
        ITEMCOUNT
    };

    ...

    HMENU hMenu = CreatePopupMenu();
    WCHAR szDisplay[128];

    if (hMenu)
    {
        LoadString(HINST_MYDLL, IDS_FOO, szDisplay, ARRAYSIZE(szDisplay));
        AppendMenu(hMenu, MF_STRING | MF_ENABLED, ID_MENU_BASE + ITEM_FOO, szDisplay);

        LoadString(HINST_MYDLL, IDS_BAR, szDisplay, ARRAYSIZE(szDisplay));
        AppendMenu(hMenu, MF_STRING | MF_ENABLED, ID_MENU_BASE + ITEM_BAR, szDisplay);

        // ... etc.  Repeat for each item in the enum.
    }

    ...

Then I had to figure out how to insert a menu item that had MF_POPUP set and an identifier set. I had to set the identifier because later on when I want to delete it, I would not necessarily know what position it would be in, since menu items tend to come and go. InsertMenu() reuses the uIDNewItem argument, so if you set MF_POPUP you have to pass the handle to the submenu in the field where you would otherwise set the id. So instead I had to use InsertMenuItem():

    ...

    MENUITEMINFO mii = {0}; 
    mii.cbSize     = sizeof(mii);
    mii.fMask      = MIIM_ID | MIIM_STATE | MIIM_SUBMENU | MIIM_TYPE;
    mii.fType      = MFT_STRING;
    mii.fState     = MFS_ENABLED;
    mii.wID        = ID_MENU_BASE;
    mii.hSubMenu   = hMenu;
    mii.dwTypeData = szDisplay;
    mii.cch        = lstrlen(szDisplay);

    InsertMenuItem(hMenuRoot, ID_ITEM_TO_INSERT_BEFORE, FALSE, &mii);

    ...

And the last thing I had to do was delete everything when it needed to go away. Seemed easy enough:

    DeleteMenu(hMenuRoot, ID_MENU_BASE, MF_BYCOMMAND);

And it did not work. I was very sad. Here is why it did not work: I was off by one. In cases where my submenu included ITEM_FOO, ITEM_FOO was appended as ID_MENU_BASE + ITEM_FOO = ID_MENU_BASE + 0 = ID_MENU_BASE !! (Note: + 0 because ITEM_FOO is the first member of my enum.) If the item you ask it to delete has a submenu, DeleteMenu() has to go and delete all submenus of the item and it does so recursively. It looked at my submenu, saw the first item was what I asked it to delete and promptly stopped recursing.

The moral of this story: Do not make submenu items that have the same identifier as any of their parent items.