On the Recent Security Issues of Web Sites


Nov 18, 2013 (2 years and 11 months ago)


National Conference on Communication and Information Security (NCCIS 2012)
Daffodil International University, Dhaka, Bangladesh, 31 March 2012.


On the Recent Security Issues of Web Sites

Ali Ashraf Molla, M Abdus Sobhan

School of Engineering and Computer Science
Independent University, Bangladesh (IUB), Dhaka, Bangladesh
E-mail: ashraf@aliashraf.com, masobiub@gmail.com

AbstractRecently, websites are being hacked
randomly by the hackers, causing colossal losses of
financial and intellectual properties. In this paper,
authors try to identify loopholes of websites through
which hackers disrupt and dismantle its operation
causing the losses of mentioned above. Authors also try
to give some recommendations as to how these ill-motive
activities may be stopped. This should be speciously
noted by the web administrator skilfully. A case study
using the Joomla security checklist highlights how to
stop hacking websites. That may provide real life
solutions procedures for the web administrators.

Keywords Website, Security, hacking, Injection,
CMS, joomla.


A. Introduction
Nowadays not only every organization has its own
website but even everybody has his own website.
But we should follow the perfect security policy,
because hackers are ready to hack or interrupt the
websites. We can see the example of the cyber war
between Bangladeshi and Indian hackers groups.
This type of destructive task is increasing day by
day. If we find the statistics of this type of task then
we can think about the security threats of websites
caused total losses in 2005 shown in Figure 1.

Figure1 The figure above shows the total losses as
reported by the 2005 CSI/FBI Annual Computer
Crime and Security Survey [1].
B. Motivation
Due to cross border cyber warfare and crime, a
colossal loss of financial and intellectual properties
is found to have become a regular matter in the
cyber World recently. Generally, the sites of
financial, Government, Education, Law and Order
Service providers are being hacked. And this cyber
attack is increasing day by day. So, we need to
increase the security level of the websites to
decrease the losses through their uninterrupted
services. The authors attempt to identify the areas or
loopholes of websites through which hackers
threaten to disrupt and dismantle the continuous
activities of the websites. Authors also tried to give
some recommendations and solutions to the above
problems, which should be taken care by the web
administrators skilfully.


Now, we discuss the types of breaking web security.
These are the ways through which hackers cause
disruption of the web sites. An Interesting Report
on Web Security provided by the web security
company, Cenzic released a report detailing trends
and numbers relating to Web security for the first
and second quarters of 2009.

Figure 2 Cenzic released a report detailing trends
and numbers related to Web security for the first
and second quarters of 2009[2].
National Conference on Communication and Information Security (NCCIS 2012)
Daffodil International University, Dhaka, Bangladesh, 31 March 2012.


A. SQL Injection
SQL injection is used to attack the security of any
website by using SQL command in a poorly
designed website to break operations on the
database other than the usual operations as intended
by the designer. It is a code injection technique that
breaks the security vulnerability in a website's
software. It happens when user input is either
incorrectly filtered or string literals escape
characters embedded in SQL statements or user
input is not strongly typed and unexpectedly
executed. SQL commands are thus injected from the
web into the database of an application (like
queries) to change the database content or dump the
database information like credit card or passwords
to the attacker. SQL injection is mostly known as an
attack vector for websites but can be used to attack
any type of SQL database.[3]

B. Cross-Site Scripting
Cross-site scripting (XSS) is another type of
security vulnerability found in Web applications
that enable attackers to inject client-side script into
Web pages viewed by other users. A cross-site
scripting vulnerability may be used by attackers to
bypass access controls such as the same origin
policy. Cross-site scripting carried out on websites
accounted for roughly 80.5% of all security
vulnerabilities documented by Symantec as of 2007.
Their effects may range from a petty nuisance to a
significant security risk, depending on the
sensitivity of the data handled by the vulnerable site
and the nature of any security mitigation
implemented by the site's owner [3].

