Linking to Content I and url

Drupal provides two convenience functions for linking to content. These are especially useful for dynamic links and moving sites from one server or domain to another: They internally will add the appropriate domain and any directories to the text to make sure that it works properly. The functions will check the path to see if it has been aliased using Drupal's Path system. And, by default, these functions also sanitize the user work to make sure that the pieces of the link and URL are safe for the user. This is just another case where using the function that works best for other reasons also provides protection for the developer.

In general, the proper way to use these functions is fairly simple. Here is an example of the l function from the Profile module:

$output = l($name, 'user/1. $object->uid, array('attributes' => array('title' => t('View user profile.1))));

In this example, the username as supplied by the user is passed directly to the l function. The l function is responsible for sanitizing that data. This example also shows the use of the $options array for the l function to set a title attribute for the username. The output of this function for my username on drupal.org is:

<a href="/user/3 67 62" title="View user profile.">greggles</a>

It is very difficult to show ways to improperly use l and uri functions. Instead, here are some examples of common mistakes that people make where they should have used the l or url function:

$form['vulnerable_markup'] = array(

lvalue1 => '<a href="'. $user_data2 .'">'. $user_data .'</a>',

This example is vulnerable in two ways:

■ The $user_data2 could close the href element and the anchor tag and then inject JavaScript.

The anchor text is not filtered in any way and could also contain JavaScript. The Vulnerable module contains data for $user_data and $user_data2, which exploit this weakness.

How bad is this? To start, someone could vastly alter the look of your site and hide the rest of the content on the page by starting an HTML comment or other HTML tag. A truly bad consequence, as you'll see in Chapter 9, is that if someone can inject XSS into your site, he can control your account. He could retrieve and submit any form on the site to change any setting he wants, including the administrator password or email.

$user_data = "<script>alert('xss')</script>";

$user_data2 = "\"><script>alert('xss')</script><a href=\"";

Fixing this code is quite easy:

$form['vulnerable_markup'] = array(

In fact, that change is so easy, and it demonstrates the point that when developers learn and use the API, they are not only safer but more effective and more efficient.

Was this article helpful?

0 0

Post a comment