WinFS

WinFS has been puttering around my idle thoughts lately. 

Yep, weird.

Why is it still available on MSDN and TechNet subscriptions?

Food for thought.

Visual Studio Step Up Promotion...The Headache

A few months ago some friends of mine at Microsoft told me about a step-up promotion that was going on for the release of Visual Studio 2010.  If you purchased a license for Visual Studio 2008 through Volume Licensing, it would translate into the next version up for the 2010 version.  Seems fairly straightforward but here is the actual process:

vsStepUp

So we upgraded our licenses to benefit from the step up.  Problem was, we couldn’t access any of the applications we were licensed to use (after RTM, obviously).  After a week or so of back and forth with Microsoft we finally got it squared away.  A lot of manual cajoling in the MSDN Sales system, I suspect, took place.  It turns out a lot of people were running into this issue.

Someone told me this issue got elevated to Steve B (not our specific issue, but the step-up issue in general).  I’m curious where things actually went wrong.  I suspect the workflow that was in place at the business level wasn’t in place at the technical level, so everything ended up becoming a manual process.  However, that is purely speculative.  Talk with Steve if you have questions.

In the end, everything worked out.  I got Visual Studio 2010 installed (which fricken rocks, btw), and my productivity will go up immensely once we get TFS deployed.  After of course, it has the necessary drop while I’m downloading and playing with the new MSDN subscription.

For those that are interested in the promotion, it’s still valid until the end of April.  Contact your account rep’s if you are interested.

Visual Studio 2010 RTM!

Earlier this morning, Microsoft launched Visual Studio 2010.  Woohoo!  here’s the jist:

Watch the Keynote and Channel 9 Live here: http://www.microsoft.com/visualstudio/en-us/watch-it-live

Get the real bits here (if you have an MSDN license): http://msdn.microsoft.com/en-ca/subscriptions/default.aspx

Get the trial bits here:

Get the Express versions here: http://www.microsoft.com/express/

All the important stuff you want/need to know about Visual Studio 2010 development: http://msdn.microsoft.com/en-ca/ff625297.aspx

Enjoy!

ViewStateUserKey, ValidateAntiForgeryToken, and the Security Development Lifecycle

Last week Microsoft published the 5th revision to the SDL.  You can get it here: http://www.microsoft.com/security/sdl/default.aspx.

Of note, there are additions for .NET -- specifically ASP.NET and the MVC Framework.  Two key things I noticed initially were the addition of System.Web.UI.Page.ViewStateUserKey, and ValidateAntiForgeryToken Attribute in MVC.

Both have existed for a while, but they are now added to requirements for final testing.

ViewStateUserKey is page-specific identifier for a user.  Sort of a viewstate session.  It’s used to prevent forging of Form data from other pages, or in fancy terms it prevents Cross-site Request Forgery attacks.

Imagine a web form that has a couple fields on it – sensitive fields, say money transfer fields: account to, amount, transaction date, etc.  You need to log in, fill in the details, and click submit.  That submit POST’s the data back to the server, and the server processes it.  The only validation that goes on is whether the viewstate hasn’t been tampered with.

Okay, so now consider that you are still logged in to that site, and someone sends you a link to a funny picture of a cat.  Yay, kittehs!  Anyway, on that page is a simple set of hidden form tags with malicious data in it.  Something like their account number, and an obscene number for cash transfer.  On page load, javascript POST’s that form data to the transfer page, and since you are already logged in, the server accepts it.  Sneaky.

The reason this worked is because the viewstate was never modified.  It could be the same viewstate across multiple sessions.  Therefore, the way you fix this to add a session identifier to the viewstate through the ViewStateUserKey.  Be forewarned, you need to do this in Page_Init, otherwise it’ll throw an exception.  The easiest way to accomplish this is:

void Page_Init (object sender, EventArgs e) 
{ 
	ViewStateUserKey = Session.SessionID; 
}

Oddly simple.  I wonder why this isn’t default in the newer versions of ASP.NET?

Next up is the ValidateAntiForgeryToken attribute.

In MVC, you add this attribute to all POST action methods.  This attribute requires all POST’ed forms have a token associated with each request.  Each token is session specific, so if it’s an old or other-session token, the POST will fail.  So given that, you need to add the token to the page.  To do that you use the Html.AntiForgeryToken() helper to add the token to the form.

It prevents the same type of attack as the ViewStateUserKey, albeit in a much simpler fashion.