C. Remote File Inclusion (RFI)
In remote file inclusion or code injection, an
attacker uses a flaw in any website to inject code
from another server to run on attacked server. It is
in the same family as XSS but much more
problematic because the hacker has full access to
the hacked server.
Any code injected to the server with an untested
variable and include() command, for example, could
run server commands: upload and download and
transfer data to other servers, check the server
passwords and user names, anything one can do on
the command line via PHP or ASP if the server
This is probably the worst. It can happen to the
server, because with command line access, it can
turn it into an attack a machine for a server network
attack, silently listen to everything and the users do
on the server and send it to another Web resource,
store information and viruses for distribution, inject
spam links.
The workaround is to turn off globals and to never
ever assemble a URI from parameter or form data.

A. Keep Code Up-to-Date
We should keep up-to-date the source code of any
website. In security system, there is no better
protection than keeping site code up-to-date. Old
versions of WordPress or Joomla install PHP and
MySQL, even old browsers, all of these are security
issues because most updates of software these days
are security patche
s. It is like a rat race between those who want the
Web to work and those who want to abuse it to
make a quick buck or to steal the site identity. So it
is wise to upgrade whenever a new version is out.
We should up-to-date not only the code of any
application software but also services provider
software. If we use PHP mysql and apache, we
should always up-to-date the PHP version, MySQL
and Apache server[3].

B. Always logout from the website administration
control panels
Always logout from the website administration
control panels. Staying logged in while not using a
system is dangerous. Other websites one surfs can
check that the site is logged in and then clickjack to
do something that the site owner does not mean to
or is not aware of. This is especially dangerous with
social media because everything done will be sent
to all others and probably replicated by them. It is a
snowball effect [3].

C. Use correct format passwords
Password policy is another issue for protect the web
site. We should use password with proper format
that means to use complex password. A password
should be changed after a certain time. It should be
changed every week.

D. Turn Off Folder Listing
Folder listing is another issue of vulnerabilities of
any website. We should hide off folder listing of
any web site. From this listing any one can try to
find the structure of any site, folder path, and
content of any site.

E. Turn Off Error Messages
It is another issue to find out the problem of any
software. From the error massage, we can find the
problem. But it should stop to view for all users. Lot
of servers is set up to show the error messages when
the browser encounters a problem. These messages
often look cryptic, but they are great source of
National Conference on Communication and Information Security (NCCIS 2012)
Daffodil International University, Dhaka, Bangladesh, 31 March 2012.


information for attackers. By the error message, any
hackers can attack the server.

F. Automatically Checking CMS contents
We can always check the software update status of
open source CMS. There is lot of tools to check the
Content Management System (CMS) version update
status. For an example, admin tools are free tools to
check the joomla update status. It also ensures the
basic security, file permission and update the
application. So, we can use these types of tools save
our site from any unwanted access from any
hackers. Some tools help us to detect the DDOS and
store the access log where the audit log is found.


In this section, the case study of open source web
security is taken from the document posted by
Joomla Security Checklist Guide in its website. This
Security Checklist Guide is very important for web
security in a generalized way and we recommend to
be consulted by every web administrator.
Now, we discuss about an open source CMS
security update. Nowadays Joomla is used by a lot
of users, web developers, web programmers etc.
Open source CMS joomla gives some security
check list to protect website. But we should think
that these checklists are not enough to protect our
website, because day by day hacking type has been
changed. So we should always update our security
and keep eyes on the recent hacking methods. The
security checklist is given below:

A. Security matters
Web security is a fast moving challenge and always
presents threat. Actually there is no single way to
secure a website and all security methods are
subject to instant obsolescence, incremental
improvement, and constant revision. All public
facing websites are open to constant attack. Are the
site owners willing and able to invest the time it
takes to administer a dynamic, 24×7, world-
accessible, database-driven, interactive, user-
authenticated website? Do they have the time and
resources to respond to the constant flow of new
Internet security threats? There are some well-
established principles upon which to base to base
the defensive plans. The following checklists point
toward current best practices for Joomla security.

