Archive for November, 2006
For the past few months I’ve been following the ha.ckers weblog, which talks about hacking websites and otherwise internet-connected systems. In the most recent two posts (part 1, part 2) a way to do port scanning without JavaScript is discussed. This all harks back to early August, when SPI Dynamics discussed port scanning using JavaScript. An often heard counter measure to this technique is disabling JavaScript, but it turns out that won’t be enough.
The scan itself is quite ingenious. It relies on the way Firefox parses the document, which by default is sequentially. First, the page itself loads from the attacker’s server. The time is noted. Then, an image is loaded with it’s source set to a server in the local network, say 192.168.0.1. Once finished, another image from the attacker’s server is loaded, the time is again noted.
Because Firefox finishes loading this image before loading the next, it’s possible to determine the time it took to load the image from the local network. If this is a couple of seconds, one can assume the image request timed out, and the port is closed. If it’s faster than that, the port is open.
This goes to show that the browser security model as it is today is not good enough. One idea would be to disallow resources from outside the local network to access resources inside the network. It sounds good to me, but then I’m not a security expert 
To close with a comment from RSnake, the ha.ckers’ author:
I think we’ve proven a our point. JavaScript isn’t the root of the problem here. Sure it enables bad stuff, but HTML and the client technologies alone can obviate the necessity for JavaScript alone. Do I think anyone is going to use this technique in reality? Probably not when JavaScript is so prevalent and cross browser compatible. But it is nice to know you can call people out when they claim they are safe because they turn off JavaScript.
Back at Reboot 8.0 Jyri Engeström introduced us to Jaiku. Jaiku is an online presence service: you can post small notes about what you’re doing, either through the website or by texting or using the mobile application. Together with web feeds you can specify this is all combined into a presence stream. It’s much like Twitter, except prettier, cooler and European. And they have Andy!
Today I signed up, and set about automating the process. First off, there’s JaikuAdium by Peter Rukavina. This will set your Adium status to your current presence. Of course, you’ll still have to go to Jaiku to actually update your presence, so we can use some improvement.
Enter some HTTP reverse-engineering. Andy already told me they might inadvertently break the code below, so be warned. This tutorial is also for OS X. Here’s what you need to run in Terminal (you can remove the \ and the line break):
curl -b "jaikuuser_XXXX=username;jaikupass_XXXX=XXXX" \
-d "icon=338" -d "message=Hello+world" --url http://jaiku.com/
The jaikuuser_XXX and jaikupass_XXX are the cookies used by Jaiku which contain your login credentials. You’ll have to retrieve these from the browser. Please note that the XXXX is a long string of letters and digits. The presence icon is identified by a number, I’m not sure of the mapping between the icons and their IDs, so you’ll just have to try. 338 is the exclamation-mark-in-a-text-balloon icon. And finally, message is exactly what you think it is. Take care to properly encode it’s contents though, it shouldn’t include whitespace, ampersands and probably some other characters.
Here’s a Ruby script which updates your presence and Adium status at the same time:
#!/usr/bin/ruby
require 'cgi'
`curl -b "jaikuuser_XXXX=username;jaikupass_XXXX=XXXX"
-d "icon=338" -d "message=#{CGI.escape(ARGV.join(' '))}" --url http://jaiku.com/`
`osascript /Applications/JaikuAdium/JaikuAdium.applescript`
Here I’ve placed the JaikuAdium script in /Applications/JaikuAdium/. Update the login credentials as mentioned above. Then, call the script with the presence message as it’s argument(s).
Enjoy!
Over the past few weeks I’ve been exchanging e-mails with Bobby van der Sluis, discussing sIFR and UFO. Among the things discussed was DOMContentReady, or more specifically my implementation for Internet Explorer, which was based on the Dojo implementation. Dojo uses the following code:
if(dojo.render.html.ie && dojo.render.os.win){
document.attachEvent("onreadystatechange", function(e){
if(document.readyState == "complete"){
dj_load_init();
}
});
}
Whereas the “official” code is as follows:
/*@cc_on @*/
/*@if (@_win32)
document.write("<script id=__ie_onload defer src=javascript:void(0)><\/script>");
var script = document.getElementById("__ie_onload");
script.onreadystatechange = function() {
if (this.readyState == "complete") {
init(); // call the onload handler
}
};
/*@end @*/
The difference may seem minor (readyState on a script instead of the document), but Dean Edwards mentioned in a comment on his site that document.readyState wouldn’t work properly. So, time for some test cases! First of all, domcontentloaded.html logs the following:
- Safari: changes to
document.readyState - Mozilla/Opera: firing of the
DOMContentLoadedevent - Internet Explorer: both techniques covered above
- All browsers: the loading of an image and
window.onload
Additionally, an external CSS file is loaded which gives the document a red background color. When the DOMContentLoaded event (or browser specific equivalent) fires, some CSS is written to the page which changes the background color to green. More on this later. The CSS file waits 5 seconds before returning data to the browser, the image waits 10 seconds.
It turns out that in Internet Explorer document.readyState fires after the loading of the image, and right before window.onload. In effect, it’s useless. The “official,” script.readyState variant does fire before the image loads, and is indeed the correct version. In the other browsers the official techniques work properly as well, and the background color of the page is green.
Safari & Style at the Opera
Now, what are we using that background color for? For sIFR it is incredibly important that all CSS has been loaded and applied before kicking into gear. It relies completely on the specified styles for the to-be-replaced elements, without it just won’t function properly. As said before, the first test case showed no surprises with the background color: it appears as if the stylesheets are applied in the correct order. In Safari and Opera, however, this turns out to be false. Enter readstyle-domcontentloaded.html. This test case is virtually the same as the one used before, however on the DOMContentLoaded event it logs the computed background color.
In Internet Explorer and Mozilla it reads out a red background color, in Safari however it reads rgba(0, 0, 0, 0) or transparent. There is also a Flash Of Unstyled Content. In Opera 9 the background color also reads as transparent, but without a FOUC. Webkit.org has an article by Dave Hyatt explaining the issue (as well as the FOUC):
(WebKit) will continue parsing a page even after a stylesheet directive has been encountered so that stylesheet and script loads can be parallelized (compared to waiting for the stylesheet to load – Mark Wubben). That way everything can be ready for display much earlier. (…) when a script attempts to access a property that involves having accurate layout/style information(, shipping Safari’s) will go ahead and lay out what it’s got even though it doesn’t have the stylesheet yet. It will also display it. This means you see FOUC whenever a script tries to access properties like scrollHeight or offsetWidth before the stylesheet has loaded. (…) we will (…) give back information that the page might consider to be incorrect, since the stylesheet that supplies the up-to-date information hasn’t loaded yet.
The article also discusses ways of solving this issue in WebKit itself. The suggested method is stalling the JavaScript execution when it tries to access a style dependent property. Unfortunately as of nightly r17760 this has not yet been implemented. This behaviour also highlights a need for something like a FinishedRendering event that would fire when the stylesheets referred to in the HTML have loaded and been applied. Right now the DOMContentLoaded movement relies quite heavily on this specific browser behaviour, if things change in Mozilla or Internet Explorer without implementing either a FinishedRendering event or stalling JavaScript execution — for backwards compatibility probably the better solution — many modern sites and applications will break.
In the mean time, no more DOMContentLoaded in sIFR for Safari and Opera.
Over the past few months I’ve been getting comments on this blog from Germans. Now, that’s great, especially since a lot of them are regarding sIFR. Something smells fishy, however. The sites behind these comments aren’t the typical sites you would expect from web developers, they are quite ugly and don’t seem to serve a real purpose. After seeing yet another weird comment today, I decided to dive into this a bit further.
We are dealing with the following domains and originating IP addresses (intentionally not linked):
- info-aerzte.de, from 212.23.126.1
- a-katalog.de, from 217.238.100.199
- 0am.de, from 212.23.126.6
- softsensive.de, from 84.139.122.75
- katulago.de, from 84.139.93.56
- restposten-zentrum.de, from 89.50.175.104, 89.50.175.82
- online-reisefuehrer.com, from 84.154.108.236
- afrika-start.de, from 62.159.35.170
- erfolgs-werkstatt.de, from 84.142.155.180
- themenrelevanz.de, from 84.178.2.131
IP addresses nicely listed:
- 62.159.35.170
- 84.139.122.75
- 84.139.93.56
- 84.142.155.180
- 84.154.108.236
- 84.178.2.131
- 89.50.175.104
- 89.50.175.82
- 212.23.126.1
- 212.23.126.6
- 217.238.100.199
Here are some sample comments:
Wow, never thought that it was so easy, fortunately we don´t have to work with this version….
Great job! Runs absolut fine with Firefox 1.5.0.7 xp sp2 german version.
The IE7 will display a few of my websites also in a different way than the new FF, but who cares….
Did you try to get the FF20? I tried to download it but the server was busy all the time. I am curious if there are new challenges for the web designer…
regards, Sandra
Most notably there are a number of comments with just one or two sentences, ending in a lot of periods. The level of English is lacking, too. (For the real German readers, I mean no offense!) Some commenters even post follow-ups. Considering how the comments fit the context, they are definitely typed by humans.
Looking through the WHOIS information for above domains gives some surprising results. Domains for which a guy named …… is the administrative contact:
- info-aertze.de
- 0am.de
- restposten-zentrum.de
The administrative contact for the domains above contacted me on December 28, informing me his sites were being spammed without his knowledge. I’ve redacted his name at his request.
Domains for which Werner Kaltofen of Neue Medien Muennich is the technical contact:
- 0am.de
- restposten-zentrum.de
- online-reisefuehrer.com
- erfolgs-werkstatt.de
Domains with kasserver.com as name server:
- a-katalog.de
- 0am.de
- restposten-zentrum.de
- online-reisefuehrer.com
- erfolgs-werkstatt.de
Softsensive.de does not appear to be registered, although it still works. The name servers for the other domains reveal nothing interesting, nor does there appear to be a connection the domains I just mentioned and the katulago.de, afrika-start.de and themenrelevanz.de.
There clearly is a connection in the WHOIS data between six of the ten suspected domains. The other domains appear to be connected through the style of the comments linking to them and the type of website found. It is, however, possible that I’m seeing ghosts. In any case, the links from the suspected comments have been removed, and I’m adding the following to my commenting guideline:
Non-contributing comments run the risk of being removed. Especially if the website seem “fishy”. Spammers, beware.