Drupal 7 Module Development

Security
Always assume that incoming data is insecure until and
unless it's been processed to ensure that it is safe.
Most security vulnerabilities come from not properly checking whether a piece of
data is what we expect it to be. Remember also that there are many of types of input.
• Any information coming from the user, either in the GET query or a POST
request, is input and may be insecure.
• Any cookies the user sends are input, and may be faked.
• Any files read from disk are input, which may contain data we do not
expect. Even if not malicious, unexpected data formats can pose a serious
security risk.
• Any data stored in a database that we didn't write to may be insecure.
• Even data stored in Drupal's own database may be insecure, unless we know
for certain that we cleaned it before saving it.
Data does not have to be malicious in order to be a
security threat.
Also remember that our website may not be the target of an attack. A very common
tactic is to post comments on a website that contains JavaScript that, when viewed,
will take over a user's web browser or trick them into visiting another site that will
download malicious code to their computer. Although our site is not harmed, it is
still used as a way to attack another user. We don't want that.
Filtering versus escaping
There are two ways of dealing with potentially insecure data, namely, filtering
and escaping.
Filtering involves stripping out portions of the data that could be trouble, or forcing
the data into a simpler, safer form. Common practice in PHP is to filter all input into
the system unequivocally. Drupal takes a slightly different tactic, as for certain pieces
of content, such as a node body, we may not know the proper format in advance. If
a user changes a text format setting, for instance, we don't want the user's previous
text to be lost, just filtered differently. Instead, we filter it on output.
[ 376 ]