Bad User Interfaces are Insecure

The Best of Intentions

So you’ve built this application.  It’s a brilliant application.  It’s design is spectacular, the architecture is flawless, the coding is clean and coherent, and you even followed the SDL best practices and created a secure application.

There is one minor problem though.  The interface is terrible.  It’s not intuitive, and settings are poorly described in the options window.  A lot of people wouldn’t necessarily see this as a security issue, but more of an interaction bug -- blame the UX people and get on with your day.

Consider this (highly hyperbolic) options window though:

BadSecuritySettings

How intuitive is it?  Notsomuch, eh?  You have to really think about what it’s asking.  Worst of all, there is so much extraneous information there that is supposed to help you decide.

At first glance I’m going to check it.  I see “security” and “enable” in the text, and naturally assume it’s asking me if I want to make it run securely (lets say for the sake of argument it speaks the truth), because god knows I’m not going to read it all the way through the first time.

By the second round through I’ve already assumed I know what it’s asking, read it fully, get confused, and struggle with what it has to say.

A normal end user will not even get to this point.  They’ll check it, and click save without thinking, because of just that – they don’t want to have to think about it.

Now, consider this:

GoodSecuritySettings

Isn’t this more intuitive?  Isn’t it easier to look at?  But wait, does it do the same thing?  Absolutely.  It asks the user if they want to run a secure application.

The Path to Security Hell

When I first considered what I wanted to say on this topic, I asked myself “how can this really be classified as a security bug?”  After all, it’s the user’s fault for checking it right?

Well, no.  It’s our fault.  We developed it securely, we told them they needed it to be run securely, and we gave them the option to turn off security (again, hyperbole, but you get the point).  It’s okay to let them choose if they want to run an insecure application, but if we confuse them, if we make it difficult to understand what the heck is going on, they aren’t actually doing what they want and we therefore failed at making the application they wanted secure, secure.

It is our problem.

So what?

Most developers I know at the very least will make an attempt to write a secure application.  They check for buffer overflows, SQL Injection, Cross Site Scripting, blah blah blah.  Unfortunately some, myself included, tend to forget that the end users don’t necessarily know about security, nor care about it.  We do like most developers do.  We tell them what we know: “There has been a fatal exception at 0x123FF567!!one! The index was outside the bounds of the array.  We need to destroy the application threads and process.”

That sounds fairly familiar to most error messages we display to our end users.  Frankly, they don’t care about it.  They are just pissed the work they were doing was just lost.

The funny thing is, we really don’t notice this.  When I was building the first settings window above, I kept reading the text and thinking to myself, it makes perfect sense.  The reason for this is by virtue of the fact that what I wrote is my logic.  I wrote the logic, I wrote the text, I inherently understand what I wrote.  We do this all the time.  I do this all the time, and then I get a phone call from some user saying “wtf does this mean?”, aaaaaaand then I change it to something a little more friendly.  By the 4th or so iteration of this I usually get it right (or maybe they just get tired of calling?).

So what does this say about us? Well, I’m not sure. I think it’s saying we need to work on our user interface skills, and as an extension of that, we need to work on our soft skills – our interpersonal skills. Maybe. Just a thought.

A Stab at a New Resume

While I am definitely not looking for a new job, I was bored and thought I would take a stab at a stylized resume to see if I could hone some of my (lack of) graphics skills.  It didn’t turn out too badly, but I am certainly no graphics designer.

What do you think?

mainResume

Putting the I Back into Infrastructure

Tonight at the IT Pro Toronto we did a pre-launch of the Infrastructure 2010 project.  Have you ever been in a position where you just don’t have a clear grasp of a concept or design?  It’s not fun.  As a result, CIPS Toronto, IT Pro Toronto, and TorontoSQL banded together to create a massive event to help make things a little more clear.  To give you a clearer understanding of how corporate networks work.  Perhaps to explain why some decisions are made, and why in retrospect, some are bad decisions.

Infrastructure 2010 is about teaching you everything there is to know about a state-of-the-art, best practices compliant, corporate intranet.  We will build, from the ground up, an entire infrastructure.  We will teach you how to build, from the ground up, an entire infrastructure.

Sessions are minimum 300 level, and content-rich.  Therefore:

i2010Proud[1]

Well, maybe.  (P.S. if you work for Microsoft, pretend you didn’t see that picture)

Visual Studio Output Window Auto-Scrolling

Just a quick one here.

