The X-Frame-Options HTTP response header is a common method to protect against the clickjacking vulnerability since it is easy to implement and configure, and all modern browsers support it. As awareness of clickjacking has grown in the past several years, I have seen more and more Qualys customers adopt X-Frame-Options to improve the security of their web applications.

However, I have also noticed there is a common implementation mistake that causes some web applications to be vulnerable to clickjacking attack even though they have X-Frame-Options configured. In this article, I describe the implementation mistake and show how to check your web applications to ensure X-Frame-Options is implemented correctly.

Last week, HostGator and CloudFlare reported an ongoing attack against WordPress sites. With over 60 Million downloads, WordPress is a popular tool used to produce and run websites. It has been downloaded over 60 Million times and can be found at the core of many of the Alexa top websites.

The attack is simple, but will no doubt capture a number of naively configured WordPress systems. It aims to gain control over WordPress installations by guessing the password to the WordPress Administrator account, named by default “admin”. Apparently the attacker controls a botnet of roughly 90,000 computers that have been instructed to seek out WordPress instances and to use a dictionary over 2,500 common passwords in a brute force password attack.