Tag Archives: coding

A case study in bad design: PHP Generator for MySQL

Welcome to the second installment of the “case study in bad design”-series, where I talk about generally horrible design in code, security or user experience. Todays subject is the PHP Generator for MySQL software by SQL Maestro (whose website will present you with a self-signed certificate for *.magicshoes.net if you try to access it via SSL, so you at least have to give them credit for creativity in that area).

PHP Generator for MySQL is a software that allows non-programmers to create web-frontends to their MySQL-Databases. It does a comparatively good job and provides some decent options, although the UI is somewhat cluttered and unintuitive, and the error reporting in places nonexistant. I was required to use it (as opposed to writing something myself) during my last employment with an institute at my university.

The story begins in July 2012, when I noticed that the code generated by PHP Generator had multiple vulnerabilities to Cross-Site scripting, allowing me to steal the login cookie (which, for good measure, contained the password in clear text, even if it was stored as a hash in the database). I cursed, wrote up some proof-of-concept code and reported the vulnerability to the devs.

A few weeks later, a new version of PHP Generator was released, fixing one of the two Cross-Site scripting holes I reported. They never responded to my mail and never fixed the second Cross-Site scripting hole. So, a year almost to the day later, I sent a follow-up mail, reminding them about the holes I reported, reporting another hole and setting a deadline of two weeks, after which I would apply for a CVE and publish the vulnerability. That got their attention and they responded within a day and got a new build out a few days later, fixing the vulnerabilities (and refusing to credit me in the changelog for reporting these issues, but hey, whatever).

A few days ago, I took another pass at the code and found another vulnerability (HTML stored in the database would be evaluated when displayed on the website), complaining that they were now using unsalted hashes of the password for authentication in the cookies (instead of session IDs completely unrelated to the password, which would be a better practice) and, after past experiences, setting a deadline of a week for a reply. Once again, they replied within a day.

Appearently, evaluating HTML from the database was a feature and not a bug. A feature that was on by default and could be disabled on a “per-input” basis. Whoever thought that was a good idea? Every “feature” that opens up the possibility for a security hole as big as stored XSS should either be completely removed or be off by default, to be enabled manually and with a big message box warning about the security implications. To make matters worse, the state of this setting seems to not be saved in the project file, leading to compatibility problems if the default value was changed (and I have no idea how they would make this state persist over restarts of the program if they save the setting nowhere…).

As for the proper session management, they claim to be working on something. They also may add salted hashes, but have not fully committed on that, citing possible compatibility issues.

They closed their mail with a statement that blew my mind:

By the way, we have never received any security related complaints from other PHP Generator users, so probably there is no real threat.

I’m not going to comment further on this statement, as anyone with at least a rudimentary understanding of security should be able to see what is wrong with this.

PHP Generator for MySQL starts at $99 for a single, non-commercial license without upgrades. I would think that you could expect more interest in the security of their customers for that.

A case study in bad design. Todays subject: the Deutsche Bahn

Welcome to the first installment of the new series “a case study in bad design“, which will probably be an ongoing series unless something very surprising happens (namely, people stopping to write horrible code).

Todays subject is the homepage of the german railways corporation, the Deutsche Bahn. (And just setting this link revealed another faux pas, namely that their SSL certificate is only valid for www.bahn.de, not for bahn.de without the leading www).

Everything began with my mother (which is, in a way, not surprising at all, but in that case I am not talking about my birth). She regularily takes the train to Bremen, and had set up a profile for her usual passenger settings (economy or first class, which kind of seat, that sort of thing) in her bahn.de-Account. She noticed her profile repeatedly disappearing, which, at some point, made her so angry she wrote a mail to the people responsible for the website.

They responded with some seemingly senseless information about her browser not allowing cookies. But since no sensible person would store those presets in a cookie if you have a perfectly good user account to store it in, so that was obviously bullshit, right?


(Checks title of blog post) ah, damn.

A quick check turned up that the travel profile was indeed stored in a cookie. Which would have been bad enough as it was, considering that this profile…

  1. …would be nice to have on more than once PC without setting it up seperately
  2. …is user specific and, subsequently, has no business being in a cookie instead of a database in the first place
  3. …is something that does not change all too often, which makes putting it into a cookie even more stupid than it already is

