FROMDEV

What Is Cross-Frame Scripting Attack (XFS) ?

XFS and XSS: Everything You Didn't Know You Needed to Know About Cross-Frame Scripting

Imagine you regularly leave the keys to your car in the ignition with the driver’s side door unlocked. Now imagine that one morning you wake up to find your car still in your driveway with the keys still in the ignition, but a report on the morning news is identifying a vehicle of your make and model with your license plate as the getaway car in a robbery. While you were blissfully unaware, someone took control of your car and used it to commit a crime.

Now imagine that instead of a car it’s your organization’s website. And instead of leaving the keys in the ignition with the door unlocked, you’ve left it vulnerable to malicious use by attackers. And instead of it being used for a robbery, it’s…well actually it’s still used for a robbery, and it’s your users’ personal and financial information that has been stolen.

Feeling Cross

In a perfect world, your website would be used by your organization to accomplish its business goals, and it would be used by your users to obtain whatever service it is that you provide, and that is the full list of ways it would be utilized. But no one lives in a perfect world, and if your websites and applications aren’t secure, they’re open to being used by bad, bad people.

Two of the ways an attacker could use your site are through cross-frame scripting (XFS) or cross-site scripting (XSS). In most cases, you would never realize that your site is being used for someone else’s malicious gain until a user reports suspicious activity. This is a security embarrassment of the highest level.

The way XSS and XFS works are technically different, but they are both efficient and come equipped with devastating consequences like stolen user information and irreparable brand damage. It’s essential that software developers consider both of these attacks during the software development process, whether through static code analysis tools or penetration testing before deployment.

XSS, FYI

XSS is an attack that takes advantage of poorly coded JavaScript, allowing an attacker to input malicious JavaScript on your website which is then output to the browser of an end user. It allows an attacker to use your site as a conduit for his or her malicious code. As an example, consider the following JavaScript code.

alert(user_input);

Let’s assume that “user_input” is a variable that contains input from a form submission. What happens if a user inputs “<script>malicious js here</script>” into the submission form field? The malicious code is printed to the browser and can execute statements that allow the attacker to steal passwords, take control of the user’s computer, or steal the user’s data and intercept their session, all using your organization’s website.

The best way to defend against XSS is to take a pessimistic world view and never assume input isn’t malicious, always stripping any HTML or script tags from the input. You can even download libraries that help you detect it.

What The F?

XFS is similar to XSS in that it allows an attacker to use your website to do his or her evil bidding. It differs, frankly, in that it’s easier. XFS uses an iFrame that displays a legitimate site to a user but allows the top frame to belong to the attacker.

For instance, imagine an attacker owns the domain name “bankkofamerica.com.” It’s similar enough to the real domain that it could go undetected by a user, especially if that attacker uses an iFrame to display the right bankofamerica.com website. When a user types in the accidental but similar domain, it appears to show the legitimate banking website, but it’s the iFrame. When the user then logs into the banking website, the attacker can use the iFrame to take a snapshot of the user’s credentials.

The good news is that since XFS attacks are easier to perpetrate, they are also easier to defend against. All you need to do is add code to your site to “break out” of iFrames. This means that if an attacker frames your site, your code will override the iFrame and refresh in the user’s browser.

The following is the JavaScript code you can add to your site to break out of frames. Remember that if you do break out of iFrames, you break out of them for all users and not just attackers. If any legitimate affiliates or webmasters use your site in an iFrame, they will be kicked out as well.

if (top != self) {top.location = self.location;}

Identifying Your Vulnerabilities

Programmers aren’t usually security experts, so it’s easier to say “think like a hacker” than it is actually to do it. That’s why organizations like Checkmarx, a security analysis provider, offer cross frame scripting examples that you can use to determine if you could be vulnerable. It’s better you find out if you’re vulnerable before an attacker does.

You can use several penetration tools and coding libraries to guard against attacks like XSS and XFS. Security has to be a priority. For the sake of your users, your brand, and your business, it just has to be. Stay educated on threats, scour your applications for vulnerabilities, make a secure development life cycle a necessity, and lock your car doors.

Live Demo

See below YouTube Video Demosntrating XFS Attack.

Exit mobile version