When you steal money or goods, somebody will notice its gone.

When you steal information, most of the time no one will notice because the information is still in their possession. - Kevin Mitnick [The Art of Deception; Wiley Publishing, 2003). Putting in the timely stitches It is one of the worst-case scenarios when one fine morning you notice your site got (or getting) attacked. A broken security, of course, and usernames, passwords, emails (all three at times) in short, sensitive information get revealed to allow an outsider log in to your bank accounts and stuff and do all sort of crummy things like making your site relay spam or turning it into a malware den that infects thousand other visiting computers. All that teaches a lesson: Do not trust the code safety on another Drupal user. It is fact that large numbers of websites lack a secure conguration. Logical/programmatic vulnerabilities in contributed (or, customized) modules turn it worse. The problem is: It is a V-E-R-Y big task tracking down all vulnerabilities attackers might use. The list is enormousand growing, too. So, we will be covering the most essential and common (or, most important) vulnerabilities. The steps shall help protecting Drupal sites by reviewing and finding the weaknesses and thereby xing them up. Later, we shall also look into a few extra steps to put up some extra protection. Drupal vulnerabilities: 1. Insecure configurations: Drupal core is very secure by default, but vulnerabilities can open unknowingly if configuration is wrong. There are possibly as many best practices as there are users, but certain settings are common in a secured Drupal environment. So, you start with limiting access and rights of anonymous users, including account creation. This will stop spammers and Google link-jackers. Spammers target is creating accounts while the other type posts links to own sites from yours for a better search engine ranking.

Anonymous users create bogus accounts with automated programs (bots) and in a Drupal attackers create account freely since Drupal discriminates only between authenticated and unauthenticated users. An unauthenticated (or, anonymous) user creating an account shall effectively obtain privileges. Next, youll disallow any content from being posted anonymously. Stopgaps will keep bots finding your site, which means, no flooding with crap content. Flooding will make your site the host on which the others shall leech from. Creating content or uploading thus must get some check or verification.

Put a limit to uploads; also, on the file types. It is possible with Drupal to set file types to be allowed, so no uploading PHP code. They might execute on the server or could be executable malware, harmfully dynamic content etc. Disallowing upload of scripts and executables secures a site greatly.

Error reporting must be curbed. Drupal code results in errors sometimes and by default, Drupal logs it in its internal error log. The same also gets displayed on the screen, but this is required only in a development environment. Whats of use to programmers are completely useless to end users; moreover, the debugging messages contain critical configuration info that attackers may make good use of. This is information disclosure vulnerability.

2.

Cross Site Scripting: Or, XSS; here, codes execute inside the browser. The code can be JavaScript, Flash or something similar. XSS is done to use your session cookies and gain all the access you got. Visiting a page with a malicious XSS code running may result in new

content post, becoming friends with the other sites users, cast votes and most annoying changing your own administrative rights! Identifying XSS, mostly, is identifying JavaScript vulnerabilities; however, others are not to be ignored. The trick that does it is using a JavaScript alert box. Its hard to miss when it pops up, especially when the alarm is particular and specific to the place where code is injected. This is helpful for tracei. backs. You can do ii. "><img src="u.png" onerror="alert('blog-node-title');"</script> it with these two strings, posted into information and then browsing around your site. The "> helps finding if the code has an HTML attribute. This shall pop-up a JavaScript box, with a message coming from the title field of a blog node. Go to the pages HTML, find where the JavaScript leaked through and back trace to the code and add a suitable filter function. "><script>alert('blog-node-title');</script>

Drupal also allows configuration changes to fight XSS. To do that, you must not use the PHP input type. Drupal has three default formats (full HTML, filtered HTML and PHP) that users utilize when filling up web forms. Filtered HTML is by far, the safest and should be used whenever possible to strip out malicious HTML codes (e.g. javascript). This will ensure safety against XSS (cross-site scripting); also against CSRF (cross-site request forgery) attacks. While PHP input-type allows users write PHP directly into the existing content and allow the server to evaluate, it also lures attackers. In case theres a need, enable permissions till its crafted. In short, it must stay disabled when not in use.0

Cross Site Request Forgeries: The Drupal Form API puts up protection against CSRF. It uses special tokens (in the forms) that are updated constantly. A module using the Form API for all datamodifying requests and the Form API documentation properly followed; theres little chance for CSRF to create trouble. For good code, see the Forms API documentation. Menu callbacks, vulnerable to CSRF are

easily dealt with by adding confirm_form() (i.e. confirmation form) to each. Drupal does the rest.

Apart from disabling PHP input-type, you may use this trick and directly leverage token generation in Drupal. It involves adding a token; the added token will be returned with a request for the following action and validated before the action is taken. The token is added to the security_review_reviewed (i) function links and then checked in security_review_toggle_check (ii).

i. $token = drupal_get_token($check['reviewcheck']); $link_options = array( 'query' => array('token' => $token), 'attributes' => array('class' => 'sec-rev-dyn'), ); ii. if (!drupal_valid_token($_GET['token'], $check_name)) { return drupal_access_denied(); } A

Token special parameter

added to a request. It tells Drupal that it

generated a link for a specific user viewing the site. Tokens are added by Drupal to every form it generates and offers invisible to the

protection developers.

However, to deal with CSRF in Drupal contributed modules (e.g. a link like <img src="http:// website-name/yourmodule/shoes/123/delete" alt="naked girls pic" />), form confirmations along with form tokens are paramount (these ask Are you sure you want to delete this item?) for Drupal core and modules. So the bottom line is: It is intelligent to use token protection when generating links and forms manually. SQL Injection and the database API: Less trustworthy data (e.g. feeds, user inputs, some other database etc.), in a database query, must not be used directly. You stand a chance of being baked if you use something like: index.php?id=12 mysql_query("UPDATE mytable SET value = '". $value ."' WHERE id = ". $_GET['id']);

Or, say, when you combine two strings of data to form a single one (concatenating) that goes in directly into the SQL queries. For example,

<?php db_query('SELECT FROM {table} t WHERE t.name = '. $_GET['user']); ?> To counter SQL injection, use Drupal functions and pass the user input treating them as parameters. It goes like this: db_query("UPDATE {mytable} SET value = :valueWHERE id = :id", array( ':value' => $value, ':id' => $id); Also, using the database abstraction layer helps to ward-off the attacks; besides, with db_query it uses proper argument substitution. <?php db_query("SELECT foo FROM {table} t WHERE t.name = '%s' ", $_GET['user']); ?>

To accommodate arguments in variable numbers in SQL, creating a placeholders array helps. So, instead of: <?php db_query("SELECT t.s FROM {table} t WHERE t.field IN (%s)", $from_user); ?>

Its better to put:

<?php $placeholders = implode(',', array_fill(0, count($from_user), "%d"));

db_query("SELECT t.s FROM {table} t WHERE t.field IN ($placeholders)", $from_user); ?>

Using db_rewrite_sql() function call with SQL statements referring to nodes (or, {node}table) will stop violation of node access restrictions. It is an absolute requirement for the mechanism that makes Drupal accesses its nodes; any violation and it is outsiders gaining access to forbidden nodes. Its done this way: <?php $result = db_query(db_rewrite_sql("SELECT n.nid, n.title FROM {node} n")); ?>

Summary This was sort of a crash-course on the many kinds of vulnerabilities that drive Drupal users mad, but anyone who had been into the rough waters will know that we have covered the three most important issues, namely - XSS, CSRF and SQL injection, out of which, the first two can be easily dealt with if the recommendations on Drupal configuration is properly followed.