I received an email the other day from a buddy from my former life in the Marine Corps. The email was basically a mass spam letting all of his friends know that he was planning on having a party in the coming months and had created a website with a forum to track reservations and random conversation. Since it’s an 8 hour drive back out there to Virginia, I only get to visit a couple of times a year and this party sounded like a pretty good excuse to make the trip. So, I went ahead and registered for an account on the website and logged in to make my reservation and see what everyone had to say about the party and what they’ve been up to.
As soon as I logged in, I made my way to the forum links to join the conversations. When I clicked on the very first link, can you guess what I was offered? That’s right, a very juicy error message letting me know that an error had occurred in the application. Now, it’s great that the server informed me that an error had occurred, but i was astonished at all of the information it was giving me…just a normal user. The first thing that I noticed is that the error page showed the average user the complete, full path to the location of the script that had failed. Not only did it give me the full path, it also showed me the exact number of the line in the script that was causing the problem…in addition to 3 lines above and below the faulty line. In those lines I got to see several interesting SQL arguments being passed, complete with tables and fields and object names. If I were specifically attacking this site, this error message would have given me some great information. Since I wasn’t attacking the site, I promptly emailed my buddy and told him about the problem I had just seen and suggested that he customize those error messages so that they don’t give out too much information. Needless to say, he got right to work on identifying the problem and limiting the amount of information that was being divulged.
Now, you might say to me, “why would it matter, it was a fairly useless website with no useable information”. I’d tell you that you are right, in the grand scheme of things. Sure, I probably wouldn’t be able to get my hands on any uber-sensitive information. That’s not what is important. What is important is that my buddy who built the site also creates some fairly powerful custom web applications for the government. If his useless website is configured in such a way, is he making the same mistakes when building applications for the people that want to keep the secrets….well, secret?
By offering up an error message like that, an attacker is able to use the information to refine their attacks. In addition to that, we used to have a saying in the Marine Corps when preparing for a wall locker inspection. “If the presentation of the wall locker is such that the inspector doesn’t want to mess it up to inspect it, you’ll do just fine. If it looks like trash, the inspector is going to start digging into things, ultimately finding more problems.” The same idea holds true for attackers. If you present an application or website that doesn’t give away too much information and appears to be well secured, most attackers will move on to the next site. If simple things like error messages divulging tons of information are found, you can bet that the attacker is going to believe that there are other configuration errors and will begin to dig around. We don’t want them doing that, now do we?
I don’t mean to pick on him about this because he is a very good programmer, security savvy and very smart guy. He and I spent many, many hours in the Marine Corps investigating incidents together and solving problems. I simply wanted to use this real world experience to illustrate how important it can be to make sure that your web applications are configured securely. Even if they appear to be useless websites that no one would be interested in, they can lead to attack escalation and possibly compromise.