Clickjacking?

Web page එකක් open කරලා තියෙනවා කියලා හිතන්න.

Screen එකේ පේන්නේ:

“ Claim Your Free Reward”

ඔයා naturally ඒ button එක click කරනවා.

ඒත් browser එකේ වෙන layer එකක, transparent iframe එකක් ඇතුළේ තියෙන්නේ logged-in account එකේ real “Delete Account” / “Change Settings” / “Transfer” / “Like” වගේ action button එකක්.

Userට පේන්නේ එක දෙයක්.

Browser එක execute කරන්නේ වෙන දෙයක්.

මේ category එකේ UI deception attack එකක් තමයි Clickjacking.

Clickjacking කියන්නේ මොකක්ද?

Clickjacking කියන්නේ user කෙනෙකුගේ genuine mouse click / touch interaction එක, attacker-controlled interface එකක් හරහා වෙන legitimate web action එකකට redirect කරවීමේ technique එකක්.

මේක UI Redress Attack කියලත් හඳුන්වනවා.

Basic idea එක:

Victim

│

▼

Attacker-controlled webpage

│

├── Fake visible button

│

└── Hidden / transparent iframe

│

▼

Target Website

│

▼

Victim’s active session

│

▼

Sensitive action

වැදගත්ම point එක:

Clickjacking එකේ attackerට target website එකේ source code එක directly control කරන්න අවශ්‍ය නැහැ.

Target application එක browser එක තුළ frame කරන්න ඉඩ දෙනවා නම්, UI layer එක abuse කරන්න පුළුවන්.

Clickjacking වැඩ කරන්නේ කොහොමද?

සාමාන්‍ය Clickjacking attack එකක components තුනක් තියෙනවා:

Target page

උදාහරණයක්:

https://target.example/account

User already logged in.

Attacker page

https://evil.example

මෙහි attacker-controlled HTML/CSS තිබෙනවා.

Embedded iframe

Attacker page එක target site එක frame කරන්න try කරනවා.

Target response එක framing allow කළොත් browser එක target page එක render කරනවා.

ඊට පස්සේ attackerට CSS positioning / opacity / layering භාවිතා කරලා තමන්ට අවශ්‍ය visual interface එක arrange කරන්න පුළුවන්.

Classic Clickjacking Example

Lab environment එකක conceptual example එකක් බලමු.

Attacker page:

<!DOCTYPE html>

<html>

<head>

<title>Clickjacking Lab</title>

<style>

body {

font-family: sans-serif;

}

.fake-button {

position: absolute;

top: 250px;

left: 200px;

z-index: 1;

padding: 20px 40px;

background: #111;

color: white;

cursor: pointer;

}

iframe {

position: absolute;

top: 200px;

left: 150px;

width: 500px;

height: 300px;

opacity: 0.01;

z-index: 2;

border: none;

}

</style>

</head>

<body>

Claim Reward

</button>

</body>

</html>

මෙහි objective එක victimගේ browser එකේ target application එක iframe එකක load කරලා, visible UI එකට සමාන location එකක legitimate control එකක් align කිරීම.

මේ example එක real third-party site එකකට use කරන්න එපා. තමන්ගේ lab / CTF / explicitly authorized environment එකකට පමණයි.

iframe එක මෙච්චර වැදගත් ඇයි?

Clickjacking attack එකේ key dependency එකක් තමයි:

Attacker page එකට target page එක frame කරන්න බැරි නම් classic clickjacking architecture එක බිඳ වැටෙනවා.

ඒ නිසා defense එකේ first question එක:

“මගේ application එක වෙන origin එකක webpage එකකට iframe එකකින් embed කරන්න browser එක allow කරනවද?”

Modern browsers මේ framing decision එකට HTTP response headers use කරනවා.

MAIN DEFENSE — CSP frame-ancestors

Modern web applications සඳහා ප්‍රධාන protection mechanism එක:

Content-Security-Policy: frame-ancestors ‘none’;

මෙයින් browser එකට කියන්නේ:

මේ document එක කිසිම parent page එකක frame කරන්න එපා.

එහෙමනම් attacker page එකේ:

දාපු එකෙන් expected target content එක load වෙන්නේ නැහැ.

frame-ancestors ‘none’

Full example:

HTTP/1.1 200 OK

Content-Security-Policy: frame-ancestors ‘none’;

මේක strongest common policy එකක් — application එක කිසිම framing use case එකකට අවශ්‍ය නොවන්නේ නම්.

MDN සහ OWASP දෙකම frame-ancestors ‘none’ use case එක frame-based clickjacking protection සඳහා ප්‍රධාන option එකක් ලෙස document කරනවා.

Same-Origin එක විතරක් allow කරන්න

Application එක තමන්ගේම pages අතර iframe use කරනවා නම්:

Content-Security-Policy: frame-ancestors ‘self’;

එයින්:

https://target.example

වල document එක same-origin context වලින් frame කිරීම allow වෙන්න පුළුවන්.

External attacker domain එකකට frame permission දෙන්නේ නැහැ.

Specific trusted origins allow කිරීම

Application එකට third-party embedding legitimately අවශ්‍ය නම්, specific sources define කරන්න පුළුවන්.

Example:

Content-Security-Policy:

frame-ancestors ‘self’ https://trusted.example;

Conceptually:

Allowed

├── Same origin

└── https://trusted.example

Denied

