futtta's blog

Ever since I installed WordPress on my (virtual) server, I’ve been using the WP Contact Form plugin to provide me with simple contact form. The plugin isn’t exactly under active development (Last Updated: 2009-8-28), but it got the job done and I was quite happy with it. Until spammers found the page and started abusing it, that is. There’s a bunch of other Contactform-plugins in the wordpress.org plugins repository, but most of them were either too feature-packed or development for them seemed to have stopped.

I considered adding ReCaptcha at first, but why would I want to put my visitors through such an ordeal; the captcha’s seem to have gotten very difficult to decipher.  Next possibility; implement Akismet (Mollom would have been a great choice as well)? There’s a great Akismet PHP5-class, you just provide your API-key and off you go. But it seemed kind of inefficient to have to do all that with the official Akismet-plugin already in place?

But wait a minute, why not just piggyback on the Akismet-plugin, as the Clean-contact plugin and wp-contactform-akismet did? Keep it simple stupid and so I just copy/pasted the clean_contact_akismet-function from Clean Contact’s code into my wp-content/plugins/wp-contact-form/wp-contactform.php and on line 142 I changed:

mail($recipient, $subject, $fullmsg, $headers);
$results = '<div style="font-weight: bold;">' . $success_msg . '</div>';
echo $results;

into:

$akismet=clean_contact_akismet($msg,$subject,$email,$name);
if (!$akismet) {
mail($recipient, $subject, $fullmsg, $headers);
$results = $success_msg;
} else {
$results = 'If it looks like spam and smells like spam, it must be spam. Leave (or rephrase)!';
}
echo '<div style="font-weight: bold;">'.$results.'</div>';

That was all it took to add Akismet spam-filtering to that KISS-y wp-contact-form plugin. I wonder why this isn’t in the plugin already?

I’ve been experimenting with the PHP OAuth PECL extension over the last few days and initially ran into some small problems getting it to function correctly. So for the sake of making this world wide web an even better place, here are some error-messages you might encounter and what you could do to resolve them:

• “OAuth::getRequestToken() URL file-access is disabled in the server configuration” → the OAuth extension by default uses fopen (streams) to fetch data from the OAuth provider (server), but you’re probably slightly paranoid (or is it security- conscious?) and have allow_url_fopen = 0 in you php.ini. Just change that value to “1″ and reload your webserver and then see …
• “SSL: fatal protocol error“ → OAuth seems to be working fine, but for reasons unknown OAuth insists something fatal just happened. You could ignore this one, or try to lower the error-reporting value or do as I did and decide to use OAuth::setRequestEngine to switch from those doomed streams to almighty Curl, until …
• “setRequestEngine expects parameter to be long, string given” → so you installed (compiled) the OAuth-extension, but you didn’t have that libcurl-dev package installed, did you? No matter how polite you request that Curl-engine, it is just not going to happen unless you install libcurl-dev, and then re-installed OAuth.

And after successfully re-installing OAuth, this time with Curl-support, you could try to build a small application, accessing GMail maybe?

I just received confirmation from the Google Security Team that the bug I discovered in the iGoogle Facebook Gadget which allowed attackers to log into an other user’s Facebook account bypassing all authentication, has been fixed. So now that the hole has been closed, let’s look at what was happening, shall we?

The gadget uses the Facebook’s Javascript API to the connect with Facebook, asking you for permission to access your FB data. In the process of getting that authorization, the gadget exchanges tokens with Facebook, some of which should absolutely be kept safe from prying eyes. And that’s where things went wrong: the gadget had the authentication info in the URL. So if a user of the iGoogle Facebook gadget clicked a link to an external site in the news feed, the request for that page had a referrer that contained all authentication-info.

And that’s exactly what happened on last week, when I spotted this referrer in my blog stats:

http://facebookiggadget.appspot.com/?exp_rpc_js=1&exp_track_js=1&st=c%3Dig%26e%3DAPu7icpJzJJhOouS8TuGegSqFHHI8XHU1r55OllrNbk0ey/aTpkUFx9jPKB/cwgcEZoGfcBuc43x/CuzuEL2cQinYglFvhFWKtlXg6j/JtKC0%252BWsAu3vo/3ZR/WA64J/Fmw1YuUFgT7q&v=fdb2b406636e1f3cff1c5d7e660f59eb&container=ig&view=home&lang=nl&country=BE&up_session=%7B%22uid%22:%221165373488%22, %22session_key%22:%2291d52d2ed5a130fd941b11f1-1175373488%22, %22secret%22:%22fdee68961b3cdee5b51390a4bdeac7a0%22,%22expires%22:0, %22access_token%22:%2283101558C90fd9KfA9KJQh5uT98TqIjxQpzUi4.%22,
%22sig%22:%22dd635ef67af1f59c1c671215076cce10%22%7D&parent=http://google.be&libs=7ndonz73vUA/lib/liberror_tracker.js,iHKb-4mKuMY/lib/librpc.js,vrFMICQBNJo/lib/libcore.js,a5j4V1JuNVE/lib/libsetprefs.js&is_signedin=1&synd=ig&view=home

You can guess what happened when I opened that URL; the iGoogle Facebook gadget initialized using the embedded credentials, automatically logging me in as the guy that was unlucky enough to have clicked the link to my blog.

