What is semantic URL attack?
Curiosity is the main motivation for many attackers, and semantic URL attacks are a good example. This type of attack consists primarily of editing URLs to discover interesting things.
For example, if the user Chris clicks on a link in your software and reaches the page Http://example.org/private.php?user=chris, it's natural that he might try to change the user's value to see what happens. For example, he might visit the Http://example.org/private.php?user=rasmus to see if he could see other people's information. While manipulation of get data is only slightly more convenient than post data, its exposure determines that it is more frequently attacked, especially for novice attackers.
Most vulnerabilities are caused by omissions rather than by particularly complex causes. Although many experienced programmers are easily aware of the dangers of trusting the URLs described above, they often come to the point where they are pointed out.
To better demonstrate how semantic URL attacks and vulnerabilities can be overlooked, for example, a webmail system, the main function of the system is that users log in to see their own messages.
Any system that is based on user login requires a password-retrieving mechanism. The usual approach is to ask a problem that an attacker might not know (such as your computer's brand, but if you can give the user the ability to specify a problem and answer better), and if the answer is correct, send the new password to the email address specified at the time of registration.
For a webmail system, the e-mail address may not be specified at registration, so a user who answers the question correctly is prompted to provide an e-mail address (the alternate e-mail address information can also be collected when a new password is sent to the e-mail address). The following form is used to ask for a new e-mail address, and his account name exists in a hidden field in the form:
Copy 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 gets all the information, including which account password is reset, and which email address to send the new password to.
If a user can see the form above (after answering the correct question), you have reason to think that he is the rightful owner of the Chris account. If he provides chris@example.org as an alternate email address, after submitting he will go to the following URL:
http://example.org/reset.php?user=chris&email=chris%40example.org
The URL appears in the Explorer bar, so any user who is in this step can easily see the role of user and mail variables. When it came to this, the user thought that php@example.org was a cool address, so he would visit the link below to try:
http://example.org/reset.php?user=php&email=chris%40example.org
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 can successfully steal the PHP account.
If you use session tracking, you can easily avoid this scenario:
Copy Code code as follows:
<?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-supplied account is not trusted and, more importantly, uses the session variable to save the user from answering the question correctly ($_session[' verified '), And the user who answered the question correctly ($_session[' user '). It is this distrust that is the key to preventing your application from creating vulnerabilities.
In fact, just remember the following principles on the line!
Do not believe any user input (that is, the user's input to do testing, although, write more trouble, but always better than the problem in the solution to come in time!) ）
