I often
surf the web and see blatant design errors that make me shake my head. Without
even investigating the security of a site, I know without a doubt that the site
will be chock full of vulnerabilities. How can I be so sure? I see programming
mistakes that illustrate an utter lack of concern for security. They are ugly
mistakes that are far too prevalent. If you have any of the issues mentioned
below in your own web application, it's time to sit down with your developers
and have a chat. If these mistakes are being made, dig deeper. You may not like
what you see, but its better that you uncover the problems than leave them to
be discovered by someone else. For each of the signs listed below, take a look
at the included examples for public evidence of just how wide spread the
problem is.
1.
Exposed Usage statistics
Everyone
wants to know who's visiting their web site and there is no shortage of
applications available to help you to figure it out. While commercial log
analyzers exist, open source alternatives tend to be the most popular, even on
commercial web sites because there are plenty to choose from that offer more
than adequate functionality. What I don't understand is why site administrators
fail to lock these applications down. First off, popular tools such as AWStats and Webalizer have had no shortage
of serious security vulnerabilities. Why advertise that you're using a potentially
vulnerable application? More importantly, the people that have been using your
web application and what they've been doing during their time there, is
confidential information. Why share it with the world?
Examples
2.
Copies of backup files
This is a
mistake that I often make myself while working on a personal website. I make
the mistake because I don't have a QA or development environment for a site
that I use for posting pictures of my last vacation for family members. I
certainly hope that's not the case for your commercial web site. Developers
often rename old copies of web pages when uploading a new version. This way, if
something goes wrong, they can easily switch back to the old version. This is
generally done by appending an extension to the file name such as ‘.old' or
‘.bak'. The problem occurs when the developer forgets to remove the old copy of
the page. Web servers don't recognize a ‘.old' or ‘.bak' file extension. If an
attacker is savvy enough to request every known page on your website with one
of these extensions and you've forgotten to remove backed up content, your web
server will gladly offer to download a copy of your source code.
Examples
3.
Your site shows up on a 'Wall of
Shame'
We're seeing
so many examples of web sites with common vulnerabilities such as cross site
scripting vulnerabilities, even the hackers are getting tired of it. "Wall of
shame" web sites have begun to emerge whereby participants post vulnerable web
sites as they come across them. While the approach is not without controversy,
I wonder if public embarrassment is the only tool that will cause companies to
take web application security seriously. Significant vendors such as Dell, HP, MySpace,
Photobucket, F5, and Acunetix have all made the sla.ckers.org wall of
shame.
Example
4.
Browseable directories
If you
can't lock down your web server, is there much hope for your web application?
While directories are occasionally made browseable by design, it is typically a
sign of poor server administration.
Examples
5.
Login credentials passed over clear
text
Passing
login credentials in clear text is a neon sign in the middle of Times Square. It says - "I know nothing about security".
6.
Outdated SSL certificates
How can you
trust a web site that isn't willing to pay a few hundred dollars to keep its
SSL certificate current? If you don't plan to keep a current certificate, it's
better not to use SSL at all. When your client gets a warning message from his
web browser letting him know that there's a problem with the connection, he may
just put his credit card away for good.
7.
Vulnerable third party applications
Don't get
me wrong, I'm a big fan of code reuse. Why re-invent the wheel when there are
perfectly good open source wheels all around you? That said, never consider any
third party code to be trusted. It should be subjected to the same security
controls as the rest of your code before being included in your project. Even
then, it is vital that you have a process in place to constantly be monitoring
for known vulnerabilities which may emerge in a library that you chose to
include in your application. At a minimum, regularly monitor the free
vulnerability aggregation sites listed below to identify problems in shared
code.
Examples
8.
Verbose error messages
Verbose
error messages are useful for developers but they're a red flags for users. You
don't need to be a security expert to know that a nasty error message suggests
a potentially vulnerable web application. SQL injection is one
of the most prevalent and damaging vulnerabilities plaguing web
applications today and error messages are a homing device that can lead you
right to them. Don't be fooled though, turning off the error messages doesn't
eliminate the vulnerability; it just makes them a bit harder to find.
Examples
9.
Developer comments in source code
Comments
are a handy way to mark sections of your source code that still require some
work. They're especially useful when you have a team of programmers working on
the same piece of code. Just make sure that you clear up any outstanding issues
and remove the comments before the code goes into production. Google has
provided us with a handy little tool known as Google Code Search which now makes
it trivial to look
for interesting developer comments hidden within vast libraries of code. Be
sure that your comments don't serve as a blueprint to point out holes in your
application.
Examples
10.
You've been defaced!
If you show
up in the Zone-H Defacement Archive, you shouldn't be wasting your time reading
this blog...you've got work to do.
Examples
- michael
Posted
11-01-2006 12:40 AM
by
erik.peterson