In the language of the millennials I should start this post with “TIL”, but for the rest of us out there that are “not so down with the cool kids” the expression is “Today I learned”.
Anyway…today I learned about a security risk called ClickJacking. You can read the full history and details of it here but the TL;DR version is:
Someone can mess with CSS and the like to make it look like your website is being displayed, but in reality, a click on it will invoke an action on a different site.
For example, you might want to buy a new phone on your favourite online auction website, and when you press the “Buy” button, unbeknown to you, someone has overlaid an invisible version of their own website on top of the auction page, and hitting “Buy” is in reality the “Send My Credit Card Details To A Nasty Person” button on the invisible website. One click and your details have been hijacked, hence the expression.
Because most clickjacking attacks involve rendering in part or full, the true version of an innocent website before augmenting it with something malicious, the use of html IFRAMEs is a common mechanism. Hence allowing your site to be referenced from within an IFRAME creates the vulnerability for it to be used to potentially clickjack someone. If you want to see if your site can be referenced from within an IFRAME, an easy way is to craft some html that does precisely that
<html> <head> <title>Am I vulnerable?</title> </head> <body> <p>Do you see the site? Hopefully not</p> https://mywebsite.com </body> </html>
A kind AskTOM reader pointed out to us that in one of our recent AskTOM deployments, we had introduced a regression in that we had reset our browser header settings, and thus allowed AskTOM to be used within an IFRAME. We’d hate anyone to be using AskTOM and get hacked as a result, so we’ve quickly fixed it. If you’re using APEX you can check your browser header security settings via Shared Components as per the GIF below, but of course, this applies for any website you look after.