Archive for December, 2007

Books, Gaming, Security, Virtual Worlds

Exploiting Online Games

I have been eyeing Gary McGraw and Greg Hoglund’s new book, Exploiting Online Games, for a while now, probably since before it was published. Seems like a no-brainer considering my recent tinkering. But I haven’t bought the book, partly because I’m buying nothing new, partly because I’ve got a stack of other books to get through.

McGraw’s recent appearance on Phil Windley’s Technometria podcast has really got me itching to get this book. Not only do they discuss why criminal abuse of online games has been on the rise in recent years (there is so much money to be had!), but explains why one might care even if games hold no interest:

If you look at online games, they have architectures which are very similar to the ones everybody’s all excited about, with SOA, and Web 2.0, and Software as a Service, where you have sort of a fat client model connected to a central server. And the security lessons that we have to take from online games are *huge*. It turns out that the kinds of attacks, the kinds of problems, the kinds of mistakes that developers make, and the kinds of exploits that those can lead to are already present in the online game world, and so we can get a real peek into the future as far as SOA and Web 2.0 systems go now.

Parenting, Personal

What We Say About Santa Claus

“I told Owen that Santa’s dead.”

Those were the first words out of Kiara’s mouth when I arrived home one day last year.

If you press her on this now, she’ll insist that she didn’t tell our dear little then-four-year-old that Santa Claus is dead. Just Saint Nicholas. Big difference. :)

We’ve never made a big deal of Santa Claus. Every year people ask if we’ve taken our kids to see him. No, we haven’t. Seeing Santa wasn’t a big deal for us when we were kids, and we don’t want to make a big deal of it with our own children. “What?!” you exclaim, “You have to take them to Santa!” No, not really. Heck, our own mothers look at us strangely when we bring it up.

This is about the time when people assume that we’ve already told our kids the “truth” about Santa, that Santa isn’t real.

No, we tell them that Santa is dead. :-D

Hah. Far from it! We read the stories, “The Night Before Christmas” and the rest. There are so many good ones, it’s not only hard to avoid, it’s pointless. They are an important part of our cultural tradition.

When Owen (now five years old) asks if Santa is a real person, a natural question with a Santa on every corner, we shift the discussion away from talking in those terms. We say that he is very real to a lot of people, that people all around the world tell a lot of different stories about Santa — for example, the Swedish will tell you that Santa lives in Spain. We don’t shy away from the fact that in some parts of the world, he’s just not a significant part of the Christmas tradition at all. We explain that Saint Nicholas was real and did some Very Good Things, and that people started telling stories about him to keep his memory alive, that some of those became stories about Santa Claus. We don’t give him gifts “from Santa,” although others do; we just don’t make a big deal out of it. We stress through our words and actions that the important thing about Christmas is not Santa Claus and presents, but the time we spend with our family, being generous and loving, and infusing the entire year with the Christmas spirit.

At this age, the difference between fantasy and reality is not as distinct as it is for (most) adults. Whether Santa is “real” or not is a non-issue. The magic of the stories, the magic of the season is very real, and that’s what we hope our children carry with them.

del.icio.us links

links for 2007-12-05

Programming, Security

If you are a web developer, please learn HTTP

No, really. Please, please, pretty please with sugar on top.

I frequently run into problems that developers either can’t figure out or had no idea existed, problems that stem from fundamentally not understanding HTTP.

For example, every few weeks I find myself evangelizing the Post-Redirect-Get pattern. Simplified, it goes like this:

  1. User submits form with POST (“buy this stuff!”).
  2. Server processes form, sends redirect to the browser to go to the results page.
  3. Browser requests results page with GET.
  4. Server sends results page.

One trick in doing this is that if you want to display a message about the transaction in step 2 on the page in step 3 (“you bought the stuff!”), you need to temporarily stuff that message into session then remove it when you’re done. Rails makes this easy by introducing the Flash, but it’s becoming more common in other frameworks, too.

Simple enough, and it solves all sorts of problems that I won’t get into now. But I still run into conceptual difficulties:

  • Maybe a developer thinks that the browser works directly with Java objects (or PHP, or C#…) and can just manipulate and share these with the server somehow in stateful way. Nope. HTTP is stateless, and your HTML form is just that: HTML.
  • It could be that a developer believes that the message can be sent back to the browser in the response in step 2 and be somehow available after the browser gets the HTML page in step 4. Um, no. Not the way you’re thinking.

The nitpicky and clever among you will point out that with trickery and by misunderstanding or misconstruing what I’m saying, it’s possible to do those things. For instance, you could use Ajax and DWR to communicate “directly” with Java objects from browser-based JavaScript. True… but not the point. It’s still not like the browser is a Java client communicating over RMI. Nothing like it. There’s a reason I put “directly” in quotes.

But how about that second example? You could stuff a message in a cookie in the response, and re-use that cookie in the results page. Right? Well, yes. Very good of you to notice.

Dreaming up these workarounds implies that you understand HTTP at least well enough to know its limitations and its mechanics. I’m not talking about you, I’m talking about people who just do not conceptually understand an HTTP transaction. And it’s not just at work, it’s not just among Java programmers, I encounter these issues all over the place and on all sorts of platforms.

I can’t really blame the developers, at least the junior ones. The APIs that we work with nowadays to write web apps remove us from the nitty-gritty of HTTP, just as we are removed from the pain of TCP/IP programming. That might be a good thing, but it leaves us with a leaky abstraction.

So what? So I’ve got a little pet peeve of a pattern. Big deal. What else is HTTP gonna get you?

Unless you have even a basic understanding of HTTP, there will be whole classes of vulnerabilities and design flaws in your web applications. You’ll have insecure session management, for starters, and probably cross-site request forgery bugs. I frequently encounter inadequately restricted URLs because of a misled belief that if a link to a page/resource isn’t exposed, that no one can get there.

Note that I wrote design flaws. These are not just developer problems, code-level vulnerabilities. Poor session management often starts with poor architecture and design. Misunderstanding the basic protocol behind the web can contribute to design problems that manifest in broken code.

How do you learn HTTP? Google around. The third chapter from the out-of-print Web Client Programming with Perl is a good start. If you like paper, I highly recommend Chris Shiflett’s HTTP Developer’s Handbook.

Here’s the trick: it’s not hard! Spend just a few minutes to understand the basics of HTTP. You’ll be a better developer, and your apps will be better for it.

del.icio.us links

links for 2007-12-04

del.icio.us links

links for 2007-12-03

Books, Personal

Legal Lit Crit

In the five years between graduating from high school and starting college, I spent a great deal of time immersed in literary theory and criticism. How else was I going to spend all those late nights drinking coffee in dark, smoky coffee houses? Once at college and on my way toward a French degree, I continued to read and work deeply in lit crit. But it began to wear on me. A couple years in, by the time I reached a point where coursework had us diving headfirst into literary theory instead of just dipping our toes, by the time when it became the focus of the program, I had had enough. It had all become just so much BS.

Still is.

Sometimes, though, sometimes, it’s fun to read something like this: “Harry Potter and the Unforgivable Curses: Norm-formation, Inconsistency, and the Rule of Law in the Wizarding World.”

« Prev