KeepItLocked.net : Secure Design, Software Security

Persistent Authentication versus Session Mechanisms

Alex — Thu, 19 Mar 2009 00:50:45 GMT

When you're dealing with users in a web environment, invariably you'll want to know who's who. Because HTTP is stateless, web applications expect some random and difficult-to-guess piece of data with each request that's unique for each user. In most modern web frameworks, this data is stored by the browser as a cookie. This correlates all requests from the same browser with a server-side session, which can be used to stash data relevant to only that user. Let's call these session mechanisms: server-side caches that are mapped through a session identifier. Authentication is handled by checking if the session identifier in the request has been used previously to submit a valid username/password. There is another approach - persistent authentication - which doesn't use a server side cache. Instead of a session identifier, it expects an authentication token. This authentication token is parsed and validated for each request. The value, while it may be difficult to guess, is not random - it's based on the user's identity.

Think of HTTP basic authentication as a canonical example of persistent authentication. The authentication token is a username and password which are Base64 encoded and sent in a request header. This is basically like sending a password with each request - an attacker can simply replay a captured value, forever.

There are a host of homegrown web applications that pass some form of credentials in each request, rather than a temporary, random session identifier. The tell-tale sign is a cookie or hidden field that is the same for each user each time they log in. I've seen this design flaw a few times recently, and it's difficult to patch because it gets so baked into the application code. Here are some of the potential problems with a persistent authentication mechanism:

1) You can't implement server-side logouts effectively, because the token will always be valid.

2) You can't implement server-side session timeouts. Once the persistent authentication token is known, it's good forever.

3) You can't lockout brute force attacks against the persistent authentication token.

4) If someone can reverse-engineer the method for creating an authentication token, you are hosed.

These flaws are a package deal and there's no good way to fix them without changing the entire authentication design. That being said, persistent authentication mechanisms can be more resilient in some cases:

1) Session fixation attacks are less likely because the token is only available to authenticated users.

2) Cross-site request forgery attacks can be made more difficult in some cases. See how the Twitter API uses HTTP basic authentication and prevents CSRF attacks.

Forms authentication in ASP.NET uses a forms authentication ticket - it's a signed and encrypted username, with some extra things thrown in. Forms authentication tickets are not exactly persistent because they time out, but they suffer from one of the same issues - you can't easily invalidate a forms authentication ticket at the server. You can only clear the client-side cookie. Either you have to wait for it to expire or keep a record of invalid tokens. This was described in a Foundstone whitepaper.

Neither architectural mechanism is perfectly designed. However, session mechanisms tend to be more commonly built into frameworks, and thus more vetted, so any sign of persistent authentication should raise a red flag.

Input versus Data, Validation versus Sanitization

Alex — Mon, 08 Oct 2007 20:41:00 GMT

Reading articles, browsing marketing materials, and listening to presentations about application security, you hear variations on a theme:

"Input validation is absolutely critical to application security, and most application risks involve tainted input at some level." – OWASP

While I don't think authors overstate the importance of problems stemming from invalid data, I have noticed these discussions gloss over two key points.

Input validation is only part of the problem. Output validation is important as well.
Validation (in the general sense) has two distinct concerns: validation and sanitization.

Input validation is only part of the problem. Output validation is important as well.

All data input from an untrusted source should be validated. If you enter a blog comment, I want to make sure it isn't empty, it is less than 500 words, and it isn't spam and won't get my readers RickRolled. However, as that data is output from the web application, it should be validated as well. Here's why:

Think about cross-site scripting – we really want to prevent tainted data from exiting the system to the rendered web page on the client. This occurs when the data is output, not input. SQL injection is also tainted data exiting the system (through a SQL query) and parameterized queries are output validation. And since these different validation rules might process the same data (say, a blog comment that is reflected in a subsequent page for approval and then stored to the database), it makes more sense to validate the data upon exit, rather than on entrance.

It's like international air travel – you pass through customs at your arrival airport (output), because at your departure airport (input), they don't know the rules for what's allowed and what isn't.

Thus, I propose that "Data Validation" be used in favor of "Input Validation" as a more accurate (although less precise) term to include input and output validation.

Validation (in the general sense) has two distinct concerns: validation and sanitization.

Validation is a Boolean operation which gives a yes or no answer to the question "Is this data acceptable in the current context?"

Sanitization (which includes encoding, escaping, and stripping) refers to transforming data in some manner so as to make it acceptable in the current context.

These two approaches can be used independently or in concert and the correct way to perform these operations from a security perspective is highly dependent on the context in which they are used.

So validation is (usually) both validation and sanitization.

Another issue which might be brought up in the subject of validation is canonicalization, which is a separate issue that warrants its own future blog post.

Just some food for thought when designing validation mechanisms – it's not all yes or no decisions, and it's not all at the front door.

Experiencing the Rich Web Could Be Costly?

Alex — Fri, 14 Sep 2007 02:37:00 GMT

I attended the Rich Web Experience conference in San Jose last week, along with my colleague Dean Saxe (who was speaking there on AJAX Security and Web Hacking).

I'm not much of a Web 2.0 designer, and some of the talks were lost on me. It reminded me a bit of a web services conference I went to a few years ago, where people were frothing at the mouth about how their <insert buzzword here> library was the end-all, be-all approach and others didn't deserve a second flush. Now, I'm sure if I was involved day-to-day in a Web 2.0 design project, I would be frothing with the best of them. As it was, I was just trying to decipher acronyms and count the number of iTunes, Gmail, and Twitter references.

There was, however, some interesting security conversation. A couple of other speakers, Joe Walker and Douglas Crockford, and Dean and I (well, really Dean, but I tagged along) were invited to a security Birds of a Feather meeting. Among the topics discussed were the prevalence of XSS, the problem with SiteKey and other anti-phishing technologies, and the inherent insecurity of cross-domain mash-ups.

I found the last subject particularly interesting. To me, mash-ups at first seemed a little cutesy and limited, but the more I learn about the RESTful and Semantic Web, the more I realize that we (the web service providers) should all be talking the same language, and talking openly. Of course, this convolutes the current security model of the web.

One interesting question I still don't know the answer to is who makes the trust decisions in a mashup. Do I say which services can talk to each other, and what type of information they can exchange, as a user? Or does the service get to make those decisions? I think fundamental questions like this need to be ironed out. There's plenty of research going on right now about secure mashups. Summing up the thoughts of the similarly-feathered birds at the conference, I can say:

I hope we don't cause more browser divergence.

I hope we don't burden the user with security decisions they aren't prepared to make.

Goofus and Gallant, Part One

Alex — Sat, 01 Sep 2007 01:49:00 GMT

Remember Goofus and Gallant, the kids in the Highlights magazine, that dentist's office staple? Goofus always made the mistakes, Gallant was always perfect. Teaching kids right from wrong.

While trying to explain a simple security problem in a web application, I realized a picture book approach might help get the point across.

This diagram demonstrates "right way" and a "wrong way" to identify users in a web application.

Sometimes we get caught up in details – it's nice to turn a thousand words into a picture.