Back to: Blog

Blog

Around the web

Fight the Future
Macbook + Coffee = Bad - one of those “laugh but also feel kinda sick about it” things.
blackrimglasses - Holy Jesus - power of attorney? - I can understand why they need it, but yeah…
Memoranda - some good points here.
The Long Term Performance of InnoDB - this is completely true, but as a web developer I really want this sort of thing to be hidden from me.
Washburn and the Winner’s Curse - I’ve been long lementing the bad contracts the Mariners have been dishing out.
WordPress MU Domain Mapping 0.1 - will be checking this out with interest.
RedMonk: We’re Not Perfect, But We Try - really glad we were able to help build this for Steve and the good folks at RedMonk.
**The opinions expressed in this blog post are mine alone…. - yeah…
Consuming Not Creating, Revisited - heh.

WordCamp Utah

September 27th is the date - registration is open.

I’m quite looking forward to this (particularly since I wasn’t able to make WordCamp SF this weekend), both as a speaker and as an attendee. I’ll probably be flying in Friday mid-day and out on Sunday.

Big thanks to Joseph Scott for organizing.

My company, Crowd Favorite, is proud to be one of the sponsors of the event.

Popularity: 13% [?]

5 Comments |

Posted August 15th, 2008 @ 5:39 PM

Debugging an XSS attack

Posted in: Development

Today I ran across a Cross Site Scripting (XSS) attack in the wild. Since the victimized site is run by a friend, I did a little digging to see how the attack was done so I could tell him about the issue and how to fix it. Here is a little background on XSS attacks and how to debug them and avoid them.¹

An XSS attack is when someone is able to inject code into a page - generally when a user can get JavaScript code to execute within a web page. These can do bad things like steal your cookies and do bad things on your behalf, or annoying things like pop up windows and redirect you places.

If you are trying to debug an XSS attack, the first rule of thumb is not to use your main browser. Don’t use anything that has “your” data in it - things like login cookies, etc. Instead, use your secondary browser or your development profile for your main browser if you have one.

Your browser can show you the behavior that the attack is performing, which is useful. However, depending on the attack, getting the HTML source from your browser may not be so easy. Also, many browsers will “clean up” the HTML a bit as they render it, so the HTML you see from your View Source command isn’t always exactly what the web server sent down.

You should use a command line utility like cURL or wget to download the raw HTML source and look through there for the vulnerability.

You’ll probably find a place in the HTML where a tag was closed before you expected it, and a SCRIPT tag somewhere you didn’t expect it.

There are a number of ways to avoid XSS attacks. The main approaches are:

Strip out tags/content you don’t want to support. These should definitely include script tags, and also attributes on other tags that can execute JavaScript - attributes like onload, onclick, etc.
Encode your HTML output so that angle backets become < instead of < and quotes become " instead of ". This prevents the JavaScript from being executed in the browser because the attempted HTML tags don’t end up as HTML tags, they instead show what would normally be seen as HTML source.

There’s a ton of info on preventing XSS attacks out there on the web. If you’re a web developer, make sure to do a little reading on this.

This is the one security area developers fail most often when interviewing for a position at Crowd Favorite. [back]

Popularity: 12% [?]

4 Comments |

Posted August 12th, 2008 @ 6:46 PM

Around the web

1 Comment

