Website Security (20)--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.
-
What is a 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.2cto.com/private.php?user=chris, 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.2cto.com/private.php?user=rasmus 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 ofLoopholesis 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:
Copy the code code as follows:
<input type= "hidden" name= "user" value= "Chris"/>
<p>please Specify the email address where you want your new password sent:
 
<input type= "text" name= "email"/>
 
<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 an alternate email address, he will enter the following URL after submission:
 
http://www.2cto.com/reset.php?user=chris&email=chris%40www.2cto.com
 
the URL appears in theBrowsercolumn, so any user who makes this step can easily see the role of users and mail variables. When the meaning comes to this point, the user thinks of a very cool address, so he accesses the following link to try it out:
 
http://www.2cto.com/reset.php?user=php&email=chris%40www.2cto.com
 
If reset.php trusts the information provided by the user, this is a semantic URL attack vulnerability. In this case,Systemwill generate a new password for the PHP account and send it to, so Chris successfully stole the PHP account.
 
If you use session tracking, it is easy to avoid the occurrence of this situation:
Copy the code code as follows:
<?php
session_start ();
$clean = Array ();
$email _pattern = '/^[^@\s<&>][email protected] ([-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-supplied account is not trusted and, more importantly, uses the SESSION variable to answer the question if the user is correctly answered ($_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.
 
In fact, just remember the following principles--noto trust the input of any user