Recently, I stumbled upon  (again) a PHP based piece of software I never had time to patch properly. As I'm surprisingly had a few man hours on my disposal, I decided to risk a cannonball in the mud. Please tighten your seatbelt and keep your popcorn reach.

The purpose of the piece of software won't be specified on it's purpose nor it's source will be released.

Let's take a look into some of it's issues.

A first issue almost killed the software. The software, build 2007-ish heavily relies on mysql_ methods of PHP5 without usage of PDO. And as a side node I got the information that the guy who build this was not even a developer, so he had zero expierience with software development. Great to hear, time to expect the worst case.

The 'inoffical' advise from the previous maintainers to me was 🙉 🙈 🙊.

And as we all know, nor PHP5.x nor mysql_ methods are supported anymore. And as the infrastructure below was updated without notice, the software stopped working, while the users needed it.

As the previous maintainers simply ignored all it's issues and let the PHP major releases pass by, a rewrite was not possible (in time) as the users was in need of the software as it was.

Time for a Wrap!

-per. The only solution to keep the software up and running was to create a kind of facade wrapper around the mysqli_ functions to 'simulate' and PHP5.x mysql_ environment. Not pretty, but realistic to get the software running again.

Did so. Software working again, Users happy, but this first glimpse of the core didn't feel good.

\'Escape your fckn input\'

Well, we all know this was coming.

Unescaped SQL, unfiltered user input, echo-ing unfiltered user input everywhere.
$query="Select * from table where email=".$_POST['email'].

What next. My first thought was 'I have to patch this ASAP', but to be realistic, possible damage has been done already for more than a decade. A proper battle plan was more important now than chaotic panic patching. So, I wrote down the details, documented the issue as good as I could and informed the stakeholder.  And the response was ¯\_(ツ)_/¯, even when I told them that a loss of data was realistic.

At this point I was baffled how less someone could care. I mean - I even had a working "exploit" (basically only a GET request) to demonstrate the issue live to show how severe it was for the stakeholders data - no real response. So no real decision there, I hoped for a 'put it offline'. After that, I decided to try to fix the majority of the issues I could find to at least calm my nervous brain a bit.

Meanwhile, the software, ugly as it is, was patched enough for the moment from my point of view. But I'm sure it won't improve any further as the options are quite limited without rewriting everything.

So I thought what to do next: Source code control and documentation!

The software had never been in a repository before. In some code files you could only see structures like

/*
20.04.2008: Changed stuff
*/

/*
01.03.2010: Commented out stuff, please comment in the day later!
*/

So it was time to properly put it in a repository to atleast get the chance to review changes in the future.

But doing git add . and hope for the best did not feel right. So I decided to do some cleanup in the code, removing all files I knew it was not used anymore.

And yes, I did a backup before, you never know.

As I knew that the software had a main index.php which includes all (all!) their needed files at once I could simply do a grep -R 'pathtoanother.php' . to find out if a file was included or not.

This step reduced the amount of source files (mostly .php) by about 50%. So 50% less room for intruders! 🥳

Time for git add .? OF COURSE! NOT.

The complete folder was about 13 GB (!) of data. As I'm focused on the development part it was time to create a .gitignore to avoid polluting the repository with non-source assets.

Finally, I was now able to run a git commit properly without throwing 13 GB of data into the repository.

Fun side note: While digging in the code, I even found  a relict from the past I hadn't seen for a long time - a marquee element!

Documentation time

Writing a fully pledged documentation is not easy for this software. This has mostly following reasons:

• No documentation of requirements existing
• How do you document code which breaks any standard? No MVC with a wild mix of code into the view?
• How do you document a database which does not even pass the 1st normal form?

So, in conclusion you don't have a proper architecture nor any kind of data model here. So what to note? I've decided to write down changes and a rough architecture view and what the unfixable issues are. This may not be sufficient to count as a 'real' documentation but it's at least something to work with in the future.

Conclusion

So what can I learn from this maintaining job?

✔ Expect things get even worse

✔ Documentate steps you do

✔ Inform the stakeholders (and leave a (digital) papertrail)

✔ You have to make decisions

❌You can't patch everything

❌For stakeholders: Never hire non-developers to develop software