<script type="text/javascript">
while(1) {
        alert("DOS");
}
</script>

This simple attack, can be much more annoying then it looks, due to the popularity of tab enabled web-browsers such as Firefox and IE7.
In todays web-browsers, if a JavaScript alert pops-up the user must dismiss it before doing anything else. That includes things like switching tabs, closing the open tab, opening menus and etc. If you want to see how annoying this little code can be, just go to this page (warning: this will turn your browser unresponsive and will force you to kill it).

As you can see this small script will turn your web-browser completely unresponsive and thus force you to kill it. The first instinct will be restore the crashed session, but it won’t be possible, as it will reopen the page with the malicious code. So you will have to start your a new session and reopen each tab manually. This small script allowed a malicious user, to force you to crash your own web-browser, while loosing data (unsent email, blog post, or any kind of unsaved form data), without you having any option to prevent it.

When I say you don’t have any option to prevent it, I say because this code might be in a link a friend send you as a way to annoy you, or in a legitimate web-site which been a victim of JavaScript injection attack. Yes, you can completely protect your self from this by surfing with JavaScript turned off, but many modern website won’t work, turning this option useless (you would deny yourself any service from many AJAX enabled sites).

To solve this situation we need to take a look at what caused it. Let’s say the malicious site has been open in its own web-browser instance. In this case you would just kill this instance and continue browsing in the other open windows. But when you open several other sites in the same instance using tabs, you will have to close all of them. This happened because there isn’t enough separation between tabs. In this case a page loaded in one effects all other opened tabs.

In order to fix and prevent this kind of DOS attack, browser developers need to take a new approach of separation between tabs.

• In under no circumstances one tab should be able to effect other tabs’ status.
• Also tab shouldn’t be able to prevent the user from closing it or switching to another tab.
• JavaScript alerts shouldn’t be modal. They could be implemented in a way so they prevent any action within the tab until they are dismissed, but in no way they should be able to prevent actions in other tabs.

I’m no web-browser developer, but this shouldn’t be too hard to implement in order to fix such old, yet annoying problem, which becomes much more annoying in a tabbed web-browsing environment.

Now we two possible ways to add the tracking code to each external link. The first one is to hack the MediaWiki internal parser for wiki code to generate additional code for each link. While this way will probably work the best it’s pretty complicated and not straightforward. The other way, which is the one will follow, is to use a small JavaScript snippet which will will iterate through the links in every page and add an “onClick” attribute to them with the tracking code.

<script>
var links = document.getElementsByTagName("a");
 
for (var i = 0; i < links.length; i++) {
        if (links[i].className=="external text") {
                addtrackcode(links[i]);
        }
}
 
function addtrackcode(obj) {
        obj.setAttribute('onClick',"javascript:urchinTracker('/outgoing/"+ obj.href.split("://")[1]+"');");
}
</script>

This code snippet should go between you Google Analytics code and the </body> tag, meaning you can add it to /wiki/skins/monobook.php if you haven’t changed the default skin for your MediaWiki. After the code is in place it may take up to 48 hours (usually you don’t have to wait at all) for the external links statistics to show up in the Google Analytics. In the Google Analytics the statistics for clicking on an external link which leads to http://www.google.com will show up as view of the page /outgoing/www.google.com. This script will also track download statistics of files which are linked from the wiki pages (like pdf’’s and such).

While this code does the job, it has a drawbacks. It only tracks the external links created by wiki code (e.g. [http://example.com]) as it uses CSS classes to determine what is external link. However this drawback isn’t very important and overall the script does a decent job tracking the external links in MediaWiki using Google Analytics.