whats even better, is if u can set up in SQL server or your DB program a
"personal" string to append to your SQL code. that way it only runs when it
sees that string there, so URL hacks will be almost useless
Pooh Bear
Web App Developer
Picture Below (chicks dig my head!)
<HTML>
<HEAD></HEAD>
<BODY>
<IMG SRC="http://www.geocities.com/kickerazn_2000/sniffles_138x92.jpg";>
</BODY>
</HTML>
>From: "Josh R" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: CF-Talk <[EMAIL PROTECTED]>
>Subject: Diary of a hack attempt
>Date: Thu, 16 Aug 2001 18:20:10
>
>Wednesday morning, someone tried hacking into my website. (Not the first
>time, won't be the last) Didn't look like they made it. I can't be
>surprised. I have a controversial article about hacking plus I offer a
>security script. The fun part is there's nothing of value up there (my
>shopping site doesn't store credit card info or anything like that). But of
>course, they don't know that, and sometimes, they don't care.
>
>Since we just had a discussion about security, I figured I'd relate some
>details and observations for the sake of information. Perhaps this will
>help
>some people improve their security. (I'm assuming it's a "he" for ease of
>writing so don't get all sexist on me.)
>
>Some non-important details have been left out to protect my butt, but
>you'll
>get the full idea.
>
>(hack attempt)
>
>The first thing the guy did was try to use a well known IIS hole to look at
>my application.cfm. Didn't work. Then he tried the same IIS hole to look at
>my cart.cfm page. No luck there either.
>
>Then I received about 100 calls in about 2 minutes, each one aiming for
>locations of known scripts. It searched for known FrontPage extensions,
>locations of standard DLL files, well known CGI scripts, EXE files,
>standard
>Cold Fusion files, stock shopping cart files, the works. He even looked for
>scandisk logs and other known items. It tried a few locations for the same
>item, but not very much. Mostly it tried specific known holes.
>
>When that failed, he seemed to leave.
>
>(/hack attempt)
>
>OBSERVATIONS:
>
>This seems to have been what many people refer to as a "script kiddie".
>Some
>young (in terms of computer skill) person with knowledge of a few holes and
>a hacking program.
>
>First, he poked around to see if he could get information on my sites
>layout
>and vital statistics. Looking at the application.cfm and cart.cfm were the
>best bets for finding out important info, so kudos to the hacker for having
>some intelligence.
>
>Once he realized he wasn't going to get anywhere that way, he launched his
>"hack weapon of death".
>
>He has a program that runs through a list of known security holes. It
>systematically tries each one and alerts him to open doors.
>
>This has become a very standard way of attempting hacks. The days of some
>computer nerd exploiting one unknown hole is over. With so many systems and
>possible security holes, the usual attack is a shotgun attack, trying every
>known hole as quickly as possible.
>
>One thing I've noticed is that this shotgun method relies on one thing:
>Standard layouts.
>
>Every single hole he tried attempted to find a specific file in a specific
>location (or locations). These locations are known because programs install
>the same way every time. For example, when installing FrontPage in the
>default way (the way 99.9% of people install software), the same extensions
>are placed in the same location every time. Since the locations are known,
>the attack aims at those specific locations. The same is true about certain
>settings. Since programs install with certain settings (or default
>passwords) these are also scanned for.
>
>In other words these attacks aren't like a "find" program that looks all
>over your system for a particular file, they're more like a "run" program
>that expects something to be in a standard location. Since the file it
>wants
>isn't where it should be, nothing runs, and the hack is unsuccessful.
>
>However, since nothing on my system is in "default locations", this attempt
>doesn't seem to work. A more personal touch is required to enter my site
>and
>this guy didn't want to spend the time when other sites will probably fall
>victim to his shotgun technique.
>
>The important thing to remember about this kind of attack is that it isn't
>personal. These hackers are going "door-to-door" knocking and checking the
>handle to see if it's unlocked. When they find an entrance they head on in.
>They don't know who you are and they don't care.
>
>This guy didn't have a personal vendetta against me or my site. If he did,
>he would have poked around a little closer, searched the internet for
>personal info about me, made phone calls, bribed employees and friends for
>info and found out as much as he could about me and my sites layout so he
>could find a way to break in.
>
>That didn't happen. He couldn't find an easy entrance so he moved on to the
>next poor sucker. I got lucky this time.
>
>LESSONS:
>
>So what can we learn from this?
>
>Change all default settings on ALL programs:
>
>If you use Cold Fusion (which of course we all do), or anything else on
>your
>servers, place it in a non-standard location. Change the install from
>C:\Program Files\Allaire\ColdFusion Studio x.x or C:\CFUSION
>to something like
>C:\MY FILES ARE\SAFERHERE\Allaire\ColdFusion Studio x.x
>Place your websites in a non-standard location, so they can't jump to
>something else via url hacking.
>
>If you use a stock shopping cart, or stock CGI script, or anything like
>that, Place it in a non-standard location like
>www.website.com/cgi-bin/realscriptshere/sendmail.cgi. Make sure nobody
>looking at your HTML can tell where your scripts are located.
>
>Example: If you use AHP Shopping Cart, or CartEase or AbleCommerce etc.
>Chances are that your files are right where hackers want them to be.
>
>IMPORTANT: Many of the attacks are looking for a hole relative to the
>website. For example they hunt for "../_vti_pvt/scripthole.dll" or
>"../../_vti_pvt/scripthole.dll" since it's usually placed one or two
>folders
>away from your website. (God I love picking on FrontPage)
>
>Change standard passwords and default settings:
>
>When you install something (in a non-default location), always go through
>it
>and change potentially dangerous default settings. Look for default
>passwords and change them.
>
>A little fact to drive the point home: A well known car company got into
>big
>trouble because they only made about 53 different keys for all the cars
>they
>made. If someone has a collection of those keys, they have access to every
>single car made by that company. This means your car unless you go through
>the trouble to have the car rekeyed with a custom key. Websites are just
>like this.
>
>I am by no means a security expert. I'm just throwing out some things I've
>noticed for the sake of discussion. If this helps great. If you have some
>tips of your own, please share.
>
>================================
>Josh - [EMAIL PROTECTED]
>================================
>
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
![http://www.geocities.com/kickerazn_2000/sniffles_138x92.jpg"](http://www.geocities.com/kickerazn_2000/sniffles_138x92.jpg"){kind=link}