I'll try to briefly explain the problem and then show how it relates to Facebook and MySpace. For more background information, please refer to these prior posts:

• Cross-Domain Ajax Insecurity, which discusses why true cross-domain Ajax is a bad idea, despite many misinformed Ajax developers claiming it's safe.
• Cross-Domain Ajax with Flash, the post that discloses the vulnerability.
• The crossdomain.xml Witch Hunt, which mentions other big sites, such as YouTube and Adobe, that suffer from the same vulnerability.

Web technologies that abide by the same-origin policy cannot reside on one site and interact with another. To be a little more specific, if you visit my site, I can't make you update your status on Twitter . If I want to try, I need to get you to send an HTTP request similar to the following:

POST /status/update HTTP/1.1
Host: twitter.com
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://twitter.com/
Content-Length: 66
 
authenticity_token=snuffleupagus&status=@shiflett+made+me+do+this.

If I use JavaScript to do this, the request is sent from you to Twitter, so it also includes any cookies Twitter uses to identify you. (I did not include the Cookie header in this example, because it's really long.) Would this work? Luckily, no, but only because I have to know the value of your authenticity_token, Twitter's anti-CSRF token. (Read my article on CSRF for more information about cross-site request forgeries and anti-CSRF tokens.)

To work around this safeguard, I need to get your anti-CSRF token. If you visit Twitter yourself and view source, you can see it:

<input name="authenticity_token" value="snuffleupagus" type="hidden" />

This token is yours and won't work for anyone else. If I want to forge a request from you, I need to know what your token is. Because you can view source and see your token, you know it's included in the response. I can use JavaScript to send a request from you, but is there a way I can also read the response?

Yes, there is. Meet XMLHttpRequest(), often abbreviated as XHR, the method most closely associated with Ajax. If I use XHR to send a request from you (to Twitter) and read the response, I can find your token and use that to update your status. Would this work? Luckily, no, because XHR abides by the same-origin policy. I can only use XHR to send requests that are considered to be within the same origin, so I cannot use XHR on my site to send a request (from you) to Twitter, a different site.

Enter crossdomain.xml. Flash supports cross-domain Ajax using an opt-in model, where the receiving site has to give permission. For example, I could make you update your Twitter status if Twitter’s cross-domain policy file let me:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
 
<cross-domain-policy>
  <allow-access-from domain="shiflett.org" />
</cross-domain-policy>

Luckily for you, Twitter doesn't trust me. More accurately, they don't force you to trust me. This is where open cross-domain policy files like the following are dangerous:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
 
<cross-domain-policy>
  <allow-access-from domain="*" />
</cross-domain-policy>

A few days ago, Yvo Schaap realized that Facebook Connect not only had an open cross-domain policy file, but also had a complete running copy of the Facebook site. (As evidence, here's the home page within the www.connect.facebook.com domain. If you're logged in, you'll be recognized.)

In other words, Yvo found another site with the same vulnerability that has plagued so many others, including Flickr, YouTube, Yahoo, and Adobe. (Cue Queen.)

MySpace made a similar mistake. Although their cross-domain policy file was not open, it trusted farm.sproutbuilder.com (Sprout Builder), a site that allows users to upload their own .swf (Flash) files, thereby gaining complete access to MySpace.

I'm glad Yvo waited until these vulnerabilities were fixed before blogging about them. Unfortunately, I already let the cat out of the bag a few years ago. Hopefully more people will pay attention this time and tread carefully when using crossdomain.xml. Adobe's own site has finally been fixed, so you no longer have to ignore the hypocrisy of their usage recommendations:

Using a cross-domain policy file could expose your site to various attacks. Please read this document before hosting a cross-domain policy.

Posted Fri, 06 Nov 2009 16:29:25 GMT in Chris Shiflett’s Blog

Unsurprisingly, my Mac didn't already have git. (It's not part of the developer tools either.) GitHub has a nice help page on installing it, including one specifically on compiling from source. I chose the latter.

GitHub's help page on compiling from source is thorough enough to make it seem complicated. To show just how simple it is, here's exactly what I did:

curl -O http://kernel.org/pub/software/scm/git/git-1.6.5.2.tar.gz
tar -xvzf git-1.6.5.2.tar.gz 
cd git-1.6.5.2
make prefix=/usr/local
sudo make install prefix=/usr/local

GitHub provides very helpful instructions when you create a new project. For my new getFavicon project, the instructions were as follows:

mkdir getFavicon
cd getFavicon
git init
touch README
git add README
git commit -m 'first commit'
git remote add origin git@github.com:shiflett/getFavicon.git
git push origin master

If only discovering favicons were this easy! :-)

