Why JavaScript Reliance Is Very Bad

An old trick is rediscovered: anti-dns pinning.

DNS pinning is a technique used in web browsers and such to keep an attacker from changing the DNS entry of a server in mid-session. If they could, an attacker might have you visit their website, then swap the DNS to an internal IP address (such as your home router’s admin webpage). The JavaScript can then make calls back to the same domain name and the browser would allow it even though it’s now talking with a completely different server.

DNS pinning caches the IP addresses and stores them for the entire length of your browsing session. A workaround is to target browsers that cache pages. Get a user to visit an attacker’s web site, then exit the browser. Restart the browser (say a day later, after having shut down the computer and gone to bed) and visit that site again. The cached page loads, but dormant JavaScript is now triggered (based on a timestamp, or maybe a request to see if a specific file exists on the server tied to the domain name used by the attacker).

But now it’s been found that simply requesting a page on a closed port (www.example.com:81) will trigger the browser to re-cache that DNS entry, making this method of attack much easier and faster, to the point that some people have already built applications that will scan the victim’s entire internal network. From there the program might ID a specific server based on unique default files that come with a default install of IIS or Apache, or maybe look at the 404 error page and parse out the name and version of the server. From there it could launch an attack on specific vulnerabilities for that server, or that web application, leading to a compromise of the system. All of this is automated. Running quietly in some hidden iframe while you continue to browse the internet.

It’s a bit complex, but it works. And there isn’t a fix for this and there may never be one. This is part of how JavaScript works. And now this method is being modified to run in ActionScript (Flash) and JAVA applets.

What’s going to happen is more and more people will start to simply not execute JavaScript, JAVA applets, or Flash movies from sites that aren’t trusted. A feat made incredibly simple with the aid of plugins like noscript. This is where you, the web developer, come in.

You have to gain a user’s trust. And you have to do so without your web page executing JavaScript. If your layout relies on JavaScript and simply displays a blank page without it (all-flash websites also included here) then what is there for the user to base their trust? So they don’t, and simply move on.

“2.0” sites are going to get screwed in this whole deal. They’ll either have to rely on word-of-mouth (“no no, that site’s okay”) or users that have blind trust. Perhaps we’ll see people or groups start to maintain “whitelists” – sites that are okay to trust. Maybe something like an RSS feed that’s updated hourly. But then you look at the history of spam blacklists and start to wonder how that’d really work out.

The simplest solution here is to not rely on JavaScript, Flash, or JAVA for your website. The web started in text, perhaps you should keep to tradition. Small bits that enhance a site’s functionality are fine, but nothing that’s critical to allowing access to your content. Then, once the user sees your site is okay, they’ll add you to a trust list and your scripts get executed and the site loads exactly as you want.

What will be really interesting is to see if there’s a backlash. Users might start to realize just how much faster and more efficient their browsers run and better their experience with the site is when all the extra scripty bits are disabled. Perhaps we’ll see a push away from crazy embedded elements and back to a simpler means.

Probably not.

Skinnable Skidoo

To prove that redux is very skinnable I plan on producing themes for it. From time to time you might check back and find I’ve put another up. At least that’s the intention… I may very well ignore redux and move on.

But I’ve already produced one new theme: Future.

It was initially inspired by a moment I had where I perceived the future of web design as being nothing but soft pastels and other light colors. I think the color scheme is a bit too soft, but so be it. It has a few key features that I like about the layout so I’m leaving it. The first is the masthead being a solid color that goes right up against the top of the viewport. No margins here! And I think the perception of using negative space to form the title for the page is a great compliment to the marginless top.

Would you call that negative space? Or is the blue the negative space? I’ll let the art critics figure that out.

The layout has a max-width applied to it, but will shrink down to a minimum of 600 pixels wide. It’s both fluid and dynamic. If anything I think that’s a trait you’ll see a lot in future web pages. It bridges both the fixed-width and fluid paradigms. And with IE7 finally supporting the max/min-width properties, it’ll be much more accepted practice.

Now on a bright monitor like an LCD or a Mac you might not notice it but the side margins (if your resolution is less than 1024×768 you won’t see this) are a slightly darker-than-white color. This then reveals that the middle column goes all the way to the bottom regardless of how tall the content of the column is. This is a trick stolen from Tank!. I like it.

I tried to get away from placing borders and lines around every single element. That’s one of my habits and I wanted to get away from it a little bit. Somewhat successful I think.