But how could this vulnerability have been exploited, you may ask? Well, easy enough; create a page that is viral enough for people to share or like  (likespam or even likejacking) and wait for users of the iGoolge Facebook-gadget (there’s over 1 million of them after all) to follow the links, feeding your webserver logfiles with credential-rich referrers.

As Google confirmed this bug indeed has been fixed. The new version of the gadget, which was deployed late last week, does not leak credentials in the referrer-URL any more:

http://facebookiggadget.appspot.com/?lang=en&country=us&.lang=en&.country=us&synd=ig&mid=101&ifpctok=6472409229927695377&exp_rpc_js=1&exp_track_js=1&exp_ids=17259&parent=http://www.google.com&libs=7ndonz73vUA/lib/liberror_tracker.js,iHKb-4mKuMY/lib/librpc.js,vrFMICQBNJo/lib/libcore.js,a5j4V1JuNVE/lib/libsetprefs.js

So if anyone asks me what my good deed for this year was; I helped protect 1 million people’s Facebook accounts from being hacked.

Sounds swell, no?

I by chance discovered a severe security vulnerability in iGoogle’s Facebook-gadget (more than 1 million users!), which allows an attacker to log into an other user’s Facebook account, bypassing authentication.

I contacted the author and the Google security team and they confirmed there appears to be a problem which they’ll look into. While they do so, I would strongly advise everyone not to use the iGoogle Facebook gadget. Once the hole is closed, I’ll provide more info on how this could be exploited.

I like Facebook. I like sharing stuff there, I like liking friends’ activities and I like friends sharing and liking my links and posts. But I really, really don’t like Facebook’s Like buttons and similar boxes! Because I see some serious problems with the like button;

1. The page containing the “like”-widget loads and renders significantly slower (i.e. performance impact)
2. Facebook can track me visiting this page, even if I don’t click on “Like” (i.e. privacy issue)
3. When I do click “Like”, I have no way of checking what will be shown on Facebook. And indeed the buttons are already being used to spread spam, malware is expected to be next (i.e. security risk)
4. “Liking” a page enters me into a relationship with the page owner, allowing them to “publish updates to the user [and] target ads to people who like [their] content” (i.e. 2nd privacy issue, severely aggravated by the security risk)

No, call me old-fashioned, but I’m much more at ease with the normal Facebook share-mechanism;

• a simple link, so no performance impact
• no contact with Facebook unless clicked on, so tracking of my surfing behavior is not possible
• an intermediate screen shows what you’re about to share, meaning a much lower security risk
• no forced relationship with the  page owner, i.e. “avert 2nd privacy-risk: CHECK”

But as I can’t force site-owners to remove the “Social Widgets”, I can only install something like No FB Tracking to disable the virus that is the Facebook Like-button. And whine about it on my blog, off course.

When I proposed the lead developer of an open source web application to enable JSONP for the API, the developer replied:

The whole thing sounds easy enough to implement, but I have some doubts that it will open the project to XSS attack of some sort. Don’t really know why, though.

We mailed a bit more about the risks of cross site scripting and then he wrote the following:

Sadly we can have malicious JS problems since cleaning up of incoming data is optional.

For an unrelated project I asked about authentication for a write-operation in the API and the reply was:

Authentication is not in the API yet. Currently you must include a session cookie along with API requests to perform a write, but the cookie itself is the one you get from logging in [in the web front end] as you would normally.

Which sounds a lot like “we support cross site request forgery out of the box” …

As with normal web applications, web API-security is an important (but complex) issue, which is not always easy to grasp. Based on a basic understanding of things, the following guidelines can go a long way into securing things both on the API-side and the client:

1. Know who you’re dealing with; disable API-access for your users by default (allowing them to opt-in), provide bullet-proof authentication and session management in the API and throw in a synchronizer token to prevent cross site request forgery
2. Never trust input from users or external systems; decide what to trust and filter out everything that’s not in that white-list (SQL-code, server-side code, javascript, and even html and css)

If you apply these basic principles to JSONP (make sure to filter the callback-parameter and set the correct content-type in your response) you’ll have a whole lot less to worry about!

More info:

• Owasp top 10 Application Security Risks 2010 (released on April 19th)
• Owasp Ajax security guidelines
• HTML Purifier: HTML filter library written in PHP.
• The risk of XSS and CSRF with JSONP (auto-translated from Swedish)

Microsoft IE8 introduced it, Apple Safari4 has it, Google Chrome4 does it and now somewhere in the not too distant future, Firefox will ship it too; support for X-FRAME-OPTIONS.

X-cuse-me? Well, X-FRAME-OPTIONS is the HTTP response header that broke Google Talk chat badge a few months ago, remember? It allows you to specify whether your site or page can be (i)framed or not, by setting it to “DENY” (not allowed to be framed) or “SAMEORIGIN” (allowed if the framing site is on the exact same domain). The most important reason for this functionality is as a prevention-mechanism for “clickjacking” (a.k.a. UI redressing), a type of web attack that tries to trick victims into clicking a framed site by hiding it behind another innocent element.

So now that feature is finally coming to Firefox as well; Mozilla’s Brendan Sterne, one of the driving forces behind Mozilla’s much broader content security policy, grabbed the bug by the balls and came up with a first patch. If all goes well, this would be an ideal candidate to get pushed out with a minor version update as per the new release process, no?