**Bugbounty wenk**: **Teken aan** vir **Intigriti**, 'n premium **bugbounty-platform wat deur hackers, vir hackers** geskep is! Sluit vandag nog by ons aan by [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) en begin om belonings tot **$100,000** te verdien!
1. Kyk of **enige waarde wat jy beheer** (_parameters_, _pad_, _koppe_?, _koekies_?) in die HTML **weerspieël** word of deur **JS**-kode **gebruik** word.
2.**Vind die konteks** waar dit weerspieël/gebruik word.
3. As dit **weerspieël** word:
1. Kyk **watter simbole jy kan gebruik** en berei die payload voor, afhangende daarvan:
1. In **rou HTML**:
1. Kan jy nuwe HTML-etikette skep?
2. Kan jy gebeurtenisse of eienskappe gebruik wat die `javascript:`-protokol ondersteun?
3. Kan jy beskerming omseil?
4. Word die HTML-inhoud deur enige kliëntkant-JS-enjin (_AngularJS_, _VueJS_, _Mavo_...) geïnterpreteer, waar jy 'n [**Kliëntkant-sjablooninspuiting**](../client-side-template-injection-csti.md) kan misbruik.
5. As jy nie HTML-etikette kan skep wat JS-kode uitvoer nie, kan jy 'n [**Hangende merk - HTML-skriptlose inspuiting**](../dangling-markup-html-scriptless-injection/) misbruik?
2. Binne 'n **HTML-etiket**:
1. Kan jy na rou HTML-konteks gaan?
2. Kan jy nuwe gebeurtenisse/eienskappe skep om JS-kode uit te voer?
3. Ondersteun die eienskap waarin jy vasgevang is JS-uitvoering?
4. Kan jy beskerming omseil?
3. Binne **JS-kode**:
1. Kan jy die `<script>`-etiket ontsnap?
2. Kan jy die string ontsnap en verskillende JS-kode uitvoer?
3. Is jou inset in sjabloontekens \`\`?
4. Kan jy beskerming omseil?
4. JS-**funksie** wat **uitgevoer** word:
1. Jy kan die naam van die funksie aandui om uit te voer. bv.: `?callback=alert(1)`
4. As dit **gebruik** word:
1. Jy kan 'n **DOM XSS** uitbuit, let op hoe jou inset beheer word en of jou **beheerde inset deur enige sink gebruik word**.
Wanneer jy aan 'n komplekse XSS werk, sal jy dit dalk interessant vind om te weet oor:
* **Tussengangers weerspieël**: As jy vind dat die waarde van 'n parameter of selfs die pad in die webblad weerspieël word, kan jy 'n **Weerspieëlde XSS** uitbuit.
* **Opgeslaan en weerspieël**: As jy vind dat 'n waarde wat deur jou beheer word, in die bediener gestoor word en elke keer as jy 'n bladsy besoek, weerspieël word, kan jy 'n **Opgeslaan XSS** uitbuit.
* **Toegang via JS**: As jy vind dat 'n waarde wat deur jou beheer word, met behulp van JS toegang verkry word, kan jy 'n **DOM XSS** uitbuit.
Wanneer jy 'n XSS probeer uitbuit, is die eerste ding wat jy moet weet, **waar jou inset weerspieël word**. Afhangende van die konteks, sal jy in staat wees om arbitrêre JS-kode op verskillende maniere uit te voer.
As jou inset **in die rou HTML**-bladsy weerspieël word, sal jy 'n sekere **HTML-etiket** moet misbruik om JS-kode uit te voer: `<img , <iframe , <svg , <script` ... dit is net 'n paar van die vele moontlike HTML-etikette wat jy kan gebruik.\
Hou ook [Kliëntkant-sjablooninspuiting](../client-side-template-injection-csti.md) in gedagte.
1. Om **uit die eienskap en uit die etiket te ontsnap** (dan sal jy in die rou HTML wees) en nuwe HTML-etiket skep om te misbruik: `"><img [...]`
2. As jy **uit die eienskap kan ontsnap, maar nie uit die etiket nie** (`>` is gekodeer of uitgevee), afhangende van die etiket, kan jy 'n **gebeurtenis skep** wat JS-kode uitvoer: `" autofocus onfocus=alert(1) x="`
3. As jy **nie uit die eienskap kan ontsnap nie** (`"` word gekodeer of uitgevee), sal jy, afhangende van **watter eienskap** jou waarde weerspieël word en **of jy die hele waarde of net 'n deel daarvan beheer**, dit kan misbruik. By **voorbeeld**, as jy 'n gebeurtenis soos `onclick=` beheer, sal jy dit kan laat arbitrêre kode uitvoer wanneer dit geklik word. 'n Ander interessante **voorbeeld** is die eienskap `href`, waar jy die `javascript:`-protokol kan gebruik om arbitrêre kode uit te voer: **`href="javascript:alert(1)"`**
4. As jou inset binne "**onuitbuitbare etikette**" weerspieël word, kan jy die **`accesskey`-truk** probeer om die kwesbaarheid te misbruik (jy sal 'n sekere mate van sosiale manipulasie nodig hê om dit uit te buit): **`" accesskey="x" onclick="alert(1)" x="`**
In hierdie geval word jou inset weerspieël tussen **`<script> [...] </script>`**-etikette van 'n HTML-bladsy, binne 'n `.js`-lêer of binne 'n eienskap wat die **`javascript:`-protokol** gebruik:
* As dit weerspieël word tussen **`<script> [...] </script>`**-etikette, selfs al is jou inset binne enige soort aanhalingstekens, kan jy probeer om `</script>` in te spuit en uit hierdie konteks te ontsnap. Dit werk omdat die **blaaier eers die HTML-etikette sal ontled** en dan die inhoud, daarom sal dit nie besef dat jou ingespotte `</script>`-etiket binne die HTML-kode is nie.
* As dit **binne 'n JS-string** weerspieël word en die vorige truuk nie werk nie, sal jy die string moet **verlaat**, jou kode **uitvoer** en die JS-kode **herkonstrueer** (as daar enige foute is, sal dit nie uitgevoer word nie):
*`'-alert(1)-'`
*`';-alert(1)//`
*`\';alert(1)//`
* As dit binne sjabloontekens weerspieël word, kan jy **JS-uitdrukkings inbed** deur die `${ ... }`-sintaksis te gebruik: `` var greetings = `Hello, ${alert(1)}` ``
* **Unicode-kodering** werk om **geldige javascript-kode** te skryf:
Javascript Hoisting verwys na die geleentheid om funksies, veranderlikes of klasse te verklaar nadat hulle gebruik is, sodat jy situasies kan misbruik waar 'n XSS onverklaarde veranderlikes of funksies gebruik.\
**Kyk na die volgende bladsy vir meer inligting:**
Verskeie webbladsye het eindpunte wat **die naam van die funksie aanvaar as parameter om uit te voer**. 'n Algemene voorbeeld wat jy in die wild kan sien, is iets soos: `?callback=callbackFunc`.
'n Goeie manier om uit te vind of iets wat direk deur die gebruiker gegee word, probeer uitgevoer word, is deur die param-waarde te **verander** (byvoorbeeld na 'Vulnerable') en in die konsole te kyk vir foute soos:
In die geval dat dit kwesbaar is, kan jy in staat wees om 'n waarskuwing te **trigger** deur net die waarde te stuur: **`?callback=alert(1)`**. Dit is egter baie algemeen dat hierdie eindpunte die inhoud sal **valideer** om slegs letters, syfers, punte en onderstreepstrepe toe te laat (**`[\w\._]`**).
Nogtans is dit steeds moontlik om sekere aksies uit te voer, selfs met daardie beperking. Dit is omdat jy daardie geldige karakters kan gebruik om enige element in die DOM te **toegang**:
Gewoonlik is die eindpunte wat die aangeduide funksie uitvoer eindpunte sonder veel interessante DOM, **ander bladsye in dieselfde oorsprong** sal 'n **meer interessante DOM** hê om meer aksies uit te voer.
Daar is **JS-kode** wat **onveilig** gebruik maak van **data wat deur 'n aanvaller beheer word**, soos `location.href`. 'n Aanvaller kan dit misbruik om willekeurige JS-kode uit te voer.
Hierdie soort XSS kan **oral** gevind word. Dit hang nie net af van die kliënt-uitbuiting van 'n webtoepassing nie, maar van **enige****konteks**. Hierdie soort **willekeurige JavaScript-uitvoering** kan selfs misbruik word om **RCE** te verkry, **willekeurige****lêers** in kliënte en bedieners te **lees**, en nog meer.\
Wanneer jou inset **binne die HTML-bladsy** weerspieël word of jy HTML-kode kan ontsnap en injekteer in hierdie konteks, is die **eerste** ding wat jy moet doen, om te kyk of jy die `<` kan misbruik om nuwe etikette te skep: Probeer net om daardie **karakter** te **weerspieël** en kyk of dit **HTML-gekodeer** of **verwyder** word, of as dit **weerspieël word sonder veranderinge**. **Slegs in die laaste geval sal jy hierdie geval kan uitbuit**.\
Vir hierdie gevalle moet jy ook **onthou** van [**Client Side Template Injection**](../client-side-template-injection-csti.md)**.**\
_**Nota: 'n HTML-kommentaar kan gesluit word met `-->` of `--!>`**_
Maar, as tags/atribute swart/lys gebruik word, sal jy nodig hê om te **brute-force watter tags** jy kan skep.\
Sodra jy **gevind het watter tags toegelaat word**, sal jy nodig hê om **brute-force atribute/gebeure** binne die gevonde geldige tags te doen om te sien hoe jy die konteks kan aanval.
Gaan na [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet) en klik op _**Kopieer tags na knipbord**_. Stuur dan almal deur gebruik te maak van Burp intruder en kyk of enige tags nie as skadelik deur die WAF ontdek is nie. Sodra jy uitgevind het watter tags jy kan gebruik, kan jy **brute force al die gebeure** gebruik deur die geldige tags (op dieselfde webbladsy klik op _**Kopieer gebeure na knipbord**_ en volg dieselfde prosedure as voorheen).
As jy nie enige geldige HTML-tag gevind het nie, kan jy probeer om **'n aangepaste tag te skep** en JS-kode uit te voer met die `onfocus` atribuut. In die XSS-versoek, moet jy die URL beëindig met `#` om die bladsy **te fokus op daardie voorwerp** en die kode **uit te voer**:
**Meer klein XSS vir verskillende omgewings** payload [**kan hier gevind word**](https://github.com/terjanq/Tiny-XSS-Payloads) en [**hier**](https://tinyxss.terjanq.me).
As jy die kwesbaarheid wil uitbuit deur die **gebruiker 'n skakel of vorm te laat klik** met vooraf ingevulde data, kan jy probeer om [**klikkaping te misbruik**](../clickjacking.md#xss-clickjacking) (as die bladsy kwesbaar is).
As jy net dink dat **dit onmoontlik is om 'n HTML-etiket met 'n eienskap te skep om JS-kode uit te voer**, moet jy [**Hangende opmaak**](../dangling-markup-html-scriptless-injection/) nagaan omdat jy die kwesbaarheid kan **uitbuit** sonder om **JS**-kode uit te voer.
As jy **binne 'n HTML-etiket** is, is die eerste ding wat jy kan probeer om uit die etiket te ontsnap en van die tegnieke wat in die [vorige afdeling](./#injecting-inside-raw-html) genoem word, te gebruik om JS-kode uit te voer.\
As jy **nie uit die etiket kan ontsnap nie**, kan jy nuwe eienskappe binne die etiket skep om te probeer om JS-kode uit te voer, byvoorbeeld deur 'n payload te gebruik soos (_let daarop dat in hierdie voorbeeld dubbele aanhalingstekens gebruik word om uit die eienskap te ontsnap, jy sal dit nie nodig hê as jou inset direk binne die etiket weerspieël word_):
Style-gebeure is 'n tipe kruiswebklets (XSS) aanval wat gebruik maak van die `style`-atribuut om skadelike kode in te spuit in 'n webbladsy se HTML-elemente. Hierdie tipe aanval maak gebruik van die feit dat die `style`-atribuut gebruik kan word om CSS-eienskappe aan elemente toe te ken.
Die aanvaller kan die `style`-atribuut gebruik om skadelike CSS-kode in te sluit, soos `background-image: url('kwaadwillige_kode');`. Wanneer die webbladsy gelaai word, sal die skadelike kode uitgevoer word en kan dit lei tot die uitbuiting van die webbladsy se veiligheid.
Om stylgebeure te voorkom, moet webontwikkelaars insette van gebruikers behoorlik valideer en ontsmet. Dit kan gedoen word deur die gebruik van 'n HTML-sanitiseringsbiblioteek of deur die implementering van 'n beperkte witlys van toelaatbare CSS-eienskappe en waardes.
Selfs as jy **nie kan ontsnap uit die eienskap nie** (`"` word gekodeer of verwyder), afhangende van **watter eienskap** jou waarde weerspieël as jy al die waarde beheer of net 'n deel daarvan, sal jy dit kan misbruik. By **voorbeeld**, as jy 'n gebeurtenis soos `onclick=` beheer, sal jy dit kan maak om willekeurige kode uit te voer wanneer dit geklik word.\
'n Ander interessante **voorbeeld** is die eienskap `href`, waar jy die `javascript:` protokol kan gebruik om willekeurige kode uit te voer: **`href="javascript:alert(1)"`**
Die **HTML-gekodeerde karakters** binne die waarde van HTML-etiketseienskappe word **tydens uitvoering gedekodeer**. Daarom sal iets soos die volgende geldig wees (die payload is vetgedruk): `<a id="author" href="http://none" onclick="var tracker='http://foo?`**`'-alert(1)-'`**`';">Go Back </a>`
**Deurloop binne-gebeurtenis deur gebruik te maak van Unicode-kodering**
Om XSS-filters te omseil wat binnen-gebeurtenissen (zoals onclick, onmouseover, enz.) controleren, kan Unicode-kodering worden gebruikt. Dit houdt in dat speciale tekens worden vervangen door hun Unicode-equivalenten.
Bijvoorbeeld, het karakter `<` kan worden vervangen door `\u003c` en het karakter `>` kan worden vervangen door `\u003e`. Op deze manier kan kwaadaardige code worden ingevoegd zonder dat deze wordt gedetecteerd door de XSS-filter.
Op deze manier kan de kwaadaardige code worden uitgevoerd wanneer de binnen-gebeurtenis wordt geactiveerd. Het is echter belangrijk op te merken dat deze techniek mogelijk niet altijd werkt, afhankelijk van de specifieke implementatie van de XSS-filter.
Daar kan jy die protokolle **`javascript:`** of **`data:`** gebruik op sekere plekke om **arbitrêre JS-kode uit te voer**. Sommige sal gebruikerinteraksie vereis en ander nie.
**In die algemeen** kan die `javascript:` protokol **gebruik word in enige tag wat die atribuut `href` aanvaar** en in **die meeste** van die tags wat die **atribuut `src`** aanvaar (maar nie `<img`) nie.
Verder is daar nog 'n **mooi truuk** vir hierdie gevalle: **Selfs as jou inset binne `javascript:...` URL-gekodeer word, sal dit URL-gekodeer word voordat dit uitgevoer word.** So, as jy moet **ontsnap** uit die **string** deur 'n **enkellike teken** te gebruik en jy sien dat dit **URL-gekodeer word**, onthou dat **dit nie saak maak nie,** dit sal tydens die **uitvoering** as 'n **enkellike teken** geïnterpreteer word.
Let daarop dat as jy probeer om **beide**`URLencode + HTMLencode` in enige volgorde te gebruik om die **payload** te enkodeer, sal dit **nie werk nie**, maar jy kan hulle **binne die payload meng**.
Reverse tab nabbing is een aanvalstechniek die wordt gebruikt om gebruikers te misleiden en hun vertrouwelijke informatie te stelen. Bij deze aanval wordt een kwaadwillende website gemaakt die eruitziet als een legitieme website waar de gebruiker al ingelogd is. Wanneer de gebruiker op een link klikt en naar een andere tabblad navigeert, wordt het oorspronkelijke tabblad vervangen door de kwaadwillende website. Hierdoor kan de aanvaller de inloggegevens en andere vertrouwelijke informatie van de gebruiker stelen.
Om deze aanval uit te voeren, maakt de aanvaller gebruik van JavaScript om de locatie van het oorspronkelijke tabblad te wijzigen naar de kwaadwillende website. Dit kan worden bereikt door de `window.opener.location` eigenschap te wijzigen. Zodra het oorspronkelijke tabblad is vervangen, kan de aanvaller de ingevoerde gegevens onderscheppen en deze naar een externe server sturen.
Om jezelf te beschermen tegen reverse tab nabbing, is het belangrijk om altijd alert te zijn op verdachte websites en links. Zorg ervoor dat je alleen vertrouwde websites bezoekt en vermijd het klikken op verdachte links. Daarnaast is het ook aan te raden om een up-to-date antivirusprogramma en een firewall te gebruiken om jezelf te beschermen tegen dergelijke aanvallen.
As jy enige URL kan invoeg in 'n willekeurige **`<a href=`** tag wat die **`target="_blank"`** en **`rel="opener"`** eienskappe bevat, kyk na die **volgende bladsy om hierdie gedrag uit te buit**:
Eerstens, kyk na hierdie bladsy ([https://portswigger.net/web-security/cross-site-scripting/cheat-sheet](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)) vir nuttige **"on" event handlers**.\
In die geval dat daar 'n swartlys is wat voorkom dat jy hierdie event handlers kan skep, kan jy die volgende omseilings probeer:
Vanaf [**hier**](https://portswigger.net/research/exploiting-xss-in-hidden-inputs-and-meta-tags) **is dit nou moontlik om verborge invoere te misbruik met:**
Vanaf [**hier**](https://portswigger.net/research/xss-in-hidden-input-fields): Jy kan 'n **XSS-payload binne 'n verborge atribuut** uitvoer, mits jy die **slagoffer** kan **oortuig** om die **sleutelkombinasie** te druk. Op Firefox Windows/Linux is die sleutelkombinasie **ALT+SHIFT+X** en op OS X is dit **CTRL+ALT+X**. Jy kan 'n ander sleutelkombinasie spesifiseer deur 'n ander sleutel in die toegangssleutel-atribuut te gebruik. Hier is die vektor:
As jy 'n **XSS in 'n baie klein deel** van die web gevind het wat enige vorm van interaksie vereis (miskien 'n klein skakel in die voetskrif met 'n onmouseover-element), kan jy probeer om **die spasie wat die element inneem te wysig** om die waarskynlikheid te maksimeer dat die skakel geaktiveer word.
Byvoorbeeld, jy kan enige stylings in die element byvoeg soos: `position: fixed; top: 0; left: 0; width: 100%; height: 100%; background-color: red; opacity: 0.5`
Hierdie truuk is geneem van [https://medium.com/@skavans\_/improving-the-impact-of-a-mouse-related-xss-with-styling-and-css-gadgets-b1e5dec2f703](https://medium.com/@skavans\_/improving-the-impact-of-a-mouse-related-xss-with-styling-and-css-gadgets-b1e5dec2f703)
In hierdie geval sal jou **inset** binne die JS-kode van 'n `.js`-lêer of tussen `<script>...</script>`-etikette of tussen HTML-gebeure wat JS-kode kan uitvoer of tussen eienskappe wat die `javascript:`-protokol aanvaar, weerspieël word.
As jou kode binne `<script> [...] var input = 'weerspiegelde data' [...] </script>` ingevoeg word, kan jy maklik die sluiting van die `<script>`-etiket **ontsnap**:
Let wel dat ons in hierdie voorbeeld **nie eens die enkel aanhalingsteken gesluit het nie**. Dit is omdat **HTML-analise eers deur die blaaier uitgevoer word**, wat betrokke is by die identifisering van bladsyelemente, insluitend blokke van skrips. Die analisering van JavaScript om die ingeslote skrips te verstaan en uit te voer, word eers daarna uitgevoer.
As `<>` gesaniteer word, kan jy steeds die tekenreekse **ontvlug** waar jou insette **geplaas** word en **arbitrêre JS uitvoer**. Dit is belangrik om die JS-sintaksie **te herstel**, want as daar enige foute is, sal die JS-kode nie uitgevoer word nie:
Om **strings** te konstrueer, aanvaar JS ook **backticks****` `` `** afgesien van enkel- en dubbele aanhalingstekens. Dit staan bekend as sjabloonliterale omdat dit toelaat om **ingebedde JS-uitdrukkings** te gebruik deur middel van die sintaksis `${ ... }`.\
Daarom, as jy vind dat jou inset binne 'n JS-string wat backticks gebruik, **weerspieël** word, kan jy die sintaksis `${ ... }` misbruik om **willekeurige JS-kode** uit te voer:
In sommige gevallen kan een aanvaller proberen om kwaadaardige code uit te voeren door deze te coderen voordat deze naar de server wordt verzonden. Dit kan worden gedaan om detectie te voorkomen of om beveiligingsmaatregelen te omzeilen.
Een veelvoorkomende techniek is het gebruik van URL-encodering om speciale tekens te vervangen door hun hexadecimale equivalent. Bijvoorbeeld, de code `<script>alert('XSS')</script>` kan worden gecodeerd als `%3Cscript%3Ealert%28%27XSS%27%29%3C%2Fscript%3E`.
Deze gecodeerde code kan vervolgens worden ingevoegd in een kwetsbaar veld op een webpagina, zoals een invoerveld of een querystring-parameter. Wanneer de server de gecodeerde code ontvangt en decodeert, wordt de kwaadaardige code uitgevoerd.
Om deze techniek te misbruiken, moet de aanvaller weten hoe de server de gecodeerde invoer decodeert. Dit kan worden ontdekt door het bestuderen van de client-side code of door het uitvoeren van reverse engineering op de server-side code.
Het is belangrijk voor ontwikkelaars om invoer correct te valideren en te saneren om dit soort aanvallen te voorkomen. Het gebruik van een Content Security Policy (CSP) kan ook helpen bij het beperken van de impact van gecodeerde code-uitvoering.
Unicode-karakters kunnen worden gebruikt om JavaScript-code te coderen en uit te voeren in een XSS-aanval. Dit kan worden gedaan door speciale Unicode-karakters te gebruiken die lijken op normale ASCII-karakters, maar een andere betekenis hebben in JavaScript.
Om Unicode-encode JS-uitvoering uit te voeren, moet je de JavaScript-code die je wilt uitvoeren, omzetten naar Unicode-tekens. Dit kan worden gedaan met behulp van online tools of door handmatig de Unicode-waarden van elk karakter te vinden en deze te vervangen.
Hier is een voorbeeld van hoe je Unicode-encode JS-uitvoering kunt gebruiken in een XSS-aanval:
```html
<script>
var payload = "\u0061\u006c\u0065\u0072\u0074('\u0048\u0061\u0063\u006b\u0065\u0064\u0021')";
In dit voorbeeld wordt de JavaScript-functie `alert()` uitgevoerd door de Unicode-gecodeerde versie van de code te gebruiken. Het gebruik van Unicode-tekens maakt het moeilijker voor filters om de kwaadaardige code te detecteren.
Het is belangrijk op te merken dat Unicode-encode JS-uitvoering niet altijd succesvol zal zijn, omdat sommige filters specifiek zijn ontworpen om dergelijke aanvallen te detecteren. Het is ook belangrijk om ethische hackingpraktijken te volgen en alleen toestemming te verkrijgen om deze technieken te gebruiken tijdens legitieme pentestactiviteiten.
In sommige gevallen kan het nodig zijn om spaties te vervangen in JavaScript-code om XSS-aanvallen te omzeilen. Dit kan handig zijn wanneer een beveiligingsmechanisme spaties detecteert en blokkeert.
Hier zijn enkele mogelijke manieren om spaties te vervangen:
1.**Unicode-ontsnapping**: Spaties kunnen worden vervangen door hun Unicode-ontsnappingsreeksen, zoals `\u0020` voor een enkele spatie. Dit kan helpen om de detectie van spaties te omzeilen.
2.**HTML-entiteiten**: Spaties kunnen worden vervangen door hun HTML-entiteitsvormen, zoals ` ` voor een enkele spatie. Dit kan ook helpen om spaties te omzeilen.
3.**Stringconcatenatie**: Spaties kunnen worden vervangen door een lege tekenreeks `''` of andere karakters, zoals `+` of `%20`, afhankelijk van de context van de code.
Het is belangrijk op te merken dat deze technieken afhankelijk zijn van de specifieke implementatie van het beveiligingsmechanisme en mogelijk niet altijd effectief zijn. Het is raadzaam om andere XSS-mitigatiestrategieën te overwegen en te testen om een robuuste beveiliging te waarborgen.
JavaScript maak gebruik van verskillende soorte spasies om kode te formateer en leesbaar te maak. Hier is 'n paar belangrike spasies om in gedagte te hou:
- **Leë spasies**: Dit is die tradisionele spasies wat gebruik word om leë ruimtes tussen woorde en uitdrukkings te skep. Dit het geen invloed op die uitvoering van die kode nie.
- **Nuwe lyn spasies**: Hierdie spasies word gebruik om kode oor verskillende lyne te verdeel. Dit help om die kode leesbaar te hou, maar het geen invloed op die uitvoering daarvan nie.
- **Tab spasies**: Tabs word gebruik om blokke van kode te identifiseer en te groepeer. Dit help om die struktuur van die kode te verduidelik, maar het geen invloed op die uitvoering daarvan nie.
- **Kommentaar spasies**: Kommentaar spasies word gebruik om kommentaar by die kode te voeg. Dit help om die kode te dokumenteer en te verduidelik, maar het geen invloed op die uitvoering daarvan nie.
Dit is belangrik om spasies korrek te gebruik om die leesbaarheid van jou JavaScript-kode te verbeter.
Wanneer 'n kommentaarveld op 'n webwerf nie behoorlik gevalideer word nie, kan dit 'n potensiële veiligheidsrisiko skep. 'n Aanvaller kan kwaadwillige Javascript-kode insluit binne 'n kommentaarveld, wat uitgevoer kan word wanneer die webwerf dit verwerk. Hierdie tipe aanval staan bekend as 'n XSS (Cross-Site Scripting) aanval.
Wanneer die webwerf hierdie kommentaarveld verwerk, sal die Javascript-kode uitgevoer word en 'n waarskuwing met die teks "XSS aanval" sal vertoon word. Dit kan gevaarlik wees, veral as die aanvaller kwaadwillige kode insluit wat persoonlike inligting steel of die webwerf se funksionaliteit ontwrig.
Om XSS-aanvalle te voorkom, moet webwerwe behoorlike invoervalidering en ontsmetting toepas op alle gebruikersinsette, insluitend kommentaarvelde. Dit sal help om die uitvoering van kwaadwillige kode te voorkom en die veiligheid van die webwerf te verseker.
In JavaScript is dit moontlik om 'n funksie op te roep sonder om hakies te gebruik. Hierdie tegniek maak gebruik van die feit dat JavaScript die funksie self as 'n waarde behandel.
Byvoorbeeld, in plaas van `myFunction()`, kan jy `myFunction` skryf. Hierdie sintaksis sal die funksie nie onmiddellik uitvoer nie, maar eerder die funksie self as 'n waarde teruggee.
Dit is belangrik om op te let dat hierdie tegniek slegs werk as die funksie geen argumente aanvaar nie. As die funksie argumente vereis, sal jy steeds hakies moet gebruik.
Reflect.apply.call`${alert}${window}${[1337]}` //Pass the function to call (“alert”), then the “this” value to that function (“window”) which avoids the illegal invocation error and finally an array of arguments to pass to the function.
Reflect.set.call`${location}${'href'}${'javascript:alert\x281337\x29'}` // It requires a valid object in the first argument (“location”), a property in the second argument and a value to assign in the third.
// The “has instance” symbol allows you to customise the behaviour of the instanceof operator, if you set this symbol it will pass the left operand to the function defined by the symbol.
Daar is **JS-kode** wat **onveilig deur 'n aanvaller beheerde data** soos `location.href` gebruik. 'n Aanvaller kan dit misbruik om willekeurige JS-kode uit te voer.\
**As gevolg van die uitbreiding van die verduideliking van** [**DOM kwesbaarhede is dit na hierdie bladsy verskuif**](dom-xss.md)**:**
Daar sal jy 'n gedetailleerde **verduideliking van wat DOM kwesbaarhede is, hoe hulle veroorsaak word, en hoe om dit uit te buit** vind.\
Moenie ook vergeet dat **aan die einde van die genoemde pos** 'n verduideliking oor [**DOM Clobbering-aanvalle**](dom-xss.md#dom-clobbering) gevind kan word.
Jy kan nagaan of die **weerspieëlde waardes** in die bediener (of aan die kliëntkant) **genormaliseerde Unicode** is en hierdie funksionaliteit misbruik om beskerming te omseil. [**Vind 'n voorbeeld hier**](../unicode-injection/#xss-cross-site-scripting).
As gevolg van **RoR massa-toewysing** word aanhalingstekens ingevoeg in die HTML en dan word die aanhalingstekenbeperking omseil en addisionele velde (onfocus) kan binne die tag bygevoeg word.\
Vormvoorbeeld ([van hierdie verslag](https://hackerone.com/reports/709336)), as jy die lading stuur:
In this example, the onfocus attribute triggers an alert when the input field is focused, while the onload attribute triggers another alert when the page finishes loading.
In this example, the onfocus attribute triggers an alert when the input field is focused, while the onmouseover attribute triggers another alert when the mouse pointer is moved over the input field.
In this example, the onfocus attribute triggers an alert when the input field is focused, while the onclick attribute triggers another alert when the input field is clicked.
These combinations can be used to create more sophisticated XSS attacks by chaining multiple events together. It is important to be aware of these possibilities when testing for XSS vulnerabilities.
As jy vind dat jy **kopters kan inspuit in 'n 302-omleiding-antwoord**, kan jy probeer om die webblaaier **arbitrêre JavaScript te laat uitvoer**. Dit is **nie eenvoudig nie**, aangesien moderne webblaaier nie die HTTP-antwoordliggaam interpreteer as die HTTP-antwoordstatuskode 'n 302 is nie, dus is 'n kruiswebkripsing-lading nutteloos.
In [**hierdie verslag**](https://www.gremwell.com/firefox-xss-302) en [**hierdie een**](https://www.hahwul.com/2020/10/03/forcing-http-redirect-xss/) kan jy lees hoe jy verskeie protokolle binne die Ligging-kopter kan toets en sien of enige van hulle die webblaaier toelaat om die XSS-lading binne die liggaam te ondersoek en uit te voer.\
As jy die **terugroepfunksie** wat JavaScript gaan **uitvoer**, kan aandui, beperk tot daardie karakters. [**Lees hierdie gedeelte van hierdie berig**](./#javascript-function) om uit te vind hoe om van hierdie gedrag misbruik te maak.
(Vanaf [**hierdie bron**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) As jy probeer om 'n skrips te laai met 'n **inhoudstipe** soos `application/octet-stream`, sal Chrome die volgende fout gooi:
> Refused to execute script from ‘[https://uploader.c.hc.lc/uploads/xxx'](https://uploader.c.hc.lc/uploads/xxx') because its MIME type (‘application/octet-stream’) is not executable, and strict MIME type checking is enabled.
Die enigste **Inhoudstipes** wat Chrome sal ondersteun om 'n **gelaai skrips** uit te voer, is diegene binne die konstante **`kSupportedJavascriptTypes`** vanaf [https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third\_party/blink/common/mime\_util/mime\_util.cc](https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third\_party/blink/common/mime\_util/mime\_util.cc)
(Vanaf [**hier**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) So, watter tipes kan aangedui word om 'n skripsie te laai?
* **module** (verstek, niks om te verduidelik nie)
* [**webbundle**](https://web.dev/web-bundles/): Web Bundles is 'n funksie wat jy 'n stel data (HTML, CSS, JS...) saam kan verpak in 'n **`.wbn`** lêer.
Hierdie gedrag is gebruik in [**hierdie skryfstuk**](https://github.com/zwade/yaca/tree/master/solution) om 'n biblioteek te herkartografeer na eval om dit te misbruik en XSS te veroorsaak.
* [**speculationrules**](https://github.com/WICG/nav-speculation)**:** Hierdie funksie is hoofsaaklik ontwerp om sekere probleme wat deur vooraf-rendering veroorsaak word, op te los. Dit werk soos volg:
(Vanaf [**hier**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) Die volgende inhoudstipes kan XSS uitvoer in alle webblaaier:
In ander webblaaier kan ander **`Inhoudstipes`** gebruik word om willekeurige JS uit te voer, kyk: [https://github.com/BlackFan/content-type-research/blob/master/XSS.md](https://github.com/BlackFan/content-type-research/blob/master/XSS.md)
Wanneer iets soos **`"some {{template}} data".replace("{{template}}", <user_input>)`** gebruik word. Die aanvaller kan [**spesiale stringvervanging**](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global\_Objects/String/replace#specifying\_a\_string\_as\_the\_replacement) gebruik om te probeer om sekere beskermings te omseil: ``"123 {{template}} 456".replace("{{template}}", JSON.stringify({"name": "$'$`alert(1)//"}))``
Byvoorbeeld in [**hierdie skryfstuk**](https://gitea.nitowa.xyz/nitowa/PlaidCTF-YACA), is dit gebruik om 'n JSON-string binne 'n skripsie te ontsnap en willekeurige kode uit te voer.
As **alles ongedefinieerd is** voor die uitvoering van onbetroubare kode (soos in [**hierdie verslag**](https://blog.huli.tw/2022/02/08/en/what-i-learned-from-dicectf-2022/#miscx2fundefined55-solves)), is dit moontlik om nuttige objekte "uit niks" te genereer om die uitvoering van willekeurige onbetroubare kode te misbruik:
[Volgens hierdie](https://stackoverflow.com/questions/28955047/why-does-a-module-level-return-statement-work-in-node-js/28955050#28955050) word modules deur Node.js binne 'n funksie gewikkel, soos hierdie:
Daarom, as ons van daardie module **'n ander funksie kan oproep**, is dit moontlik om `arguments.callee.caller.arguments[1]` van daardie funksie te gebruik om toegang te verkry tot **`require`**:
Op 'n soortgelyke manier as die vorige voorbeeld, is dit moontlik om **fouthanteraars te gebruik** om toegang te verkry tot die **wrapping** van die module en die **`require`**-funksie te kry:
* Meer gesofistikeerde JSFuck: [https://medium.com/@Master\_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce](https://medium.com/@Master\_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce)
Jy **sal nie toegang hê tot die koekies vanaf JavaScript** as die HTTPOnly-vlag in die koekie ingestel is nie. Maar hier het jy [sommige maniere om hierdie beskerming te omseil](../hacking-with-cookies/#httponly) as jy gelukkig genoeg is.
Om interne IP-adresse te vind, kan jy die volgende tegnieke gebruik:
#### 1. DNS-terugvoer
As jy toegang het tot 'n DNS-diens wat interne IP-adresse terugvoer, kan jy dit gebruik om die interne IP-adresse van 'n teikenstelsel te vind. Voer 'n DNS-navraag uit vir die teikenstelsel se domeinnaam en kyk na die terugvoer vir enige interne IP-adresse wat verskyn.
Deur ARP-spoofing te gebruik, kan jy die ARP-tabel van 'n teikenstelsel manipuleer om die interne IP-adresse van ander toestelle in die netwerk te sien. Deur die ARP-tabel te onderskep en te analiseer, kan jy die interne IP-adresse van die teikenstelsel en ander toestelle in die netwerk vind.
#### 3. Netwerkkaartspoofing
Met netwerkkaartspoofing kan jy jou netwerkkaart se MAC-adres vervals om toegang te verkry tot die interne netwerk. Deur jou netwerkkaart se MAC-adres te vervals, kan jy die interne IP-adresse van ander toestelle in die netwerk sien.
#### 4. Netwerkverkenning
Deur netwerkverkenningstegnieke soos portskandering en netwerkkaartspoofing te gebruik, kan jy die interne IP-adresse van toestelle in die netwerk identifiseer. Deur die netwerk te skandeer vir aktiewe toestelle en die IP-adresse te analiseer, kan jy die interne IP-adresse van die teikenstelsel vind.
Onthou om altyd wettige en etiese hackingpraktyke te volg en slegs toestemming te verkry om hierdie tegnieke op 'n netwerk toe te pas.
Hierdie tegniek maak gebruik van 'n fetch-versoek om te bepaal of 'n spesifieke poort oop of toe is op 'n teikenbediener. Dit kan nuttig wees tydens pentesting om te bepaal watter poorte oop is en moontlike aanvalsveilighede te identifiseer.
Vervang `target-server.com` met die teikenbediener se URL en `port` met die poortnommer wat jy wil skandeer.
#### Opmerkings
- Hierdie tegniek maak gebruik van die `fetch`-funksie in JavaScript om 'n HTTP-versoek na die teikenbediener te stuur.
- As die versoek suksesvol is en die teikenbediener 'n geldige antwoord gee (HTTP-statuskode 200), beteken dit dat die poort oop is.
- As die versoek nie suksesvol is nie (HTTP-statuskode 404, 500, ens.), beteken dit dat die poort toe is of dat daar 'n fout opgetree het.
- Dit is belangrik om te onthou dat hierdie tegniek slegs die status van die poort bepaal en nie die veiligheid van die teikenbediener self beoordeel nie.
Hierdie tegniek maak gebruik van websockets om 'n poortskandering uit te voer op 'n doelwitbediener. Websockets is 'n kommunikasieprotokol wat toelaat vir vol-duplex kommunikasie tussen 'n kliënt en 'n bediener oor 'n enkele TCP-verbinding.
#### Hoe werk dit?
1. Die aanvaller stel 'n webtoepassing op wat websockets ondersteun.
2. Die aanvaller maak 'n verbinding met die webtoepassing en stel 'n websockets-kanaal op.
3. Die aanvaller stuur 'n versoek na die doelwitbediener se poort om te kyk of dit oop of gesluit is.
4. As die poort oop is, sal die bediener 'n suksesvolle verbinding bevestig.
5. Die aanvaller kan dan die resultate van die poortskandering analiseer en verdere aanvalstegnieke implementeer.
In hierdie voorbeeld maak die aanvaller 'n websockets-verbinding met die doelwitbediener en stuur 'n HTTP-versoek na die doelwitbediener se poort. As die bediener 'n suksesvolle verbinding bevestig deur 'n "200 OK" antwoord terug te stuur, weet die aanvaller dat die poort oop is.
Hersien die lys van verbode porte in Chrome [**hier**](https://src.chromium.org/viewvc/chrome/trunk/src/net/base/net\_util.cc) en in Firefox [**hier**](https://www-archive.mozilla.org/projects/netlib/portbanning#portlist).
Auto-fill passwords is 'n handige funksie wat deur baie webblaaierplatforms aangebied word. Dit stel gebruikers in staat om wagwoorde outomaties in te vul wanneer hulle aanmeld by 'n webwerf. Hierdie funksie kan egter 'n veiligheidsrisiko inhou, veral as dit gekombineer word met 'n XSS-aanval (Cross-Site Scripting).
Met 'n XSS-aanval kan 'n aanvaller skadelike kode insluit in 'n webwerf se invoerveld. As 'n gebruiker dan die webwerf besoek en die invoerveld gebruik, sal die skadelike kode uitgevoer word. As die webwerf 'n outomatiese invul wagwoordfunksie het, kan die aanvaller die wagwoord van die gebruiker onderskep en dit na 'n eksterne bediener stuur.
Om outomatiese invul wagwoorde te onderskep, kan 'n aanvaller gebruik maak van verskillende tegnieke, soos die insluiting van 'n skadelike skripsie in 'n webwerf se invoerveld of die gebruik van 'n skadelike URL wat die wagwoord onderskep wanneer dit outomaties ingevul word.
Dit is belangrik vir webwerfontwikkelaars om bewus te wees van hierdie risiko en om gepaste maatreëls te tref om dit te voorkom. Dit kan insluit die korrekte hantering van gebruikersinsette, die gebruik van beveiligingsmaatreëls soos inhoudsbeveiligingsbeleide (Content Security Policy) en die deaktivering van outomatiese invul wagwoorde.
Gebruikers kan ook hulself beskerm teen hierdie tipe aanvalle deur nie outomatiese invul wagwoorde te gebruik nie en deur bewus te wees van die risiko's van XSS-aanvalle. Dit sluit in om nie op verdagte skakels te klik nie en om slegs vertroude webwerwe te besoek.
As 'n pentester is dit belangrik om bewus te wees van hierdie tegniek en om dit te gebruik om die veiligheid van 'n webwerf te evalueer.
Wanneer enige data in die wagwoordveld ingevoer word, word die gebruikersnaam en wagwoord na die aanvaller se bediener gestuur, selfs as die klient 'n gestoorde wagwoord kies en niks skryf nie, sal die geloofsbriewe uitgelek word.
PostMessage is 'n API wat gebruik word om boodskappe tussen vensters te stuur in 'n webtoepassing. Dit kan egter ook misbruik word deur 'n aanvaller om boodskappe te steel wat tussen vensters gestuur word.
#### Hoe werk dit?
Wanneer 'n webtoepassing PostMessage gebruik om 'n boodskap na 'n ander venster te stuur, word die boodskap as 'n objek gestruktureer en deur die `postMessage`-funksie gestuur. Die ontvangende venster kan dan die boodskap onderskep en die inhoud daarvan gebruik.
'n Aanvaller kan hierdie funksionaliteit misbruik deur 'n kwaadwillige webtoepassing te skep wat 'n venster oopmaak en 'n PostMessage-boodskap stuur na 'n ander venster wat die aanvaller wil teiken. As die aanvaller die boodskap kan onderskep, kan hy die inhoud daarvan steel en dit vir sy eie voordeel gebruik.
#### Hoe om PostMessage-diefstal te voorkom?
Om PostMessage-diefstal te voorkom, moet die volgende maatreëls in ag geneem word:
1. Vertrou nie blindeel vensters nie: Moenie blindeel vensters oopmaak en PostMessage-boodskappe stuur sonder om die inhoud van die venster te verifieer nie. Dit kan aanvallers die geleentheid bied om boodskappe te steel.
2. Verifieer die oorsprong van die venster: Voordat 'n PostMessage-boodskap aan 'n ander venster gestuur word, moet die oorsprong van die venster geverifieer word. Dit kan gedoen word deur die `origin`-parameter van die `postMessage`-funksie te gebruik.
3. Gebruik 'n veilige kommunikasiekanale: As die PostMessage-boodskap gevoelige inligting bevat, moet 'n veilige kommunikasiekanale, soos HTTPS, gebruik word om die boodskap te stuur. Dit sal die risiko van inligtingsoortdring verminder.
Deur hierdie maatreëls te volg, kan die risiko van PostMessage-diefstal verminder word en kan die veiligheid van webtoepassings verbeter word.
<!-- html5sec - eventhandler - element fires an "onpageshow" event without user interaction on all modern browsers. This can be abused to bypass blacklists as the event is not very well known. -->
<!-- ... add more CDNs, you'll get WARNING: Tried to load angular more than once if multiple load. but that does not matter you'll get a HTTP interaction/exfiltration :-]... -->
Vanaf [**hierdie skryfstuk**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-piyosay) is dit moontlik om te leer dat selfs al verdwyn sommige waardes uit JS, dit steeds moontlik is om hulle te vind in JS-eienskappe in verskillende objekte. Byvoorbeeld, 'n invoer van 'n REGEX is steeds moontlik om dit te vind nadat die waarde van die invoer van die regex verwyder is:
As 'n webbladsy 'n PDF skep deur gebruikersbeheerde insette te gebruik, kan jy probeer om die bot wat die PDF skep, te **verneuk** om arbitrêre JS-kode uit te voer.\
As die **PDF-skepper-bot** 'n soort **HTML**-**tags** vind, gaan dit hulle **interpreteer**, en jy kan hierdie gedrag **misbruik** om 'n **Bediener XSS** te veroorsaak.
AMP, gemik op die versnelling van webbladsy-prestasie op mobiele toestelle, inkorporeer HTML-tags aangevul deur JavaScript om funksionaliteit te verseker met die klem op spoed en veiligheid. Dit ondersteun 'n verskeidenheid komponente vir verskillende funksies, toeganklik via [AMP-komponente](https://amp.dev/documentation/components/?format=websites).
Die [**AMP vir E-pos**](https://amp.dev/documentation/guides-and-tutorials/learn/email-spec/amp-email-format/) formaat brei spesifieke AMP-komponente uit na e-posse, wat ontvangers in staat stel om direk met inhoud in hul e-posse te interaksieer.
**Bug bounty wenk**: **teken aan** vir **Intigriti**, 'n premium **bug bounty platform geskep deur hackers, vir hackers**! Sluit vandag by ons aan by [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) en begin om belonings tot **$100,000** te verdien!
<summary><strong>Leer AWS-hacking van nul tot held met</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* As jy jou **maatskappy geadverteer wil sien in HackTricks** of **HackTricks in PDF wil aflaai**, kyk na die [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
* Kry die [**amptelike PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Ontdek [**The PEASS Family**](https://opensea.io/collection/the-peass-family), ons versameling eksklusiewe [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Sluit aan by die** 💬 [**Discord-groep**](https://discord.gg/hRep4RUj7f) of die [**telegram-groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Deel jou hacktruuks deur PR's in te dien by die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github-repos.