Have you ever been using the output window in Visual Studio, scrolled up, and then lost the auto-scroll functionality?  It’s really annoying when you have a thousand things coming out through the likes of Debug.Write, or even if it’s just a massive build.

To re-enable autoscrolling, while in the output window just hit CTRL+END.

Kinda wished I knew that a year ago…

A Thought on Windows Mobile 7

The other day while I was sitting in the airport in Washington, D.C., I had a random thought.  When the ZuneHD first hit the shelves people were talking about how Mobile 7 might borrow the look and feel.  It’s sleek, easy to use/easy to understand, and is very simple.  So I started thinking about what such an interface might look like.  This is something I did quickly.  Nothing was provided by Microsoft.  Nobody has said anything about Mobile 7 design (at least, not at that point, but nobody cared anyway).  This is simply something I thought the interface might look like.

homeScreen

Some things to notice are the list-like menu’s, and the bing search at the bottom.  Blah-blah-blah anti-trust, the point is search is easily accessible, not necessarily just to Microsoft’s own search engine.  It could be Google’s search too.  Also, there is the location-specific information at the top showing the current weather.  Also mimicking the Windows 7 interface is the idea of pinning things to the home screen such as the Internet Explorer application.

There are some things that should probably change.  It feels a little cluttered at the bottom showing current messages and the appointments color is iffy.  There may not be any need for the middle separation either.

Just a thought…

Six Simple Development Rules (for Writing Secure Code)

I wish I could say that I came up with this list, but alas I did not.  I came across it on the Assessment, Consulting & Engineering Team blog from Microsoft, this morning.  They are a core part of the Microsoft internal IT Security Group, and are around to provide resources for internal and external software developers.  These 6 rules are key to developing secure applications, and they should be followed at all times.

Personally, I try to follow the rules closely, and am working hard at creating an SDL for our department.  Aside from Rule 1, you could consider each step a sort of checklist for when you sign off, or preferably design, the application for production.

--

Rule #1: Implement a Secure Development Lifecycle in your organization.

This includes the following activities:

  • Train your developers, and testers in secure development and secure testing respectively
  • Establish a team of security experts to be the ‘go to’ group when people want advice on security
  • Implement Threat Modeling in your development process. If you do nothing else, do this!
  • Implement Automatic and Manual Code Reviews for your in-house written applications
  • Ensure you have ‘Right to Inspect’ clauses in your contracts with vendors and third parties that are producing software for you
  • Have your testers include basic security testing in their standard testing practices
  • Do deployment reviews and hardening exercises for your systems
  • Have an emergency response process in place and keep it updated

If you want some good information on doing this, email me and check out this link:
http://www.microsoft.com/sdl

Rule #2: Implement a centralized input validation system (CIVS) in your organization.

These CIVS systems are designed to perform common input validation on commonly accepted input values. Let’s face it, as much as we’d all like to believe that we are the only ones doing things like, registering users, or recording data from visitors it’s actually all the same thing.

When you receive data it will very likely be an integer, decimal, phone number, date, URI, email address, post code, or string. The values and formats of the first 7 of those are very predictable. The string’s are a bit harder to deal with but they can all be validated against known good values. Always remember to check for the three F’s; Form, Fit and Function.

  • Form: Is the data the right type of data that you expect? If you are expecting a quantity, is the data an integer? Always cast data to a strong type as soon as possible to help determine this.
  • Fit: Is the data the right length/size? Will the data fit in the buffer you allocated (including any trailing nulls if applicable). If you are expecting and Int32, or a Short, make sure you didn’t get an Int64 value. Did you get a positive integer for a quantity rather than a negative integer?
  • Function: Can the data you received be used for the purpose it was intended? If you receive a date, is the date value in the right range? If you received an integer to be used as an index, is it in the right range? If you received an int as a value for an Enum, does it match a legitimate Enum value?

In a vast majority of the cases, string data being sent to an application will be 0-9, a-z, A-Z. In some cases such as names or currencies you may want to allow –, $, % and ‘. You will almost never need , <> {} or [] unless you have a special use case such as http://www.regexlib.com in which case see Rule #3.

You want to build this as a centralized library so that all of the applications in your organization can use it. This means if you have to fix your phone number validator, everyone gets the fix. By the same token, you have to inspect and scrutinize the crap out of these CIVS to ensure that they are not prone to errors and vulnerabilities because everyone will be relying on it. But, applying heavy scrutiny to a centralized library is far better than having to apply that same scrutiny to every single input value of every single application.  You can be fairly confident that as long as they are using the CIVS, that they are doing the right thing.