B. The most important guidelines
These checklists are long and growing because the
full plot is thick, complex, and expanding, but do
not despair! Here are a few essential guidelines for
securing in any website. Following them will
protect the site from most of the catastrophes.

Back up early and often: Set up (and use and test)
a regular backup and recovery process. When done
well, this ensures that the site can recover from
almost any imaginable disaster.

Update early and often: Promptly update to the
latest stable version of Joomla and any installed
third-party extensions. This ensures that the site is
protected from the newest vulnerabilities as soon as
a fix is released and from the latest attack methods
as soon as a defence is developed.

Use a secure host: Use a high-quality Web host. Do
not be fooled by offers of unlimited bandwidth,
unlimited hard drive space, unlimited databases, etc.

C. The bad news
There is no perfect security on the Web: As
economists would say, "There is no free lunch." Not
to be fooled by Joomla's award winning ease-of-use.
Maintaining a secure Web site on the open Internet
is not easy. Maintaining adequate security requires a
wide and ever-growing range of skills and
knowledge, constant watchfulness, and a robust
backup and recovery process.

There is no one right way: Due to the variety and
complexity of modern web systems, security issues
cannot be resolved with simple, one-size-fits-all
solutions. One (or someone trust) must learn enough
about the server infrastructure to make valid
security decisions. Strong security is a moving
target. Today's expert might be tomorrow's victim.

There is no substitute for experience: To secure
the Web site, one must gain real experience (some
of which will be bitter), or get experienced help
from others. If one does not invest, considerable
time it takes to learn how to maintain a secure Web
site. Read this tongue-in-cheek description of the
Top 10 Stupidest Administrator Tricks which
illustrates typical, blow-by-blow examples of how
to learn Web security the hard way.

D. The good news
Even a beginner can start at the head of the herd:
User forums for many systems are clogged with
Help! One may have hacked posts by people who
did NOT follow standard security practices. If he is
studying this checklist before his site is attacked, he
is ahead of the herd.

National Conference on Communication and Information Security (NCCIS 2012)
Daffodil International University, Dhaka, Bangladesh, 31 March 2012.


It is not as hard as it looks: If this is one of the
first websites, security issues may seem
overwhelming, but one is to deal with all of them at
once. Start with the most critical issues. As he
becomes more familiar with GNU tools and
techniques, including GNU/Linux, Apache, MySQL,
Subversion, JavaScript, and Joomla! ,he will add
refinements to his set of security tactics.

You can get help: If one believes his website was
attacked, he should not simply post an
announcement with full details in the Joomla
forums. If one is dealing with a new vulnerability or
new form of attack, publishing that information
could put other websites at risk. Instead, he should
report possible security vulnerabilities to the Joomla
Security Task Force.

E. The most important decision
Probably no decision is more critical to site security
than the choice of hosts and servers. However, due
to the wide variety of hosting options and
configurations, it is not possible to provide a
complete list for all situations. Check this unbiased
list of recommended hostswho fully meet the
security requirements of a typical Joomla site.

F. Shared server risks
If one is on a tight budget and his site does not
process highly confidential data, he can probably
get by with a shared server, but he must understand
the unavoidable risks. Most of the tips listed below
are appropriate for securing sites on shared server

G. Avoid sloppy server configurations
For a real eye-opener, read this report on thousands
of sites that allowed Google to index the results of
phpinfo(). Not to make this mistake on ones site!
The report includes alarming statistics on the
percentage of sites that use deprecated settings such
as register_globals ON or that do not have
open_basedir set at all: By the way, if phpini and
register_globals are unfamiliar terms one is
probably not ready to securely manage his own site.

H. Configuring Apache
Use Apache .htaccess: Block typical exploit
attempts with local Apache .htaccess files. This
option is not enabled on all servers. One should
check his host if he runs into problems.
Using .htaccess, one can password protect sensitive
directories, such as administrator, restrict access to
sensitive directories by IP Address, and depending
on his server's configuration, he may be able to
increase security by switching from PHP4 to PHP5.