├── https://evil.example

├── https://attacker.example

└── any other origin

මෙතන biggest mistake එක තමයි:

“අපි iframe allow කරන නිසා හැම domain එකකටම allow කරමු.”

ඒක unnecessary attack surface එකක්.

frame-src සහ frame-ancestors එකම දෙයක් නෙවෙයි

Developers අතර common confusion එක:

frame-src

frame-ancestors

frame-src

Page එක කුමන iframe sources load කරන්නද කියන policy එකට අදාලයි.

frame-ancestors

කවුද මේ page එක iframe එකකින් embed කරන්න පුළුවන්? කියන policy එකට අදාලයි.

ඒ නිසා Clickjacking defense එකේ target directive එක:

frame-ancestors

MDN explicitly මේ දෙකේ distinction එක දක්වනවා.

X-Frame-Options

Legacy / compatibility protection සඳහා තවත් header එකක්:

X-Frame-Options: DENY

මේකෙන් browser එකට:

Do not display this page inside a frame.

කියන policy එකක් ලැබෙනවා.

ප්‍රධාන values:

X-Frame-Options: DENY

හෝ

X-Frame-Options: SAMEORIGIN

DENY

කිසිම framing එකකට allow නොකරන්න.

SAMEORIGIN

Same-origin framing පමණක් allow කරන්න.

RFC 7034 X-Frame-Options එක browser එකට transmitted content එක frames තුළ display කරන්න පුළුවන්ද කියන server-side policy mechanism එකක් ලෙස define කරනවා.

ALLOW-FROM ගැන වැදගත් point එකක්

පරණ tutorials වල මෙහෙම දකින්න පුළුවන්:

X-Frame-Options: ALLOW-FROM https://example.com

මෙය modern browsers සඳහා obsolete approach එකක්.

OWASP එකත් ALLOW-FROM මත rely කිරීම modern environments සඳහා appropriate defense එකක් නොවන බව සඳහන් කරනවා. frame-ancestors තමයි flexible modern approach එක.

ඒ නිසා random old tutorial එකකින් copy-paste කරලා security configuration කරන්න එපා.

CSP + X-Frame-Options දෙකම දාන්න පුළුවන්ද?

ඔව්.

Common defense-in-depth pattern එක:

Content-Security-Policy: frame-ancestors ‘none’;

X-Frame-Options: DENY

Modern browsers සඳහා CSP frame-ancestors ප්‍රධාන control එක.

X-Frame-Options additional compatibility / defense-in-depth layer එකක් ලෙස තබාගන්න පුළුවන්.

SameSite Cookies — තවත් layer එකක්

Clickjacking protection එකේ තවත් important layer එකක් තමයි:

Set-Cookie: session=…; Secure; HttpOnly; SameSite=Lax

හෝ stronger cross-site restriction අවශ්‍ය නම්:

Set-Cookie: session=…; Secure; HttpOnly; SameSite=Strict

SameSite setting එක cross-site contexts වල cookie transmission restrict කරන්න පුළුවන්.

මේකෙන් embedded context එකක authentication cookie නොයන අවස්ථා තිබෙන නිසා clickjacking risk එක reduce වෙන්න පුළුවන්.

නමුත්:

SameSite ≠ complete Clickjacking defense

මේක additional / partial mitigation එකක්.

MDN සහ OWASP දෙකම SameSite cookie policy එක clickjacking සඳහා defense-in-depth mechanism එකක් ලෙස පෙන්වනවා.

Clickjacking vulnerability එක test කරන්නේ කොහොමද?

Authorized lab එකක් / test application එකක් තියෙනවා කියලා හිතමු.

මුලින් response headers inspect කරන්න.

cURL:

curl -I https://target.example/account

Look for:

Content-Security-Policy

X-Frame-Options

Example:

HTTP/2 200

content-security-policy: frame-ancestors ‘none’

x-frame-options: DENY

හෝ potentially weak response එකක්:

HTTP/2 200

content-type: text/html

මෙතන header protection එකක් පෙනෙන්නේ නැහැ.

Header missing = automatically exploitable කියලා direct conclusion එකකට යන්න එපා.

Actual browser behavior සහ page functionality verify කරන්න.

Burp Suite වලින් test කිරීම

Authorized penetration test එකකදී Burp Suite use කරලා response එක inspect කරන්න පුළුවන්.

PortSwigger current testing guidance අනුව Burp Scanner එකෙන් Frameable response findings identify කළ හැකි අතර, manual proof-of-concept testing සඳහා Clickbandit වැනි functionality භාවිතා කළ හැක.

Basic workflow:

Target

↓

Burp Proxy

↓

HTTP response

↓

Inspect headers

↓

Check frameability

↓

Verify sensitive UI action

↓

Document impact

Scanner finding එකක් තිබුණා කියලා alone critical vulnerability කියලා report කරන්න එපා.

Impact matters.

Clickjacking හැම වෙලාවෙම critical ද?

නැහැ.

මේක common overstatement එකක්.

Example:

Low-impact page

Public About Page

Frameable වීමේ impact එක negligible වෙන්න පුළුවන්.

High-impact page

Account settings

Password management

Financial action

Destructive action

Permission change

Administrative action

මෙවැනි authenticated sensitive action එකක් user interaction එකෙන් trigger කරන්න පුළුවන් නම් impact එක dramatically increase වෙනවා.