Top 25 Most Dangerous Software Errors

SQL Injection tops CWE’s list of 25 Most Dangerous Software Errors.

See my post on guarding against SQL Injection.

-Krip

 

Is your password secure?

Sad to say, chances are, it isn’t.

Do you use an English word as your password?  Maybe with a number appended to it?  Not good.  Dictionary attacks are commonplace.

Let’s see, do you use a bit of information in your password that’s easily obtainable?  Like your birth date or spouse’s name?  Again, you’re asking for it.

Now the kicker: do you use the same password on multiple sites?  Oh oh.  My personal pet peeve.  Think of your password like a lock.  Would you put the identical lock on your house, cars, safe, etc?  What if you lost your key?  You’d have to change all the locks.  What’s worse, with the Internet you don’t always know when the key is lost.  Actually here’s one time we do know: Sony’s been hacked (again) and 40,000 username/password combinations have been posted for all to see.  So if you’re in that list, and you used the same password on other sites – well, I don’t need to tell you.

To test password uniqueness, Hunt compared the Sony data to a database of
Gawker usernames and passwords, which were hacked and released late last 
year. He found that of those accounts that used the same email address on
both sites, 67% used the same password on both systems.

Here are some basic rules to follow when coming up with a password:

1. Use a different password for every site.
2. Make it long.  How long?  Well it’s easier to say what’s not long enough, and that’s 6 characters.  Go 8 or 10 characters or even longer.  You could use an entire phrase.  Research shows size trumps content.
3. Use a mix of character types.  So upper and lower case letters.  Some numbers.  And at least one special character (non-alphanumeric).
4. The best passwords are random ones, and people don’t generate the best entropy.  Actually even machines have a hard time generating a truly random number.  But given the differences, you’re best off using a utility to generate a random password for you.  Yeah, yeah, you’ll need some way to keep track of all those passwords.  Welcome to the information age.

-Krip

How to protect against SQL injection attacks

SQL injection is the act of injecting some characters (e.g. SQL) into a SQL statement causing it to perform an unintended (e.g. malicious) action.  It most often occurs when some criteria fed to the query is provided by user input (or is editable by a user – say the querystring in a URL or a field on a web form).

A number of things contribute to making this type of attack possible including: 1) insecure code, 2) unnecessarily highly privileged database access accounts.

Things you can do to protect against SQL injection:

1. DO NOT execute any T-SQL by concatenating values, particularly where user input is involved
2. Use parameterized SQL instead – this ensures that values are escaped such that a T-SQL command cannot be terminated
3. Use stored procedures where the T-SQL is static and criteria values are passed in as parameters (then use in conjunction with point 2 above)
4. Do not grant your database accounts used by your application unrestricted access to databases.  DO NOT grant them DBO rights in a production OR test environment.  This is a HUGE BENEFIT of stored procedures.  Stored Procedures can be granted execute rights and SQL Server’s chaining system (known as ownership chains) will automatically allow those operations to run against objects (e.g. tables) without explicit rights there.  Grant rights directly to tables only if application code must run SQL directly.  Even then pay attention to SELECT vs UPDATE rights.

References:

1. How To: Protect from SQL Injection in ASP.NET (MSDN article from Microsoft Patterns & Practices)
2. SQL Injection (MSDN article with great tips on protecting against this)

-Krip

Poor user interface – learn from their mistakes!

Just went through a website registration process where I’m left uncertain if the registration succeeded or not.  A look under the covers leads me to believe it did complete successfully.  I will explain further but note that I’m not here to expose the source but to provide education for developers so we get more intuitive user interfaces with proper visual clues on what went through and what didn’t!!  The term affordance has evolved to mean “easy discoverability of possible actions”.  And false affordance “leads to mistakes and misunderstandings”.  I think they apply in this case.

I filled out a form, clicked submit, then a pop-up appeared.  Correction: a pop-up tried to appear.  I must enable that in my browser.  The pop-up appeared, I entered the CAPTCHA, and then a message box appears indicating that ‘my email was sent’.  The pop-up closed and I’m left on the original form with a red message indicating asterisk denotes a mandatory field!  Huh?  What do I do?

Here are the UI mistakes:

• UI mistake number 1: When the pop-up didn’t appear I was left wondering if I’ve already lost the game.
• UI mistake number 2: What “email”?  I’m not writing an email.  So now I’m further confused.
• UI mistake number 3: I’m left on the data entry form with all my data filled in and a red star next to mandatory fields, all of which I’ve filled out!  What do I do now?

My suggestions for fixing:

• Don’t do pop-ups as there are lots of pop-up blockers out there.
• Remove references to “email” – say something like “your request has been submitted”.
• Move users off the form if they’ve submitted it successfully.
• Send users an email so they have a receipt of their submission.

As a final note, I peaked under the hood at the HTML source behind the pop-up – the JavaScript alert (message box) appeared BEFORE a method was called that submitted the form fields to the server.  BIG MISTAKE!  The submission should happen and THEN the user be given confirmation.

OK, one more: the complete CAPTCHA system can be defeated by analyzing the HTML of that pop-up 🙂  But we’ll leave security for another post.

-Krip

How to use Forms Authentication with SSRS

SSRS out-of-the-box supports Windows Authentication.  Microsoft, however, has baked in an extension model that allows you to plug in your own authentication scheme.  So it’s fully possible to change over to Forms authentication.  This is particularly useful if you want to run reports from inside of your own website that uses Forms Authentication.

When you convert SSRS over, all use of the system will then use Forms Authentication.  So this includes:

• The web portal (Report Manager)
• The power user reporting tool (Report Builder)
• API access (Web Services use of Report Server)
• SQL Server Mangement Studio (when connecting to SSRS)

So I will say you end up with a robust solution.  But getting there is not for the faint of heart!  There are a number of steps to take including writing some custom code, adding some pages, and changing a bunch of settings in a number of config files.  I keep hoping Microsoft will one day make this a lever we just pull!  I’ve done these steps on more than one enterprise project in SQL Server 2005.  From what I see things haven’t changed much on this front in SQL Server 2008 R2 but feel free to drop me a line if you’ve got some notes there.

You can configure SSRS to use the very same aspnet database that your website uses and that’s probably where the real value lies.  So you’re actually passing through the same credentials from your web app through to SSRS.  If you do the extension right, you can even make use of ASP.NET Roles when granting access to reports and folders in SSRS.  That will reduce the administration burden and IT will thank you.

So here’s the steps in detail: Security Extension Sample for SQL Server 2005.  And if you’re using SQL Server 2008 R2, have a look at Implementing a Security Extension.

If you’re going to have to do the changeover several times (and I’d be surprised if you didn’t), do yourself a favour and write a tool to do it.  We did that on our team and it was a lifesaver, particularly since more than one group was involved in installations, and we had dozens to do!

-Krip

The One Taste of TechEd Session You Should Not Miss Today (Wed May 18)

Looking at all the Taste of TechEd sessions for today, the one that looks the most interesting is:

• SIM302 Lessons from Hackwarts Vol 1: Defense against the Dark Arts 2011
  Level: 300 – Advanced
  by Andy Malone
  5:00 PM – 6:15 PM
  Room: C305

-Krip