Jan

31

Software engineering teams everywhere are moving towards, or have already adopted, an iterative style of development, because it creates a number of desirable effects: better time to market, earlier feedback, easier to manage, to name a few.

But what does this mean to the groups they work with? In this, the last of 4 posts, I look at the challenges to the QA team caused by an iterative style of development, and how you can address them. The first post in this series, Challenges in Iterative Development, gave an overview of this style of development, and some reasons why you’d want to adopt it. The second, Iterative Development Challenges Business Stakeholders, reviewed the challenges faced by the customers of an organization moving to an iterative style. The third, Iterative Development Challenges the Data Team, dealt with challenges in the database organization and how you can address them.

Read more

Jan

30

CAPTCHA Cracked

January 30, 2008 | 1 Comment

I wrote earlier in the week about the possible use of something like CAPTCHA to combat Cross-site Request Forgery attacks, and as if by magic, we see the news breaking that CAPTCHA has apparently been cracked by a team of Russian hackers. For a quick recap, CAPTCHA generates images consisting of letters and numbers, then asks the (presumably human) user of a site to enter them in order to verify that it’s a human using the service, rather than a machine.

The argument I made was that you could use something like CAPTCHA to try to verify that requests for certain services (such as check-out, or changing user profile information) was requested by a real user, rather than a javascript program pretending to be human.

The wily Russian(s) in question claim the ability to decode CAPTCHA about 35% of the time, which is probably plenty for most sites. This would probably severely hamper, if not eliminate the usefulness of CAPTCHA as part of the CSRF solution.

Back to the drawing board…

Jan

29

Software engineering teams everywhere are moving towards, or have already adopted, an iterative style of development, because it creates a number of desirable effects: better time to market, earlier feedback, easier to manage, to name a few.

But what does this mean to the groups they work with? In this, the third of 4 posts, I look at the challenges to the data team caused by an iterative style of development, and how you can address them. The first post in this series, Challenges in Iterative Development, gave an overview of this style of development, and some reasons why you’d want to adopt it. The second, Iterative Development Challenges Business Stakeholders, reviewed the challenges faced by the customers of an organization moving to an iterative style. This post covers the data team. Read more

Jan

29

This morning I chased a link over to Dark Reading, and found an interesting article on Cross-Site Request Forgery (CSRF). Some readers may be familiar with Cross-Site Scripting (XSS) attacks. XSS attacks occur when a script on one web page is used to steal session cookies, allowing an attacker to take over an authorized user’s session, for instance.

CSRF is a variation on the theme, where rather than trying to steal sessions or other sensitive information via XSS, the scrips in question simply make requests using the user’s completely valid session credentials. Here’s a human-readable scenario that discusses the technique.

Web browsers and the protocol that they use (HTTP, Hypertext Transfer Protocol) are stateless. This means that when I visit the front page of a popular online retailer, such as Amazon.com, then click on the “books” link, HTTP gives us Amazon.com no built-in mechanism to determine that the two requests came from the same user. It’s as though you were talking with someone by writing them a separate letter for each sentence, and without any sort of indication of who’d written any particular letter. The truth is that the folks that invented HTTP never imagined that it would be put to the types of stateful uses that it is today. Online commerce wasn’t really part of that thought process.

“But wait a minute…” I hear you say, “whizbang.com (fictitious example) does know! Because they can keep track of what’s in my shopping cart!”. So what’s going on here, how do web sites keep track of your conversation? How do they string together each of the clicks you make into a stateful conversation?

A couple of different mechanisms have evolved to do this. The most popular is the use of cookies to assign a unique session ID to each conversation. The server in question makes up a long, random string and sends it to the browser as a cookie. These session cookies are typically set to expire when you shut your browser down.

Cookies, for those unfamiliar with them, are sent from the web server to the browser, and then the browser returns them back to the server as part of each request it sends. Using session cookies to uniquely identify a conversation allows the web server to keep track of the actions you’ve performed using that same session cookie. It’s as though each letter that I send (the letters containing a sentence each, remember?) had the same secret code written in the upper-right hand corner.

There are a few other techniques around to keep track of a session other than cookies, the most popular being URL rewriting and hidden form fields, but cookies are by far the most dominant, so we won’t talk about those here.

So suppose you have an account at the Foo Bank, which is very popular because they offer free network attached storage hardware when you open an account, the modern day equivalent of the free toaster (clearly, this is a fictitious scenario, but it serves to illustrate the point). Because Foo Bank is so popular, I decide to target it. I put together a web site which includes a little javascript program. This program looks through your browser history and determines if you have logged in to Foo Bank as part of your current browser session.

You visit my web page, and my program is downloaded to your browser as part of my web page when you visit my site. The program looks through your history and determines that yes, indeed, you visited Foo Bank and then came to visit my site without shutting your browser down first.

This means that there’s a chance that the session cookie sent to you from Foo Bank is still around, and still valid. My javascript program can make requests to Foo Bank without even showing you a window (yes, they can do that, this is the foundation of AJAX technologies in fact), and determine whether you’re still considered logged in.

Lo and behold, you’re session cookie is still there, and Foo Bank hasn’t logged you out for inactivity. My javascript program can now make requests to Foo Bank using your session, doing whatever I programmed it to do (such as transfer a million dollars to my offshore bank account). I don’t even need my program to access your cookie, because the browser will send it for me automatically.

