PHP Security - Semantic URL Attack

Semantic URL Attack

Curiosity is a primary motivation for many attackers, and semantic URL attacks are a good example. This type of attack mainly involves editing the URL in the hope of discovering something interesting. For example, if user chris clicks on a link in your software and reaches the page http://www.php.cn/, Naturally he might try to change the value of user and see what happens. For example, he might visit http://www.php.cn/ to see if he can see other people's information. Although the manipulation of GET data is only slightly more convenient than that of POST data, its exposure determines that it is more frequently attacked, especially for novice attackers.

Most vulnerabilities occur due to oversights rather than particularly complex causes. Although many experienced programmers are easily aware of the dangers of trusting URLs described above, they often don't realize it until someone else points it out to them.

To better demonstrate how semantic URL attacks and vulnerabilities can be overlooked, consider a Webmail system whose main function is for users to log in and view their own emails. Any system based on user login requires a password retrieval mechanism. The usual approach is to ask a question that the attacker is unlikely to know (such as the brand of your computer, etc., but it would be better if the user can specify the question and answer themselves). If the question is answered correctly, a new password is sent to the registration. Specified email address.

For a Webmail system, an email address may not be specified during registration, so users who answer the question correctly will be prompted to provide an email address (alternative email address information may also be collected while a new password is sent to that email address). The following form asks for a new email address, and its account name is stored 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 where
you want your new password sent:</p>
  <input type="text" name="email" /><br
/>
  <input type="submit" value="Send Password"
/>
  </form>

It can be seen that the receiving script reset.php will get all the information, including which account's password is reset, and which email address the new password will be sent to.

If a user can see the form above (after answering the correct questions), you have reason to assume that they are the legal owner of the chris account. If he provided chris@example.org as an alternate email address, after submission he would be directed to the following URL:

CODE:

http://www.php.cn/

The URL appears in the browser bar, so anyone who has made it this far can easily see what the user and mail variables do. After realizing this, the user thought that php@example.org was a very cool address, so he visited the following link to try:

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 Chris successfully steals the php account.

If you use session tracking, you can easily avoid the above situation:

CODE:

 <?php
 
  session_start();
 
  $clean = array();
  $email_pattern =
&#39;/^[^@\s<&>]+@([-a-z0-9]+\.)+[a-z]{2,}$/i&#39;;
 
  if (preg_match($email_pattern,
$_POST[&#39;email&#39;]))
  {
    $clean[&#39;email&#39;] = $_POST[&#39;email&#39;];
    $user = $_SESSION[&#39;user&#39;];
    $new_password = md5(uniqid(rand(), TRUE));
 
    if ($_SESSION[&#39;verified&#39;])
    {
      /* Update Password */
 
      mail($clean[&#39;email&#39;], &#39;Your New Password&#39;,
$new_password);
    }
  }
 
  ?>

Although the above example omits some details (such as more detailed email information or a reasonable password), it demonstrates the distrust of the account provided by the user, and more importantly uses the session variable to save whether the user answered the question correctly. ($_SESSION['verified']), and the user who answered the question correctly ($_SESSION['user']). It is this distrust that is key to preventing vulnerabilities in your application.

This example is not completely fictitious. It was discovered by Microsoft in May 2003 Inspired by Passport's vulnerability. Please visit http://www.php.cn/ See specific examples, discussions, and other information.

The above is the content of PHP security-semantic URL attack. For more related content, please pay attention to the PHP Chinese website (www.php.cn)!