The most significant security problem since the last digest is without a doubt the homograph attack against Chrome, Firefox and Opera browsers. This attack allowed an attacker to register a domain using foreign characters, which look a lot or even exactly like ASCII characters. The proof-of-concept shows the
www.apple.com domain in Chrome’s URL bar, while it should actually be
xn--pple-43d.com. This attack exists because these browsers decided not to show the underlying punycode, where these foreign characters are translated into an ASCII variant.
This attack is on top of the digest because of its potential to fool even the most hardened security professionals. Fortunately, patches for the problem are on the way so that the problem will be addressed soon.
Almost every developer has heard about the OWASP top 10, and in 2017, we can expect a new and updated edition. RC1 of the 2017 top 10 has been released, and is sparking a lot of discussion. People are questioning whether issues such as A7 - Insufficient Attack Protection should be on there. Similarly, A10 - Underprotected APIs seems weird to be listed as a risk in a top 10. We actually had a discussion about this during the closing of the Web Security Essentials course, and it seems that A10 covers a lot of known vulnerabilities, but now applied to APIs. However, if you take a look at the data behind the OWASP top 10, it definitely seems that these decisions are well thought-out.
If you have an opinion on this, you still have about two months to chime in and help shape the OWASP top 10!
Facebook’s account recovery service went in beta last week. With the service, Facebook hopes to put an end to the password recovery email. Applications can allow the user to register account recovery information with Facebook (don’t worry, it’s encrypted!), which can be used when access to the account needs to be recovered. At that time, Facebook will request a re-authentication to make sure it’s the user requesting the recovery, and then provides the data back to the original application.
Account recovery is definitely a common problem to address, and this service may very well make it a lot easier to deal with. Of course, this makes you dependent on Facebook, and depending on how the user authenticates to Facebook, this may even become the weakest link in the chain …
Ever since Chrome announced that they will make the presence of Certificate Transparency information mandatory for all certificates in October 2017, there has been a lot of discussion on the subject. It seems that all of the stakeholders are actually convinced of the usefulness of Certificate Transparency. To make sure that there’s sufficient time to implement support and upgrade the ecosystem to fully support Certificate Transparency, Google has decided to push back the deadline to April 2018. TFrom then on, Chrome will expect valid Signed Certificate Timestamps (SCTs) with every public certificate.
Finally, I wanted to highlight other news coming from Google Chrome. In the upcoming release (58), Chrome is going to make stricter security decisions regarding HTTPS. First of all, the homograph attack covered in the beginning of this digest will be addressed. Additionally, Chrome will start ignoring the CN field in a certificate (did you know this was supposed to be phased out a long time ago?). Other changes include requiring HTTPS for more features (Media extensions and notifications), reducing the whitelist of WoSign certificates, and a few smaller changes.
I’ll be talking at a few public events before summer:
- I have been invited to give a talk on building secure Angular applications at AppSec EU in Ireland. This is one of the most important web security conferences in Europe, so I definitely hope to see you there!
- On June 22nd, I’ll be giving a similar talk at Voxxed Days Luxembourg
As usual, you can find the full list of events on my speaking page.