One of the particularly sinister aspects of this type of attack is that it looks so much like what the application is supposed to be doing, making it particularly difficult for Foo Bank to determine that you didn’t make the request, and for you to prove to Foo Bank that you didn’t make the request. The security term for this is non-repudiation, and CSRF compromises it in a big way.

What to Do

So what can be done about CSRF? One technique is to use “leashes” on a session, tying a session to a particular IP address, or a particular domain. This is an unsatisfying solution, because anyone who’s IP address changes frequently would be forced to re-authenticate when the address does change. Most home users are dynamically assigned IP addresses by the ISP using the DHCP protocol.

Corporate users, on the other hand, are frequently behind a firewall that performs NAT, or network address translation, making it appear that the entire corporate network is really just a few (sometimes only a single) IP address. So this leashing by IP address is unsatisfactory to both ends of the spectrum.

Another approach might be to require something like Captcha, and requiring the user to enter some form of input that allows us to determine if the request is coming from a machine or a person. This is probably a generally useful technique, although it would need to be restricted to interactions where you’re content to exclude machines as one side of the conversation. What do I mean by that?

Well, SOAP, a widely used protocol for Web Services, uses HTTP as a transport mechanism, and since both sides of that conversation are machines, we couldn’t use this technique for all HTTP requests if we want to use SOAP as well. If we restrict ourselves to securing only conversations where we expect one side to be a person, we might be okay.

It’d also be pretty annoying to users if every time they wanted to send information to a web server, they had to enter a Captcha string or the equivalent, so it would be important to use such a technique judiciously, perhaps only at review and check out.

The mechanics of any a particular technique used to address a CSRF vulnerability will therefore depend on the nature of the application you’re building, on an assessment of the risks involved, and on the customer’s tolerance for the contemplated solution. As with everything else related to computer security, it’s the same old continuum: easy to use on one end, secure on the other; you have to pick your point on the line based on an assessment of, and your tolerance of, the risks involved.

Jan

28

I’ve seen the story of a US spy satellite currently in orbit which has “lost power and propulsion” and is set to come crashing down to Earth in the near future.  Some sources are reporting that it’s likely a photo reconnaissance satellite. Both the articles I read mentioned that there’s no way to control the bird now, that we don’t know where it’s coming down, and “it may contain hazardous substances” (as if falling from the sky wasn’t hazardous enough).

The thing I keep wondering is, if it’s so highly classified that we can’t tell you what type of satellite it is, or why and when it lost power, then who’s going to go and make sure nobody looks at it when it crashes (by picking up the pieces, maybe?), and when are they going to know where they’re going to?

Jan

28

I got rather excited about this feature on Applying Unix Philosophy to Personal Productivity over at LifeHacker. I read ESR’s book, the Art of Unix Programming, a number of years ago (it’s still around here somewhere…), but I’d forgotten most of it. As usual, someone’s done a much better job summing up the points in an easy to understand way than I could have.

I think that as developers, we could do ourselves a service by sticking to these points as we set out to develop software. I’ve got a post coming up in the future about keeping it simple, but this is a nice segway.

Jan

28

Software engineering teams everywhere are moving towards, or have already adopted, an iterative style of development, because it creates a number of desirable effects: better time to market, earlier feedback, easier to manage, to name a few.

But what does this mean to the groups they work with? In this, the second of 4 posts, I look at the challenges to business stakeholders (the customers) caused by an iterative style of development, and how you can address them. The previous post, Challenges in Iterative Development, gave an overview of this style of development, and some reasons why you’d want to adopt it. The next posts will review challenges to the data team, and the quality assurance team. Read more

Jan

26

I was talking with a potential client this past week, and one of the things they asked was about the challenges they would face moving to an iterative style of development. I thought sharing my experience with a wider audience might be a good idea. Many development organizations want to move to an iterative style of development. The current darling child in the field is Scrum, XP, or another form of Agile development, but what does it mean, and why would we want to do it? Read more

Jan

25

I’m moving the old Adept Technologies site over to be pages under WordPress.  At the moment, I’ve got all the pages over here, but the old site is still up as well, so it’s a bit weird. Don’t panic, I’m aware it’s like this, and will straighten it out shortly.

Jan

25

There’s an interesting article over at the Washington Post, found via Slashdot, in which we find that the EU is proposing that IP addresses be treated as personal data.

Scharr [Germany’s data protection commissioner] told a European Parliament hearing on online data protection that when someone is identified by an IP, or Internet protocol, address, “then it has to be regarded as personal data.”

I’ve long been a fan of the way the Europe treats personal information. Here in the US, it seems that any information a business collects about me is the property of the business. This includes things like my address, my birthday, my phone numbers, etc.

In Europe, personal information is treated as the property of the person, rather than the business, and the restrictions on what can be done with the information, and how it must be protected are rather more stringent.

It’s going to be a real challenge to treat IP addresses in this category. For one thing, as the article points out, these addresses can (and do) change when addresses are dynamically assigned via DHCP, rather than statically bound to a person.

It’s also going to be a real change of business practices for anyone using IP addresses to track purchases, or otherwise snoop on an internet user. What, for instance, will this mean for your average web site, who’s web server logs are full of these IP addresses, recording where requests came from and what was requested? How will we balance the right of the individual or business providing a web site to manage their services, with the rights of the EU individual to have their IP address secured as personal information?

It’s too soon to see what this means yet, but on the face of it, it looks like the stated goal of the EU is going to be technologically very difficult to achieve.

keep looking »

Blogroll

WP Themes