Robert Hurlbut's Blog

In my everyday life, I work with both SQL Server and Oracle databases to develop databases, schemas, stored procedures, and functions as well as the middle-tier applications that wrap the database functionality.  Along with that work, I also spend a lot of time validating input data, and dealing with other issues of secure coding.

In my upcoming security talk, I will spend some time outlining the dangers of SQL Injection, as I have mentioned before.  I have mentioned, and mostly seen, the problems that you can have with SQL Server regarding SQL Injection, but similar attacks can be done with Oracle, and many other database vendors.  I found a great article today that was mentioned on one of my security mailing lists (sign up for the SC-L mailing list at securecoding.org).  The article is An Introduction to SQL Injection Attacks for Oracle Developers.  There are some really good tips and advice in the article on countering SQL Injection in regards to Oracle databases.  This is also a great read for a general introduction to understanding this important security topic.  Get it today, and be informed.

By way of Harry Pierson's DevHawk blog:

patterns & practices has published a new App Block: Authorization and Profile.

This block is a reusable code component that builds on the capabilities of the Microsoft .NET Framework to help you perform authorization and access profile information.

You can read it online or download it.

If you have worked with Shadowfax, some of this code should already be familiar (under the Security folder).  It's great to see it is now available separately.

I have been busy the last few days writing lots of code for business and data components.  I came across an interesting “bug” in VS.NET.  In my unmanaged days, I would compile all binary files to a central location in order to quickly register and/or deploy them into an install application.  Carrying over that habit, I set up my VS.NET projects/solution to compile to one folder as well (i.e. Dev\Bin\Debug and Dev\Bin\Release, accordingly).   But, late last night, I started to get this message:

Could not copy temporary files to the output directory.
The file 'assembly name' cannot be copied to the run directory. The process cannot access the file because it is being used by another process.

It turns out there is a bug in VS.NET:  BUG: "Could Not Copy Temporary Files to the Output Directory" Error Message When You Build a Solution That Contains Multiple Projects (Q313512).  Apparently, when an assembly gets over 64 KB in size, the IntelliSense engine of a project will lock a referenced assembly. The IntelliSense engine locks only those referenced assemblies that are larger than 64 KB.  In this case, as I was seeing while debugging which assemblies the VS.NET process was holding, I did find my assembly being “locked“!

Mark Michaelis wrote about this last October and had some very helpful tips:

If you create a solution that compiles multiple projects to the same folder and the compile is larger than 64 KB you are bound to encounter and error such as "Could Not Copy Temporary Files to the Output Directory."  To avoid this try the following steps:

1. Set the Copy Local property of the project to True
2. Leave the output to the VS.NET default location, ..bindebug for example.
3. Setup references to point to the common output location, ..bin  for example.  Obviously this requires at least one compile.
4. Add a post build step to copy the DLLs to the common location:
        copy $(TargetDir)$(TargetName)*.* r:bin

(Thanks to John Pritt for this info.)

 

On February 3, 2004, I will be speaking to the Boston C# Users Group in Waltham, MA (at the Microsoft offices) on one of my favorite topics:  Secure Coding: Best Practices.  Essentially, it is an extension of the topic I mentioned in this post (Part 1).

Here is a summary of what I will be talking about:

Security is important to nearly every company, but security can never be an add-on to an existing product.  Developers need to be aware of common security threats, and they need to follow best practices for developing secure code.  This presentation will introduce security topics such as checking data input, buffer overruns, Cross-Site Scripting, SQL injection, and the Rule of Least Privilege.  The best techniques for secure coding will also be demonstrated.

If you are in the area, stop by and say hello.

Last July, I mentioned I installed DevHawk Wiki as our team's Wiki engine.  About a month ago, we decided to upgrade to FlexWiki instead.  It was very easy to move our Wiki pages from one Wiki engine to another.  If you are looking for a low-friction collaboration tool for your group or organization, check out Wiki.  Our team uses it extensively to keep updated on the project (FlexWiki also provides RSS feeds of updated and new pages!).

This week, I moved our Wiki to a new machine (after updating FlexWiki to the latest version), and installed the much recommended security tools IISLockdown and URLScan on a Windows XP box.  What I found was the Wiki was no longer working!  It turned out that URLScan was prohibiting the viewing of pages that have extra “dots” in the URL. 

One of the ways Wiki works is that pages are created as text files with .wiki extensions.  If you have a CoolProject as your Namespace, for example, as a folder location of your Wiki files, and have created a new Wiki page for your name, RobertHurlbut.wiki, for example, then to see the page in FlexWiki, you would use this URL: 

http://localhost/Wiki/default.aspx/CoolProject.RobertHurlbut

Notice the “dot” in the URL.  For URLScan, you can configure the AllowDotInPath filter setting from 0 (default) to 1 in the urlscan.ini file.  This fixed the problem with viewing Wiki pages in FlexWiki.

Note:  Notice that URLScan 2.5 is the latest version.  With IIS 6.0 (only on Windows Server 2003), many of the features of IISLockdown and URLScan are now either built into IIS 6.0 or are better than what is offered by these tools.  In some cases, though, URLScan does offer some out of the box features that IIS 6.0 still doesn't offer.  See this article to determine if you should install it or not on Windows Server 2003:  http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/urlscan.asp.  For all other OSs (i.e. Windows NT, 2000, XP), you should install these security tools.

Debug Note:  One other “gotcha” with URLScan is that it watches for the key verbs coming across:  GET, POST, etc.  In order to debug ASP.NET pages, when URLScan is installed, you must add the verb DEBUG in the allowed verb list in the urlscan.ini file (as noted here).

Update:  As Darrell Norton points out on his blog, for .Net, you can download the specific urlscan.ini files for .Net Production and .Net Development servers.  These scripts are featured in the Operating .Net Applications, part of the the excellent Patterns and Practices series from Microsoft.  Thanks again, Darrell.

Looking for a good summary of information on the Global Assembly Cache (GAC)?  Jeremiah Talkar has updated his article on The Code Project:

Demystifying the .NET Global Assembly Cache - Good roundup of info, including various APIs for interacting with the GAC, what it contains, and what you can do with it. [from Mike Gunderloy's Larkware News]

If you spend any time with .Net Security and/or Enterprise Services, you should look at this article as both technologies require some knowledge and understanding of the GAC. 

Continuing the saga, I was able to find someone at Oracle who could duplicate the problem we had been having, and it definitely was the MTS proxy file from Oracle.  In particular, its the oramts.dll file, part of the Oracle Services for MTS 9.2.0.4 package.  I found Oracle had noted it internally as a bug back in December, but it hasn't been updated in the above package.  I was pointed to a zipped version of the oramts.dll to download and install.  After installing (actually, replacing the old oramts.dll file with the new oramts.dll file), all of my distributed transactions using COM+, ES, ODP.NET, and Microsoft's Oracle Provider worked!

Updated:  A patch is available on MetaLink as patch #3252645.  Download the p3252645_9204_WINNT.zip file which contains oramts.dll and oramts.dbg, marked as version 9.2.0.4.1, fixing the following issue:  BRANCH IN TX GIVES: NEW TRANSACTION CANNOT ENLIST IN THE SPECIFIED COORDINATOR.  Obtain the patch if you are using Oracle Services for MTS 9.2.0.4 with OraOLEDB, ODP.NET, and/or Microsoft's System.Data.OracleClient .NET provider.

I am assuming the fix was something similar to what Florin mentioned to us (listed in Sam's post).