Apps and Security

We Need a Free Browser, Not Just an Open Source Browser

2012-02-18T18:20:00.005+01:00

The security community was chocked when Trustwave came clean and revoked a subordinate root certificate it had sold to a third party which explicitly said it would use it to introspect SSL traffic.

The news of Trustwave's severe malpractice sparked demands for removing the Trustwave root certificates from the Mozilla trust stores (Firefox, Thunderbird, SeaMonkey). The demand was filed as a bug in Bugzilla and the issue has also gotten a fair amount of attention on the Mozilla-dev-security-policy mailing list.

We experienced the same process – Bugzilla + mailing list outbursts – during the recent DigiNotar and Comodo scandals.

Kill or Not to Kill, That's the Question
According to Trustwave they had to sell the man-in-the-middle certificate since other CAs do it. That in itself is extremely worrying. These bastards who've been charging us $$$ for maintaining trust on the Internet. They've not only been negligent in their security operations but also done business selling out the trust built in by all browsers.

So, should Mozilla kill the Trustwave root because of their misconduct? Tricky question.

On the one hand I feel Trustwave's CA business deserves nothing less than the ditch. They did the wrong thing with open eyes.

On the other hand we probably have a large scale problem at our hand – CAs worldwide have been issuing subCA certs that allow employers, governments, and agencies to intercept the traffic we all thought was authenticated, encrypted, and integrity checked. Killing the Trustwave root doesn't fix that.

Think about it. The whole trust model crumbles. Can customers now claim someone else must have manipulated their buy order for the stock that later plummeted? Can payment providers who leak credit cards now claim somebody must have MItMed them? Will the increase in online shopping continue once mainstream media understands and writes about this issue?

Whichever path we take it has to lead to reestablished trust in the CA model. The alternatives such as building on DNSSEC or Moxie's excellent Convergence are nowhere near mainstream roll-out.

But you know what? Democracy and openness seem to work. Mozilla has made the right decision.

CAs world-wide have until April 27 to come clean. Mozilla says the following on its security blog:

"Earlier today we sent an email to all certificate authorities in the Mozilla root program to clarify our expectations around certificate issuance. In particular, we made it clear that the issuance of subordinate CA certificates for the purposes of SSL man-in-the-middle interception or traffic management is unacceptable. We made it clear that this practice remains unacceptable even when the intended deployment of such a certificate is restricted to a closed network.

In addition to this clarification, we have made several requests. We have requested that any such certificates be revoked, and their HSMs destroyed. We have requested the serial numbers of those certificates and fingerprints of their signing roots so that we, and other relying parties, can detect and distrust these subCA certificates if encountered. We have requested that any CAs who have issued subCA certificates fulfill these requests no later than April 27, 2012."

Where else did you see such a clear message to the CAs who have abused our trust? Mozilla makes me proud.

We Need a Free Browser, Not Only an Open Source Browser

The handling of Comodo, DigiNotar and Trustwave tells me we truly need Mozilla and Firefox. Nowhere else in the web community have I seen such openness, freedom of speech, and focus on regular users' interests. Hey, even internet trolls get their say on the mailing list :).

Sure, I love my Chrome, I know Google is a high-paying partner to Mozilla, and I know Firefox has been lagging behind in performance and developer tools. But there's something really great and important in a free alternative.

Speaking of lagging behind ... JavaScript performance and Chrome's V8 have been industry standard for a few years. But when I run the SunSpider 0.9.1 benchmark on my new MacBook Air I get:

Chrome v17.0.963.56: 280.8 ms
Firefox v10.0.2: 233.0 ms

Therefore I would like to urge the Mozilla Foundation to get us tab sandboxing and silent auto-upgrades in Firefox so I can go all-in!

We need a free browser, not just an open source browser.

Stateless CSRF Protection

2012-01-06T17:09:00.005+01:00

In the era of RESTful services and rich internet applications it's important to find security solutions that don't impose unnecessary state or computation on servers. I previously wrote a post on stateless session ids. Let's have a look at how we can protect against cross-site request forgeries (CSRF) without server-side state.

CSRF Basics
Forged requests are nasty attacks. They rely on the fact that your browser automatically adds cookies to HTTP requests if it has cookies associated with the target domain and path. That includes session cookies.

Let's say you're currently authenticated to twitter.com. If you visit another site on another domain that site can issue requests to twitter.com and your Twitter session cookie will be added to those requests.

How can domain B issue requests to domain A, formally doing a cross-site HTTP request? Well, there are some obvious cases – images, JavaScript, and CSS.

<img src="whatever.domain.org/path/logo.png" />

… is allowed from any site, which means a malicious site can contain tags like …

<img src=”https://secure.bank.com/checkAccounts" height=0 width=0 />

Such a tag will issue an HTTP GET to secure.bank.com/checkAccounts including the victim's session cookie for *.bank.com should he or she be logged in. The browser doesn't know if there's an image on that URL or not. It just fires the request. And by setting the image size to 0x0 the victim will see nothing.

CSRF With POST
Most sensitive stuff require an HTTP POST since a GET should be idempotent and not change any state server-side. So can a malicious page issue an HTTP POST to any domain? Yes.

The CSRF code from the image above ($ is jQuery):

<form id="target" method="POST"   action="https://1-liner.org/form">
<input type="text" value="I hate OWASP!" name="oneLiner"/>
<input type="submit"  value="POST"/>
</form>

<script>
$(document).ready(function() {
$('#target').submit();
});
</script>

CSRF Against RESTful Services
But maybe you've left HTML forms behind and go with rich clients, a RESTful backend and communication via JSON? Can a malicious page issue an HTTP POST targeting such services? Yes.

You can change the encoding of HTML forms to text/plain and do some tricks to produce parseable JSON in the request body. Here's an example that I got working with a Java JAXRS backend:

<form id="target" method="POST"  
action="https://vulnerable.1-liner.org: 8444/ws/oneliners"  
style="visibility:hidden"  enctype="text/plain"> <input type="text" 
name='{"id": 0, "nickName": "John",
"oneLiner": "I hate OWASP!", 
"timestamp": "20111006"}//'
value="dummy" /> <input type="submit" value="Go" />
 </form>

Notice the enctype and that the JSON is in the input name, not the value. The above form produces a request body looking like this:

{"id": 0, "nickName": "John","oneLiner": "I hate OWASP!","timestamp": "20111006"}//=dummy

… which is accepted by for instance the Jackson parser.

CSRF Protection With Double Submit
Traditional anti-CSRF techniques use tokens issued by the server that the client has to post back. The server validates the request by comparing the incoming token with it's copy. But that small word "copy" means server-side state. Not good.