Fortunately implementing a CIVS is easy if you start with the Enterprise Library Validation Application Block which is a free download from Microsoft that you can use in all of your applications.

Rule #3: Implement input/output encoding for all externally supplied values.

Due to the prevalence of cross site scripting vulnerabilities, you need to encode any values that came from an outside source that you may display back to the browser. (even embedded browsers in thick client applications). The encoding essentially takes potentially dangerous characters like < or > and converts them into their HTML, HTTP, or URL equivalents.

For example, if you were to HTTP encode <script>alert(‘XSS Bug’)</script> it would look like: &lt;script&gt;alert('XSS Bug')&lt;/script&gt;  A lot of this functionality is build into the .NET system. For example, the code to do the above looks like:

Server.HtmlEncode("<script>alert('XSS Bug')</script>");

However it is important to know that the Server.HTMLEncode only encodes about 4 of the nasty characters you might encounter. It’s better to use a more ‘industrial strength’ library like the Anti Cross Site Scripting library. Another free download from Microsoft. This library does a lot more encoding and will do HTTP and URI encoding based on a white list. The above encoding would look like this in AntiXSS

using Microsoft.Security.Application;
AntiXss.HtmlEncode("<script>alert('XSS Bug')</script>");

You can also run a neat test system that a friend of mine developed to test your application for XSS vulnerabilities in its outputs. It is aptly named XSS Attack Tool.

Rule #4: Abandon Dynamic SQL

There is no reason you should be using dynamic SQL in your applications anymore. If your database does not support parameterized stored procedures in one form or another, get a new database.

Dynamic SQL is when developers try to build a SQL query in code then submit it to the DB to be executed as a string rather than calling a stored procedures and feeding it the values. It usually looks something like this:

(for you VB fans)

dim sql
sql = "Select ArticleTitle, ArticleBody FROM Articles WHERE ArticleID = "
sql = sql & request.querystring("ArticleID")
set results = objConn.execute(sql)

In fact, this article from 2001 is chock full of what NOT to do. Including dynamic SQL in a stored procedure.

Here is an example of a stored procedure that is vulnerable to SQL Injection:

Create Procedure GenericTableSelect @TableName VarChar(100)
AS
Declare @SQL VarChar(1000)
SELECT @SQL = 'SELECT * FROM '
SELECT @SQL = @SQL + @TableName
Exec ( @SQL) GO

See this article for a look at using Parameterized Stored Procedures.

Rule #5: Properly architect your applications for scalability and failover

Applications can be brought down by a simple crash. Or a not so simple one. Architecting your applications so that they can scale easily, vertically or horizontally, and so that they are fault tolerant will give you a lot of breathing room.

Keep in mind that fault tolerant is not just a way to say that they restart when they crash. It means that you have a proper exception handling hierarchy built into the application.  It also means that the application needs to be able to handle situations that result in server failover. This is usually where session management comes in.

The best fault tolerant session management solution is to store session state in SQL Server.  This also helps avoid the server affinity issues some applications have.

You will also want a good load balancer up front. This will help distribute load evenly so that you won’t run into the failover scenario often hopefully.

And by all means do NOT do what they did on the site in the beginning of this article. Set up your routers and switches to properly shunt bad traffic or DOS traffic. Then let your applications handle the input filtering.

Rule #6: Always check the configuration of your production servers

Configuration mistakes are all too popular. When you consider that proper server hardening and standard out of the box deployments are probably a good secure default, there are a lot of people out there changing stuff that shouldn’t be. You may have remembered when Bing went down for about 45 minutes. That was due to configuration issues.

To help address this, we have released the Web Application Configuration Auditor (WACA). This is a free download that you can use on your servers to see if they are configured according to best practice. You can download it at this link.

You should establish a standard SOE for your web servers that is hardened and properly configured. Any variations to that SOE should be scrutinised and go through a very thorough change control process. Test them first before turning them loose on the production environment…please.

So with all that being said, you will be well on your way to stopping the majority of attacks you are likely to encounter on your web applications. Most of the attacks that occur are SQL Injection, XSS, and improper configuration issues. The above rules will knock out most of them. In fact, Input Validation is your best friend. Regardless of inspecting firewalls and things, the applications is the only link in the chain that can make an intelligent and informed decision on if the incoming data is actually legit or not. So put your effort where it will do you the most good.