Paul Abrams: The McCain Strategy Is Vintage Karl Rove, the Media Loves It, and the Obama Camp Is Not Taking It Seriously Enough
tecosystems - Big Brother is Watching You. On Twitter.
Sprint: Sprint Finally Makes Good On 3G Data Capping - this totally sucks. (thanks Eric)
Paris Hilton Responds to McCain Ad - “I’ll see you at the debates, bitches.” - hah!
Beta testing on iPhone 2.0 - I think “half-baked” is a generous term for the current state of the App Store.
Davenetics* : Tiger and Steve
Zennaware - Cornerstone - another lovely looking Subversion client for the Mac. Great to see competition for Versions - I look forward to testing this out.
Twitter is down again, hilarious Chris Shiflett: End of Life for PHP 4 (thanks Shawn)
Will There Be Only One Cloud?
Placating people with options - interesting take on the Google Code license availability changes.
Google Code vs License Proliferation - good commentary from Steve, as usual.
Try before you buy at the iPhone App Store? - I have to think the people at Apple know this too.
iPhone, iCal, and CalDAV - calendaring options are improving drastically.
Short random thoughts from Coors Field - I consider Safeco and Coors fields two of the best places to actually watch a ballgame.
Uses for an iPod Touch Around the House - at some point I need to do this for our house.
iPhone App Store is Revolutionary - for all it’s warts, this is also true.
The MobileMe Thunderbird Address Book Sync
Configure ActiveSync with a single Exchange server (Exchange sync for an iPhone)
WordPress 2.6.1-beta1 - Dougal’s right on top of this stuff.
Wake n’ Bacon (thanks Jeremy)
OMG I heart the iPhone! - while the iPhone succeeds wildly in bringing the “smartphone” to the masses, it also fails in some pretty fundamental ways.
Action! - I look forward to seeing how this goes. I’ve got no doubt Ethan can pull it off.
IE previews from within Coda - very nice.

I credit Brent and the excellent NetNewsWire for iPhone for my newfound ability to (almost) keep up with my feeds again.

Addictomatic Refreshed

Posted in: Crowd Favorite, Case Studies, News

Addictomatic is sporting a shiny new suit today.

The overall look has been updated with a great new design from Bryan Bell, and a number of little features have been added and minor tweaks made since the initial launch.

I’ve got a few more screenshots here, but it’s a lot more fun to just go poke around.

Here is a partial list of the changes:

New theme design.
Welcome message for first time visitors.
List of Hot Topics next to the Create box.
New Browse the News navigation.
Integrated ads from the Deck.
More little JavaScript effect niceties.
Numerous behind the scenes changes for performance.

The main focus of the refresh was to make it easier for new visitors to explore the site. To this end we exposed more links to Hot Topics, added weight to the Browse the News (formerly Newsfix) button, and configured the Browse the News drawer to stay open on Browse the News pages. This last change keeps the other news topics visible more often, giving people enticing things to click on. Hopefully the results will be good.

Thanks, as always, to Dave Pell for trusting us to work on his baby. We have a lot of fun building and using Addictomatic.

Popularity: 14% [?]

2 Comments |

Posted August 6th, 2008 @ 11:15 AM

Twitter Tools 1.5b1

Posted in: News, WordPress

I’ve got a new version of Twitter Tools ready to test. This version has a number of changes, including one that has been very frequently requested:

Weekly digests! This needs a good deal of testing, help us find bugs
Ability to exclude @replies from daily and weekly digests and blog posts
Updates to match Twitter API changes so that “in reply to” links are properly created
A bunch of little things I’m forgetting now

Weekly digests is a rather complicated feature to build, and took a good chunk of time. Luckily, we had a development sponsor for this feature, who I will thank properly in the final release (once I receive permission to give them credit).

I realize that version 1.2 never got to a final release version, but we had an opportunity to get these features built, so I took advantage of it.

Finding time to test, package and release plugins has been a bit challenging of late.¹ Hopefully I’ll have more time to get things pushed out going forward.

The download and more information are available on my WordPress Plugins page.

If you have any trouble with this, please open a thread in the WP Support Forums and send me the link.

UPDATE: looks like some PHP 5 specific code (a try/catch) snuck in here. If your server uses PHP 4, I recommend waiting until the next beta release.

My business has been growing which has brought a number of interesting and time consuming challenges. [back]

Popularity: 16% [?]

20 Comments |

Posted August 5th, 2008 @ 2:39 PM

Around the web

0 Comments

