How to Prevent website attacks through semantic URLs in PHP

What is a semantic URL attack?

Curiosity is the main motive of many attackers. semantic URL attacks are a good example. Such attacks mainly include editing URLs to find interesting things.

For example, if user chris clicks a link in your software and reaches the page http://example.org/private.php? User = chris. Naturally, he may try to change the user value to see what will happen. For example, could he access http://example.org/private.php? User = rasmus: check if he can see other people's information. Although the GET data is easier to manipulate than the POST data, its exposure makes it more vulnerable to attacks, especially for new users.

Most vulnerabilities are caused by omissions, rather than complicated ones. Although many experienced programmers can easily realize the danger brought by the above-mentioned trust in URLs, they often suddenly realize it only when someone else points out it.

To better demonstrate how semantic URL attacks and vulnerabilities are neglected, take a Webmail system as an example. The main function of this system is to log on to view their own emails.

Any system based on user logon requires a password retrieval mechanism. The common method is to ask a question that the attacker cannot know (such as the brand of your computer). If the user can specify the question and answer, the new password is sent to the email address specified at registration.

For a Webmail system, the email address may not be specified during registration. Therefore, the user who correctly answers the question will be prompted to provide an email address (while sending a new password to the email address, you can also collect the backup email address information ). The following form is used to query a new email address, and its account name is included in a hidden field of the form:Copy codeThe Code is 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>

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

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

Http://example.org/reset.php? User = chris & email = chris % 40example.org

This URL appears in the browser bar, so any user who performs this step can conveniently see the role of the user and mail variables. At this point, the user thought that php@example.org was a very cool address, so he would access the following link to try:

Http://example.org/reset.php? User = php & email = chris % 40example.org

If reset. php trusts the information provided by users, 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 the chris@example.org, so chris successfully steals the php account.

If session tracking is used, the above situation can be easily avoided:Copy codeThe Code is 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 some details (such as more detailed email information or a reasonable password) are omitted in the above example, it demonstrates that the Account Provided by the user is not trusted, at the same time, it is more important to use the session variable to save the user's correct answers ($ _ SESSION ['verified ']), and the user who correctly answers the question ($ _ SESSION ['user']). This type of untrusted approach is the key to preventing vulnerabilities in your applications.

In fact, you just need to remember the following principles!

Do not trust any user input (that is, to detect user input. Although it is difficult to write, it is always easier to solve the problem !)