Posted Mon, 02 Nov 2009 13:31:33 GMT in Chris Shiflett’s Blog

I'm learning HTML and CSS.

When I ran my first marathon, I read a book called the Non-Runner's Marathon Trainer. One of the first few chapters explains that you should choose a marathon and tell everyone you know you're running it. This helps motivate you, because you feel as if you've made a promise. You're on the hook.

I'm putting myself on the hook.

Now that I'm on the hook, it's time to get started. I'm reading a book Jon Tan reviewed a few months ago called HTML and CSS Web Standards Solutions. I think it's going to be a perfect fit.

I know HTTP pretty well. Perhaps because HTTP is so familiar, I took a few notes while reading the first two chapters that I'd like to share with you in the hopes it will help you understand the Web a bit better.

From Chapter 2:

The .html part is important: it is a suffix, referred to as an extension, that tells the browser the document is a web page.

This isn't strictly true. URLs don't have file extensions, although it can appear so because of how easily you can map a URL to the filesystem, and how common it is to do so. The Content-Type header indicates the content type. This is why a URL like http://shiflett.org/about doesn't appear to have a file extension, yet browsers still know to treat it as HTML.

A file extension can seem important if the resource is something users might download. Luckily, it's not even necessary in this scenario; you can indicate your preferred filename with the Content-Disposition header. For example, regardless of URL, you can suggest the filename foo.bar as follows:

Content-Disposition: inline; filename=foo.bar

Also from Chapter 2:

The last thing we need to ensure our pages validate is a character encoding.

The suggested way to do this is with a meta tag:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

A meta tag of the http-equiv variety is a substitute for an HTTP header. Adding this tag is useful, and the W3C Validator even suggests it. Pages still validate without it, but you'll receive the following warning if you leave it out:

No character encoding information was found within the document, either in an HTML meta element or an XML declaration. It is often recommended to declare the character encoding in the document itself, especially if there is a chance that the document will be read from or saved to disk, CD, etc.

In order to prevent problems, including some security vulnerabilities, be sure to always indicate the character encoding, and make sure you're consistent.

Now it's time to read Chapter 3. I hope you enjoyed this quick HTTP lesson.

Posted Mon, 26 Oct 2009 20:58:54 GMT in Chris Shiflett’s Blog

Judging by the nice comments left on Twitter and Joind.in, everyone really liked my talks. Comments like "this was my favorite talk of the day" and "by far the most entertaining presentation" are especially uplifting. I put a lot of effort into my talks, and I really appreciate when people take the time to let me know when I've done a good job. Thank you so much!

It was great having the conference visit NY, especially since it was so near my apartment. On the first day, I took everyone to Siggy's for a late lunch. NY is known for great food, and Siggy's didn't disappoint:

Just had quite possibly the best veggie burger I've ever had. Ever. Thank you, Siggy's in NYC, you have made my day!

For lunch the next day, I took everyone to Grimaldi's for the best pizza in the universe, but the real highlight of the day was the beer dinner at Beer Table I had been planning.

Beer Table is a local bar in Park Slope operated by Justin and Tricia Philips. The beer selection is admittedly overpriced, but it's worth it for a great selection, an intimate atmosphere, and very good food. When I first spoke to Justin about hosting a beer dinner there, he noted that Beer Table has never been closed to the public, but there's a first time for everything.

Beer Table's first private event hosted some of the Web's friendliest designers, developers, copywriters, and illustrators:

• Alan Colville
• Alejandro Garcia
• Andrei Zmievski
• Anthony Gentile
• Arbi Arzoumani
• Ben Ramsey
• Chris Shiflett
• Derick Rethans
• Ed Finkler
• Elizabeth Naramore
• Helgi Þormar Þorbjörnsson
• Jason Santa Maria
• Jessica Hische
• Jon Tan
• Lisa Denlinger
• Nate Abele
• Nicholas Sloan
• Paul Jones
• Sean Coates
• Scott MacVicar
• William Burks Spencer

For those who went, here is the menu, with links to each of the beers, using RateBeer where possible, BeerAdvocate otherwise:

1^st Course

Roasted beet salad paired with De Glazen Toren Saison D'Erpe Mere and Saint Somewhere Saison Athene