Joomla ships with a preconfigured .htaccess file, but
*one* needs to choose to use it. The file is called
htaccess.txt. To use it, rename it to .htaccess and
place it in the root of the site using FTP. One
important point to note is that as the distributed file
is called htaccess.txt and the live file on the site is
called .htaccess, the file the site actually uses is
NOT updated when he updates his site to use to a
new version of Joomla. One must manually make
the changes to use the new file version.

Use Apache mod_security: Configure Apache
mod_security and mod_rewrite filters to block PHP
attacks. See Google search for mod_security and
Google search for mod_rewrite.

I. Configuring MySQL
Secure the database: Be sure MySQL accounts are
set with limited access. The initial install of MySQL
is insecure and careful configuration is required.
Note: This item applies only to those administering
their own servers, such as dedicated servers. Users
of shared servers are dependent on their hosting
provider to set proper database security.)

J. Configuring PHP
Understand how PHP works: Understand how to
work with the php.ini file, and how PHP
configurations are controlled. Study the Official
List of php.ini Directives at http://www.php.net, and
the well-documented default php.ini file included
with every PHP install. Here is the latest default
php.ini file on the official PHP site.

Use PHP5
Use local php.ini files: On shared servers one
cannot edit the main php.ini file, but he may be able
to add custom, local php.ini files. If so, he will need
to copy the php.ini files to every sub-directory that
requires custom settings.

There are a few important things to keep in

Local php.ini files only have an effect if the server
is configured to use them. This includes a php.ini
file in the http_root directory. He can test whether
or not these file affect the site by setting an obvious
directive in the local php.ini file to see if it affects
the site.

National Conference on Communication and Information Security (NCCIS 2012)
Daffodil International University, Dhaka, Bangladesh, 31 March 2012.


Local php.ini files only affect .php files that are
located within the same directory (or included() or
required() from those files). This means that there
are normally only two Joomla directories in which
one would want to place a php.ini file. They are the
http_root( sites actual directory name may vary),
which is where Joomla's Front-end index.php file is
located, and the Joomla administrator directory,
which is where the Back-end administrator
index.php file is located. Other directories that do
not have files called via the Web do not need local
php.ini files.

If one has a php.ini file in every directory, some
script probably did this. If one did not intend it to
happen, he probably should root them out, but given
#2 above, he probably only have to panic about the
php.ini files in http_root and the administrator

Use PHP disable_functions: Use disable_functions
to disable dangerous PHP functions that are not
needed by ones site. Here is a typical setup for a
Joomla site:
disable_functions = show_source, system,
shell_exec, passthru, exec, phpinfo, popen,

Consider Using PHP open_basedir: One might
consider enabling open_basedir. This directive
limits the files that can be opened by PHP to the
specified directory-tree. This directive is NOT
affected by whether Safe Mode is ON or OFF.

The restriction specified with open_basedir is a
prefix, not a directory name. This means that
open_basedir = /dir/incl allows access to
/dir/include and /dir/incls if they exist. To restrict
access to only the specified directory, end with a
slash. For more information, see PHP Security and
Safe Mode Configuration Directives.
open_basedir = /home/users/you/public_html
Additionally, if open_basedir is set it may be
necessary to set PHP upload_tmp_dir configuration
directive to a path that falls within the scope of
open_basedir or, alternatively, add the
upload_tmp_dir path to open_basedir using the
appropriate path separator for the host system.
open_basedir =

PHP will use the system's temporary directory when
upload_tmp_dir is not set or when it is set but the
directory does not exist; therefore it may be
necessary to add it to open_basedir as above to
avoid uploading errors within Joomla.

Don't use PHP safe_mode: This feature has been
DEPRECATED as of PHP 5.3.0. Relying on this
feature is highly discouraged. Avoid the use of PHP
safe_mode. This is a valid but incomplete solution
to a deeper problem and provides a false sense of

safe_mode = 0

