1. Kontroleer of **enige waarde wat jy beheer** (_parameters_, _pad_, _koppe_?, _koekies_?) in die HTML **weerspieël** word of deur **JS**-kode **gebruik** word.
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 geïnterpreteer (_AngularJS_, _VueJS_, _Mavo_...), jy kan 'n [**Kliëntkant-sjablooninspuiting**](../client-side-template-injection-csti.md) misbruik.
5. As jy nie HTML-etikette kan skep wat JS-kode uitvoer nie, kan jy 'n [**Hangende Merkteken - HTML-skriptlose inspuiting**](../dangling-markup-html-scriptless-injection/) misbruik?
* **Tussenliggend weerspieël**: As jy vind dat die waarde van 'n parameter of selfs die pad in die webbladsy weerspieël word, kan jy 'n **Weerspieëlde XSS** uitbuit.
* **Gestoor en weerspieël**: As jy vind dat 'n waarde wat deur jou beheer word op die bediener gestoor word en elke keer as jy 'n bladsy besoek weerspieël word, kan jy 'n **Gestoorde XSS** uitbuit.
Wanneer jy probeer om 'n XSS uit te buit, is die eerste ding wat jy moet weet **waar jou inset weerspieël word**. Afhangende van die konteks, sal jy arbitrêre JS-kode op verskillende maniere kan uitvoer.
As jou inset **weerspieël word op die rou HTML**-bladsy, sal jy enige **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.\
2. As jy **uit die eienskap kan ontsnap maar nie uit die etiket nie** (`>` is gekodeer of verwyder), 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 verwyder), dan afhangende van **watter eienskap** jou waarde weerspieël word in **as jy al die waarde beheer of net 'n deel** jy kan dit misbruik. Byvoorbeeld, as jy 'n gebeurtenis soos `onclick=` beheer, sal jy arbitrêre kode kan laat 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 soort sosiale ingenieur 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 as jou inset binne enige soort aanhalingstekens is, kan jy probeer om `</script>` in te spuit en te ontsnap uit hierdie konteks. Dit werk omdat die **blaaier eers die HTML-etikette sal ontled** en dan die inhoud, daarom sal dit nie agterkom dat jou ingespotte `</script>` etiket binne die HTML-kode is nie.
* As dit weerspieël word **binne 'n JS-string** en die vorige truuk nie werk nie, sal jy die string moet **verlaat**, jou kode **uitvoer** en die JS-kode **herkonstrueer** (as daar enige fout is, sal dit nie uitgevoer word nie):
* As dit weerspieël word binne sjabloenliterale kan jy **JS-uitdrukkings** inbed met behulp van `${ ... }` sintaksis: `` var greetings = `Hello, ${alert(1)}` ``
Javascript Hoisting verwys na die geleentheid om **funksies, veranderlikes of klasse te verklaar nadat hulle gebruik is sodat jy scenarios kan misbruik waar 'n XSS onverklaarde veranderlikes of funksies gebruik.**\
Verskeie webbladsye het eindpunte wat **die naam van die funksie aanvaar as parameter om uit te voer**. 'n Algemene voorbeeld wat in die wild gesien word, 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 paramwaarde te wysig** (byvoorbeeld na 'Vulnerable') en in die konsole te kyk vir foute soos:
Indien dit vatbaar is, kan jy dalk 'n waarskuwing **trigger** deur net die waarde te stuur: **`?callback=alert(1)`**. Dit is egter baie algemeen dat hierdie eindpunte die inhoud **valideer** om slegs letters, syfers, kolletjies en onderstrepe toe te laat (**`[\w\._]`**).
Nieteenstaande daardie beperking is dit steeds moontlik om sekere aksies uit te voer. Dit is omdat jy daardie geldige karakters kan gebruik om enige element in die DOM **te benader**:
Gewoonlik is die eindpunte wat die aangeduide funksie uitvoer eindpunte sonder baie 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** van 'n aanvaller beheerde data gebruik 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 meer.\
Wanneer jou inset **binne die HTML-bladsy** gereflekteer word of jy HTML-kode kan ontsnap en inspuit in hierdie konteks, is die **eerste** ding wat jy moet doen, kyk of jy `<` kan misbruik om nuwe etikette te skep: Probeer net om daardie **karakter** te **reflekteer** en kyk of dit **HTML-geënkripteer** word of **verwyder** of as dit sonder veranderinge **gereflekteer** word. **Slegs in die laaste geval sal jy hierdie geval kan uitbuit**.\
Vir hierdie gevalle moet jy ook in gedagte hou [**Kliëntkant-sjablooninspuiting**](../client-side-template-injection-csti.md)**.**\
Sodra jy **geïdentifiseer het watter tags toegelaat word**, sal jy nodig hê om **brute-force kenmerke/gebeurtenisse** binne die gevonde geldige tags 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 van hulle met Burp intruder en kontroleer of enige tags nie as skadelik deur die WAF ontdek is nie. Sodra jy ontdek het watter tags jy kan gebruik, kan jy **brute force al die gebeurtenisse** gebruik deur die geldige tags (op dieselfde webbladsy klik op _**Kopieer gebeurtenisse 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` kenmerk. In die XSS versoek, moet jy die URL eindig met `#` om die bladsy **te fokus op daardie objek** en die kode **uit te voer**:
**Meer klein XSS vir verskillende omgewings** lading [**kan hier gevind word**](https://github.com/terjanq/Tiny-XSS-Payloads) en [**hier**](https://tinyxss.terjanq.me).
Indien om die kwesbaarheid uit te buit jy die **gebruiker nodig het om op 'n skakel of 'n vorm** met vooraf ingevulde data te kliek, kan jy probeer om [**Clickjacking te misbruik**](../clickjacking.md#xss-clickjacking) (as die bladsy kwesbaar is).
Indien jy net dink dat **dit onmoontlik is om 'n HTML-tag te skep met 'n attribuut om JS-kode uit te voer**, moet jy [**Danglig Markup**](../dangling-markup-html-scriptless-injection/) nagaan omdat jy die kwesbaarheid kan **uitbuit** sonder om **JS**-kode uit te voer.
Indien jy **binne 'n HTML-tag** is, kan jy eerste probeer om te **ontsnap** van die tag en van die tegnieke wat genoem word in die [vorige afdeling](./#injecting-inside-raw-html) gebruik maak om JS-kode uit te voer.\
As jy **nie kan ontsnap van die tag nie**, kan jy nuwe eienskappe binne die tag skep om te probeer om JS-kode uit te voer, byvoorbeeld deur 'n sekere lading te gebruik (_let daarop dat in hierdie voorbeeld dubbele aanhalingstekens gebruik word om te ontsnap van die attribuut, jy sal hulle nie nodig hê as jou inset direk binne die tag weerspieël word_):
Selfs as jy **nie kan ontsnap van die attribuut nie** (`"` word gekodeer of verwyder), afhangende van **watter attribuut** jou waarde weerspieël waaroor jy beheer het, 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 arbitêre kode uit te voer wanneer dit geklik word.\
'n Ander interessante **voorbeeld** is die attribuut `href`, waar jy die `javascript:` protokol kan gebruik om arbitêre kode uit te voer: **`href="javascript:alert(1)"`**
Die **HTML-gekodeerde karakters** binne die waarde van HTML-etiketatribute word tydens uitvoering **gedekodeer**. Daarom sal iets soos die volgende geldig wees (die lading is vetgedruk): `<a id="author" href="http://none" onclick="var tracker='http://foo?`**`'-alert(1)-'`**`';">Go Back </a>`
Daar kan jy die protokolle **`javascript:`** of **`data:`** op sommige plekke gebruik 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 attribuut `href` aanvaar** en in **die meeste** van die tags wat die **attribuut `src`** aanvaar (maar nie `<img`)
Verder is daar nog 'n **mooi truuk** vir hierdie gevalle: **Selfs as jou inset binne `javascript:...` URL-gekodeer is, sal dit URL-dekodeer word voordat dit uitgevoer word.** Dus, as jy moet **ontsnapping** van die **string** doen met 'n **enkellid** en jy sien dat **dit URL-gekodeer word**, onthou dat **dit nie saak maak nie,** dit sal tydens die **uitvoertyd** geïnterpreteer word as 'n **enkellid**.
Merk op dat as jy probeer om **beide**`URLencode + HTMLencode` in enige volgorde te gebruik om die **payload** te kodeer, sal dit **nie werk nie**, maar jy kan **hulle binne die payload meng**.
Indien jy enige URL kan inspuit in 'n willekeurige **`<a href=`** tag wat die **`target="_blank" en rel="opener"`** eienskappe bevat, kontroleer die **volgende bladsy om hierdie gedrag te misbruik**:
Eerstens, kontroleer 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" gebeurtenishanterers**.\
In geval daar 'n swartlys is wat voorkom dat jy hierdie gebeurtenishanterers 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-lading binne 'n verborge attribuut** 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 attribuut te gebruik. Hier is die vektor:
Verskeie truuks met die gebruik van verskillende enkodering is reeds blootgestel binne hierdie afdeling. Gaan **terug om te leer waar jy kan gebruik:**
As jy 'n **XSS in 'n baie klein deel** van die web gevind het wat 'n soort interaksie vereis (miskien 'n klein skakel in die voetnota met 'n onmouseover element), kan jy probeer om **die spasie wat die element inneem te wysig** om die kanse te maksimeer om die skakel te laat afgaan.
Byvoorbeeld, jy kan bietjie styl by die element voeg 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 **word jou inset** weerspieël binne die JS-kode van 'n `.js` lêer of tussen `<script>...</script>` etikette of tussen HTML-gebeurtenisse wat JS-kode kan uitvoer of tussen eienskappe wat die `javascript:` protokol aanvaar.
As jou kode binne `<script> [...] var input = 'weerspieëlde data' [...] </script>` ingevoeg word, kan jy maklik die **ontsnapping van die sluiting van die `<script>`** etiket:
Merk op dat ons in hierdie voorbeeld selfs die enkel aanhalingsteken **nie eers gesluit het nie**. Dit is omdat **HTML-analise word eerste deur die webblaaier** uitgevoer, wat die identifisering van bladsyelemente insluit, insluitend blokke van skrips. Die analisering van JavaScript om die ingeslote skripte te verstaan en uit te voer, word eers daarna uitgevoer.
As `<>` gesanitiseer word, kan jy steeds die string **ontvlug** waar jou inset is **geleë** 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** saam te stel, behalwe enkel en dubbele aanhalingstekens, aanvaar JS ook **backticks****` `` `**. Dit staan bekend as sjabloonliterale omdat hulle toelaat om **ingeslote JS-uitdrukkings** te gebruik met behulp van `${ ... }`-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:
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** gebruik soos `location.href`. 'n Aanvaller kan dit misbruik om willekeurige JS-kode uit te voer.\
Moenie ook vergeet dat **aan die einde van die genoemde pos** jy 'n verduideliking kan vind oor [**DOM Clobbering aanvalle**](dom-xss.md#dom-clobbering).
As jy 'n XSS kan veroorsaak deur die lading binne 'n koekie te stuur, is dit gewoonlik 'n self-XSS. Maar as jy 'n **kwesbare subdomein vir XSS vind**, kan jy hierdie XSS misbruik om 'n koekie in die hele domein in te spuit en sodoende die koekie XSS in die hoofdomein of ander subdomeine te veroorsaak (diegene wat vatbaar is vir koekie XSS). Hiervoor kan jy die koekie-tossing-aanval gebruik:
Jy kan 'n groot misbruik van hierdie tegniek vind in [**hierdie blogpos**](https://nokline.github.io/bugbounty/2024/06/07/Zoom-ATO.html).
### Stuur jou sessie na die admin
Miskien kan 'n gebruiker sy profiel deel met die admin en as die self-XSS binne die profiel van die gebruiker is en die admin dit toegang gee, sal hy die kwesbaarheid veroorsaak.
### Sessie-weerspieëling
As jy 'n self-XSS vind en die webbladsy het 'n **sessie-weerspieëling vir administrateurs**, wat byvoorbeeld kliënte toelaat om vir hulp te vra en sodat die admin jou kan help, sal hy sien wat jy in jou sessie sien maar vanuit sy sessie.
Jy kan die **administrateur jou self-XSS laat veroorsaak** en sy koekies/sessie steel.
Jy kan nagaan of die **weerspieëlde waardes****unicode-geüniformeer** word op die bediener (of aan die kliëntkant) en hierdie funksionaliteit misbruik om beskermings te omseil. [**Vind 'n voorbeeld hier**](../unicode-injection/#xss-cross-site-scripting).
As gevolg van **RoR mass assignment** word aanhalings in die HTML ingevoeg en dan word die aanhalingsbeperking omseil en addisionele velde (onfocus) kan binne die tag bygevoeg word.\
As jy vind dat jy **koptekste kan inspuit in 'n 302 Herlei-antwoord** kan jy probeer om die browser **willekeurige JavaScript te laat uitvoer**. Dit is **nie triviaal** nie aangesien moderne webblaaier nie die HTTP-antwoordliggaam interpreteer as die HTTP-antwoordstatuskode 'n 302 is nie, so net 'n kruissite-skripsinjeksie-lading is 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-koptekstuk kan toets en sien of enige van hulle die browser toelaat om die XSS-lading binne die liggaam te ondersoek en uit te voer.\
As jy in staat is om die **terugroep** aan te dui wat javascript gaan **uitvoer** beperk tot daardie karakters. [**Lees hierdie afdeling van hierdie pos**](./#javascript-function) om uit te vind hoe om hierdie gedrag te misbruik.
(Van [**hier**](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`** van [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)
(Van [**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?
* [**webbundle**](https://web.dev/web-bundles/): Web Bundles is 'n kenmerk waar jy 'n klomp data (HTML, CSS, JS...) saam in 'n **`.wbn`** lêer kan pakketteer.
Hierdie gedrag is gebruik in [**hierdie skryfstuk**](https://github.com/zwade/yaca/tree/master/solution) om 'n biblioteek te herken aan 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 veroorsaak word deur vooraf-rendering op te los. Dit werk soos volg:
(Van [**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 arbitrêre kode uit te voer.
Indien **alles ongedefinieerd is** voor die uitvoering van onbetroubare kode (soos in [**hierdie uiteensetting**](https://blog.huli.tw/2022/02/08/en/what-i-learned-from-dicectf-2022/#miscx2fundefined55-solves)), is dit moontlik om nuttige voorwerpe "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 aanroep**, 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 kry tot die **omhulsel** 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 in staat wees om die koekies vanaf JavaScript te benader as die HTTPOnly-vlag in die koekie ingestel is nie. Maar hier het jy [sekere maniere om hierdie beskerming te omseil](../hacking-with-cookies/#httponly) as jy genoeg geluk het.
Gaan die lys van verbode porte in Chrome na [**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).
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 uitgefilter 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-kenmerke 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 **robot te mislei** wat die PDF skep om **arbitrêre JS-kode uit te voer**.\
Dus, as die **PDF-skepper-robot** 'n soort **HTML****tags vind**, gaan dit hulle **interpreteer**, en jy kan van hierdie gedrag **misbruik** maak om 'n **Bediener XSS** te veroorsaak.
AMP, gemik op die versnelling van webbladprestasie op mobiele toestelle, sluit HTML-tags aangevul deur JavaScript in om funksionaliteit te verseker met 'n klem op spoed en sekuriteit. Dit ondersteun 'n verskeidenheid komponente vir verskeie kenmerke, 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 interaksioneer.
<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 [**INSKRYWINGSPLANNE**](https://github.com/sponsors/carlospolop)!
* **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 hack-truuks deur PR's in te dien by die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github-opslag.
