Sharing methods to prevent website attacks through semantic URLs in PHP_PHP Tutorial

What is a semantic URL attack?

Curiosity is the main 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://example.org/private.php?user=chris, it is natural that he may try to change user's value and see what happens. For example, he might visit http://example.org/private.php?user=rasmus 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 are caused by oversights rather than particularly complicated reasons. Although many experienced programmers readily recognize 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, take a Webmail system as an example. The main function of this system is for users to log in to 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 when registering, so users who answer the question correctly will be prompted to provide an email address (while a new password is sent to this email address, backup passwords may also be collected email address information). The following form is used to ask for a new email address, and his account name is stored in a hidden field of the form:

Copy code The code is as follows:

Please specify the email address where you want your new password sent:

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 he is the legal owner of the chris account. If he provides chris@example.org as an alternative email address, after submission he will be directed to the following URL:

http://example.org/reset.php?user=chris&email=chris%40example. org

The URL appears in the browser bar, so any user who has reached this step can easily see the role of the user and mail variables. After realizing this, the user thought that php@example.org was a very cool address, so he would visit the following link 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 chris successfully steals the php account.

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

Copy the code The code is as follows:

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 more detailed email information or a reasonable password), it demonstrates the distrust of the account provided by the user, and more importantly, the use of session variables to save the user is correct. The question was answered ($_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.

Actually, just remember the following principles!

Don’t trust any user input (that is, detecting user input. Although it is more troublesome to write, it is better than solving the problem in time!)

http://www.bkjia.com/PHPjc/324280.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/324280.htmlTechArticleWhat is a 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 order to discover some...