Troy Hunt put together a list of top Australian banks and their SSL rating using the Qualys SSL Server Test that reveals the somewhat depressing state of SSL security of various banks down-under.

This got me wondering how US financial institutions stack up, and I thought I’d share:

HTML, SQL and XSS injection vulnerabilities aren’t new but they are still largely ignored by developers.

My first encounter with these issues was in 1999 whilst writing an extranet e-commerce web site. Back then the ASP fix consisted of Server.HtmlEncode for all output and a Replace("'", """")Replace("'", """") for strings heading to SQL (other types headed there via CInt/CLong/CDate and I wasn’t aware of parametrized queries).

If you don’t encode data when using any of the following methods to output to HTML your application could be compromised by unexpected HTML turning up in the page and modifying everything from formatting though to capturing and interfering with form data via remote scripts (XSS). Such vulnerabilities are incredibly dangerous.

Using MonoRail or Microsoft’s MVC does not make you automatically immune — use {! }{! } in MonoRail’s Brail engine and the HtmlHelpers in Microsoft’s MVC to ensure correct encoding.

A few years ago I believed that HTML and SQL injection vulnerabilities were headed for extinction. Thanks to object-relational mapping tools SQL injection continues to die but HTML and script injection vulnerabilities are as popular as ever.

Part of the problem stems from the “back-to-basics” approach to rendering web pages, throwing out classes and controls for string-based libraries (primitive obsession) and helpers which do not encode HTML or even offer a concise simple syntax to do so.

Earlier this week the ASP.NET article of the day linked to 4-Tier Architecture in ASP.NET with C# which I noticed suffered from both HTML and SQL injection. I promptly informed the author and the ASP.NET site (who pulled the link) but the author was rather unconcerned and wrote (after editing my comment):

Thanks for your feedback Damieng. Sql statement has been used here to make the tutorial simple, it is informed in the DAL description.

Last nights Guernsey Software Developers Forum meeting was sparsely attended with a number of the regulars attendees absent. There were however two new faces including Kezzer who I’d been chatting to on-line for years.

Hopefully the low numbers were down to the seasonal summer holidays and the subsequent knock-on effect that we couldn’t get email out to the BCS Guernsey division to gather sufficient awareness.

This presentation is now available on-line.

I will be giving a talk about web application security tonight at the Guernsey Software Developers Forum.

Back in ’98 I was developing an extranet site for a local company when I realized that it would be open for exploit if somebody put single quotes in text fields. It was early in the development cycle so I fixed it and moved on, unable to find out how other people were avoiding the problem.

It turned out many were not and it became a well-known exploit called SQL injection. Unfortunately there are many developers who don’t know or appreciate the problem, and it is this:

Currently “hot news” is the fact that Firefox, Mozilla and Safari browsers have been demonstrated as susceptible to a new form of phishing attack.

Basically all these browsers support International Domain Names (IDN) that let you use the full Unicode set of foreign characters and symbols, and some of these foreign characters while technically different from the Latin ones look identical. In the case demonstrated they have used the Arabic aa to replace a Latin aa in “PayPal” to get another site. This isn’t really anything new, even the original RFC commented on how this would be a problem and the IETF issued guidelines that would have limited their scope if only Verisign actually implemented them. (Specifically the guideline for preventing mixing of languages within a domain name would reduce the scope for attack considerably).