Page Nav

HIDE

Grid

GRID_STYLE

Trending News

latest

VULNERABILITY: Click-Jacking!

The flexibility of web technology can open doors for bad actors. Did you get an email like this from a ‘Bug Hunter’ this week warning so...

The flexibility of web technology can open doors for bad actors.
Did you get an email like this from a ‘Bug Hunter’ this week warning some vulnerability issues on your site, smartphone, App or social account? Then you're not alone, and while these types of emails trying to expose and incite panic throughout your organization, it’s important that you DO NOT RESPOND to them!

As a rule of thumb, never respond directly to these emails. Always immediately loop in your cybersecurity team or provider. These emails are intended to use scare tactics to get you to pay a bug bounty or for a service they want to sell you - which is a very bad practice. Unfortunately, that doesn’t mean the bugs or security gaps they surfaced aren’t real.

They could be real gaps that have serious potential for exploit, but that’s a question for your security team to answer, not a random, mystery bug hunter. What’s the difference between iFraming, Click-Jacking, Form-Jacking, and Credential Skimming? An iframe (short for inline frame) is an HTML element that allows an external webpage to be embedded in an HTML document.

Unlike traditional frames, which were used to create the structure of a webpage, iFrames can be inserted anywhere within a webpage layout. iFraming content is a very common practice. If you have proprietary content that you monetize and do not want other’s distributing via iFraming your content then you may want to block that activity. Click-Jacking is both a client-side attack and a type of phishing attack that iFrames a vulnerable site on the attackers’ web page.

The attacker then places different content over the vulnerable page so that the victim does not know the vulnerable page is there. A typical attack could be an online survey that is on top of the vulnerable page. But the survey is configured so that when you answer yes/no questions you are actually clicking on buttons inside the iFramed page. Hence the term ‘Click-Jacking’.

For example: You get an email for an online survey. You click the link to go to the survey and click a few buttons asked in the survey. Behind the scenes, the attacker has overlaid the survey buttons with your bank account’s security settings. When you answer a question ‘no’, you may have just opted out of 2-factor authentication on your bank. A clever attacker may even be able to get you to reset your password using this attack. All you will see is a survey.

Older browser versions make this attack much worse in that any user input could be captured by the top-level page outside the frame to skim credentials and other information. This part has since been patched by all modern browsers. It’s a clever attack but a few things need to happen first for this attack to be successful: you must have already been authenticated to your bank before you clicked the link to the survey. your bank has not enabled Click-Jacking protection. Form-Jacking is a different type of attack, but both are client-side security risks.

Form-Jacking happens when a site’s code has been modified to send all customer-entered information to a site controlled by the attacker. Form-Jacking, Credential Skimming, and MageCart attacks are generally all the same type of attack. A typical Form-Jacking attack happens when an attacker exploits a weakness in a 3rd-party vendor.

If the attacker is able to compromise a vendor that has JavaScript running on that eCommerce site, then the attacker can now control anything that happens in the customer ’s browser. They can capture all user inputs like credit card information or credentials. They can even redirect the user to download additional malware and back doors on the customer’s computer.

These attacks have been found in JavaScript hosted from AWS’s S3 service, chatbots, and even plugins used by the host website. There is not a lot the consumer can do here to prevent these types of attacks.

The responsibility is that of the site owner to audit all their vendors constantly to ensure their code is secure. They can implement Content Security Policies to further lock down what scripts are allowed to do on-page and use security software to block unwanted or exploited scripts from loading on the site.