Robert Hurlbut's Blog

The Microsoft ACE Team has put together a specific blog on Threat Modeling [found again (again as in I can't remember where I saw the original link over the weeked) through Jason Haley -- btw, check out Jason's new and improved site -- excellent work!].

This, I hope, will be a great resource. I have been impressed with the ACE Team's work, and the TM tool I have been testing recently from them will be a great resource for security people, and for those designing new systems and refitting old systems. Take a look.

I installed the latest Vista 5308 (as released to MSDN subscribers as the Feb CTP version) and so far, I haven't been able to get IIS to install. Has anyone got this working?

Update: Eric Deily (ericde), Program Manager at Microsoft, posted this information in the comments:

You can install IIS7 via Add/Remove Windows Components. To get there, click Start->Computer, then click on "Change or remove a program". In the explorer bar above that says ">Control Panel > Programs > Installed Programs", click the arrow after "Programs", then select "Advanced Options". Double-click on "Windows Features", and you should be able to select what you need in the "Windows Features" dialog, we're under "Internet Information Services".

Also note that there's a web relnote that should go live here shortly that will tell you how to use the package manager command line tool to install IIS7. We signed off on that relnote yesterday. For Vista Ultimate (the relnote contains instructions for how to do this on ALL client editions), you can install using the following "long" command line (run from an elevated command prompt):

start /w pkgmgr /l:log.etw /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

That's a big help. I tried getting the release notes from Connect most of today, but the file manager had problems downloading the documents for some reason. Thanks, Eric!

Keith Brown mentions the 30 minute video he, some Security Developer MVPs, and other well known application security people put together recently called "The Code Room: Breaking Into Vegas". I watched it when it was announced last night and it is hilarious! Enjoy it, and learn something too.

Cast:

• Caleb Sima (CTO & Founder, SPI Dynamics)
• Duane LaFlotte (CTO, CriticalSites)
• Joel Scambray (Senior Director MSN Security, Microsoft)
• Rick Samona (Product Manager, Microsoft)
• Frank Swiderski (Security Software Engineer, Microsoft)
• Keith Brown (Co-Founder, PluralSight)
• John Viega (CTO & Founder, Secure Software)

Hosts:

• Jesse Knapp
• Joe Stagner (Developer Security Evangelist, Microsoft)

Watch it now!

I heard about this sometime ago, and now it looks like the Microsoft Anti-Cross Site Scripting Library V1.0 has been released [found by way of Jason Haley -- if you have no other RSS feed you subscribe to, get Jason's!]

Cross Site Scripting (XSS) is listed on the OWASP Top Ten list of the most critical web application security vulnerabilities at the #4 spot:

The web application can be used as a mechanism to transport an attack to an end user's browser. A successful attack can disclose the end user's session token, attack the local machine, or spoof content to fool the user.

More information can be found here: Information on Cross-Site Scripting Security Vulnerability. Also, Keith Brown did several labs recently that are posted on Channel 9; there is one on Cross Site Scripting as well.

The new .NET library from Microsoft indicates it is supported on Windows 2000, Windows XP, and Windows 2003, and can be used with .NET 1.0, .NET 1.1, and .NET 2.0. The library exposes these two methods: HtmlEncode and UrlEncode (taking a single string paramter). These are the same methods as found in the System.Web.HttpUtility namespace in the .NET Framework today.

Why is there a new set of functions? The standard .NET functions use what is called "black-listing" or implementing the "principle of exclusions". This means they look for specific characters to encode only (such as < (less than), > (greater than), & (ampersand), and " (double quote)). While this is good, certain other characters could slip through that could cause problems. The new library takes the opposite approach with a method called "white-listing" or implementing the "principle of inclusions". This means instead of looking for what's bad and filtering it out, the new methods now look for what's good and considers everything else as bad and replaces those characters with their escape character equivalents. I checked this directly through Reflector, and this is happening underneath. I am surprised this wasn't already done in the Framework, especially for .NET 2.0.

Here is a chart that shows what the new library considers "good" characters (from the documentation):

If you are writing ASP.NET applications (with any of the .NET Framework versions), take a look at this as a more secure solution to guard against XSS.

This has been circulating among the .NET security community for several months, and now finally, we have "official" word that Windows Communication Foundation (WCF, formerly known as "Indigo") will not support partial trust clients or services. Read the announcement here from Doug Purdy [found by way of Dominick Baier].

Kenny Kerr has written an excellent article:

Credential Management with the .NET Framework 2.0

that discusses the Credentials Management API included with Windows XP as well as a method to interact with the API using managed code. He discusses various issues and provides a nice tool called the PromptForCredentials Builder which allows you to establish various criteria for your credential requests and generate code (using Kenny's PromptForCredentials class he built especially for this purpose) for the same. He also mentions SecureString, while a great idea, lacks in general usage at the moment since not every input method (i.e. Textboxes, etc.) allows direct insertion into a SecureString.

Lots of great information and tools here -- you owe yourself a look.

Dominick Baier has posted (titled Beware (=be aware) of ClickOnce default Settings) some startling results from research he completed with the .NET 2.0 RTM version of ClickOnce (beyond the excellent article he and Keith Brown co-wrote here based on the Beta 2 version). He points out the default settings of ClickOnce have changed in a significant way from Beta 2 to the RTM version:

Up to Beta 2 Microsoft chose the following default settings:

Intranet Zone & Trusted Sites: Permission Elevation allowed
Internet Zone: Elevation only allowed for applications signed by a trusted certificate with the “Code Signing” intended purpose.
Untrusted Sites: Permission elevation not allowed

and now:

Microsoft changed this default behaviour in 2.0 RTM – it is now:

Intranet Zone & Trusted Sites: Permission Elevation allowed
Internet Zone: Permission Elevation allowed
Untrusted Sites: Permission elevation not allowed

The significance of this is an unsuspecting user could run malicious .NET 2.0 code from the internet (through a ClickOnce application). This is true simply because the internet application can elevate its permissions after asking the user if it can do so through the standard ClickOnce "let me have permission" dialog!

Dominick summarizes the post with these warnings:

So what to do next?
Make sure you understand the implications of the ClickOnce default settings. You can configure this behavior in the registry. I provide some .reg files to lock down the prompting behavior that you can import. I also wrote an administrative template that can be used to centrally distribute theses settings via Active Directory Group Policy objects. Furthermore educate your users that they should never run executables directly from the internet if they are not 100% sure about what they are doing.

In particular, Dominick (in related posts) points to this article by Brian Noyes which indicates the following:

The registry key \HKLM\Software\Microsoft\.NETFramework\Security\TrustManager\PromptingLevel is the one that allows you to customize the prompting behavior. This key is not present by default after a .NET Framework 2.0 installation, so you will have to create it manually if you want to customize these settings.

Dominick has provided these changes in the lockdown registry script. If you are writing ClickOnce applications, be sure to read this post and understand the issues as well as use his suggestions for locking down your own deployment.

Aaron Margosis is posting a series of posts on "LUA" bugs, including what they are (and what aren't bugs) and how to fix them. As always, excellent work by Aaron to keep developers aware of the issues.

He also mentions briefly the tool he has been developing called "LUA BugLight" which will help developers to find these kinds of bugs. I have seen a demo of this tool, and it looks great -- simple and to the point. Currently, the newly updated Microsoft Application Verifier has this feature, but it is proving to be difficult to use with the mountain of data you need to wade through. So this new tool will be a nice addition to the developer's toolkit (along with the invaluable tools from SysInternals: RegMon, FileMon, and the recently updated Process Explorer [found by way of Sam Gentile]). Stay tuned to Aaron's blog for more information on the new "LUA BugLight" tool.

I found this link to an interesting article on AJAX Security yesterday on the Secure Coding Mailing List, posted by Kenneth R. van Wyk. The article is by Stewart Twynham of Bawden Quinn Associates. The key points to take away are in the summary:

The AJAX "Top 5" security tips:

To succeed - you must start with good planning. Efforts should be focussed on reducing and simplifying the AJAX calls, and creating a standard format for responses that follows convention (ideally XML) where possible.

Follow best practice from sites such as the Open Web Application Security Project. This especially includes checking for Access Control and Input Validation flaws, whilst ensuring sensitive information travels over SSL rather than in the clear.

Never assume that Server Side AJAX checks for Access Control or User Input Validation will replace the need for final re-checking at the Server. Adding AJAX controls will never reduce your validation workload, they will only increase it.

Never assume that Client Side obfuscation (making the JavaScript difficult to read or decode) will protect your most important commercial secrets. Using JavaScript is a poor way to hide programming tricks and advances from your competitors.

Finally, you must be prepared to exercise a tight reign over your development team. Wonderful ideas using AJAX may sound compelling, but you should consider saving them for version 2, whilst you focus on building a rock-solid version 1.

I think the article is timely with the increased focus on AJAX in the web development space, and I have also wondered about the security implications of using AJAX in our applications without thought or pre-planning for security. Take a look at the article. What is your company or development project doing now for security when using AJAX (or some similar variation)?

Update (2/20/2006): Eric Pascarello mentioned in the comments he was interviewed recently by TechTarget on Ajax security. You can read the article here, but here is his list of things to watch for in developing with Ajax:

Pascarello's Rules of Thumb for Ajax Security:

1. If you use user authentication, make sure you check for it on the request page!
2. Check for SQL injections.
3. Check for JavaScript injections.
4. Keep the business logic on the server!
5. Don't assume every request is real!
6. Check the data with validation!
7. Look at the request's header information and make sure it is correct.

Great list! It goes back to the security mantra: Don't trust user input!