Care and Feeding of CreateFile

The Win32 CreateFile call can open not only files but also a handle to a named pipe, a mailslot, or a communications resource. If your application gets the name of a file to open from an untrusted source which you know is a bad thing, right! you should ensure that the handle you get from the CreateFile call is to a file by calling GetFileType. Furthermore, you should never call CreateFile from a highly privileged account by using a filename from an untrusted source. The untrusted source could give you the name of a pipe instead of a file. By default, when you open a named pipe, you give permission to the code listening at the other end of the pipe to impersonate you. If the untrusted source gives you the name of a pipe and you open it from a privileged account, the code listening at the other end of the pipe presumably code written by the same untrusted source that gave you the name in the first place can impersonate your privileged account (an elevation of privilege attack).

For an extra layer of defense, you should set the dwFlagsAndAttributes argument to SECURITY_SQOS_PRESENT SECURITY_IDENTIFICATION to prevent impersonation. The following code snippet demonstrates this:

HANDLE hFile = CreateFile(pFullPathName, 0,0,NULL, OPEN_EXISTING, SECURITY_SQOS_PRESENT SECURITY_IDENTIFICATION, NULL);

There is a small negative side effect of this. SECURITY_SQOS_PRESENT SECURITY_IDENTIFICATION is the same value as FILE_FLAG_OPEN_NO_RECALL, intended for use by remote storage systems. Therefore, your code could not fetch data from remote storage and move it to local storage when this security option is in place.

IMPORTANT
Accessing a file determined by a user is obviously a dangerous practice, regardless of CreateFile semantics.