[转载]Web Server Security Themes
信息来源：[url]http://www.greeknetizen.net/[/url]**PREFACE
Today anyone can decide on a free web hosting service in order to make up
a website or just upload a backuped file collection (archive) for security
reasons or anything. However, nearly all webmasters do not take care on
the security and "design" of their systems, and this fact appeals a broad
majority of the bad hackers community. The reasons can be just fun, although
an attack can cause such confusion to the admins that they will lose their
head. Since you can know numerous holes and vulnerabilities you could exploit
at any time, you could cheat sensitive information by invoking a script (in
any scripting language that the server is compatible: PHP, Perl, Shell Script,
etc).
We will focus first on directories, relational databases, and so on. Not only what
I refer applies in Unix operating systems, but also servers that run Windows.
All these kinds of attacks I am going to refer to below are a result of the
administrators' laziness, and inapropriate organisation of their systems.
**SEGMENT 1 - BASIC
Some administrators and/or webmasters who would like to attract many visitors to
their websites rush into providing them with the so-called free webhosting, and
of course a URL (subdomain or subfolder). However, as we know there is such
antagonism out there between those stupid admins and/or webmasters, that they
offer even "better" services, such (!)as a scripting language(!).
A scripting language that anyone provides to an unknown user, who can have
malicious intentions, can be a miracle for the system adiministrator.
MISTAKE 1: some administrators do not protect their own directories (I mean the
directories of their main webiste with an .htaccess file so that noone can access
them). For example, if someone provided users with PHP and they did not protect
ther directories (not only the websites but also /usr/bin/ and /bin/musql and so
on - sensitive but most of all vital directories). For example, if PHP was provided
anyone could create a file, say "dirs.php" chmod it to 755, open it up, and type
the following code:
PHP CODE:
<?php
/* Show all directories by hiting values in the query string
say [url]http://www.yourhoster.xx/youraccount/dir.php?dir=..[/url]
*/
error_reporting(E_PARSE);
if($dir) {
$fd = opendir($dir);
if(!$fd) {
print "Sorry, <b>$dir</b> cannot be opened at the moment.\n";
exit;
} else {
while($fileordir = $fd->read()) {
if(is_dir($fileordir)) {
print "Dir: ".$fileordir."<br>";
} elseif(is_file($fileordir)) {
print "File: ".$fileordir."<br>";
} else {
print "Not A file or directory: ".$fileordir;
}
}
print "<br>";
$killproc = closedir($fd);
//die of errors
if(!$killproc) { die("Cannot close the directory".$dir); }
}
}
?>
With this piece of code, someone could learn about the organisation of the website they
want to attack. But this is nothing! Someone, being aware that he can run PHP in their dirs
he could simply, gain access in the websites files, say "index.php" - the frontpage of a website.
Let us assume that the full path is /public_html/index.php.
The following piece of PHP code can read the contents of a file and many ...mmmm useful things
...like the PHP code of the pages ...and many secret things.
CODE:
<?php
/* Print out the contents of the file located at /public_html/index.php */
error_reporting(E_PARSE); // we do not want exceptions throwing here
function dieandtryagain() {
print "The file cannot be opened! Maybe";
print " its permissions are incorrext for you. Let's try and fix them!";
//try to switch the file perms to 777
$t = chmod($pathToFile,777);
//exceptions
if(!$t) {
die("The permissions on the file cannot be cahnged! Try on another file.");
}
}
$pathToFile = "/public_html/index.php";
$fp = @fopen($pathToFile) or dieandtryagain($pathToFile);
print "<textarea style=\"width:100%;height:400\">";
while($line = @fgets($fp, 1024)) {
print $line."<br>";
}
print "</textarea>";
@fclose($fp) or die("Cannot close file!");
?>
**SEGMENT 2 - DATABASE PROTECTION
If this PHP script (whic prints out the contents of a file) workd, I mean if the output to your browser
is the contents of the file, then ...yes man... you know can apply this step to other files you know
and get the code... Then sometimes, the developers of such sites make connections to mySQL or other relational
databases in order to get or send information to the SQL server. This is just a plus for you,
as this happens, you can get: a) The server location; b) The username of the database;
c) The ...yeah ...password of the database. You will be surprised to see that in many occassions
there is no password for a database used!
Now anyone could connect to this database, say from a unix shell or directly from their account
on the website, and at least get the contents of the database. For example, anyone could at least
connect to the SQL server from their Unix Shell and run a "SHOW TABLES" command, and get all the
tables in the database. Note that it is likely that the permissions for the user of the database
can have a limited number of actions allowed. Moreover, I mean that a user e.g. "search_get" to a
database named consequently "search" may only grand SELECT on the database, and provoke any other
commands, such as DROP, ALTER and so on. If you are lucky, the user to the database could have
all permissions granted! Then you could do anything with it: dump it(yeah), drop it (do not do that),
add keys(useless), alter keys, and many more.
I will not write a sample PHP script here that connects to SQL servers and runs commands on it; I
assume you already know how to do this thing.
DANGER: The step I mentioned above can be very harmful! Let us take an example. Assume we have
a website that not only does it provide free web hosting to visitors, but also has an e-shop
where visitors register, giving their creadit card number. If so, if there was, for example, some
page on the website, eg login.* and after submitting the username and password, the form action is
set to another page (say res.*) or on the same page, then there is surely some script that
invokes a database. SO: Being aware you can gain access in such files of the parent directory
of the /public_html/ file which is configured to contain files for HTTP, you can connect
to the database that the script calls (after you have opened the page that contains it), and
steal ...yeah all the creadit card numbers. This is a very usual kind of threat, that some old
hackers rushed into. Anyone, could dump that database and threaten the webmaste of the website
to sell the credit card numbers, unless they pay him/her a great amount of money. You could
dump a mysql database from your shell using the dump function, or just from the account they offer
you with a PHP script, running an exec() command.
NOTE THAT: It is very common that some webmasters or developers forget to change the default passwords
for their MySQL database, so anyone could connect to that database, and that could lead to
confrontation! Not that noone would want to dump the contents of a credit card database, but
such an action could put the responsible people in prison, after you or anyone else ...dumps the
money out of the creadit card account.
TO ADMINISTRATORS AND WEB DEVELOPERS
You know that not only does the webmaster takes responsibility
on the security of your users's sensitive information, but also the lazy web developers who
do not organize and secure their contents, in order to avoid any hacking attack.
Do not rush into making money! Just spend a few months beta testing you site, in order to
shield any attack (mysql injection, PHP script hole exploiting and many more).
**SEGMENT 3 - RESULTS OF ANY ATTACK
An attack like the abovementioned could lead to many bad results. Firstly, you could loose many
visitors/clients, after they get aware that the website they are visiting is insecure ...and most
of all that their credit card numbers and/or other sensitive information is on somebody's
hands. Secondly, your traffic will slump to a number that you have never thought of. Thirdly,
your website will become the hackers' exploring place on the net, as they would normally
try to find more holes on your system/scripts and exploit. You wouldn't like that! Thirdly,
consider the responsibilities you have on your clients's information! You certainly would
not like to play chicken with the law - or rather - you would not like to be thrown into prison!
All the consequences I refer here may be nothing - you may face even stricter punishments.
**SEGMENT 4 - A SAMPLE ORGANIZATION OF A NETWORK
I assume that you own two servers that are connected toghether by a linker. A very common
connection between two servers.
/------------------------CONNECTION------------------------\
.________. _________________ ---------- ___________________ .__________.
| S | |________| | S |
| E | ^ | E |
___| R | | | R |
| | V | terminal/linker | V | <-- IP 2
| | E | | E | THIS SERVER
| | R | <- connection between to servers is gained -> | R | CONTAINS THE
| | 1 | <- only by server proccesses -> | 2 | USER SITES
^ .________. .__________. --------------
^ \_______________________________________________________/ | THE GUI OF THE
| ^ | | CPANEL MUST BE
| \ here you store your main website, *H* |ISP| ON SERVER 1
| say an e-shop and on the other *T* | --------------
| machine (SERVER 2) your free *T* | FILE TRANSFERING
| web hosting system. *P* ^ IS GAINED THROUGH
| Different from the | ^ LINKER PROCCESS
| SERVER 2. Connection is gained through | | ---------------
| a terminal. | | SEE MPORE DETAILS>>
| | |
| o----------o |
O------>>--------SEND/GET DATA-------<<---|ISP|-----------|USER'S PC |------+
connection between | | WEB | |
user (PC) and | | | |
webserver1 | o----------o |
O------CONNECTION-------O
The SERVER 1 must contain all files of the main website and the GUI interface for
the administration tools fot the users website. All the domains may be binded to
SERVER 1. TRANSFERING FILES is gained by the linker. In SERVER 1 FTP connection
is prohibited for every user. The user subdomains, for example, [url]http://mysite.example.com/[/url]
must be binded to SERVER 2. FTP ACCESS is allowed only to registered users.
**SEGMENT 5 - TRAPPING ALL HOLES
If you allow your users to store their files one your main server (bad choice of yours), then you a lot
of holes open up. Not that there are no holes in the server itself, but a lot of other problems utter.
Of course, you always create webpages -- e.g. in PHP, ASP, CFML, JSP -- to provide dynamic content.
However creating a base folder for your users to store files means that they can run their own scripts,
anything that the administrators can normally run. So, you must create a .htaccess file. There you must
define the following: a) you must prohibit users from gainning access to your restricted files; b) prohibit
users from running PHP, ASP, Perl, etc. scripts on their account; c) If your server runs SSI or has Frontpage
extensions installed, you must revoke access to them for your users. With SSI (and also all the other scripting
languages) a malicious user can include any file, you would not like them to. If you leave SSI open, then
someone could write in a *.shtml? file: <#--include virtual="../index.php" -->. (We assume that with ../ you
get to the base folder /public_html/). Then because the file has the *.shtm extension the PHP or any other code
does not execute, so it is included in the Page Source. Anyone could open up the source code and do the same
on other files. Then they could learn more about on the organization of your website as on other things,
and this will mean trouble. They could meat the chance to find all possible holes and exploit them to harm you.
Also, you will have to configure your system not to accept socket connections from unknown sources. Take a
look at all your open ports that anybody could connect to, and run commands, and finally cause damage to your
site.
Next, thing of any possible attacks that somebody could do to you, from form-hijacking to more complex ones.
You already know that you cannot stop somebody from hitting different values from a query string. Do not make
the mistake of printing user input on a page from a query string. If, for example, you have a contact page, and then
when you press the submit or next>> button the PHP script outputs the user input, anyone could change the referer
and in the query string write, for example <?php include("/etc/passwd"); ?>, and get a copy of your password file.
Anyone could even include a PHP, ASP or other page. Or they could get a list of the files in a directory, anything
we discussed obove.
**SEGMENT 6 - Running Commands
If you allow someone to have access on some place at your server, you cannot stop him from running commands
on it. And you cannot stop him from running harmful commands for your webserver. You can control what commands
anyone runs after thay are connected to your server. Fisrt, you can always take a look at your log files.
You should write some PHP, or Perl script for manipulating your logfile. And always take a look on it.
An you can configure your system to run selected commands at a time, for granted users.
**SEGMENT 7 - File inclusion and error reporting
If your website is based on only one pages (for example: index.php, default.aspx, etc) then will also be
based on query strings. Generally speaking, if your site provides a web form for your users, and your site
URL is [url]http://wwww.xxxxxxx.xx/[/url], suppose you have the query string URL+?page=Contact. You hit the query string
after the base URL, and the web form appears on your browser. Try replacing a standard value with XODLLLDOOSOS.
If the developer has switched the error reporting of the parser in PHP or other language in, say "Warning",
and you enter an invalid value -- say XODLLLDOOSOS -- you get a Warning which informs you that inclusion for
XODLLLDOOSOS.* (where * is the extension of the file to be included) cannot happen.
Such a message appears when the coder of the programme does not take control of the exceptions that the
programme can throw.
For example, a basic script that carries out file inclusion for an index.php page is the following:
<?php
/*
Say the variable in the query string has a variable page and a number of values that
can be applied to include several pages.
*/
if(!$page) {
$page = "indexpage.php"
} else {
include($page."php");
}
?>
If you run this script on your webserver and you hit XMMDMDMDMD as a value, an exception will be thrown
or a warning message. However, if you put "error_reporting(E_PARSE);" in the first line of your script,
you will only get parsing errors. And in our occassion, we will never get a parse error, as long as
the script has no syntax errors.
And if you would like, you could throw your own exceptions. For example, you could transform this script
to:
<?php
/*
Say the variable in the query string has a variable page and a number of values that
can be applied to include several pages.
*/
if(!$page) {
$page = "indexpage.php"
} else {
$inc = include($page."php");
//
if(!$inc) { print "Page Not Found"; exit; } // CHECKLINE
// Or you could replace CHECKLINE with
// if(!$inc) { header("Status: 404 Not Found"); }
}
?>
Note that, all the included files should hve the extension .php, even these PHP files which have no PHP
code included. If you include a file with a .htm or .html or any other extension which is not configured
on your server and include it, it is very dangerous. And I SAY it is dangerous, because I can prove this
to you, (assuming you have not already set error_reporting to E_PARSE).
The trick proccess is: You visit the site and as a value to the include-page variable you set a value
which is not valid, for example XMDMDMDFKFFOFOF, which is likely not to be recognized by the script.
Then you get a )Warning Message( that tells you you cannot include XMDMDMDFKFFOFOF.* (where * is the
extension of the file to be included). Suppose all inclusion files have .htm extensiom and include PHP
code. With the warning message you can hit the exact URL to the hypothetically HTML page, and read the
PHP code. So, take the chance and configure your own script to include files with extension .php.
And, finally, this is the appropriate solution to this problem, because as you know when you hit PHP page
that actually includes PHP code, the any PHP code is executed anyway!
页:
[1]