And one last bit, something I did by accident, look at the menus. Each menu item has a white border inside the darker color outer border. I think it makes them stand out just a little bit more, but isn’t so obvious as to disrupt your eyes moving across the page.

Now obviously this theme is broken in one very key area: color. They’re too soft, too washed out. You would never use this color scheme because users with contrast problems would have great difficulty using the page. Furthermore, I think it starts to annoy your eyes after about 20 seconds. So were you to use this theme I’d say darken the colors up a bit, maybe stick left and right borders on #page-wrapper that are darker than the background color of the body element and maybe 5 pixels wide or so. And maybe add another 50 pixels of padding to the top of the masthead. I can’t get enough empty space!

Skidoo Redux

Skidoo Redux is the latest Skidoo derivative. It came about when I attempted to update Skidoo to work with IE7 (a few minor bugs here and there). In the process of cracking down on the bugs I became frustrated with how other browser hacks in the old Skidoo stylesheets were too embedded. It was hard to get a handle on what hack did what and why I had put them in there in the first place.

The final straw was when I found an ugly horizontal scrolling bug in all previous Skidoo layouts under IE/Win 5.0. I decided to start over from scratch.

The CSS is commented to the point of insanity. It’s probably 25% CSS, 75% comment. In it I try to detail every rule, why it’s there, how the hack works (if the rule is a hack) and I did my best to target specific browsers so hacks wouldn’t be applied in browsers they were not intended.

I also took the time to write a bit about why these float-based layouts can cause headaches, specifically with elements dropping down to the bottom of the page. Hopefully this will clear up some of the confusion about these layouts that seem to be the source of most of the e-mail I receive.

It is, by far, the most compatible layout I’ve created to date. There is no Netscape 4 support, it simply renders as a plain page with just text and no layout, but some might call that Netscape 4 support.

I’ve purposely stuck with shades of gray for my various background colors in the hopes that it will get others who use the layout to change the color. I’ve seen a lot of skidoo and skidoo too sites out there that stick with the default color scheme and it’s starting to get to me.

The layout is very skinnable! And I plan to prove it…

rMenu Update

Ruthsarian Menus have been updated with what I think is the most significant update yet. Horizontally centered menus. This was one of the last hurdles to jump and it proved to be deceptively simple.

I think I can finally say this menu system has finally added something back to the community. Up until now it was just a copy of Suckerfish with a lot of hacks to bring super-compatibility. But centered menus? Nobody seems to have done that, at least not with Suckerfish, or not without a lot of specific hacks and pixel sizing of elements.

There’s a new section in the bottom right column of the rMenu page that covers the details but the basics are:

Dropdowns only work if the parent LI element is a block element (a generalization, but the root of the problem). You can’t text-align block elements. You can’t float:center. So what’s the trick? In the past you’d have to set specific widths on the LI elements and, knowing this, set a fixed with on the parent UL element. Then you can set the left and right margins to auto. A big pain in the ass, especially if you want to add new menu elements.

rMenu doesn’t require any of that crap.

What happens is that 50% left padding is applied to the parent UL element. This gets a left-floating menu to start at the middle of the screen. All you have to do now is get the menu to move back 50% of it’s own width. That’s the trick. Margins and positioning percent values are based on the dimensions of the parent element. A UL with 50% left padding will not have padding equivalent to 50% of the UL’s width, but of it’s parent (the body of the page).

This means to move the menu back to the left to achieve the centering, you need to position the child elements of the UL, in this case the immediate LI children.

Ah! One problem. The UL is a block element. It’ll default to the width of its parent element regardless of how wide the menu actually is. So you need to somehow get the UL element to collapse to only the width of its children (the menu). This can be achieved by simply floating the UL element.

With the UL floating, the LIs can be positioned 50% to the left, which will be 50% the width of the UL, effectively centering the menu on the page.

Now it’s not perfect. IE/Mac won’t center the elements, it just keeps them left-aligned. They still work, they just don’t center. I’ll need to spend time on figuring out why and perhaps fixing the problem (if it’s fixable). But at this point I think it’s worth releasing in its current state.

I’ve also made a ZIP of the rMenu system available to help ease users in implementing it.

Good luck!

Back in Business

If you’re seeing this then the new weblog server is up and running.

I’d been waiting to continue my posting to the blog until the migration had been completed. We’ve changed platforms for this box and moved it into a VM to consolidate our hardware resources. It’s also now stuck behind a much tighter firewall as well as other added security precautions. Not because this server is being hacked, but because nobody trusts old MT 2.661 it seems.

So here we are. Much to talk about. I’ll get to it in my next post.