Double submit is a variation of the token scheme where the client is required to submit the token both as a request parameter and as a cookie.

A malicious page on another domain cannot read the anti-CSRF cookie before its request and thus cannot include it as a request parameter.

Two Misconceptions About Double Submit
There are two common misconceptions about the double submit CSRF protection.

First, it has been suggested that the session cookie should be used for this purpose. Since you have to use JavaScript to pick up the cookie value and add it as a request parameter the cookie cannot have the HTTPOnly attribute. And you want HTTPOnly on your session cookie to prevent session hijacking via cross-site scripting.

But you should not use the session cookie as anti-CSRF cookie. Instead add a specific anti-CSRF cookie which does not have the HTTPOnly attribute and keep your session cookie protected.

Second, people have stuck with server-generated, stateful anti-CSRF cookies. But double submit cookies can be generated client-side and don't have to be saved by the server at all.

Stateless CSRF Protection with Double Submit
The protective measure of double submit lies in the fact that a malicious site cannot read the cookie and include it as request parameter. That condition still holds if the cookie is generated by the client and never saved by the server.

So let the client generate the anti-CSRF value and only compare and check format of cookie and request parameter on the server. Ergo, stateless CSRF protection!

Hardening the Double Submit Protection
Double submit protection breaks down if the attacker somehow can read or set the anti-CSRF value. We can harden double submit against malicious reads.

First of all we make the client change the anti-CSRF value upon every request. This is typically done by centralizing backend calls to a custom AJAX proxy, possibly inherited.

Second, we zero the anti-CSRF cookie directly after each backend call. This will allow for accurate server-side detection of forged requests. A zeroed double submit cookie is a clear signal of either a client-side bug or a forged request. With zeroed anti-CRSF cookies the attacker has to issue his/her attack to exactly when the cookie is set by the client.

Drawbacks of Double Submit
You typically hear two drawbacks of the double submit protection – it's reliance on JavaScript to add the cookie value as request parameter, and the possibility to read the anti-CSRF cookie via cross-site scripting.

The issue with JavaScript is diminishing as JavaScript is becoming a requirement for more and more sites anyway.

The cross-site scripting critique is invalid. If you can script the site you already own all of it and can setup your own AJAX proxy, read any tokens in the DOM etc.

The Anatomy of a Twitter Storm

2011-12-17T19:38:00.006+01:00

Hi! I'm @johnwilander and yesterday I unwillingly created a Twitter storm.

#GodIsNotGreat and Twitter Trends
It was Friday afternoon in Stockholm, Sweden and I came across a tweet with the interesting tag #GodIsNotGreat. Earlier that day I had read about famous atheist and writer Christopher Hitchens passing away but there was something else going on around this tag. In the tag stream I read about christians threatening tweeters using the tag and several claims that Twitter had pulled the tag from the trends list.

I couldn't find the tag in my trends list nor in the US or European list. Still, tweets with the tag were pouring in. In the stream I found a tweet from @HillyFoz saying:

"So Twitter, it's ok for #reasonstobeatyourgirlfriend to trend but you saw fit to put a stop to #GodIsNotGreat ?"

Apparently #ReasonsToBeatYourGirlfriend had been a trend. Now that's interesting too. So I wrote The Tweet what would become a Twitter storm:

As you can see in the screenshot, numerous people eventually retweeted this.

I could see the amplification within a minute. Suddenly around 10 people had retweeted it and new retweets where being reported faster than I could open them on the activity tab.

At this point I reviewed my tweet and saw that I had claimed something I couldn't back up with a source or a reference. Such things make a about-to-be-PhD blush a little :). Soon enough I started to get complaints. I considered deleting the tweet but decided to let it live on to see what this storm would be like.

Here Come the Trending Bots
Time for the first bot to spot me. Apparently I was trending in the UK:

While the retweets, complaints and comments were pouring in I quickly became a trend in USA and Canada too:

About 30 minutes later the spam bots had caught on and I started getting all kinds of weird stuff. Some of them I couldn't tell if they we're real people or bots. For instance this (not even a reply to my tweet):

I did not respond :).

The final bot step was when the @favstar50 bot congratulated me to my first 50+ favorited tweet.

Trying to Find a Source
Some of the complaints I got where getting nasty so I thought I might be lucky enough to find a source and patch my earlier tweet. UK online paper Huffington Post gave me at least half an excuse as they wrote:

"The hash tag #GodIsNotGreat also began trending, which was followed by a storm of protests by the religious, many unaware that the hash tag was a tribute to the author's passing.

Twitter reportedly removed the topic from the trending lists following threats of violence towards the creators of the hash tag. The irony that Hitchens book, one that makes stark the link between religion and violence, had stirred the religious to then threaten violence was not lost on the twitterati."

But my antagonists quickly dismissed Huffington Post as a bad source and also pointed out that they said "reportedly" which I failed to do in my 140 chars. So much for the patchwork.

The Day After
When I got up Saturday I checked my email. Well ...

I had got quite a few new followers. Woot! But I guess most of them will unfollow when I go back to tweetin' about JavaScript and application security. Easy come, easy go, huh? Note the browser tab for Twitter with 19 new notifications that dropped in while I was taking the screenshot.

I checked my Klout score:

It looks like the revenue diagrams Uncle Scrooge has on his wall :).

Later I found out that Gizmodo had written an article about it – Shutup, Twitter Isn't Censoring Your Dumb Trends. There, in the middle of their bashing was my tweet! Luckily, Gizmodo didn't dig out the source but rather took poor Jessica K's commenting retweet as an example. Phew.

Lessons Learned
My lessons learned:

I should probably check the sources of every tweet, not just my tech tweets.
Rumors spread extremely fast on Twitter. As long as the message is interesting, people retweet.
Twitter trends are not based on volume, they're based on derivatives, or speed if you will. If the increase of the #GodIsNotGreat tag would have been steady it would have still been a trend. But it wasn't.

REST and Stateless Session IDs

2011-04-09T18:45:00.008+02:00

Nowadays there's a general reluctance to introduce (more) server-side session state because of scalability. And there's specific reluctance to session state in RESTful web services, due to design principles.

In the stateless requirement of REST we read:

"The client–server communication is constrained by no client context being stored on the server between requests. Each request from any client contains all of the information necessary to service the request, and any session state is held in the client. The server can be stateful; this constraint merely requires that server-side state be addressable by URL as a resource." [Wikipedia]

This is a tough requirement, especially if we want features such as authentication and sessions.

