Poll Time - What One Problem in Web Security Do You Want to Fix?

It is poll time. Doing a little planning and trying to figure out what people view as the biggest architectural weaknesses on the web security wise. I'm mainly focused on things within HTTP and HTML/JS/CSS themselves, not things at the TLS layer.

There is a small poll on the right hand side of the blog. If you have other ideas, pleas stick them in the comments.

A few things I didn't include as I wasn't sure what to do with them:

• Fixing XSS. Change core web protocols/technologies to provide a much cleaner code/data separation. Maybe CSP does this well enough?
• Fixing CA's and how they work. I consider this a related but separate problem.
• Fixing CSRF. It could make the list and there are several options architecturally such as scope-cookies and/or the Origin header.

[UPDATE-1] - I'm interested in fixing to webservers, browsers, core protocols, etc. Not what individuals writing web apps should do to make their own apps more secure. So, for example, fixing Struts/Spring/etc. would be out of scope for this survey.

[UPDATE-2] - The item in the poll for improving authentication is partially about the HTTP protocol, but also about web browser UI, how auth data gets handled in the Chrome, etc.

A quick clarification on HSTS (HTTP Strict Transport Security) policy on non-standard ports

Been having an interesting blog comment and twitter discussion with John Wilander.

He wrote a post and some tweets and even filed a Mozilla bug against the HSTS behavior in FF-4.

I posted this to his blog, but thought I'd post it here too.

Essentially there is some confusion about how HSTS works, and how it rewrites ports. The spec is a little vague (or earlier versions were, I think =JeffH fixed it, and if not, I know for a fact he has it on his To-Do list) on what to do about port rewriting.

A few points.

1. HTTP URIs that don't have an explicit port number default to port-80.

2. HTTPS URIs that don't have an explicit port number default to port-443.

3. A URI can specify a non-default port, and the browser will use the port specified.

When we looked at this in determining the proper behavior of the spec, we had a few decisions to make.

HSTS can transparently convert HTTP to HTTPS, and automatically switch from the well-known port-80 to 443 when enforcing TLS.

When the URI has a non-standard port, there are only two "reasonable" behaviors:

1. Don't force TLS, and access the port with HTTP
2. Use the specified port in the URI, but force-TLS on that socket connection

An unreasonable behavior would be:

3. Use some random port calculation scheme and convert the chosen port to another port via some non-standard port number manipulation/rewrite scheme.

We chose #2 as the desired behavior, because #1 leaks cookies which we specifically don't want to do, and #3 is right out because there is no well-known way to calculate the TLS port that corresponds to any other random "high port".

The only way to guarantee that a host is protected on all ports, and a browser refuses to use a cleartext protocol with HTTP, we have to force TLS upgrade on all non-std ports.

I'll go re-read the spec, and if this isn't clear, will make sure we address it in a new draft.

Presenting at 2010 Web 2.0 Security and Privacy Workshop

Presenting a position paper with my colleague Jeff Hodges.

The Need for Coherent Web Security Policy Framework(s)

More details on the workshop at: http://w2spconf.com/2010/

New Role - Internet Standards and Governance

Not that I expect everyone to watch my job title changes, but I recently made one and figured I'd go ahead and blog about what I'm working on these days.

For the past 2+ years I've been running the Secure Development Program at PayPal. This involves rolling out secure development methodology, tools, training, etc. I've also been doing a fair bit of internal product management for application security features. This was needless to say more than a fulltime job.

In my spare time (yeah right) I've been doing some work on internet governance. Things like working on web browser security policies and frameworks (Strict-Transport-Security was part of that work) as well as broader internet-governance things like working with ICANN, advocating through multiple forums for DNSSEC deployment, etc.

I recently decided that I needed to focus more and despite loving the SDL work I was doing, my overall plans and interests align even more with the internet standards and governance work than they do with SDL work.

So, as of this April I'm now heading up a team responsible for internet standards (mostly security) and internet governance. We'll be focusing a lot on the same types of things above, along with some other things. When asked what my job is I say - "I'm trying to make the internet safer."

As I wrote the other day - I wouldn't have taken on this new role if I weren't at heart either an optimist, hopelessly naive, or crazy. Only time will tell.

I'll be doing most of my posting either here on this blog, or on the one for our broader team over at http://www.thesecuritypractice.com.

More on - freedom to tinker

Ben Adida has an interesting blog post up about freedom to tinker and the iPad. I wrote a comment there in response that I'll post here in case I want to update it further.

Ben laments some of the lack of tinkering/hacking capability in the iPad. I said:

Cars are an interesting comparison technology. It used to be that *everyone* had to be a car tinkerer because they just didn't run right and keep running by themselves. You learned how to do maintenance, how to tweak, adjust, etc. And then we put in catalytic converters and to make sure you guaranteed emissions we stopped you from mucking around with timing, etc. We got rid of carburetors and replaced them with fuel injectors. We got rid of timing belts and camshafts and went to electronic valves. We removed a lot of the tinkerable parts. We killed a lot of the innovation in that space. We also reduced auto pollution a ton and made cars safer.

Was it a good tradeoff? Are there fewer auto mechanics than there used to be because of this? Have we lost something fundamental to our culture and society?

I don't know the answer.

Bank Fraud Detection Must Balance False Positives and False Negatives

Krebs posted this morning about commercial bank customers again and Gunnar also picked up on the theme.

In Krebs piece he quotes the customer saying:

"When I first talked to the bank, my question to them was, ‘We’ve always done the same five payroll transactions a month, this was outside the norm, so why didn’t you flag them?’” Diaz recalled. “They told me because [the thieves] answered the secret questions correctly and because the amount was under $10,000 and their daily limit, they let it go just based on the amount.”

I totally understand that sentiment, but I'd also like to offer up a counter. The negative customer experience that goes along with a denied transaction, and our expectation that our bank should follow our instructions and not second guess us.

A few examples are in order. From the "Mercury News Action Line" this week:

Q: For months, Wells Fargo has been harassing me by putting fraud alerts on routine credit card transactions. Wells Fargo declines the transactions outright and blocks my credit cards.

What do we tell this customer when the bank's fraud blocking is being too ambitious?

Or, how about the wonderful story that Gunnar himself recounts about the ATM network and its distributed nature, and how it just works, and did for Robert Morris Sr.

There is a triple boundary in this town that I was in between Norway, Finland and Russia.But what I did there, was, I had a card about wallet size, I stuck it into a machine, I punched in four digits, and it gave me about 2,000 krone, whatever the hell that is.

So, a guy who isn't usually in Norway puts his ATM card into a machine, and it just works. The bank doesn't throw up a frau alert and say - "WTF, you don't usually take money out from Norway, this must be fraud." It says - "You have the ATM card and passed my security test by knowing the PIN, I'm going to give you money."

My point is that we can't celebrate the ability of an American to take money out of an ATM in Norway and at the same time say that banks should block all transactions out of the ordinary.

Where we strike the balance between false positives and false negatives, and who has the liability for that choice is of course an interesting question, but a one-size-fits-all solution is going to be ugly.