Has your site got the 3 basic security measures?

Written by Gim Yeap

In recent weeks, attacks on prominent sites such as Yahoo and Ebay have brought home a very pressing point - site security. Anywhere you have a dynamically-generated page, you could be open to attacks where malicious HTML is embedded into your pages. Your pages could be rewritten to substitute your customers' names with "Dummy." Or, credit card information could be intercepted and sent to a secret depository for later use. What can we do about this?

There are many methods by which a hacker may attack or take control of a site. I am focusing this discussion on attacks that come via form input. That is, anywhere you have input coming in from your web user, e.g. a registration form, user login or even a search on your site. Scripts could be sent to your server by entering < script> some malicious code < /script> in your input fields. The following are steps you can take to minimiserepparttar risk of this happening. These measures will not make your site hacker-proof (no site can be if a hacker really has it in for you), but it can make it less of an easy target. Step 1: Place character limits on your inputs You do this by addingrepparttar 132110 "maxlength" attribute into your text input tags

e.g. < input type="text" name="firstname" maxlength="15">

The example above restrictsrepparttar 132111 user to a 15 character input for that field. The "< script>" and "< /script>" tags alone will take 17 characters so repparttar 132112 smaller you limit your "maxlength" attribute to,repparttar 132113 harder it will be to include rogue codes in your inputs. Of course, you must ensure that you impose a suitable limit so that actual input from your valid users will not be excluded. Step 2: Filtering your data All data received from your site should be filtered, you can either filter your data when it comes into your server as user input, or when it goes out as results for your user's browser. Whether you should filter input or output, depends on your site and its requirements, there is a good discussion on this at http://www.cert.org ech_tips/malicious_code_mitigation.html/ . Filters can be written in any language, here is an example in Perl :

# This function checksrepparttar 132114 input, $firstname, forrepparttar 132115 following symbols ;<>?*/'&$!#()[]{}:"' # and tellsrepparttar 132116 user to re-enter his/her firstname if any ofrepparttar 132117 symbols is found if($firstname =~ /([;<>?*/'&$!#()[]{}:'"])/) { print p('Invalid input found, please use only alphanumerical input. Please re-enter your FIRSTNAME'); } You can see this script at work on our site : http://www.payingads.com/freesignup.html . Step 3: Settingrepparttar 132118 character encoding

Redirect Worms Away

Written by Richard Lowe

My site is hosted on an Apache web server. Why is that? Because, in my humble opinion, Microsoft's IIS web server is in no way qualified to service internet web sites (it is excellent as an intranet and applications server, however). Another reason isrepparttar vast number of security issues that seem to pop up day after day.

In point of fact,repparttar 132109 Gartner Group has recommended "that businesses hit by both Code Red and Nimda immediately investigate alternatives to IIS, including moving Web applications to Web server software from other vendors such as iPlanet and Apache".


But what about those of us who are already hosting their sites on Apache servers? I've seen lots of articles about how to protect, detect, cleanse and preventrepparttar 132110 worms from attacking IIS servers. Whilerepparttar 132111 worms do not penetrate Apache security, they do cause damage.

Some ofrepparttar 132112 damage includes:Server logs get filled with junk - The Nimda worm alone created over 20,000 entries in a 2 day period in my log files.

The server is made very busy - This is especially true if you've got a custom 404 error page, as I do. This means that every timerepparttar 132113 worm attempts a penetration, then entire 404 page is returned (in my case, that's about 40k). That adds up to a lot of wasted bandwidth.

I thought about this issue for a while after examining my logs and seeing thousands of 404 errors from attempted worm penetrations. Surely there was a way to at least reducerepparttar 132114 impact of these things? As I sawrepparttar 132115 404 error count increase, I realized that a significant portion ofrepparttar 132116 bandwidth that I was paying for was being thrown away.

An examination ofrepparttar 132117 log files produced several thousand attempts at each ofrepparttar 132118 following URLs. Obviously each of these isrepparttar 132119 address of a possible weakness in an IIS server.

/_mem_bin/..%5c../..%5c../..%5c../winnt/system32/cmd.exe /c/winnt/system32/cmd.exe /d/winnt/system32/cmd.exe /scripts/..%2f../winnt/system32/cmd.exe /scripts/..%c1%9c../winnt/system32/cmd.exe /scripts/..%%35%63../winnt/system32/cmd.exe /scripts/ .%%35c../winnt/system32/cmd.exe /scripts/..%c0%2f../winnt/system32/cmd.exe /scripts/..%c0%af../winnt/system32/cmd.exe /MSADC/root.exe

Cont'd on page 2 ==>
ImproveHomeLife.com © 2005
Terms of Use