So, can we have session ids without server-side session state? Yes.

The Relation Between Sessions and Authentication
There's often a tight relationship between authenticating users and holding their sessions. Anonymous sessions are not very sensitive whereas authenticated sessions have to be protected against hijacking, fixation, forging, and replay. Actually, a valid session token authenticates the session, so you're basically authenticating yourself every request. Which leads us to the first stateless session solution ...

No Sessions => Authenticate Every Request
If session ids are in fact authentication tokens we might as well use the mental model of no sessions, instead authenticate each request. The old HTTP Basic Authentication does this by storing your username and password for subsequent requests. But there are more advanced versions such as authentication in Amazon's S3 REST API.

They use a custom HTTP scheme based on a keyed-HMAC (Hash Message Authentication Code). To authenticate a request, you first concatenate selected elements of the request to form a string. You then use a shared "AWS Secret Access Key" to calculate the HMAC of that string, i.e. you sign the request. Finally, you add this signature as a parameter of the request.

GET /photos/puppy.jpg HTTP/1.1
Host: johnsmith.s3.amazonaws.com
Date: Mon, 26 Mar 2007 19:37:58 +0000

Authorization: AWS 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

Looking deeper into how this scheme works you find the following spec:

Authorization = "AWS" + " " + AWSAccessKeyId + ":" + Signature;

Signature = Base64( HMAC-SHA1( UTF-8-Encoding-Of( YourSecretAccessKeyID, StringToSign ) ) );

StringToSign = HTTP-Verb + "\n" +
________Content-MD5 + "\n" +
________Content-Type + "\n" +
________Date + "\n" +
________CanonicalizedAmzHeaders +
________CanonicalizedResource;

Canonicalization of course requires some processing such as converting headers to lower-case and sorting them lexicographically. The date works as a timestamp and narrows the replay window.

The server then does the same signing with the shared secret associated with the AWSAccessKeyId. So we're switching from server-side session state to more cycles and latency on both client and server.

Worth noting:

Signed requests are much stronger than mere session ids. Cross-site request forgeries will be mitigated with this scheme.
By authenticating all requests with a shared secret we don't have any time-bound sessions or timeouts. Just fire whenever you want.
The persistent shared secret is much more sensitive than a temporary session id. A cross-site scripting attack will steal the shared secret which is much worse than session hijacking. This means the scheme is less suitable for browsing sessions and more suitable for machine-to-machine communication.

Stateless, Hashed Session ID and Salt
The server can generate session id cookies by hashing usernames and a random global salt:

sessionIdCookie_v1 = username ":" SHA256(username + global salt)

The salt is used for all sessions but only valid for a certain timeframe, say 15 minutes. A new salt is produced every 5 minutes and incoming session ids produced with the previous but still valid salt will be exchanged for a new session id with the fresh salt. That means a session timeout of 15-5=10 minutes.

If we truly want to go stateless we cannot kill such a session since that would require a server-side table of revoked session ids. So in the stateless case an attacker will have a 15 minute replay window in which he/she will refresh the session and have endless access.

Stateless, Encrypted Session ID
By just storing a server-side symmetric crypto key we can effectively decrypt incoming session IDs and trust their contents. Imagine a cookie based on:

sessionIdCookie_v2 = AES_GCM(128 bit key, auth tag, username + timestamp)

This means we don't have to store each session ID. Instead we pay the price of decrypting incoming cookies and checking that the timestamp is within a timeframe, say 15 minutes. For all incoming session IDs older than 5 minutes we regenerate a new cookie to effectively run a 15-5=10 minute session timeout window.

Again, if we want to go stateless we cannot kill such a session since that would require a server-side table of revoked session ids. So an attacker will have a 15 minute replay window in which he/she will refresh the session and have endless access.

Conclusion
There are three competing parameters to prioritize between:

Server CPU cycles per request
Server-side session state
The replay window

The tradeoff between CPU cycles and memory footprint will change with new technologies such as non-blocking IO in node.js. So yesterday's best practice might not be valid today.

The difference between regular session hijacking and hijacking of stateless session ids is that successful theft of a stateless session id authenticates the attacker even if the victim has logged out. Remember, the server doesn't store the session state. And even if the server would store the boolean isLoggedIn for each user, an old session id will still be valid if the user logs in again, as long as it hasn't timed out.

So ask yourselves what your tradeoff between CPU cycles and server-side state is. Then consider the replay+refresh leverage of a successful cross-site scripting attack.

Friday JavaScript & Web Dev Links

2011-04-08T13:23:00.002+02:00

I'm summing up some reading tips for JavaScript and web development. Just thought you'd like 'em.

JavaScript

Command-Line JavaScript on Rhino
So you want to write command-line JavaScript on Rhino? Here's how you do it on Mac OS:

Download Rhino 1.7R2: http://www.mozilla.org/rhino/download.html
Unzip Rhino in for instance Applications/Utilities/Java
Download JLine: http://jline.sourceforge.net/
Unzip JLine in for instance Applications/Utilities/Java
Move jline-0.9.94.jar to /Library/Java/Extensions
In a shell: cd /Applications/Utilities/Java/rhino_1_7R2
In the very same shell: java org.mozilla.javascript.tools.shell.Main

Code away!

Building Large-Scale jQuery Applications

A good read on RIA architecture and links to lib and framework choices, not only for jQuery junkies:

http://addyosmani.com/blog/large-scale-jquery

JavaScript Primitive Types Becoming Objects

About JavaScript's primitive types and how they become objects when their properties are used:

http://javascriptweblog.wordpress.com/2010/09/27/the-secret-life-of-javascript-primitives

Scoping and Hoisting in JavaScript

If you haven't looked into scoping and variable assignments in JavaScript, read this and improve your programs:

http://www.adequatelygood.com/2010/2/JavaScript-Scoping-and-Hoisting

'String'.replace() Only Replaces First Instance

String.prototype.replace, i.e. 'yourString'.replace(), only replaces the first instance of the regexp. So beware. Twitter made the mistake and got vulnerable because of it. Read about it and a suggested patch:

http://www.thespanner.co.uk/2010/09/27/string-replace-javascript-bad-design

Non-Blocking JavaScript Loading (and more) With head.js

With Head JS your scripts load like images - completely separated from page rendering, and in parallel!

http://headjs.com

Web Development

RESTful Design, Patterns and Anti-Patterns

A nice webcast on REST design. For instance brings up the idea of session ids with constant state on the server. But as always, I wonder when the CSRF storm is going to hit all these REST services out there?