Well, we now know that this information is stored in a cookie. Then again, this does not explain the random disappearence of it. That is, until you check the cookie information.

Yes, the cookie is valid for a whooping 10 days! This means that every time you don’t visit bahn.de for 10 or more days, you will loose all your preset profiles. Who exactly thought that this was a good idea? Because that person was wrong. As an added bonus, the cookie is not deleted if you log out, so if you, for some reason, create a profile on a public computer, you are leaking your travelling preferences (that’s probably not a big deal, but completely unnecessary).

But, while we’re at it, let’s play around with that cookie. Maybe we can find some Cross-Site scripting (considering all the places I have already found it, it would not surprise me to find it here). Quickly add some quotation marks, just to see what happens, aaaaand…


A quick trip to the source code (a mere 3000 lines of horribly indented HTML and Javascript) reveals a bunch of JavaScript imports. A glance at the *.min.js-files, followed by a curse, followed by the awesomeness that is http://jsbeautifier.org/, revealed somewhat readable Javascript code, containing gems like “b && (a = b)” (a shorthand for “if (b) a = b;”, as it seems) and wonderful “for”-statements like the following:
for (var f = c, c = d, e = void 0, e = void 0, g = [], f = f.substring(4); 0 < f.length && 0 != f.indexOf("]#");)
Appearently, separating statements in a conditional with commata makes them evaluate one after another, and the last statements result is used to check if the conditions of the conditional are fulfilled. I especially love the double assignment of e = void 0.

I will not torture you (or me) with the whole >12 000 lines of Code, but rest assured that it does not get better. In the end, I gave up on finding the cause for the lifelock that occured after my modifications to the cookie, seeing as I am not likely to be paid for this crap and my pain resistance is not high enough for this single-letter variable bullshit. I’ll notify them about it anyway, although I am not sure what (if anything) will come of it.

Introducing IssueBot, a Jabber MUC notification bot for GitHub

As part of a development team working on improving Enigmail, I recently found myself in need of a bot sending notifications to a Jabber multi-user chat (MUC) when the Issues of a GitHub-project receive an update (we already had a similar program for new commits in place, called commitbot). I searched for a while and did not find anything that fulfilled our requirements.

So, being a CS student and all that, I decided to write one.

Introducing IssueBot

IssueBot is a Python / Twisted bot, using the GitHub API to fetch information about the issues of a GitHub project. Those are then sent to a Jabber MUC. It can monitor multiple repositories at the same time, authenticate itself using an OAuth token (if you generate one manually) to increase the rate limit on the GitHub API, and will generate Notifications in the following conditions:

  • New ussue
  • Issue closed
  • One of the following has changed about the issue:
    • Title
    • State (open -> closed or vice versa)
    • Assignee
    • New comments

Development is still actively going on, with new features being planned and bugs being fixed, so keep an eye on the GitHub-Repository.

Configuration is done using a .tac-file (an example file is provided with the program). Just update the variables in it and you should be good to go. Instructions on how to use it can be found in the README.

As parts of the code are derived from the aforementioned commitbot, the Code is licensed under the GNU GPLv3. Feel free to fork, improve and send pull requests on the project page on GitHub.

The making of IssueBot

