The Apache Software Foundation rolled out a patch last week to fix an Apache Server reverse-proxy vulnerability that allowed malicious hackers to access protected folders. Whether or not your organization runs Apache, the incident serves as a great reminder of the importance of performing vulnerability testing -- not just on the code you write in-house but that of third-party offerings as well.
The Apache reverse proxy flaw, in short, enabled hackers to access off-limits folders by simply inputting a directory path with a missing forward slash. With the slash removed, the application is no longer locked down to a hard-coded root or an anchor folder.
[ Download Roger Grimes's new "Data Loss Prevention Deep Dive" PDF expert guide today! | Follow the latest in open source developments and thinking with InfoWorld's Technology: Open Source newsletter. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. | Get a dose of daily computer security news by following Roger Grimes on Twitter. ]
Longtime security watchers may find this particular exploit interesting in that it's reminiscent of Web server hacking techniques we saw a lot -- a decade ago. Back in those days, many attacks began with multiple slashes interspersed with periods, often indicating current or parent folders. Thus, an attack back in the year 2000 might look something like this: ../..//../../. The idea was to use slashes and dots to confuse the program into allowing access to folders the host did not intend.
Over the past 10 years, these types of simple attacks have faded into obscurity -- or so we thought. The Apache vulnerability goes to show that old attack styles still have to be taken into consideration when designing modern-day software.
The vulnerability also demonstrates the importance of always testing your applications. Today's Internet server hacks primarily concentrate on unpatched bugs and application errors. Developers already know they should write their code using SDL (security development lifecycle) techniques, but I'm not sure most realize they should also check the quality of the code they don't write, such as Apache. You can't assume that code you didn't write is as secure as code that undergoes your own secure development and review.
