What’s Bitcoin good for, anyway?

​The idea of using Bitcoins instead of “normal” monetary currencies has been getting a lot of attention lately, and a lot of people seem to be wondering why anyone would want to use Bitcoin in the first place. This is, of course, a question worth pondering, but I think it has been sufficiently addressed. Entrepreneur and software engineer Marc Andreessen has persuasively argued in favor of Bitcoin, highlighting several advantages of Bitcoin over conventional currency. Consider for a moment that one of the characteristics that makes Bitcoin a completely revolutionary currency is that it can be divided into very small amounts. While a U.S. dollar can be divided into no more than one hundred parts – or up to 2 decimal places – a Bitcoin can be partitioned into a number with 8 decimal places. This is actually very exciting and opens up a whole new world of possibilities, and Marc Andreessen points out that the ability to send very small amounts of money (“micropayments”) can be harnessed for beneficial purposes. For instance, Bitcoins could be instrumental in filtering out spam: if posting a comment to a given site required the commenter to pay a very small fee in Bitcoins, then spammers would almost certainly be hesitant to post. Since the effectiveness of spam relies on the volume of spam, having to pay for spam content would basically defeat the whole purpose of spam. On the other hand, individuals who genuinely have something to say would not be affected all that much since the “Bitcoin fee” would be extremely small (say, thousandths of a penny).

Read more!

Escape unescaped

JavaScript has earned reputation of tricky and well, the most popular language nowadays. But in day-to-day programming life software engineers try to avoid any hacks, shortcuts and tricks. This make code simple, easy to maintain and even more reliable. Although there is a flip side of the coin – security, which requires more deep understanding of how the language and the browser works. The world have seen a lot of examples of XSS and other JavaScript-based attacks even on such reliable websites as Facebook, Facebook, Google, Google – just to list few recent attacks. Therefore when I came by this nifty JavaScript escaping challenge I immediately decided to test my skills.

Spoiler Alert: I’m going to walk through each challenge and explain my solution for it. So if you want to test your knowledge of JavaScript first – stop reading and come back only if you desparate.

If you reading this line, means that you either stuck somewhere in the middle of the quiz or just want to learn something new about JavaScript. Welcome.

Each challenge consists in a given JavaScript function which accepts single parameter – string. Your job is to write such a string, that will force the function to execute alert(1).

Challenge 0

function escape(s) {
  // Warmup.
  return '<script>console.log("'+s+'");</script>';
}

Solution

");alert(1)//

This is pretty straight-forward XSS injection. The resulting html will be

<script>console.log("");alert(1)//");</script>

which is completely different from what an author intended to do there.

Read more!

CSS-only: Load images on demand

The brain is a muscle, and as all muscles, it needs regular exercise to keep sharp.

Thats why I decided to take very old (but efficient) web optimization technique and implement it in new crazy way. You most likely heard about loading images (and other resources) on demand – which is not only a common sense, but also a good way to speedup initial page load.  Usually it is implemented via JavaScript, but today I’ll share with you how you can achieve the same effect by using pure CSS.

Read more!

Another scriptless clickjacking vector

Recently, one of my colleagues showed to me that Google do the following trick on their search results page. If you search for something, initially search results contains html with anchors we’d expect:

<a class="l" onmousedown="return rwt(this,'','','','1','AFQjCNGGfyJjOyiWYPB3FW-h7Pt6A5uwlA','4k2v33QNU7tijpC6ZLriyQ','0CDIQFjAA','','',event)" 
href="http://en.wikipedia.org/wiki/Cross-site_scripting"><em>Cross-site scripting</em> - Wikipedia, the free encyclopedia</a>

But have you noted onmousedown event handler? Let’s see what it does – right click on a link and examine its html again:

<a class="l" onmousedown="return rwt(this,'','','','1','AFQjCNGGfyJjOyiWYPB3FW-h7Pt6A5uwlA','4k2v33QNU7tijpC6ZLriyQ','0CDIQFjAA','','',event)" 
href="/url?sa=t&amp;rct=j&amp;q=&amp;esrc=s&amp;source=web&amp;cd=1&amp;cad=rja&amp;ved=0CDIQFjAA&amp;url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FCross-site_scripting&amp;ei=6oZYUcKUA4WSiALF4YHYDQ&amp;usg=AFQjCNGGfyJjOyiWYPB3FW-h7Pt6A5uwlA&amp;sig2=4k2v33QNU7tijpC6ZLriyQ"><em>Cross-site scripting</em> - Wikipedia, the free encyclopedia</a>

Now it points to a different location! Also note that before we click on it – status bar, at the bottom, showed us a link to Wikipedia instead of google’s /url page…

It is a clickjacking attack, isn’t it? Of course Google is a good boy and will navigate us to Wikipedia eventually, but first it will log our navigation through /url page.

Due to their high practical impact, clickjacking attacks have attracted a lot of attention from the security community members. If you recall, I’ve wrote several blog posts dedicated to this topic, and here are some more links for you:

A Solution for the Automated Detection of Clickjacking Attacks

Scriptless Attacks – Stealing the Pie Without Touching the Sill

Clickjacking in LinkedIn

Self-Exfiltration: The Dangers of Browser-Enforced Information Flow Control

UI Redressing Mayhem: Identification Attacks and UI Redressing in Chrome

Hyperlink Spoofing and the Modern Web

Following the developments and published work mentioned above, a plethora of more or less feasible defense techniques has been proposed. All these attempts have a clear goal: stopping clickjacking attacks. In general, one can say that if an attacker manages to execute JavaScript on the target domain, then he can control the whole Web page navigated at by the victim. Therefore, a recommended mitigation strategy would be to deactivate/limit JavaScript code execution for security reasons, employing tools such as NoScript, Content Security Policy (CSP), or, alternatively, making use of HTML5-sandboxed Iframes.

In this blog post I’d like to evaluate whether restricting scripting content is sufficient for attack mitigation by examining it in practice. For the rest of the article I assume that an attacker has access to DOM and/or CSS of the victim page, but scripting is completely disabled.

Read more!

Unbound methods in JavaScript

In my previous blog post I described technique how to avoid context object exposure in Observer pattern.

publish: function (publication) {
    for (var i = 0, len = subscribers.length; i < len; i++) {
        subscribers[i].call(undefined, publication); //hide context by specifying undefined as new execution context
    }
}

But foo.call(undefined, ...) may lead to assumption that context (this keyword) of the foo function will be equal to undefined. Well, it is not exactly true. this will be resolved to global window object.

function foo(){
    document.write(Object.prototype.toString.call(this)); //[object global]
}
foo.call(undefined);

But if the engine is running on strict mode, then this will be resolved as expected — to the exact thing it was applied to:

"use strict"
function foo(){
    document.write(Object.prototype.toString.call(this)); //[object Undefined]
}
foo.call(undefined);

Be careful with your assumption, especially in JavaScript!

Read more!