http://www.parleys.com/parleysserver/indexing/presentation.form?id=1397

Chrome Web Dev Extensions

Google Chrome is becoming many web developers' favorite browser. The bundled developer tools are good. But check out the extensions too, for instance the CSS reloader:

https://chrome.google.com/extensions/featured/web_dev

iframe Loading Techniques and How They Affect Performance

Want your iframes to stop blocking and allow onLoad to fire earlier? Check these techniques out:

http://www.aaronpeters.nl/blog/iframe-loading-techniques-performance

Did I miss a good resource or read? Just fire away below.

The new security features in Firefox 4

2011-03-24T10:31:00.000+01:00

The new security features in Firefox 4.

Content Security Policy (CSP). This is completely new opt-in security innovation and it's among the first to address the Internet plague called cross-site scripting (XSS). Currently Firefox 4 is the only browser supporting CSP but Webkit browsers (Chrome and Safari) are developing their own flavor. The feature lets the developer specify a whitelist of source domains for JavaScript, images, media, and styling. The servers passes on the whitelist policy in a response header and the browser then enforces the policy for all subsequent resource loads when rendering the page. CSP also demands that all JavaScript code be loaded from files and not be inline. Since XSS attack code typically is either from a domain not on the whitelist or inline, the browser will not execute it if CSP is enabled. Coming up with the correct whitelist and moving all your JavaScript to files will be a burden on developers so adoption will take time. Twitter has already deployed a CSP on mobile.twitter.com and will enable it for twitter.com after a trial period (http://engineering.twitter.com/2011/03/improving-browser-security-with-csp.html).

HTTP Strict Transport Security (HSTS). This is also a policy mechanism. It allows developers to tell browsers that this domain should only be accessed over SSL and the certificate may not cause any browser warnings. The policy is again sent via a response header so you would think it could be included in CSP. But there is a crucial difference. HSTS also specifies a time for how long in the future the browser should enforce it. After all the policy directive is about future requests. So the browser caches the HSTS policy for a whole domain and possibly for its subdomains which is fundamentally different from CSP which applies its policy to each page individually and allows a new policy on every request. PayPal have been one of the main contributors to HSTS and have deployed a policy for some time. HSTS is already supported by Chome and the Firefox plugin NoScript.

X-Frame-Options (XFO). Again, a response header security directive, originally a Microsoft innovation. It specifies whether the page should be allowed to be framed by another page or not. As such it's a partial countermeasure for clickjacking. But it really shouldn't be presented as such, rather a non-framing option for developers.

