PHP security-semantic URL attack

Semantic URL attack

Curiosity is the main motive of many attackers, and semantic URL attacks are a good example. This type of attack mainly involves editing the URL to find something interesting. For example, if a user Chris clicked on a link in your software and reached the page http://www.php.cn/, it would be natural for him to try to change the user's value to see what would happen. For example, he might visit http://www.php.cn/to see if he can read other people's information. While manipulation of get data is only slightly more convenient than post data, its exposure determines its more frequent attacks, especially for novice attackers.

Most of the loopholes are caused by omissions, not particularly complex causes. While many experienced programmers can easily be aware of the dangers of the above-mentioned trust in URLs, they often come to the point of being pointed out.

To better demonstrate how semantic URL attacks and vulnerabilities are overlooked, take a webmail system as an example, the main function of the system is that users log in to view their own messages. Any system that is based on user login requires a password recovery mechanism. The usual approach is to ask a question that an attacker would not be able to know (such as your computer's brand, etc.), but if the problem is answered correctly, send the new password to the email address specified at the time of registration.

For a webmail system, the email address may not be specified at the time of registration, so the user who correctly answers the question will be prompted to provide an email address (you can also collect alternate email address information while sending a new password to the email address). The following form is used to ask for a new e-mail address, while his account name exists in a hidden field in the form:

CODE:

<form action= "reset.php" method= "GET" >  <input type= "hidden" name= "user" value= "Chris"/>  <p >please Specify the email address whereyou want your new password sent:</p> <input  type= "text" name= "email "/><br/>  <input type=" Submit "value=" Send Password "/>  </form>

As you can see, the receive script reset.php will get all the information, including resetting which account's password, and giving the email address to which to send the new password.

If a user can see the form above (after answering the correct question), you have reason to think that he is the legal owner of the Chris account. If he provides chris@example.org as an alternate email address, he will enter the following URL after submission:

CODE:

http://www.php.cn/

The URL appears in the Explorer bar, so any user who makes this step can easily see the role of the user and mail variables. When that was the point, the user thought that php@example.org was a very cool address, so he would visit the following link to try it out:

CODE:

http://www.php.cn/

If reset.php trusts the information provided by the user, this is a semantic URL attack vulnerability. In this case, the system will generate a new password for the PHP account and send it to chris@example.org so that Chris successfully steals the PHP account.

If you use session tracking, it is easy to avoid the occurrence of this situation:

CODE:

<?php   session_start ();   $clean = Array ();  $email _pattern = '/^[^@\s<&>]+@ ([-a-z0-9]+\.) +[a-z]{2,}$/i ';   if (Preg_match ($email _pattern,$_post[' email '))  {    $clean [' email '] = $_post[' email '];    $user = $_session[' user '];    $new _password = MD5 (Uniqid (rand (), TRUE));     if ($_session[' verified ')    } {/      * Update Password *       /Mail ($clean [' email '], ' Your New Password ', $new _ password);    }  }   ? >

Although the above example omits some details (such as a more detailed email message or a reasonable password), it demonstrates that the user-provided account is not trusted and, more importantly, the SESSION variable is used to save the user answering the question correctly ($_session[' verified '). And the user who answered the question correctly ($_session[' user '). It is this mistrust that is the key to preventing your application from creating vulnerabilities.

This instance is not entirely fictitious. It was the inspiration from the microsoftpassport loophole discovered in May 2003. Please visit http://www.php.cn/to see specific examples, discussions and other information.

The above is the PHP security-semantic URL attack content, more relevant content please pay attention to topic.alibabacloud.com (www.php.cn)!