2^nd Course

Cannellini beans with pork, roasted tomatoes, and rosemary paired with Green Flash West Coast IPA and Burton Bridge Empire IPA

3^rd Course

Triple chocolate cookies paired with Hitachino Espresso Stout and Harvey's A. le Coq 2003

Half of the dinner was sponsored by the fine people at echolibre, a web development company based in Dublin that is the home of respected developers like David Coallier and Helgi Þormar Þorbjörnsson. The other half was sponsored by a small group of people including Jon Tan, Andrei Zmievski, Alan Colville, and myself. We're not quite ready to talk about what we're up to, but we hope to be soon.

This is the last of my conference appearances for the year. Now it's time to focus on my new company. More about that soon!

Posted Mon, 19 Oct 2009 02:11:05 GMT in Chris Shiflett’s Blog

• Atlanta
• Miami
• Washington
• New York

I'll be giving two talks. The first is my current favorite, Security-Centered Design:

Security is more than filtering input and escaping output (FIEO). It's more than cross-site scripting (XSS) and cross-site request forgeries (CSRF). Security isn't even always black and white. In order to create a more secure user experience, we need to understand how people think. Perception can be as important as reality, and meeting user expectations is a fundamental of good security. In this multifarious talk, I'll introduce some of what I have learned about cognitive psychology, exploring topics such as change blindness and ambient signifiers, and I'll show some real-world examples that demonstrate the profound impact human behavior can have on security.

The other is a new talk about Fun with Maps and PHP:

On a recent road trip around Iceland, my friends (PHP developers Andrei and Helgi) and I decided to make a travel site. We brought our cameras, GPS, and Flips, and we used PHP to:

• Aggregate our experience in the form of photos (Flickr), tweets (Twitter), and videos (Vimeo).
• Geotag all of these assets, so we'd remember precisely where we were.
• Create a map that marks our path each day and plots our photos, tweets, and videos.

We made most of this while taking in scenic views and experiencing all Iceland has to offer, and we learned a lot about geotagging, GPSes, time zones, and maps along the way. This talks shows you how to do the same, but you'll have to buy your own flight.

I hope to see you there!

Posted Mon, 28 Sep 2009 15:21:43 GMT in Chris Shiflett’s Blog

Next year, I'm hoping to return as a panelist. As SXSW veterans know, part of the selection process involves voting via the PanelPicker, where you can vote for the panels you'd like to see. (Voting is open now and closes Fri, 04 Sep 2009.) I know getting a panel accepted is a long shot, but I want to try. I'd really appreciate you taking a moment to register (if you haven't already), and kindly voting for my panels if they sound interesting. Anyone can vote; you don't have to have been to SXSW before or even be planning to attend this year.

The first panel is entitled Travelog With Maps: When 1000 Photos Aren't Enough:

They say photos are worth a thousand words. Is that enough to describe a trip? We don't think so. Learn how a GPS device, a dash of code, and a bit of creativity combine to tell the story of your travels. We did it in the land of fire and ice, and so can you.

This panel includes my good friend Andrei and is inspired by our trip to Iceland with Helgi, where we spent a few hours every evening importing and interpreting GPS logs, geotagging and uploading photos, writing code, and aggregating various other assets, like videos and tweets. We wanted to create a travelog that our friends and family could use to follow along with our trip, and to tell our story to those who may be considering a similar trip of their own. In this panel, we want to share what we learned along the way and inspire others to share their own travel stories without having to overcome as many obstacles.

The other panel is entitled Social Web Security: From Psychology to Programming:

The user-generated, interconnected Social Web is ripe for the plucking by criminals and other malicious users. We'll demonstrate how psychology and user experience have as much to do with security as coding and sysadmin skills, and how to apply all of them to protect your users.

This panel includes Ed, Simon, and Alex, and explores the security implications of emerging trends in social apps as well as some innovative, nontraditional techniques you can use to help keep people and their data safe. This panel is one part web application security, one part design, and one part psychology. If you like my talk on security-centered design, I think you'll like this panel. I've been talking to Ed about this for quite some time, and we're really excited about it.

I appreciate you taking the time to vote. If you also want to be kind enough to share this on Twitter or elsewhere, I've created some short links you can use:

• http://tr.im/travelog
• http://tr.im/socialwebsecurity

Here's hoping I see you in Austin. :-)

Posted Tue, 25 Aug 2009 16:44:46 GMT in Chris Shiflett’s Blog