ES5/JavaScript Strict-Mode. Another Firefox first. JavaScript, formally named EcmaScript, is evolving and in version 5 there is an opt-in "strict mode" which gets rid of many of the nasty things in earlier versions. Attackers love the old oddities whereas developers hate them. So we can probably look forward to a fairly good adoption rate out there as soon as other browsers implement it (current statushttp://kangax.github.com/es5-compat-table).

Do-Not-Track (DNT). This is a privacy feature requested by the US Federal Trade Commission and jointly designed by Stanford Security Lab and Law School. It's an opt-in request header, i e sent by the browser not the server, which specifies that the enduser doesn't want to be tracked. This is of course a major issue for advertise-driven companies such as Google and Facebook who earn money on tracking endusers and serving them in-context ads. Security professionals are arguing that nobody will be able to know if they've been tracked anyway so we'll probably have to wait for large enduser adoption and a public lawsuit on some major company before DNT starts to mean something.

The 5 Complexity Dimensions of Software

2011-03-21T18:17:00.002+01:00

I've used this image on countless occasions in my talks on software and on application security. I got it from an academic research presentation back in 2004 or so.

The 5 Complexity Dimensions of Software

Complexity in this regard means complex for humans to understand and contribute to.

Scale. The larger the system, the more complex.
Diversity. The more frameworks, languages, integration techniques, tools, platforms, and design patterns used, the more complex.
Connectivity. The more connections, the more complex. This relates to coupling.
Dynamics. The more number of states or the larger state space, the more complex.
Refinement. Over time every living piece of software is refined, optimized, and polished. Corner cases are found and handled, and regression test suites grow. Refinement drives complexity.

In the context of application security there's always a relation between security and complexity. The more complex a system gets, the higher the risk of security vulnerabilities. Therefore managing application security is partly about managing the five dimensions above.

Sadly, computer science undergraduates rarely meet or learn about this kind of software complexity. That's why industry is reluctant to hire them. Solving 100 coding assignments comprising 200 lines of code each, just doesn't equal developing a system of 20,000 lines of code.

Tomorrow I will give a talk on why and how CS undergrads at Linköping University should learn about software complexity.

A Client-Oriented OWASP

2011-03-01T01:56:00.004+01:00

Right now there are tons of thoughts, ideas, and discussions on where OWASP should go. I'm beginning to see an image of a Client-Oriented OWASP (thanks Dinis, for finding the word). In that image there are great initiatives as well as a few things we have to set straight.

Current New Initiatives
A few samples of the thoughts going around: Jeff Williams sent his OWASP 4.0 email, I wrote about the gap between appsec and developers, Mark Curphey wrote about OWASP reaching a tipping point, and Michael Coates wrote about a vision for OWASP.

Since then Michael started the Defenders Community and I started the Developer Outreach Initiative which will become the Builders Community shortly.

Client-Oriented Part 1 – Builders and Defenders
If you combine the Defenders and Builders initiatives, a new, more client-oriented OWASP emerges. Client-oriented in the sense that we put more effort into understanding and helping the IT industry who builds, operates and maintains web applications. On the less technical side we're doing this already with processes and guides – great!

But on the more technical side, OWASP needs to mix up the pentesting and appsec tooling with how to defend and how to build secure webapps. And that for me means Builders and Defenders projects but also gearing our conferences and chapters more towards builders and defenders.

I'm not saying we should cut down on pentesting or scanning tools. I love pentesters and ethical hackers. Heck, I read and retweet your blogs daily. I'm also very interested in static analysis tools, proven by my publications in the area in 2002 and 2005. I'm just saying we need to address a larger crowd and get more balance into our efforts.

Client-Oriented Part 2 – Dealing With Independence
"Our freedom from commercial pressures allows us to provide unbiased, practical, cost-effective information about application security." —About OWASP

Independent or unbiased has two parts in my opinion:

OWASP should be independent in the statements it publishes, all the way from chapters to the board.
OWASP should not avoid certain projects, results, or discussions only because some individual/corporate member or sponsoring organization will be upset.

Right now I think OWASP is doing fine on number one. I hear no bashing nor promoting of brands or vendors except for publicly thanking them for their support. Thank you supporters!

But number two is worrying me. At AppSec NYC 2008 there was a talk on comparing static analysis tools called "NIST and SAMATE Static Analysis Tool Exposition" (video). Some well-known brands were in the study. But the speaker refused to show figures for individual tools. There seemed to be a consensus in the community that we should not present anything that could be interpreted as negative for certain vendors, not even if the test setup was made totally transparent. That's a violation of point two above, in my opinion.

2.5 years have gone and we're still not using our independence to compare and test appsec tools. Why? John Steven, an OWASP leader with immense experience in static analysis has published serious obstacles to comparing static analysis tools but they are all saying "Just don't make your tool choices based on a general comparison" which is good advice. We should tell people that. But we still need to start putting appsec tools to the test.

Creating the Client-Oriented OWASP means we'll have to start doing independent, client-oriented research. And if OWASP has been implicitly silenced before I will not take it anymore. Here's a list of ideas:

Commit to Stefano Di Paola's brand new OWASP Myth Breakers Project.
Create a space for customer comments on appsec tools (free as well as commercial). Something like AppStore reviews, good and bad.
Start to compare blackbox and whitebox scanning tools. I suggest we go for a synthesized testbed (i.e. a controlled environment) and invite tool vendors/builders to take part. They get a workday to configure their tools and then we go. The testbed, configurations, and versions will all be published along with due reservations such as John Steven's.
Start to organize free pentests and design reviews of open platforms. In the best case we cooperate, in the worst case we make our information public in an ethical way to help clients make the right choices.
Sign the Open Letter to WebAppSec Tool and Services Vendors: Release Your Schemas and Allow Automation

Let's Get the Outreach Started

2011-02-23T21:08:00.000+01:00

The developer outreach mailing list now has 52 subscribers. And we're starting right now. Here's the plan in which you can join directly.

Reach out to developers you know or work with, asking what their security itches are. A two week first iteration, so "deadline" is March 10. Whatever you get back you can dump to john.wilander[@]owasp.org and I'll organize it. Please ask developers:

1. Years in software development:

2. Programming languages most used:

3. What are your software security itches in design & code (not working, too complex, can't find it etc):

(And please make sure we don't taint this by asking ninja security guys. ;)

Developer Outreach Initiative

2011-02-22T01:24:00.002+01:00

Today I sent out an email to hopefully kick start OWASP's developer outreach. Recipients were an interesting mix of developers and appsec experts. If you want to join us just subscribe to the Developer Outreach mailing list.

Here's the content of the initial email:

The Problem

The web is developing at great speed and I love it. But when I read that the average website has nearly 13 serious vulnerabilities I get sad [1]. It's hindering us from doing more stuff on Internet. Douglas Crockford even suggested we scrap the current HTML5 spec and fix cross-site scripting first [2]. We have a problem.

Developer Outreach

I'd like to get rid of those 13 vulnerabilities per site and I'm convinced designers and developers of web frameworks and applications are the ones who can make it happen. We just have to get the right things into their toolboxes. This has been called "developer outreach" and currently it's a failure.

Proposed Solution – Security Itches

My first proposition is this: Instead of pushing coding guidelines and security tools onto developers I think we should start by asking them "What are your security itches?". Whatever we get back will be our starting point. Maybe we'll pick ten itches and publish good solutions.

What if they have the *wrong* itches? Well, the goal of the outreach is 1) to find out what developers think, and 2) address their itches to build some well-needed credibility. Before we have credibility we cannot push coding guidelines. And if developers think SSL certs are their primary problem that *is* important.

Proposed Solution – Open Test Data

Security people tell developers to "do input validation". Input validation is no news to developers. The problem is defining the data model and testing the input validation. We can do something important here – building opentestdata.org. I own the domain and dream about the following beautiful community effort:

You go to the site and can either "submit test data" or "download test data". On the submission page you can anonymously enter e.g. a Portuguese postal address, an Indian human name, a Swedish postal/zip code ... or 100 SQL injection strings. The effort is almost zero.

On the download page you choose your format and download in context. "We have European customers so we want European human names, postal addresses, and phone numbers". Developers will love it. And that's where we can start promoting security testing!

Questions for You

First question – do you like these ideas? Are they the right way forward? Would you like to be part of making it happen?
How should we ask for security itches? And how do we collect answers? Email? Remember we'll probably get one-liners as well as small essays.
How do we get the test data site flying? App and infrastructure? Auditing à la Wikipedia with a couple of dedicated moderators?

References:

[1] https://www.whitehatsec.com/home/assets/WPstats_fall10_10th.pdf

[2] http://blip.tv/play/g_MngeaxVgI (jump to 20:55)

Fears & Hopes for OWASP

2011-02-13T21:31:00.000+01:00

As I leave the OWASP Summit 2011 in Portugal several questions and thoughts are tumbling around in my head. Is the Summit format the right way to do productive conferences? Are we becoming a paperware organization? Will the right people run for the board considering all the formalities? Is the appsec community failing because of an attitude problem towards developers?

I don't like long blog posts so I have split it up. Here's the menu:
1. New OWASP Board – My 10 Questions
2. Security People vs Developers – Does OWASP Have an Attitude Problem?
3. OWASP Paperware Project – Will Non-Code Projects Take Over OWASP?
4. The Summit Is the Right Direction

The OWASP Summit Is the Right Direction

2011-02-13T21:28:00.000+01:00

I was on the organizing team for the OWASP Summit 2011. Not as deeply involved as Sarah, Dinis, Lorna, Jason, Deb, Sandra, and Paulo ... but I did organize the four Browser Security sessions.

I truly believe that the Summit format is the way OWASP conferences should go. We should not try to compete with Black Hat, Defcon, BSides or whatever conference out there. We should do something different, geared towards productivity.

Below is how I setup the browser security track and my humble suggestion for making a difference:

1. Prioritize People when Planning
The success of your session boils down to people. If you're at a workshop and "the guy who has all the answers" is not there the workshop is not going to be productive. So my overall goal was to get the right people there. However, you cannot start by inviting people, you only need to start with it as your top priority.

2. Build a Draft Agenda
To be able to successfully invite the right people I had to have a relevant draft agenda. So I spent a weekend watching various webcasts of talks from the people I wanted to invite. From that I built my draft agenda. I basically adopted their agenda and tweaked it with some personal stuff.

3. Reach Out to Key Players
Now that you have a draft agenda you can reach out to key players you already know and that are likely to say yes. Ask them what they think of the draft agenda and more importantly, ask if they would consider co-chairing a topic or two. Get their names up there.

4. Market Your Heroes
When you have a first couple of key players onboard it's time to get the buzz started. Tweet about it. Blog about it. Talk about it. And make use of the heroes who are already booked.

5. Reach Out in Waves
Now you need to get key players onboard that you did not previously know. It's time consuming so I do it in waves. A good weekend with the right inspiration you can hunt down a few more of the people you need to get there, explain the agenda and who else is going. Make use of your network and CC people who might be able to vouch for your workshop. As soon as you get people hooked ask if they want to be involved.

6. Have Faith
A lot of the so called key players are very busy. You may have gotten a confirmation four weeks ago but not heard anything since. Just make sure you send them updates every other week anyway. They'll come. Have faith.

7. Work Onsite
At the workshop you need to tend to practical stuff. I think I was the only session chair who cleaned all the tables up on stage before my sessions. Fresh blocks of paper, new water glasses, no garbage. Also make sure you have an announcement up on the big screen and walk around reminding people that it's only 10 minutes to you session. Do not underestimate what this kind of lightweight service can do for your session.

Another OWASP Paperware Project, Anyone?

2011-02-13T21:25:00.000+01:00

Summing up the OWASP 2011 Summit I fear OWASP is becoming more and more paperware and less and less software. On the Summit's fixed schedule we had 15 technical sessions and 27 non-technical sessions (my interpretation). That's almost two thirds non-tech.

The only guys I saw actually coding at the summit were people we had invited and that are not OWASP leaders (Powerpoint slides with code do not qualify as coding). At the same time OWASP is getting desperate about not reaching developers.

The solution is in my opinion to cut down on paperware, pdfs, Powerpoint presentations, guidelines, and policies. Developers want code, not Word documents. I tried to bring this up during the OWASP Secure Coding Practice session but failed to convey my view. Who would have thought a coding guide did not contain code?

If you hand a document to a developer that says "Do canonicalization" you will not get canonicalization in the application. But if you hand a developer code snippets in a relevant language that show a couple of instances of canonicalization problems and how the solution could look you will get a change.

So, why do we still have all these guidelines and policies that talk about code? I believe the reason is that the authors don't know how to program. Guys writing appsec guidelines typically cannot code themselves and developers can smell it a mile away.

Do you believe OWASP needs to reach developers?
Are you right now working in a word processor rather than an IDE?
Stop!

Developers believe in other developers and working code. You want to change how they play? Get in their game.

Security People vs Developers

2011-02-13T21:11:00.003+01:00

"Developers don't know shit about security". That may very well have been the most retweeted quote from the 2011 OWASP Summit. I heard it from stage firsthand and I wrote the original tweet about it, adding "Well, I got news. You don't know shit about development".

I truly believe this is one of OWASP's biggest problems. I hear it all over the place – frustrated appsec people claiming that developers and managers are ignorant, lazy, or untrained since they don't prioritize security. But it's we, the appsec people who are ignorant, lazy, and untrained! And that's why we're failing in developer outreach. We keep going to our own conferences, pushing Powerpoint slides, discussing unsexy web 1.5 code, and still think we're on the top of the hill. We're at the bottom, guys!

I've done surveys with 200+ developers to figure out how security is prioritized. In general, this is the picture:

Software Priorities According to Developers

Functions and features as specified or envisioned
Performance
Usability
Uptime
Maintainability
Security

When I tell appsec people this they typically go "Yeah! See, that's the problem. We should be much higher on that list!" No. No, no, no. We belong at level six and unless we appreciate and understand how security fits in with functions, performance, usability, uptime, and maintainability we will keep being ignored by developers.

Why? Well, a featureless system is useless. A security feature that hits performance notably is out. A system with poor usability will bring no business so usability is above security. "Uptime, hey that's a security thing!" No. Just because DoS attacks hit your uptime doesn't mean we own the issue. Many things affect uptime such as release and deploy cycles, maintainability, caching, scalability, configuration, and patching (no, not just security patching). Finally, maintainability affects ROI much more than security in the general case. Thus, security == level six.

Appsec friends, let 2011 be the year where you go to training to learn what's important in software and where security fits in the big picture. Then we won't hear anymore jokes on ignorant developers in 2012. Instead we'll be humble and get things done.

New OWASP Board – My 10 Questions

2011-02-13T21:07:00.003+01:00

At the OWASP 2011 Summit I attended some of the sessions on OWASP Bylaws and OWASP Governance. I agree we need to update and define roles and duties but there are more urgent issues.

Discussing the board is complicated if you're not natively English speaking. Asian, South American, and European OWASPers tend to know English appsec terms but they do not know the nuances in what's being said about governance. This effectively means only English speaking people will define how OWASP should be governed and mainly English speaking people will run for the board. Today the board consists of 4 Americans, 1 Irish, 1 Portuguese living in London, and 1 Belgian. That is neither representative nor good for OWASP.

I'd like to see the OWASP board grow more diverse. Therefore I will ask the questions below to the members who run for the board. Note, this is not a requirements list, rather parameters I'd like to see diversity in.

Which human languages do you speak?
In which parts of the world have you lived at least 3 months?
Have you shipped production code? How long ago?
Please provide a list of web technologies you consider yourself proficient in (markup, styling, scripting, server-side code, server configuration and operational setup ...)
What is your typical appsec role (pentester, trainer, developer, project manager ...)? Are you a consultant, vendor, or do you have an appsec role within an organization?
Please provide a list of appsec activities you consider yourself proficient in (code auditing, threat modeling, SDLC implementation ...)
Have you run or are you running an OWASP chapter? Which?
Have you run or are you running any OWASP projects? Which?
Do you have a college or university degree? (No requirement, I just want the right mix)
Do you have a postgraduate degree? (I'd like to have at least one on the board)

There are no correct or preferred answers to the questions above. I only want to ensure we have people from as many parts of the appsec community as possible. For me that's more important than knowing all the English terms in our bylaws or policies.

65,000 New Jobs in Sweden 2011

2011-01-27T15:25:00.000+01:00

Sweden is in a better economic and fiscal shape than most other OECD countries, says OECD. That situation means labor demand is growing and The Swedish Public Employment Service today announced its predictions for empoyment in 2011.

"A total of 65,000 more are expected to get jobs during the year and the number of occupations where there is a shortage of labor is increasing steadily. Most difficult for employers to find staff will be in the computer professions, engineering professions and construction trades because there are too few trained."

Here's their press release in Swedish. You can translate it with Google.

If you have IT skills – welcome to Sweden!

Countdown Challenge for OWASP Summit

2011-01-26T13:27:00.000+01:00

The official OWASP Summit Challenge is out – a JavaScript fighting arena where your script should show its name more prominently than its competitors. The first round attracted 8 contestants and "dross" scored the first point. Check out all the scripts and the next round of competition: http://makeXORbreak.com

The challenge starts the countdown to one of the most important meetings in application security history. February 8-11 we invite you all to join round-table discussions with industry and research leaders on how to solve XSS and enhance browser security, which appsec metrics work, security of HTML5 and EcmaScript 5 and more. We truly believe that crucial things can happen in a social, productivity-oriented environment. That's why OWASP is going all-in on the Summit.

Google will be there. Mozilla will be there. Microsoft will be there. Facebook will be there. PayPal will be there. Apache will be there. The world's top appsec companies will be there. The authors of (my) favorite appsec books will be there.

OWASP Summit 2011

Best thing of all? You are most welcome to join!

Running Civ IV on HFS+ Case-Sensitive

2011-01-07T01:47:00.005+01:00

This post is completely unrelated to application security but since I struggled for two hours not finding my specific solution anywhere I just though I'd post ...

How I got Civ IV working on my Mac OS X with case-sensitive file system (HFS+ case-sensitive).

The basic trick is to create a new case-insensitive disk image using the disk utility tool in /Applications/Utilities. Do it with the following specs (taken from this blog post):

Name: caseinsensitive (or any other lower-case name of your liking)
Size: Custom 30 Gb (it will only use up the space you need anyway)
Format: Mac OS Extended journaled (i e not case-sensitive)
Encryption: None
Partitions: No partition map
Image format: Sparse bundle disk image (this makes sure you only use the space necessary)

Now you uninstall Civ IV from your regular drive (most probably from /Applications) by deleting these folders and files:

"Civilization IV Gold" folder which contains the game applications
"home folder\Documents\Civilization IV" folder
"home folder\Documents\Civilization IV Warlords" folder if you have Civ IV Gold Ed.
"home folder\Library\Application Support\Civilization IV" folder
"home folder\Library\Application Support\Civilization IV Warlords" folder if you have Civ IV Gold Ed.
"home folder\Library\Preferences\com.aspyr.civ4.plist" file
"home folder\Library\Preferences\com.aspyr.civ4warlords.plist" file if you have Civ IV Gold Ed.

Then you install Civ IV from your DVD to the newly created disk image named "caseinsensitive". I additionally created a folder structure on the new disk image using these shell commands (don't know if they're needed):

mkdir /Volumes/caseinsensitive/Documents/
mkdir /Volumes/caseinsensitive/Documents/Civilization\ IV
mkdir /Volumes/caseinsensitive/Library
mkdir /Volumes/caseinsensitive/Library/Preferences
mkdir /Volumes/caseinsensitive/Library/Application\ Support
mkdir /Volumes/caseinsensitive/Library/Application\ Support/Civilization\ IV

Finally you just start Civ IV from the new disk image. Happy gaming!

Java regexp for Unicode letters

2010-12-13T10:02:00.000+01:00

Just to get this out there ...

Java regular expression for matching all Unicode letters:
Pattern p = Pattern.compile("\\p{L}*");

Chrome Behavior Confirmed, FF Checked With HSTS Add-On

2010-11-27T13:15:00.003+01:00

Both Google and Mozilla have been very responsive in the discussion on HSTS behavior for non-default ports.

Chrome Behavior Confirmed
Adam Langley from Google confirmed that Chrome doesn't enforce HSTS for non-default ports:

From the write up you appear to be using a non-default HTTP port
(8080). That doesn't trigger rewriting in Chromium:

if (scheme == "http" &&
     (request->url().port().empty() || port == 80) &&
     request->context()->transport_security_state() &&
     request->context()->transport_security_state()->IsEnabledForHost(
         &domain_state, request->url().host())) {

I understand that the draft may be updated to cover this case in the
future, in which case the code will also be updated.

AGL

Firefox Nightly Behavior Checked With HSTS Add-On
Daniel Veditz asked me to use Sid Stamm's Firefox add-on for HSTS:
https://addons.mozilla.org/en-US/firefox/addon/246797/

I installed it, accessed https://www.paypal.com to see that it showed up in the list which it did. But my site does not show up when I surf to it:

So we're now trying to find out if this is because of any of the following:

Non-default port 8443
Self-signed SSL certificate added as a permanent security exception in Firefox
Domain john.com resolves to 127.0.0.1 on my machine via /etc/hosts

Stay tuned :).

Still no HSTS in FF4 nightly or Chrome 7

2010-11-25T22:20:00.000+01:00

This weekend i blogged about my proof-of-concept implementation of Strict-Transport-Security in Struts 2 and the fact that I didn't get the expected behavior in Firefox 4 nightly or Chrome 7, only in Firefox 3.6.12 + NoScript.

Mozilla have responded and cannot reproduce the problem/bug. So I set up the stuff again and really made sure I did it right.

The Problem
The problem is that the draft specification of HTTP Strict Transport Security (HSTS) doesn't make clear what should happen for non-default ports, i e 80 for HTTP and 443 for HTTPS. Unclear specs typically lead to undefined and different behavior between implementations.

For proper security HSTS should always switch from HTTP to HTTPS for HSTS-enabled sites within the max-age time space. After my blog post Andy Steingruebl addressed the issue on his blog.

My Setup
I've set my HSTS max-age to 30 seconds to be sure it won't time out. For each test I do the following:

Make sure the browser at hand fully trusts my self-signed SSL cert for john.com. In the case of Chrome this means adding the cert to the Mac OS system keychain and activating SSL trust for it. In the case of Firefox it means adding a permanent security exception to the browser.
Load http://john.com:8080/struts2/register to make sure it loads over HTTP.
Load https://john.com:8443/struts2/register that should set the HSTS max-age to 30 seconds.
Load http://john.com:8080/struts2/register to make sure it switches to HTTPS.

Still Works in FF 3.6 + NoScript
First I confirmed that Firefox 3.6.12 + NoScript still detects my strict-transport-security header and switches from HTTP to HTTPS. Se screenshot below. Sorry for the Swedish error message :), but in essence Firefox has switched to HTTPS without changing the port and my server simply doesn't respond with an HTTPS connection on that port.

Chrome 7 Does Not Switch to HTTPS
Performing the four test steps in Chrome 7.0.517.44 does not result in the browser switching to HTTPS. Instead it gladly loads john.com over HTTP after having got the HSTS header. I tested this both by reloading a tab with the HTTP URL and by opening a new tab and entering the HTTP URL to make sure Chrome's sandboxing and one-process-per-tab was not the cause.

The screenshots below also show the HSTS header. First the HTTPS load:

... then the HTTP load:

Firefox 4.0b8pre (aka Minefield) Does Not Switch to HTTPS
The four test steps in the nightly build of Firefox 4 beta does not result in a switch to HTTPS either. See screenshots below.

First the HTTPS load:

... then the HTTP load:

Conclusion
I am always humble in these kind of cases. There might be errors or misunderstandings in my setup. Nevertheless, I think these test should work, at least to make me confident in Chrome's and Firefox's support for HSTS.

Strict-Transport-Security in Struts 2

2010-11-21T18:55:00.002+01:00

One of the topics of the upcoming OWASP Global Summit is Browser Security and the new security features in the form of optional HTTP headers.

Strict-Transport-Security, HSTS (draft spec)
X-Frame-Options (announcement from Microsoft)
X-Content-Security-Policy (announcement from Mozilla)

Is this the path towards enduser security in the era of web applications? Perhaps. Anyway, I did some proof-of-concept implementations to check out how they work and which browsers support them. In this blog post I'll cover the first one ...

HTTP Strict-Transport-Security

All the details are in the draft specification so I won't spend too much time explaining it here. Basically, it's about a response header like this:

Strict-Transport-Security: max-age=60; includeSubDomains

... where the max-age is specified in seconds and the includeSubDomains directive is optional. The header tells the browser to only accept or set up HTTPS connections with that domain for a number of seconds ahead. Further, the browser should not accept any kind of shortcomings of the SSL certificate presented by the server and should not let the user click through.

Strict-Transport-Security as a Struts 2 Interceptor

I implemented this as a Struts 2 interceptor:

import com.opensymphony.xwork2.ActionContext;
import com.opensymphony.xwork2.ActionInvocation;
import com.opensymphony.xwork2.interceptor.AbstractInterceptor;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.struts2.StrutsStatics;

import javax.servlet.http.HttpServletResponse;

public class StrictTransportSecurityInterceptor extends AbstractInterceptor {
    private static final Log logger = LogFactory.getLog(StrictTransportSecurityInterceptor.class);
    private static final String HSTS_HEADER = "Strict-Transport-Security";
    private static final String HSTS_VALUE_NAME = "max-age=";
    private static final int HSTS_VALUE_IN_SECONDS = 10;
    private static final String HSTS_VALUE_INCLUDE_SUBDOMAINS = "; includeSubDomains";

    @Override
    public String intercept(ActionInvocation invocation) throws Exception {
        ActionContext context = invocation.getInvocationContext();
        HttpServletResponse response = (HttpServletResponse) context.get(StrutsStatics.HTTP_RESPONSE);
        String headerValue = HSTS_VALUE_NAME + HSTS_VALUE_IN_SECONDS;
        response.addHeader(HSTS_HEADER, headerValue);
        logger.debug("HSTS interceptor with policy: " + headerValue);
        return invocation.invoke();
    }
}

And the interceptor can be used either directly (in struts.xml):

<package extends="struts-default" name="secureApp">
  <interceptors>
   <interceptor class="se.johnwilander.secureApp.strutsInterceptors.StrictTransportSecurityInterceptor" name="strictTransportSecurityInterceptor">
   </interceptor>
  </interceptors>

  <action class="se.johnwilander.secureApp.strutsActions.RegisterAction" name="register">
    <interceptor-ref name="strictTransportSecurityInterceptor"></interceptor-ref>
    <result name="success">/index.jsp</result>
  </action>
</package>

... or be included in your custom Struts 2 interceptor stack.

Supported in Chrome 7, FF 3 + NoScript, and forthcoming FF 4
HSTS is only supported in Mozilla's and Google's browsers at the moment. But given the amount of attention around SSL problems and session hijacking lately (SSLStrip, Firesheep) I think Apple, Opera, and Microsoft will follow soon.

HSTS Draft Spec Doesn't Cover Non-Default Ports
When I tested the above interceptor on my local setup I could only get it to work in Firefox + NoScript, not in Chrome or Minefield (Firefox 4 beta). After contacting Mozilla (and Google) they explained that the specification is unclear on what the browser should do with non-default ports such as 8080 and 8443. Here's what Sid Stamm at Mozilla told me:

Hi John,

Basically, HSTS is not specified to do anything with non-default ports.

With regards to the Minefield implementation, https://bugzilla.mozilla.org/show_bug.cgi?id=495115#c57 kind of explains that non-default port handling is not addressed very well in the HSTS specification. Non-standard ports are not changed by the "upgrade" performed by HSTS, but port 80 is changed to 443 (because 80 is default for HTTP and 443 is default for HTTPS).

The main use case that triggered the development of HSTS is that users don't usually type the scheme or port in address bar. My reasoning for implementing it to ignore non-default ports is as follows:

If a user requests (by typing in address bar, following link or bookmark, etc) a specific port, they should get that port.
If the user doesn't type a port, they get the default port. In the case where no port _or_ scheme is typed, they currently get http on port 80 (which for HSTS hosts, is "upgraded").
If the scheme https is entered, HSTS is not needed.

I hope this helps. Basically, what I'm saying is that the behavior you noticed is intended. If you change the http server port to 80 and the https port to 443, HSTS should work as specified.

This of course makes it a little bit harder to test on your own machine. You'll have to set up some kind of forwarding of port 80 to 8080 and 443 to 8443 so that the browser detects the switch from default https to default http.

MItM Attacks Possible By Abusing Non-Default Ports?
Making HSTS testing harder on your localhost is a minor problem compared to the possibility of circumventing the whole protection scheme by using non-default ports. Today SSLStrip just changes from default 443 to default 80 when it strips all https links, but it should be perfectly possible to change all those links to 8080 or the like. Client firewalls might refuse the request but I doubt it in the general case.

I would rather like HSTS to be effective for all port configurations but allow the enduser to configure it under the browser's preferences menu.

AppSec Manifesto

2010-11-21T16:07:00.001+01:00

To start this blog off I want to publish my personal AppSec Manifesto.

AppSec Manifesto

Developers are not lazy, rather quality oriented ⇒ Insecure applications do not stem from laziness.
Features and functions are always more important than security ⇒ Security should enable more features and functions.
Responsible disclosure is a good way of achieving more secure applications ⇒ Hackers are needed.
Technology is a crucial part of security ⇒ Therefore I keep coding.

This manifesto will most probably evolve along with my future insights.