Mobile Security - and why it pays to test!

As Australia’s foremost publisher of all things IT security, it would be remiss of us not to mention that we discovered a little bug yesterday that (initially) gave us cause for alarm.

We’ve decided in the interests of transparency - and lessons learned, etc. to talk about it openly so you can act on the issue if required, or simply learn from our blunder.

It was brought to our attention shortly before lunch that a bug in our mobile site was, under very specific circumstances, exposing the email address of a reader in the URL string.

This anomaly only occurred under specific circumstances:

• when a reader received our newsletter in their inbox from a mobile device AND;
• When that reader clicked through to a story (which led to our mobile site) AND
• When the reader then shared the story on social media or email using the native sharing features of their mobile browser.

We rectified the problem at 1:00pm yesterday.

It should only impact mobile content a subscriber shared via these methods between January 10 (the day we launched our new mobile site) and 1:00pm yesterday (Wednesday February 17).

Our thanks to Saso Virag (@VS_) and Gavin Costello (@gavincostello) for finding the problem and helping us to figure it out (it helps to have InfoSec gurus watching over us).

We’re confident this affects very, very few of our readers. If you’re concerned, we advise those of you that tend to read and share stories from our newsletter from a mobile device to:

Look back through your Tweet stream for an example of where you shared an iTnews story, and check the full length of the URL string to make sure it does not contain your email address.

We’re confident that in 99.99 percent of cases, it won’t. But if you do find it, it would be

1. Useful to send us a screenshot or embed so we can gauge if the problem was bigger than we expected.
2. Delete the Tweet.

Once again I stress that we’ve resolved the problem. We absolutely encourage the sharing of our stories!

The details

How did this happen?

First, we always start from the position of encrypting links in our newsletters. Any information that a link might carry should never be visible in clear text.

When a user clicks on a link from our newsletter, one of two things happens:

1. If using a desktop client, the iTnews website grabs the information from the encrypted links and redirects to the article to the decrypted URL, stripping out any other information that had been encrypted prior.
2. If using a mobile client, the iTnews website detects the mobile browser and redirects to the iTnews mobile site.

Unfortunately, when we launched the new and (mostly) improved mobile site on January 10, that part of the code that determines whether a reader is clicking a newsletter article from a mobile or desktop site and redirects accordingly was placed before the code that stripped all the remnant data from the now-decrypted URL. That’s why in rare cases, a Tweeter might find their email address in clear text within the URL string of the tweet.

What we’ve learned

Lesson #1 - Clean out old code

Software that changes frequently - which is fast becoming all software - is often burdened with old code for features you aren’t using anymore. We assumed in this case that as long as all the bits and bobs the iTnews site took from the newsletter was encrypted, it didn’t especially matter. What we didn’t count on was the impact of future changes on the site, which brings us to Lesson #2…

Lesson #2 - Test new features against old

Of course we tested our new site! But we’re only a small operation, its difficult to know where to call it a day on testing the impact of every change on every browser or scenario.

We need to re-think these dependencies for future development, but not get so caught up in it that we slow down our pace of delivery.

Encryption or not, we’re cutting out any data that isn’t essential from the newsletter-to-website process. That includes your email address.

I apologise and be assured it won’t happen again!

Brett Winterford, editor guy.