Do not use PHP register_globals: Automatically
registering global variables was probably one of the
dumbest decisions the developers of PHP made.
This directive determines whether or not to register
the EGPCS (Environment, GET, POST, Cookie,
Server) variables as global variables where they
become immediately available to all PHP scripts,
and where they can easily overwrite ones own
variable if he is not careful. Luckily, the PHP
developers long since realized the mistake and have
deprecated this 'feature'.

If ones site is on a shared server with a hosting
provider that insists register_globals must be on,
yhe should be very worried. Although he can often
turn register_globals off for his own site with a
local php.ini file, this adds little security as other
sites on the same server remain vulnerable to
attacks which can then launch attacks against his
site from within the server. For more information,
register_globals = 0

Do not use PHP allow_url_fopen: Do not use PHP
allow_url_fopen. This option enables the URL-
aware fopen wrappers that enable accessing URL
object like files. Default wrappers are provided for
the access of remote files using the ftp or http
protocol, some extensions like zlib may register
additional wrappers. Note: This can only be set in
php.ini due to security reasons.
allow_url_fopen = 0

K. File permissions
If a joomla installation is hosted on apache with
mod_php, then all virtual hosts on that server run in
the same context as his joomla code. If the files are
owned by some other user than 'nobody' or
'wwwrun', the safest permissions are those which
prevent changes to the joomla code, unless via an
authorised channel (e.g. FTP):
· DocumentRoot directory: 750 (e.g.
· Files: 644
· Directories: 755 (711 if you are paranoid,
but not for directories which need to be
listed) (owner: some user)
National Conference on Communication and Information Security (NCCIS 2012)
Daffodil International University, Dhaka, Bangladesh, 31 March 2012.


With these permissions set, one will need to use
FTP to update his Joomla installation. Not all
modules support this. Remove modules which do
not support FTP upgrades. Other processes running
under mod_php can read ones configuration.php.
He can frustrate automated hacks by renaming this
file. He should not store his FTP password in his
configuration file on such hosts, as his account will
be compromised.
If a joomla installation is hosted on apache with
fast-cgi, suphp or cgi that runs as a different user,
then he should set his permissions as follows:
· DocumentRoot directory: 750 (e.g. public_html)
· PHP files: 600 (400 if you are truly paranoid)
· HTML and image files: 644 (444 if you are
truly paranoid)
· Directories: 755 (711 if you are paranoid, but
not for directories which need to be listed)

L. Setup a backup and recovery process
The most important rule: One should at all time be
able to return his site to a previous working state
through regular use of a strong, off-site backup and
recovery process. One should be that his backup
and recovery process is in place and tested
BEFORE goes go live. This is the single best way
(and often the only way) to recover from such
inevitable catastrophes as:

1. A compromised/cracked site.
2. Broken site due to a faulty upgrade.
3. Hardware failure, such as dead hard drives,
power failures, server theft, etc.
4. Authoritarian government intervention. (More
common than some think.)
5. Needing to quickly relocate to a new server or
hosting provider.

M. Testing and Development
Develop locally, deploy globally: Develop and test
ones site on a local machine first. Installing Joomla
locally is not as hard as it may sound, and the
exercise will greatly boost his confidence.

Use an IDE: Consider using an Integrated
Development Environment (IDE). One free IDE
that many Joomla Developers use is Eclipse. See
Setting up the workstation for Eclipse development
for instructions on installing Eclipse.

Use a versioning system: Be able to roll back to an
earlier version of the site using a modern version
control system, such as CVS, Subversion, or git.
The Eclipse IDE indicated above includes a
Subversion plugin. This allows one to work with the
Joomla Source repository as well as other projects
hosted on JoomlaCode.

Setup a backup process first

The most important rule: Some one should
always be able to return his site to a previous
working state through regular use of a strong, off-
site backup and recovery processes.

He should be aware about the backup and recovery
processes are ready and tested BEFORE the site
goes live.

This is the single best way (and often the only way)
to recover from such inevitable catastrophes as:
1. A compromised/cracked site.
2. Broken site due to a faulty upgrade.
3. Hardware failure, such as dead hard drives,
power failures, server theft, etc.
4. Authoritarian government intervention. (More
common than some think.)
5. Needing to quickly relocate to a new server or
hosting provider.

N. Install official versions of Joomla
To avoid breaking about some ones, he should
search the forums for reports of incompatible
extensions before upgrading to a new version of

Upgrade to the latest stable version of Joomla as
soon as possible.

Download Joomla from official sites only, such as
JoomlaCode.org, and check the MD5 hash.

Use Joomla Diagnostics to ensure that all files were
installed correctly.

Protect directories and files: Increase the security of
the critical configuration.php file by moving it
outside of the public_html directory. Ensure that all
configurable paths to writable or uploadable
directories (document repositories, image galleries,
caches) are outside of public_html. Check third
party extensions such as DOCMan and Gallery2 for
editable paths to writable directories.

Adjust file and directory permissions: This option
no longer appears in Joomla. On Older versions of
Joomla : Once ones site is configured and stable,
write-protect critical directories and files by
changing directory permissions to 755, and file
permissions to 644. There is a feature in Site -->
Global Configuration --> Server to set all folders
National Conference on Communication and Information Security (NCCIS 2012)
Daffodil International University, Dhaka, Bangladesh, 31 March 2012.


and file permissions at once. Test third party
extensions afterwards and carefully review the code
of any extension that has trouble with such settings.
Note: Depending on ones server's permissions, he
may need to temporarily reset to more open
permissions when installing more extensions with
the Joomla installer. This option no longer appears
in Joomla; but is included for historical purposes.

O. Installing Joomla Extensions
Backup before installing: Before installing
extensions, always backup the site's files and
database. This follows a very basic principle:

One should at all times be able to return his site to a
previous working state.

Therefore, it is smart to set up a simple and fast
backup script to automate this task. If one does not
set up an easy process in advance, he will be sorely
tempted to do a quick upgrade without backing up
first. This very understandable tendency is however
one of the chief causes of premature hair loss,
sudden career changes, and even death.

Check for extension vulnerabilities: Most security
vulnerabilities are caused by third party extensions.
Before installing extensions, check the Official List
of Vulnerable 3rd Party/Non Joomla Extensions.
There is an entire forum dedicated to vulnerable
third part extensions. Subscribe to it.
Download from trusted sites: The fully qualified
and official definition of a "trusted site" is one that
some body trusts.

User should be aware! Check the code quality:
Third party extensions come in all flavors of quality
and age. Although Joomla coding standards exist,
third party developers are not required to follow
them. Extensions listed on the official Joomla site
are not reviewed for compliance, however if
verified vulnerabilities are reported, they will be
removed from the list until they are fixed.

Test all extensions on a development site before
installing on a production site. Then test on the
production site. Do not forget to check the logs for
runtime errors and warnings.

Remove junk files: Remove all unused extensions
and double check that related folders and files were
actually removed by uninstall scripts. Note that
during uninstall, many third party extensions will
leave related files on the site, and related database
tables complete with data. This is either a feature or
a bug depending on the point of view. Any files left
on the server remain accessible from the Web via
direct URLs.

Avoid encrypted code: Joomla is (and despite
disinformation campaigns, always has been) a GNU
GPL project. This means that all extensions to
Joomla must also be free (as in freedom) and open
(as in readable code). Encrypted code may be safe,
but one cannot determine this for himself, and so he
must trust the developers. Using others' encrypted
code puts him back in the world of proprietary
software where he must wait for security patches
from the developer, hoping that attackers do not
find the site first before a fix is released.

Some people are often not free to modify, improve,
or share encrypted code. These restrictions make
encrypted code less valuable to the community as a
whole, and reduce the overall viability of the
Joomla project which depends on open sharing
among all participants.

Of course, code that is not distributed to others is
exempt from GNU GPL distribution requirements.
Thus one can encrypt Joomla-related code on his
own servers, providing he does not share it with

Avoid shared servers if possible: For maximum
security, avoid a shared server on which one does
not know or cannot trust all the other users or their
code quality.

Use an SSL server: This has more to do with secure
payments and administration, and is not Joomla
core or server security, but has been included here
for advisory purposes.

SSL servers are currently the only way to securely
process confidential transactions and secure user
authentication. SSL works by encrypting all HTTP
communications between the Web server and Web
clients. Thus, even if a transmission is intercepted,
it cannot be read.
Joomla 1.0.x does not allow some one to assign an
SSL server to individual sub-directories.

Use Apache's .htaccess: For an additional layer of
password protection, one can use .htaccess to
password protect critical directories. This is usually
adequate for blocking the typical script kiddie, but
be aware that .htaccess password protection alone is
not a highly secure method. It MUST be combined
with an SSL server for maximum protection. An
National Conference on Communication and Information Security (NCCIS 2012)
Daffodil International University, Dhaka, Bangladesh, 31 March 2012.


SSL server is required for protecting the site from
more sophisticated attacks, such as packet sniffing.

Switch to Joomla 1.5 or newer: The most significant
upgrade in Joomla's history includes powerful
security and performance enhancements.
· Joomla 1.5 Overview
· Joomla Downloads

Add Joomla Security Announcements to the site:
The Joomla Security Team supports and RSS feed
that provides the latest Joomla security information.
The following explains how to add this feed to the

P. Site Administration
Use well-formed passwords: Change passwords
regularly and keep them unique. A strong password
has a random combination of letters, numbers, or
symbols. Avoid using single names or words found
in a dictionary. Never use the names of the relatives,
pets, etc. Search the forums for a script supplied by
Wizzie that automatically changes passwords. This
is a great tool for administrators or multiple sites.
There are numerous handy.

Follow a password levelling scheme: Most users
may not need more than three levels of passwords
and webmasters any more than five. Each level
must be completely unrelated to the others in terms
of which usernames and passwords are used.
Maintain a strong site backup process: Never rely
on others' backups. Take responsibility for the
backup procedures. Many ISPs state in their
contract that one cannot rely solely on their backups.

Monitor crack attempts: VPS and dedicated server
users can run TripWire or SAMHAIN. These
applications provide exhaustive file checking and
reporting functionality, and can be installed in a
stealthy manner to help protect them in the event of
a serious infiltration. (Note: Users of shared servers
cannot use this technique.)

Perform automated intrusion detection: Use an
Intrusion Prevention/Detection Systems to
block/alert on malicious HTTP requests.

Perform manual intrusion detection: Regularly
check raw logs for suspicious activity. Do not rely
on summaries and graphs.

Q. Site Recovery
If one believes his site was attacked, do not create
yet another oh-so-boring post in the Joomla forums
with the title, "Help! This tells us nothing of
importance. The vast majority of compromised sites
were not setup correctly or were using obsolete
versions of Joomla or third-party extensions. This is
what one needs to investigate.
If some body discover a real vulnerability,
publishing the information could put other Web
sites at risk.


A. Discussions
Ways of hacking websites are discussed thoroughly
in the paper. Also are presented recommendations
to stop these evil hacking activities. These kind of
hacking made tremendous threats and losses to
carry out online business of any kind and including
all kinds of financial and official transactions of
important government, non-government, military
and educational institutions. The authors also
discuss over the loopholes of websites, as unfolded
by The Joomla Security Team, through which
hackers disrupt and dismantle operation of websites
causing huge threat to financial, security and other
types of losses. If recommendations put here are
practiced, the it may provide to stop hacking of
websites and stop those immense losses in websites..

B. Conclusion
Hacking websites posed a great threat to the
security of the websites. Ways should be found out
and necessary cross-border cyber laws should be
framed and enacted globally to combat this crime to
carry out e-Commerce, e-Governance and other e
activities safely in the Internet.


1. http://www.acunetix.com/blog/
2. http://www.cenzic.com/downloads/Cenzic_AppSecTrends_
3. http://en.wikipedia.org
4. http://docs.joomla.org/Security_Checklist_1_-