TL;DR, There used to be a bug in Internet Explorer allowing attackers to force victims to send requests with malformed Host headers. File Descriptor used it to steal GitHub OAuth tokens, and we used it to confuse Heroku and Fastly’s host routing to make them serve our content on their customers’ domains. Fastly and Heroku have since then patched the issue on their side.
When it comes to Amazon Web Services (AWS), both S3 and CloudFront lack domain validation. If a domain has a DNS entry pointing to either S3 or CloudFront but the domain is not actually claimed in S3 or CloudFront, it’s possible for anyone to claim the domain and serve their own content on the domain using these two AWS services. We will explain another problem with the lack of domain verification, combining trailing dot domains, conflict checks and how SSL common name matching works today.
This is a walkthrough of a hard-to-reproduce bug I found in Slack a few months back. Even though the payload was only working because of a legacy migration, by utilizing Python’s AppKit to insert data into Chrome’s rich text format clipboard, I was able to add and modify the XSS payload already inside Slack.
HTTP Public Key Pinning (HPKP) is very powerful if configured correctly. It has the ability to protect against the most sophisticated targeted attacks that seriously threaten the security on the Internet, for all of us. But, with great security comes great responsibility. If HPKP is deployed into a production environment without being thoroughly tested and designed, the website may be inaccessible for all the previous visited clients. The fear of incorrectly deploying an HPKP-policy could scare the security-responsible into not using the security mechanism at all. So is it worth it? Should you use HPKP?