As it turns out, it is actually really easy to query the GitHub API. You send a request to a specific URL (for example, https://api.github.com/repos/octocat/hello-world/issues) and get a response with some JSON and some headers telling you how many requests you have remaining for the current hour (the API limit for unauthenticated users is 60 requests per hour).

Since it is pretty easy to do this in Python, and it has some nice support for JSON built-in using the standard json module, it was pretty easy to query the API, parse the result into a Python dictionary, and parse that into the local database. Then, the changes could be determined and notification messages generated. The only thing missing was the interface to Jabber.

For that, I decided to reuse some code from the commitbot project. This blew up the list of dependencies, but made it possible to somewhat painlessly work with Jabber MUCs. As an added bonus, one of the dependencies, Twisted, deamonizes the process automatically, saving me the trouble.

In the end, it took me about three hours to hack together the current version of the program. Most of the time was spent trying to figure out how to get Twisted to work with my main loop, which was actually non-trivial until I stumbled upon the LoopingCall-Instruction provided by Twisted.internet.task. As Twisted has some rather… interesting views on how it should be used, and my use case did not quite fit into that pattern, I found documentation on how to use it hard to find.

The program is now happily running on my server, spitting out the occasional notification into our chat, and works like a charm.

Drinking games in Vatican: Implementing the SSH RandomArt-Algorithm in Javascript

I recently read an article about the algorithm used to generate the RandomArt-Images used for SSH keys (the “drunken bishop” algorithm). I looked around for a bit and did not find an implementation in Javascript, so I quickly hacked one together.

The algorithm is explained really well in the article I linked above, so I’ll not go over it again. The algorithm is pretty easy to implement, the main parts of this algorithm are:

  • Representing the field the bishop moves on (easy enough with a 2D array of integers)
  • Converting Hex to binary (surprisingly, there is no builtin function for that, but there is a good answer on StackOverflow to that)
  • Isolating the bit-pairs (by iterating through two-character substrings of the words)
  • Checking if moves are valid (by checking if the target coordinates are within the limits of the array)
  • Showing the results (by writing them into a div with a monospaced font set)

So, all in all, it was mostly an exercise in javascript and nothing really fancy, but it was fun to implement it, debug it (too much python, forgetting semicolons all over the place), get the whitespaces to work properly (there are about one million kinds of white spaces, and appearently only one does what I want), and finally testing it.

No effort was made to keep this code simple, efficient, or beautiful to look at. It was a proof of concept and some exercise for my rusty JavaScript skills, mixed with a general interest on how the RandomArt algorithm works.

You can take a look at the code in action at jsfiddle, or just look at the horrible code in the gist on github and make fun of me in the comments.

Thoughts on usability vs. security

Warning: This has become a wall of text, and is much less coherent than I wanted it to be. I hope I got my point across.

In the last few days, I had a lot of discussions about usability, security, and the conflict between them. One was in the “Issues”-section of Mailpile, and upcoming FOSS webmail client with encryption support, among other things. One was with another participant of the “Night of Code” last Friday. Both of them were very civil, but at least in the second, it seems I did not get my point across properly. As I expect to discuss this again soon, I thought I’d just write up my argument in a coherent fashion and put it here for everyone to see and discuss.

Usually, the topic comes up when I am discussing improving Mail Encryption to be more user-friendly, as the current version of Enigmail is just plain horrible in that regard (sorry, devs, but it’s the truth). There are several improvements on the way that I know about, but as I am helping design some of them, I sometimes get into an argument with others about how a “thing” should be designed. And that is good, by the way. The only way to make something better is to talk about what’s wrong and how to improve it.

So, usually, the discussion goes somewhat like this: “Hey, let’s improve the process of checking fingerprints to make keysigning parties less horrible” – “Great Idea!” – “oh, yes, and since checking fingerprints is so much easier then, let’s notify people when they are trying to send a mail to an untrusted public key” – “Hmmm. You know, that could be really annoying for people…” – “Yeah, and let’s add a big red warning message that you have to work really hard to turn off so people start signing keys” – “yeah, well, that would be extremely annoying and make people just randomly start signing keys, destroying the Web of Trust system” – “then let’s make it really hard to sign keys without checking fingerprints” – “Noooooooooooooo” – and so on.

The problem, I think, is that the other person is trying to design for security with an added bonus of a bit of usability for nerds, while I am trying to design for regular people, with changes where security may suffer a bit (if you do not know what you are doing). I am always pushing people to adopt mail encryption, and usually the answer is “hell no, that’s way too complicated”. I’m even getting that reply from other CS students, by the way, so that goes to show you just how bad it is (or at least, how bad it is perceived).

So, from my point of view, it is better if a person is using mail encryption in a way that is not completely secure against a sophisticated attack, it is still better than if the person is mailing completely unencrypted. Or, to put it another way: I’d rather have everyone mailing encrypted and 0.0001 % of them being attacked with a targeted, sophisticated attack, than having everyone mailing unencrypted and having their mails read by everyone and their dog (and the NSA).

So, I’m arguing for the following: Make Mail encryption as “out of my face” as possible. Make it possible to automatically download recipient keys. Make it easy, but not required, to validate keys. Make it easy to read your mail on any device, even if it is encrypted (this is not an issue with Enigmail but with the ecosystem of PGP apps in general). Make the usage as easy to understand as possible, and error messages without any technobabble. You can always add a button “details” to show the technical details of what went wrong, but my grandma does not need to know “Error – No valid armored OpenPGP block found”, she only needs to know that something went wrong and she cannot be sure the mail is actually signed, and that in a language that she can understand.

This is hard. I know it is because I did not manage to come up with an error message that fits the criteria outlined above. But it being hard should not keep us from trying to achieve it. We are the only people able to change this, and the rest of the population is depending on us to get this solved so they can use it, too.

Create all of those features outlined above. Turn them on by default. Make the wizzard pop up on first launch (yes, there is a wizzard. It’s even supposed to pop up, but it doesn’t for me). Make it really easy to use PGP. Then make it possible to turn those options off again, for people who know what they are doing and want a clean keyring. But build a system your parents could use, and your non-technical friends could use. Because they are sending their data around unencrypted. And sometimes they are sending your data around. Unencrypted.

Think about it.

Results from the inofficial Enigmail “Night of Code”

Yesterday, we had a small “Night of Code” in Hamburg. Basically, five hackers met up in the rooms of the CCC Hamburg and tried to improve Enigmail, the Thunderbird extension for PGP-encrypting Mails. It was a hell of a lot of fun, and we actually made quite a bit of progress on several improvements.

It all started with a discussion on the mailing list of the computer science department of the University of Hamburg. We had a lengthy discussion on what is wrong with Enigmail and PGP, and some of us decided to do something about it. Someone organized a room, called for a “Night of Code”, and a few people responded, me among them.

We started with a short introduction on the architecture of Enigmail and what the important files are. Afterwards, we discussed what needed improvements (the consensus being “basically everything about the UI”) and everyone chose one of the proposed improvements and started working.

I don’t want to spoil the surprise on what the others have been working (although all of it will come in pretty handy, once it is finished and hopefully merged into the main project), but I can say a bit about what I worked on.

So, one of the important things when using PGP is to manage your Web of Trust. This includes the signing of the keys of other people (after you validated that they are, in fact, the person they are saying they are). For that purpose, there are Key-signing parties. And one of the major annoyances about those parties is the distribution of freshly signed keys.

On Linux, there is a neat command line tool called caff. It takes any number of Key-IDs, downloads the public keys, signs each ID seperately and mails it (encrypted) to the provided eMail address. The problem is that caff is pretty annoying to set up, and only works on Linux.

The Feature I am working on is something along those lines. I added a new checkbox on sigining keys…

The second checkbox is new, in case you were wondering.
The second checkbox is new, in case you were wondering. And the keys are totally legit, I checked. 😉

If you select the checkbox and sign a key (and no error occurs during the signing process), a new Message composition window will open:

The new Message

It will contain some sort of preset text and have the signed public key attached.

Now, this is all working great already, but there are still some things to do:

  • Save the last decision on whether to mail the key or not (currently, due to some weird behaviour of the Enigmail preferences function that I still need to figure out, it is not saved)
  • Automatically set the mail to be encrypted and signed, regardless of the settings.
  • Perhaps encrypt the public key before attaching it, to make sure the recipient needs his private key to get the new signatures?
  • Perhaps choose the sending account based on the private key that was used to sign the public key?

Now, the experience to work on Enigmail has been interesting and somewhat cool, but not without its problems.

  • To say the documentation of Enigmail is bad would be misleading, as it implies that there actually is a documentation, which is not the case. Everything you want to use, you need to figure out yourself, possibly by using the addon with debug output active and seeing which functions are used in what order.
  • Thunderbird isn’t much better. Many of the important functions (adding an attachment!) had to be reverse engineered from other addons or from the very helpful thunderbird-stdlib-Project on GitHub, as the documentation has some pretty big holes in significant places.

If you are an Enigmail dev and reading this: Please provide at least some documentation on what is done where in the code, and what APIs can be used for new features. I know you probably understand the code, but it makes the entry barrier for new devs very high.

If you are a Thunderbird dev: See above. The current docs are not enough, and the function names are in parts weird enough to make it almost impossible to find out how to actually use them without checking the source files, which takes time and is extremely annoying.

All in all, I enjoyed my time hacking on Enigmail. But it could have been a lot more productive if there was some form of documentation one could use. As for the new feature: I will try to get it to work properly and then submit a patch to the devs, but I do not know how long that will take, as my time is currently pretty limited because of other things I need to take care of (my bachelors thesis among them).

As for the others: I don’t know when their features will be finished, but we already have a bunch of ideas on what to do next, and if we find the time, we’ll create some more new features. Some of our ideas have the potential to vastly increase usability, so I am very curious as to the reactions of the devs. Let’s hope for the best.

Coding Project of the day: seinfeld.sh

Today, I was looking for a command line program that implements the seinfeld calendar / seinfeld chain. As it turns out, there are a lot of programs on GitHub that do something like that, but none that did exactly what I was looking for (actually, that’s wrong. One Project did pretty much exactly what I wanted, but it refused to install).

Well, building a simple seinfeld chain tracker is not hard, so I quickly hacked together a small shell script that did exactly that. Introducing seinfeld.sh.

Now, the script is pretty simple, as I said, and probably has a bunch of bugs as well (and, frankly, some horrible code). At the moment, it does not even automatically detect new days, so I helped myself by copying the script on my server, putting the text file the script used into my dropbox, and triggering the “newday” routine via a cronjob on the server every day at midnight.

Current Features of the script:

  • seinfeld.sh do [project]: Mark a project as “done” for the day (represented by a “#”)
  • seinfeld.sh undo [project]: Mark a project as “not done” for the day (represented by a “-“)
  • seinfeld.sh newday: Add a new day to every project (represented by appending a “-“)
  • seinfeld.sh ls: Show the current chains
  • The script will ignore lines beginning with a “#”, so use that for comments
  • Update May 15th: Chain links are now color coded (green for “done”, yellow for “not done”)
  • Please read the instruction on the GitHub-Page

Feel free to clone the code, make improvements and send a pull request.

Find this Project on GitHub

Coding Project of the Day: attmail

(I have no idea if there are any projects out there that are named attmail. No copyright violations intended, it’s just my woking title 😉 )

Today, I had to get a backup script running on the server of my company. One part of the script should send an eMail with the backup attached every week.

Easy thing, right? I’ve got SSH access, so I can use just about anything a Linux Server has to offer.

Yeah, as it turns out, sending mails with attachments is actually not that easy if you can’t install your own stuff on the machine. The only (working) eMail solution available was Sendmail, and for that, you need to basically provide the whole eMail, encoded and everything. And, to make matters even worse, I had no access to uuencode. At least, I had Base64, so I knew that, somehow, it had to be possible.

Luckily, I found this thread, explaining how to send Base64-encoded attachments via sendmail. Bingo.

Being the computer science student that I am, I was not satisfied with the script (I am never satisfied with scripts that have everything fixed. I like my parameters). So, I set out to rework the script to make it more dynamic.

Now, about 3 hours later, I finally have a working solution (and have learned a lot about bash scripting). I know that any experienced Linux guy will probably claw his eyes out on seeing this code, but I’ll post it nontheless.

The Code on Pastebin (including usage instructions)

This Project on GitHub, in the unlikely case you want to fork and modify it.

It should be obvious that the code requires a working installation of sendmail to work correctly.

As always, feel free to comment with suggestions on how to improve the code, report any bugs (Untested usage scenarios include full path to attachment file (should work, I think), Filenames with Spaces or special characters except for .-_, and more). The code works for the scenario I intended it for, and that’s all I wanted. If it helps you, even better, but I will not offer too much in the way of support, due to time constraints and other problems.

Thanks, and have a nice day 😉