Tip #1 - If you build it, they will come through the Internets

Let me paint a picture of some of the recent problems I've come across:

1. http://boydswebsite.com/admin
2. http://boydswebsite.com/test?_f=/tmp/view.bmp
3. http://boydswebsite.com/test?filename=/web/view2/note.txt
4. http://boydswebsite.com/test?url=http://boydspartnerwebsite.com
5. http://boydswebsite.com/public/sensitivefile.doc

---

The web addresses listed all had one (at least) problem. Programmers or administrators created these potential backdoors with one thought in mind: I have to get this thing to work. I'll walkthrough each of these examples and why they are bad.

1. This website gives a GUI administrative interface into the application with no credentials needed. Reasoning: No one knows that this page exists. Why it's bad: People can easily guess this page might exist.

2,3. These look like files to me. What happens if I throw in a ../../../../../../../etc/shadow or ../../../{cont}/boot.ini? Maybe this comes back with the file instead of an error message. Reasoning: This is a function the web site needs for interaction. Why it's bad: People who see this function will guess that arbitrary files could be gathered without any authentication.

4. This is basically important for spammers or hackers. The url parameter might send a client to a hacker website. Google owasp for more details on this one.

5. Not much to describe here. Web servers often allow directory listing... taking away the hard work for hackers. Directory listings sharing sensitive files occur very often-just ask JohnnyIhackstuff. Reasoning: I need to share this file with a co-worker and it's too big to email. Why it's bad: Most likely these files will remain for months or years somewhere on the Internet.

Moral of the story: People exist who want to take advantage of low hanging fruit. Check the simple stuff first.