Browsing to a website is still largely the same experience as 15 years ago. Granted, the looks and user experience have changed, but what about the mechanics? It turns out that the belly of the web consists of a large number of transparent systems. These systems enhance performance, extract analytics and supply various additional services.
This extensive post takes you down the rabbit hole of transparent middleboxes. It turns out that malformed requests and esoteric headers expose these systems and enable practical attacks.
The post is a write-up of a talk at BlackHat, so you’ll be able to watch the video soon too.
And to stay in the same realm, I wanted to point you towards this article covering script injection attack vectors in ReactJS. The morale of the story (spoiler alert) is that you’re good if you use ReactJS in the way it’s meant to be used. So you should read this post to be aware of dangerous bad practices, and setup your development environment to catch them!
When I talk about script injection for Angular and Ember, I sometimes get the question: “What about React?”. I’m not a ReactJS expert, but I’m glad I can now refer people to this insightful post.
The next story is something different. I stumbled across this link on Twitter. Go ahead, it points to a Google search, and it’s safe for work too.
In the example above, Google discloses various private RSA keys. This trick works on a lot of other types of files too. Think about database dumps from mysqldump, API keys, …
One way to avoid accidental disclosure in Git repositories is setting up pre-commit hooks to catch these sensitive files. Here’s a post describing how to do this with common regexes. It only takes a minute to set up, and may some day save you from a heap of trouble.
I want to conclude with another DefCon talk. This one covers unintended side-effects of Certificate Transparency (CT). First, a short introduction if you’re not familiar with CT. CT requires a CA to publish all generated certificates in a log. This enables domain owners to detect if a CA screws up and issues a certificate for your domain by mistake. In the future, browsers will only accept certificates that are published in a log, so CT will become “mandatory”.
These logs are public information and anyone can query the log. For example, here you can see the log results for websec.be. This means that any host that has a valid CA certificate is now publicly listed.
Now, on to the side-effects covered in this article. First, CT logs contain a lot of information about which subdomains you are using. This includes information on intranet hosts or hidden systems.
Second, if you’re setting up a new website, it will be immediately detectible in a CT log. The article shows pratical attacks against this. One scary example is looking for WordPress installers, and taking over the installation.
A number of events are being lined up for after summer. Here are two highlights:
- On October 3rd, I’ll be speaking at ACA-IT’s Tomorrow starts Today event, which is all about the secrets of innovation.
- On November 20-21, you can attend a new edition of the Web Security Essentials training course. The course will show you where your applications are vulnerable, how you can protect them, and which best practices you should be applying today. Attending the course also means you get a free set of YubiKeys. More information and registration.
As usual, you can find the full list of events on my speaking page.