What Came After PHP?

Seriously. Not asking for a friend.

At my day job, I continue to take a lot of flak from the dev team for building web apps with PHP and MySQL. They don’t consider PHP a real programming language, and anyone who uses it is stuck in the past with Britney Spears and Austin Powers. Myself? I still like it, specifically because I can deploy a web app very quickly.

I wasn’t hired to build web apps, but when you’re trying to manage complex processes and large amounts of disparate information, you start looking for solutions that are efficient, accessible, and easy to build a process around.

For example, we get a lot of requests from customers about whether or not our product is affected by the latest CVE (Common Vulnerabilities and Exposures). When those requests come in, we usually have to forward them to our dev team for investigation. If they’ve answered the question before, they have to go through old emails to find their previous responses.

This is not a good process; it interrupts important dev work (those witty Reddit comments aren’t going to write themselves).

So what we needed was a way for the Technical team to proxy those inquiries, log the responses, and hopefully, prevent requests from getting to the dev team. This would require two separate pieces:

  • An internal app to add/edit/delete CVEs from the database
  • An external app to display the database

Although I often try to defend my apps as more than glorified interfaces for a simple spreadsheet, these two are pretty much that. The only interesting thing I got to do was URL rewriting, so that we could link to individual issues as domain.com/CVE-2017-0993. It just looks nicer.

Having these apps allows me to create a dead-simple CVE request process for my Support Techs to follow:

  1. Check CVE against database
  2. If found, send response to customer
  3. If not found, send request to development
  4. Add CVE and development response to database
  5. Send response to customer.

Ideally, once dev answers a question about a particular CVE, they’ll never have to be bothered about it again… unless I somehow overwrite the PHP files that power the app. Not that I’ve ever done that.

Here’s some .htaccess magic to make URL rewriting work:

RewriteEngine On
RewriteCond /var/www/docs/%{REQUEST_FILENAME} !-f
RewriteCond /var/www/docs/%{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/docs/cve/sitemap\.xml$
RewriteCond %{REQUEST_URI} !^/docs/cve/pdf/.*$
RewriteRule (.*) index.php

Don’t ask me what any of these things do. Like I said, it’s magic.

And here’s how you get the relevant info out:

$path = ltrim($_SERVER['REQUEST_URI'], "/"); # trim leading slash(es)

# trim everything after ?
if(strpos($path,"?") !== FALSE)
     $path = substr($path, 0, strpos($path,"?"));

$elements = explode('/',$path);
$cve = cve_scrub($elements[2]); # first 2 elements are part of url path

The cve_scrub function contains a whole host of filtering commands because hackers.

I love how fast apps can be put together with PHP/MySQL, but for the last several years, I’ve had this nagging feeling that there’s something better out there. If anyone wants to point me in the right direction, let me know in the comments.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s