Entries tagged as csrf
breach cookies crime heist https samesite time tls web websecurity code c freesoftware freewvs php programming security sizeof xss english babelfish cacert camera canon china chinese cryptography email etymologie gadgets gammu gentoo gnokii googletranslate gphoto josm journalist language linux mandarin media merkaartor mobile moodle nokia openssl openstreetmap ptp rc2 russia russian s9y serendipity smime ssl translation travel universaltranslator writing 23c3 27c3 3d 3ddrucker adobe amusementpark asia ati backnang base64 bash beijing berlin beryl bios blob bonn bufferoverflow ccc cellular chdk chemnitz chromium cinderella cinelerra clt codecs compiz compizfusion composite compression console copyright creativecommons css cve ddwrt debian desktop developingworld digitalcamera disney disneyland driver dvd eltorito evince exe fake ffmpeg film firefox firmware france freeculture freiegesellschaft freifunk frequencies frequency froscon froscon2007 fsf fsfe gaia games gargoyle ghost gimp glibc gnome google googleearth graphics grub gsm hardware heartbleed homebrew ibm ico icons icoutils iso itu ixus jugendumweltbewegung jukss karlsruhe kde königswusterhausen kpdf laptop lenovo lessig license lpi lpic lspci lsusb lug memdisk messe microsoft mobilephones movie musik nancy nessus nouveau nvidia ökologie okular olpc openbsc openbts openexpo opengl opensourceexpo openvas osmocombb pciids pdf phoronix poppler presse privacy rapidprototyping rar realmedia realvideo redhat reprap retrogames reverseengineering rmll router rv30 rv40 science sciencefiction script sfd shellshock shijingshan siegburg simcity society softwarefreedomday sqlinjection stepmania sumatrapdf sunras syslinux talk theory thesource theunarchiver thinkpad trip2011 tuxmas unar usbids video videoediting vulnerability wii wiibrew wiki windows windowsrefund wiretapping wos wos4 wrestool xorg afra spam vortrag webapps wordpress adguard android antivirus apache browser ca certificate certificates cloudflare cms crypto dell edellroot encryption facebook freak hash http joomla kaspersky komodia letsencrypt maninthemiddle mitm netfiltersdk nginx ocsp ocspstapling privdog protocolfilters revocation rss sha1 sha256 sni superfish transvalid update updates windowsxp x509 blog 0days addresssanitizer aead aes aiglx algorithm altushost antivir aok apt asan auskunftsanspruch axfr azure badkeys barcamp berserk bias bigbluebutton bleichenbacher bodensee botnetz braunschweig bsi bsideshn bugbounty bundesdatenschutzgesetz bundestrojaner bundesverfassungsgericht busby bypass cbc cccamp11 cfb chcounter chrome clamav clang clickjacking cmi conflictofinterest cookie crash darmstadt datenschutz deb deolalikar diffiehellman dingens diploma diplomarbeit distributions dns domain drupal easterhegg eff eplus fedora fileexfiltration firewall fortigate fortinet forwardsecrecy ftp fuzzing gajim gallery gcc git gnupg gnutls gobi gpg gsoc gstreamer hackerone hacking hannover helma infoleak informationdisclosure internetscan ircbot itsecurity jabber javascript jodconverter key keyexchange leak libreoffice luckythirteen malware mantis math md5 memorysafety mephisto milleniumproblems modulobias mozilla mpaa mplayer mrmcd mrmcd100b mrmcd101b multimedia mysql napster newspaper nist nss ntp ntpd observatory onlinedurchsuchung openleaks openpgp otr owncloud packagemanagement padding panda papierlos password passwordalert passwort passwörter pdo pgp phishing pnp poodle privatekey provablesecurity pss python rand random rhein rpm rsa rsapss salinecourier schlüssel server session sha2 sha512 shellbot sicherheit signatures slides snallygaster sniffing squirrelmail staatsanwaltschaft stacktrace study stuttgart subdomain support taz thesis tlsdate toendacms überwachung ubuntu unicef unicode useafterfree userdir utf-8 verschlüsselung virus vlc vulnerabilities webmontag wiesbaden xgl xine xmpp xsa zerodays zugangsdaten zzuf calendar ipv6 mod_rewrite date ntimed ntpsec openntpd picture roughtime securetime cccamp cccamp15 certificateauthority libressl openbsd symantec acid3 html midori webdesign webkit webstandards content-security-policy core coredump csp grsecurity segfault symlink webhosting webroot webserver okte
Monday, April 13. 2020
Generating CRIME safe CSRF Tokens
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
