“Document labelled UTF-16 but has UTF-8 content” - or how I was accidentally emailed a user’s password
I have very few personal projects, and I tend not to take very good care of them. Of these, the most expensive and one of the longest running personal projects is Google Voice for Outlook Mobile Service. I believe I made it the summer after I graduated from High School, and for some crazy reason I just loved Outlook.
Either way, I figured out that Outlook, when connected to an OMS provider, could send text messages. “How beneficial!” I thought. Have your text messages and email addresses in the same inbox, yet still appearing separate.
I looked into these OMS providers that Outlook linked to, and they all charged money, of course. Pay per text message - every single one of them. It was a hard bargain for me, since I had a cellular phone I paid for and Google Voice on top of that. Why should I get another number, that will only be useful inside of Outlook, and then pay for every single message I send.
So I did what any resourceful programmer would do – I started looking into how Outlook connected to these providers to send text messages, and then wrote a quick and dirty webapp to do the deed. PHP was my language of choice – and seeing as this was the pre-composer, ZF1, CakePHP erra – I started writing immediately without any hint of framework code. Soon enough, my project was online and costing me plenty of money to maintain. (Dreamhost didn’t - and still doesn’t - support HTTPS via SNI, which means I’m currently paying for an IPv4 address - Not Cheap!)
Fast Forward about four years and here we are, GVOMS sitting on it’s own little server, getting a small amount of activity (Honestly no clue how much, I’m still not logging the amount of text messages sent). And I get an email in my inbox. PHP Error Reporting. Through maybe four years of time the program had worked so well without any PHP errors that I hadn’t even remembered that I set it up to email me with any errors and their context.
The error was interesting in and of itself, “Document labelled UTF-16 but has UTF-8 content” - a problem that I had solved for all working versions of Outlook at the time, but I had done it in a non-case-sensitive way, and according to the XML in the context, “Microsoft SharePoint” decided that it was going to start sending the encoding lowercase (as UTF-16 despite sending UTF-8).
But that’s right, it sent me the XML of the request - and oh goodness gracious it was a login verification request. I sat for a moment and stared at the username and password of a very unfortunately gmail user.
At this point, there were a multitude of options I could have taken, but I didn’t spend any time thinking about them before I went the lawful good route and immediately emailed the user.
Hello! You are inadvertently flooding my inbox with errors, apparently. I didn’t even know I had error reporting like that turned on.
Anyway, I’ve noticed you’re having some issues with GVOMS and I will be able to check on them sometime after 6pm eastern.
Two things:
- Please stop attempting to connect, as I really don’t need any more emails, thank you.
- Inadvertently, your password was sent to me via email over plain-text. I recommend you change it. (I also, in general, recommend people switch to dual-factor authentication) I’m very sorry for the inconvenience I’m sure this is, and I’ll be reviewing my code so that I don’t get other people’s passwords in the future.
At my next available opportunity I did the sensible thing and ran the context variable the email was spitting out at me through a regex parser to filter out the contents of the <password> tag and fixed the case-insensitivity bug, and followed up with another email letting the user know that the bugs were fixed.
Unfortunately, I haven’t heard back from the user - but I can only hope they aren’t too upset.