Font Conference - CollegeHumor video - bwahahaha.
John Resig - Keypress in Safari 3.1
Griffin Technology: PowerDock - this is fantastic on so many levels. (thanks Shawn)
Beyond REST, or Beyond XMPP? Both? The Q&A - great interview and responses, I expect nothing less from Steve and Joe.
MsgFiler 2.0.3 Released! - this is a must-have.
Not Yet Squirrelly - great to see anything that improves JavaScript.
The Dell Hybrid - Dell waking up to industrial design?
Cuil, a mini-review - pretty consistent with every review I’ve seen so far.
My Hiatus From Twitter - Why You Should Join Me ++
PHP Markdown Extra (thanks Eric)
Hulu - Point Counterpoint: Lee Marvin & Michelle Triola: Saturday Night Live - not sure why I’m just now getting into Hulu.
Welcome to iPhone: Your Crappy Mac of Tomorrow, Today!
Killing your phone’s GSM buzz with ferrite beads - I’m desparate to try this in my car.
so… - it’s funny/cool/strange to see so many friends climbing to successful positions.
The One About The New Job - Devin has hit the ground running nicely.
CodeIgniter Community Voice - Generating PDF files using CodeIgniter - need to check this out as an alternative to domPDF.
Disable iTunes iPhone backup, updated for iTunes 7.7.1
Dear America. Please fix your country so I can visit it again. - hrmmm.
OpenDNS - one of the first things I do on any new computer.

404s and WordPress Server Load

Posted in: WordPress, Development

A few months back we launched a site redesign/redevelopment project for a client, and made a simple mistake that had some interesting ramifications. It’s worth posting here so others don’t make the same mistake.

What Happened

When redeveloping the site, we moved the WordPress instance from the web root:

/public_html/wp-config.php
/public_html/wp-includes/
/public_html/…

to a subdirectory within the web root:

/public_html/wordpress/wp-config.php
/public_html/wordpress/wp-includes/
/public_html/…

I consider this to be a best practice for WordPress powered sites, as it makes version upgrades a bit easier (among other things).¹ Some plugins don’t work well with symlinked “plugins” directories, but those generally have easy fixes (use ABSPATH, not dirname() in your plugin).

These changes were made and thoroughly tested on our dev server with historical data. We then made the changes in a staging environment under a beta.example.com style domain name before pushing the changes live. In short, we were pretty careful and tested pretty well.

The Result

When we finally pushed everything live, the production server was brought to its knees. Yikes!

A little poking around, some bug reports, and very shortly thereafter we figured out the problem. We had failed to set up a rewrite rule to map content from:

/wp-content/uploads/

to:

/wordpress/wp-content/uploads/

where it was now located.

An omission like this wouldn’t have had much effect on server load in some site configurations, but one of the wonderful features of WordPress - its lovely permalinks - has a hidden caveat that can be exposed if someone makes a configuration mistake (like we did).

WordPress’s permalink system basically works like this:

See if a file exists in the location that was requested; if the file exists, serve it. This is how images, media, non-WordPress files, etc. are served without conflicting with WordPress.
If no file is found at the location that was requested, then pass the URL to WordPress and see if WordPress can figure out what to show.

It’s a really elegant system and works very well. However, it also means that 404 requests - http requests that result in a “file not found” message - have a much higher impact on the server than a traditional 404 request does. For every 404, the server instantiates WordPress, does some database work to try to see if it can figure out what to serve, etc.

When we didn’t set up proper redirects for the content in “uploads”, we basically increased the server load by a factor of 20. Instead of a single request going to WordPress and 20 requests serving static content by Apache, all 21 requests were being sent to WordPress.

The increased load on the server had some… adverse effects on performance. Yeah.

Why We Missed It

So this should be a pretty easy thing to catch, right? If the URLs to the images are broken, we’d all be seeing a bunch of broken images all over the place in our testing - right?

Not exactly, and for two different reasons:

When we tested on the production server using the beta.example.com hostname, the content was still pointing to example.com and the live production server was dutifully serving the images. It wasn’t until we pushed the changes live that the images were no longer at the previous URLs.
Even when the images were no longer in the proper place, our browsers that we were testing in were showing the images properly. This was due to longer expires headers we had just implemented for media on the server in order to reduce overall server load. In casual testing, everything looked to us to be working properly.

Once we tested in browsers that didn’t have the images cached, we immediately saw the problem.

Easy Fix

Luckily, this is a really easy problem to fix. A simple mod_rewrite rule (placed before the standard WordPress rewrite block) fixed everything right up:

RewriteRule ^wp-content/uploads/(.*)$ /wordpress/wp-content/uploads/$1 [L,R=301]

(alternate code, improvements to syntax welcome)

With this in place, the old URLs were redirected to the new location and no longer were spinning up WordPress on every image request.

Hopefully this will be useful to people who might be doing something similar, or who have made the same mistake and are looking to recover from it.