A place where we write words Ignition Blog

A vulnerability in one of the internet's core security technologies was publically disclosed Monday night that has the potential to cause widespread panic and damage.

The vulnerability is a bug in a software library that many web sites and internet-enabled services use to secure traffic between users and their servers. This bug allows an attacker to read chunks of the server's memory, normally inaccessible from outside the server, and discover potentially damaging security data, including usernames and passwords.

The bug has existed for two years in the wild, and has most likely been exploited vigorously.

You can find more information and analysis of the vulnerability on most technology sites:

• http://arstechnica.com/security/2014/04/critical-crypto-bug-exposes-yahoo-mail-passwords-russian-roulette-style/
• https://www.schneier.com/blog/archives/2014/04/heartbleed.html
• http://blog.cryptographyengineering.com/2014/04/attack-of-week-openssl-heartbleed.html

Are Ignition customers affected?

No. Web sites hosted on our internal platform are not affected by this vulnerability. Ignition uses Microsoft Internet Information Services (IIS) for hosting, which does not use the affected software library. Our external customers use their own installations of Microsoft IIS and are also not vulnerable to this bug.

Security on the internet is just like being chased by bears; you don’t have to out run the bear, you just have to out run the other guy. We make sure to stay at the forefront of security and vulnerability research so that our customers can out run the bear and the other guy.

If you have any questions, please contact us and we’ll be happy to assist.

What if my site isn’t built by Ignition?

Contact your hosting provider or web site developer immediately.

If your site is hosted on Microsoft IIS you’re probably safe, but any other hosting platform is most likely vulnerable to this bug. You can test your site using https://www.ssllabs.com/ssltest/.

How do I keep myself safe?

Many of the web sites you use daily will be affected by this vulnerability.

There is a very real danger that many sites are being actively exploited using this vulnerability or will not apply the patch quickly enough even though the vulnerability has now been publically disclosed.

There are two scenarios to be concerned about as a user of a vulnerable site:

• Usernames and passwords may have been stolen from the server
• The SSL certificate that identifies the site may have been compromised and attackers may set up a fake site to steal usernames and passwords in the future

You should audit the web sites where you have a user account. Check with the site administrator to see if the site was vulnerable to the "Heartbleed" bug, and if the appropriate patch has been applied. Once the site has been patched, change your password.

Additionally, change your password anywhere you’ve re-used it.

Best-practice password management advice applies; don’t re-use passwords on multiple sites, always generate complex passwords, and use a password manager tool to store them.

Many potentially compromised SSL certificates will be revoked over the next few weeks. If your browser is not set to check for certificate revocation, you are exposed to a greater risk of visiting a phishing site that uses a stolen certificate. Internet Explorer and Firefox check for certificate revocation by default, but Chrome does not; check your browser help if you’re not sure how to enable certification revocation checks.

In general you’ll need to pay special attention to browser certificate warnings from now on.

Be aware of potential phishing emails that instruct you to reset your password. Many sites will be sending these emails to their users, especially if the site administrators believe the site has been compromised, but so will potential attackers. Instead of clicking a link offered in an email, we recommend visiting the affected site in your browser directly and following the links to reset your password there.

If you’d like assistance with web site security or development, please contact us. We’ll make sure you can out run the bears.

As we were moving from the age of hand crafted stored procedures and inline SQL into the new age of OR-mappers, we had a few different choices to make in terms of which product to go with. After a period of research we eventually decided on staying away from third party applications as much as possible and relied on Microsoft’s Entity Framework (as Linq2SQL was fading away at that point).

Over the many years I’ve spent developing applications, I’ve always managed to end up in the role where I try to improve performance where ever it’s possible, and about 90% of the time the most gain is achieved by improving an application’s interaction with the database.

Bearing this in mind, I set out to create a simple platform or wrapper of the functionality to streamline the methods for retrieving and saving data. Seeing how it’s always a goal to have as maintainable code as possible, I wanted to enable developers to make the easiest way to access data the most maintainable and readable way as well, as well as taking away some of the complexities so people don’t necessarily need to know 100% what’s going on under the hood, just that data gets saved/retrieved from the database.

After a bit of development, the internally labeled “JanDAL” project was born, and it has simplified the initial setup of a data-layer in all projects where it’s been used immensely. Shortly after it was extended to include methods for caching, ensuring even better performance without the need for hand-crafted caching methods.

I’ve kept refining and optimizing this over the years based on feedback and real world experience, and we currently have quite a few applications running in production environments based exclusively on this layer for its data-retrieval and storage strategy, including all SFF sites.

As the latest version of Entity Framework shipped, I adapted the layer to the work with both the old and new versions and decided it was time to send it off into the world so others might take advantage of this, and bravely put together a NuGet package with the data layer, as well as other tools we frequently use in our projects.

If you’re a developer and want to take advantage of this, you can download the library Mijan DataLayer from the NuGet package manager, and refer to the overview and cache information at the personal site at http://janheggernes.net/post/mijan-core-datalayer-nuget-package-overview and the cache overview at http://janheggernes.net/post/mijan-core-datalayer-quick-cache-samples along with the service framework we use at http://janheggernes.net/post/mijan-core-service-overview

If you’re a business who struggles with performance in your .NET applications, get in touch with us for help with performance.

- Jan