mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
311 lines
20 KiB
Markdown
311 lines
20 KiB
Markdown
# Koekies Hacking
|
|
|
|
{{#include ../../banners/hacktricks-training.md}}
|
|
|
|
## Koekie Attribuut
|
|
|
|
Koekies kom met verskeie attribuut wat hul gedrag in die gebruiker se blaaiers beheer. Hier is 'n oorsig van hierdie attribuut in 'n meer passiewe stem:
|
|
|
|
### Vervaldatum en Max-Age
|
|
|
|
Die vervaldatum van 'n koekie word bepaal deur die `Expires` attribuut. Omgekeerd definieer die `Max-age` attribuut die tyd in sekondes totdat 'n koekie verwyder word. **Kies vir `Max-age` aangesien dit meer moderne praktyke weerspieël.**
|
|
|
|
### Domein
|
|
|
|
Die gasheer wat 'n koekie ontvang, word gespesifiseer deur die `Domain` attribuut. Standaard is dit ingestel op die gasheer wat die koekie uitgereik het, sonder om sy subdomeine in te sluit. Wanneer die `Domain` attribuut egter eksplisiet ingestel word, sluit dit ook subdomeine in. Dit maak die spesifikasie van die `Domain` attribuut 'n minder beperkende opsie, nuttig vir scenario's waar koekie deel tussen subdomeine nodig is. Byvoorbeeld, om `Domain=mozilla.org` in te stel, maak koekies beskikbaar op sy subdomeine soos `developer.mozilla.org`.
|
|
|
|
### Pad
|
|
|
|
'n Spesifieke URL-pad wat teenwoordig moet wees in die versoekte URL vir die `Cookie` kop om gestuur te word, word aangedui deur die `Path` attribuut. Hierdie attribuut beskou die `/` karakter as 'n gids skeider, wat ooreenkomste in subgidse moontlik maak.
|
|
|
|
### Bestellingsreëls
|
|
|
|
Wanneer twee koekies dieselfde naam het, word die een wat gekies word om te stuur, gebaseer op:
|
|
|
|
- Die koekie wat die langste pad in die versoekte URL ooreenstem.
|
|
- Die mees onlangs ingestelde koekie as die pades identies is.
|
|
|
|
### SameSite
|
|
|
|
- Die `SameSite` attribuut bepaal of koekies gestuur word op versoeke wat afkomstig is van derdeparty-domeine. Dit bied drie instellings:
|
|
- **Streng**: Beperk die koekie om nie op derdeparty versoeke gestuur te word nie.
|
|
- **Lax**: Laat die koekie toe om gestuur te word met GET versoeke wat deur derdeparty-webwerwe geïnisieer word.
|
|
- **Geen**: Laat die koekie toe om van enige derdeparty-domein gestuur te word.
|
|
|
|
Onthou, terwyl jy koekies konfigureer, kan die begrip van hierdie attribuut help om te verseker dat hulle soos verwag oor verskillende scenario's optree.
|
|
|
|
| **Versoektipe** | **Voorbeeldkode** | **Koekies Gestuur Wanneer** |
|
|
| ---------------- | ---------------------------------- | --------------------- |
|
|
| Skakel | \<a href="...">\</a> | NotSet\*, Lax, None |
|
|
| Prerender | \<link rel="prerender" href=".."/> | NotSet\*, Lax, None |
|
|
| Vorm GET | \<form method="GET" action="..."> | NotSet\*, Lax, None |
|
|
| Vorm POST | \<form method="POST" action="..."> | NotSet\*, None |
|
|
| iframe | \<iframe src="...">\</iframe> | NotSet\*, None |
|
|
| AJAX | $.get("...") | NotSet\*, None |
|
|
| Beeld | \<img src="..."> | NetSet\*, None |
|
|
|
|
Tabel van [Invicti](https://www.netsparker.com/blog/web-security/same-site-cookie-attribute-prevent-cross-site-request-forgery/) en effens gewysig.\
|
|
'n Koekie met _**SameSite**_ attribuut sal **CSRF-aanvalle verminder** waar 'n ingelogde sessie nodig is.
|
|
|
|
**\*Let daarop dat vanaf Chrome80 (feb/2019) die standaard gedrag van 'n koekie sonder 'n koekie samesite** **attribuut sal lax wees** ([https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/](https://www.troyhunt.com/promiscuous-cookies-and-their-impending-death-via-the-samesite-policy/)).\
|
|
Let daarop dat tydelik, na die toepassing van hierdie verandering, die **koekies sonder 'n SameSite** **beleid** in Chrome sal **as Geen behandel word** gedurende die **eerste 2 minute en dan as Lax vir topvlak kruis-web POST versoek.**
|
|
|
|
## Koekies Vlaggies
|
|
|
|
### HttpOnly
|
|
|
|
Dit verhoed dat die **klient** toegang tot die koekie het (Via **Javascript** byvoorbeeld: `document.cookie`)
|
|
|
|
#### **Omseilings**
|
|
|
|
- As die bladsy **die koekies as die antwoord** van 'n versoek stuur (byvoorbeeld in 'n **PHPinfo** bladsy), is dit moontlik om die XSS te misbruik om 'n versoek na hierdie bladsy te stuur en **die koekies** uit die antwoord te **steel** (kyk 'n voorbeeld in [https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/](https://hackcommander.github.io/posts/2022/11/12/bypass-httponly-via-php-info-page/)).
|
|
- Dit kan omseil word met **TRACE** **HTTP** versoeke aangesien die antwoord van die bediener (as hierdie HTTP metode beskikbaar is) die koekies wat gestuur is, sal weerspieël. Hierdie tegniek word **Cross-Site Tracking** genoem.
|
|
- Hierdie tegniek word vermy deur **moderne blaaiers deur nie toe te laat om 'n TRACE** versoek van JS te stuur nie. Daar is egter sekere omseilings in spesifieke sagteware gevind, soos om `\r\nTRACE` in plaas van `TRACE` na IE6.0 SP2 te stuur.
|
|
- 'n Ander manier is die uitbuiting van nul/dag kwesbaarhede van die blaaiers.
|
|
- Dit is moontlik om **HttpOnly koekies** te oorskry deur 'n Koekie Jar oorgeloop aanval uit te voer:
|
|
|
|
{{#ref}}
|
|
cookie-jar-overflow.md
|
|
{{#endref}}
|
|
|
|
- Dit is moontlik om [**Koekie Smuggling**](#cookie-smuggling) aanval te gebruik om hierdie koekies te ekfiltreer.
|
|
|
|
### Veilige
|
|
|
|
Die versoek sal **slegs** die koekie in 'n HTTP versoek stuur as die versoek oor 'n veilige kanaal (tipies **HTTPS**) oorgedra word.
|
|
|
|
## Koekies Vooraf
|
|
|
|
Koekies wat met `__Secure-` voorafgegaan word, moet saam met die `secure` vlag van bladsye wat deur HTTPS beveilig is, ingestel word.
|
|
|
|
Vir koekies wat met `__Host-` voorafgegaan word, moet verskeie voorwaardes nagekom word:
|
|
|
|
- Hulle moet met die `secure` vlag ingestel word.
|
|
- Hulle moet afkomstig wees van 'n bladsy wat deur HTTPS beveilig is.
|
|
- Hulle is verbode om 'n domein te spesifiseer, wat hul oordrag na subdomeine voorkom.
|
|
- Die pad vir hierdie koekies moet op `/` ingestel wees.
|
|
|
|
Dit is belangrik om te noem dat koekies wat met `__Host-` voorafgegaan word, nie toegelaat word om na superdomeine of subdomeine gestuur te word nie. Hierdie beperking help om toepassingskoekies te isoleer. Dus, om die `__Host-` voorvoegsel vir alle toepassingskoekies te gebruik, kan beskou word as 'n goeie praktyk om sekuriteit en isolasie te verbeter.
|
|
|
|
### Oorskry van koekies
|
|
|
|
So, een van die beskermings van `__Host-` voorafgegaan koekies is om te voorkom dat hulle van subdomeine oorgeskryf word. Dit voorkom byvoorbeeld [**Koekie Tossing aanvalle**](cookie-tossing.md). In die praatjie [**Koekies Krummel: Ontsluiting van Web Sessies Integriteit Kwesbaarhede**](https://www.youtube.com/watch?v=F_wAzF4a7Xg) ([**papier**](https://www.usenix.org/system/files/usenixsecurity23-squarcina.pdf)) word aangebied dat dit moontlik was om \_\_HOST- voorafgegaan koekies van subdomein in te stel, deur die parser te bedrieg, byvoorbeeld, om "=" aan die begin of aan die begin en die einde by te voeg...:
|
|
|
|
<figure><img src="../../images/image (6) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
|
|
|
Of in PHP was dit moontlik om **ander karakters aan die begin** van die koekie naam by te voeg wat gaan **vervang word deur onderstreep** karakters, wat toelaat om `__HOST-` koekies te oorskry:
|
|
|
|
<figure><img src="../../images/image (7) (1) (1) (1) (1).png" alt="" width="373"><figcaption></figcaption></figure>
|
|
|
|
## Koekies Aanvalle
|
|
|
|
As 'n pasgemaakte koekie sensitiewe data bevat, kyk daarna (veral as jy 'n CTF speel), aangesien dit kwesbaar mag wees.
|
|
|
|
### Dekodering en Manipulering van Koekies
|
|
|
|
Sensitiewe data wat in koekies ingebed is, moet altyd ondersoek word. Koekies wat in Base64 of soortgelyke formate gekodeer is, kan dikwels gedekodeer word. Hierdie kwesbaarheid laat aanvallers toe om die koekie se inhoud te verander en ander gebruikers na te boots deur hul gewysigde data terug in die koekie te kodeer.
|
|
|
|
### Sessiediefstal
|
|
|
|
Hierdie aanval behels die steel van 'n gebruiker se koekie om ongeoorloofde toegang tot hul rekening binne 'n toepassing te verkry. Deur die gesteelde koekie te gebruik, kan 'n aanvaller die wettige gebruiker na boots.
|
|
|
|
### Sessiefiksasie
|
|
|
|
In hierdie scenario bedrieg 'n aanvaller 'n slagoffer om 'n spesifieke koekie te gebruik om in te log. As die toepassing nie 'n nuwe koekie toeken nie wanneer daar ingelog word, kan die aanvaller, wat die oorspronklike koekie besit, die slagoffer na boots. Hierdie tegniek is afhanklik van die slagoffer wat inlog met 'n koekie wat deur die aanvaller verskaf is.
|
|
|
|
As jy 'n **XSS in 'n subdomein** gevind het of jy **beheer 'n subdomein**, lees:
|
|
|
|
{{#ref}}
|
|
cookie-tossing.md
|
|
{{#endref}}
|
|
|
|
### Sessiedonasie
|
|
|
|
Hier oortuig die aanvaller die slagoffer om die aanvaller se sessie koekie te gebruik. Die slagoffer, wat glo dat hulle in hul eie rekening ingelog is, sal onbewustelik aksies in die konteks van die aanvaller se rekening uitvoer.
|
|
|
|
As jy 'n **XSS in 'n subdomein** gevind het of jy **beheer 'n subdomein**, lees:
|
|
|
|
{{#ref}}
|
|
cookie-tossing.md
|
|
{{#endref}}
|
|
|
|
### [JWT Koekies](../hacking-jwt-json-web-tokens.md)
|
|
|
|
Klik op die vorige skakel om toegang te verkry tot 'n bladsy wat moontlike gebreke in JWT verduidelik.
|
|
|
|
JSON Web Tokens (JWT) wat in koekies gebruik word, kan ook kwesbaarhede hê. Vir diepgaande inligting oor potensiële gebreke en hoe om dit te benut, word dit aanbeveel om die gekoppelde dokument oor die hack van JWT te raadpleeg.
|
|
|
|
### Kruis-web Versoek Forgery (CSRF)
|
|
|
|
Hierdie aanval dwing 'n ingelogde gebruiker om ongewenste aksies op 'n webtoepassing uit te voer waarin hulle tans geverifieer is. Aanvallers kan koekies wat outomaties met elke versoek na die kwesbare webwerf gestuur word, benut.
|
|
|
|
### Leë Koekies
|
|
|
|
(Kyk verdere besonderhede in die [oorspronklike navorsing](https://blog.ankursundara.com/cookie-bugs/)) Blaaiers laat die skepping van koekies sonder 'n naam toe, wat deur JavaScript soos volg demonstreer kan word:
|
|
```js
|
|
document.cookie = "a=v1"
|
|
document.cookie = "=test value;" // Setting an empty named cookie
|
|
document.cookie = "b=v2"
|
|
```
|
|
Die resultaat in die gestuurde koekie kop is `a=v1; test value; b=v2;`. Interessant genoeg, dit stel die manipulasie van koekies in staat as 'n leë naam koekie gestel word, wat moontlik ander koekies kan beheer deur die leë koekie na 'n spesifieke waarde te stel:
|
|
```js
|
|
function setCookie(name, value) {
|
|
document.cookie = `${name}=${value}`
|
|
}
|
|
|
|
setCookie("", "a=b") // Setting the empty cookie modifies another cookie's value
|
|
```
|
|
Dit lei daartoe dat die blaaiert 'n koekie-kop stuur wat deur elke webbediener geïnterpreteer word as 'n koekie met die naam `a` en 'n waarde `b`.
|
|
|
|
#### Chrome Fout: Unicode Surrogate Codepoint Probleem
|
|
|
|
In Chrome, as 'n Unicode surrogate codepoint deel is van 'n stel koekie, word `document.cookie` beskadig, wat 'n leë string teruggee:
|
|
```js
|
|
document.cookie = "\ud800=meep"
|
|
```
|
|
Dit lei tot `document.cookie` wat 'n leë string uitset, wat permanente korrupsie aandui.
|
|
|
|
#### Koekie Smuggling Weens Parsing Probleme
|
|
|
|
(Kyk na verdere besonderhede in die [oorspronklike navorsing](https://blog.ankursundara.com/cookie-bugs/)) Verskeie webbedieners, insluitend dié van Java (Jetty, TomCat, Undertow) en Python (Zope, cherrypy, web.py, aiohttp, bottle, webob), hanteer koekie stringe verkeerd weens verouderde RFC2965 ondersteuning. Hulle lees 'n dubbel-aanhaling koekiewaarde as 'n enkele waarde, selfs al sluit dit puntkommas in, wat normaalweg sleutel-waarde pare moet skei:
|
|
```
|
|
RENDER_TEXT="hello world; JSESSIONID=13371337; ASDF=end";
|
|
```
|
|
#### Koekie-inspuitingskw vulnerabilities
|
|
|
|
(Kyk na verdere besonderhede in die [oorspronklike navorsing](https://blog.ankursundara.com/cookie-bugs/)) Die onakkurate ontleding van koekies deur bedieners, veral Undertow, Zope, en dié wat Python se `http.cookie.SimpleCookie` en `http.cookie.BaseCookie` gebruik, skep geleenthede vir koekie-inspuitingsaanvalle. Hierdie bedieners slaag nie daarin om die begin van nuwe koekies behoorlik te begrens nie, wat dit moontlik maak vir aanvallers om koekies na te maak:
|
|
|
|
- Undertow verwag 'n nuwe koekie onmiddellik na 'n aangehaalde waarde sonder 'n puntkomma.
|
|
- Zope soek 'n komma om die volgende koekie te begin ontleed.
|
|
- Python se koekieklasse begin ontleed op 'n spasiekarakter.
|
|
|
|
Hierdie kwesbaarheid is veral gevaarlik in webtoepassings wat op koekie-gebaseerde CSRF-beskerming staatmaak, aangesien dit aanvallers in staat stel om nagebootste CSRF-token koekies in te spuit, wat moontlik sekuriteitsmaatreëls kan omseil. Die probleem word vererger deur Python se hantering van duplikaat koekiename, waar die laaste voorkoms vroeëre oorskry. Dit wek ook kommer vir `__Secure-` en `__Host-` koekies in onveilige kontekste en kan lei tot magtigingsoorskryding wanneer koekies aan agtergrondbedieners oorgedra word wat vatbaar is vir nabootsing.
|
|
|
|
### Koekies $version
|
|
|
|
#### WAF Oorskryding
|
|
|
|
Volgens [**hierdie blogpos**](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie), mag dit moontlik wees om die koekie-attribuut **`$Version=1`** te gebruik om die agtergrond 'n ou logika te laat gebruik om die koekie te ontleed as gevolg van die **RFC2109**. Boonop kan ander waardes soos **`$Domain`** en **`$Path`** gebruik word om die gedrag van die agtergrond met die koekie te verander.
|
|
|
|
#### Koekie-sandwich-aanval
|
|
|
|
Volgens [**hierdie blogpos**](https://portswigger.net/research/stealing-httponly-cookies-with-the-cookie-sandwich-technique) is dit moontlik om die koekie-sandwich-tegniek te gebruik om HttpOnly koekies te steel. Dit is die vereistes en stappe:
|
|
|
|
- Vind 'n plek waar 'n blykbaar nuttelose **koekie in die antwoord weerspieël word**
|
|
- **Skep 'n koekie genaamd `$Version`** met die waarde `1` (jy kan dit in 'n XSS-aanval vanaf JS doen) met 'n meer spesifieke pad sodat dit die aanvanklike posisie kry (sommige raamwerke soos Python het nie hierdie stap nodig nie)
|
|
- **Skep die koekie wat weerspieël word** met 'n waarde wat 'n **oop dubbele aanhalingstekens** laat en met 'n spesifieke pad sodat dit in die koekiedatabasis na die vorige een (`$Version`) geposisioneer word
|
|
- Dan sal die wettige koekie volgende in die volgorde gaan
|
|
- **Skep 'n dummy koekie wat die dubbele aanhalingstekens** binne sy waarde sluit
|
|
|
|
Op hierdie manier word die slagoffer koekie vasgevang binne die nuwe koekie weergawe 1 en sal dit weerspieël word wanneer dit weerspieël word.
|
|
bv. uit die pos:
|
|
```javascript
|
|
document.cookie = `$Version=1;`;
|
|
document.cookie = `param1="start`;
|
|
// any cookies inside the sandwich will be placed into param1 value server-side
|
|
document.cookie = `param2=end";`;
|
|
```
|
|
### WAF omseilings
|
|
|
|
#### Cookies $version
|
|
|
|
Kyk die vorige afdeling.
|
|
|
|
#### Omseiling van waarde-analisering met aangehaalde-string kodering
|
|
|
|
Hierdie ontleding dui aan om ontsnapte waardes binne die koekies te ontsnap, sodat "\a" "a" word. Dit kan nuttig wees om WAFS te omseil soos:
|
|
|
|
- `eval('test') => verbode`
|
|
- `"\e\v\a\l\(\'\t\e\s\t\'\)" => toegelaat`
|
|
|
|
#### Omseiling van koekie-naam bloklyste
|
|
|
|
In die RFC2109 word aangedui dat 'n **komma as 'n skeidingsteken tussen koekiewaardes gebruik kan word**. En dit is ook moontlik om **spasies en tabulasies voor en na die gelykteken by te voeg**. Daarom genereer 'n koekie soos `$Version=1; foo=bar, abc = qux` nie die koekie `"foo":"bar, admin = qux"` nie, maar die koekies `foo":"bar"` en `"admin":"qux"`. Let op hoe 2 koekies gegenereer word en hoe admin die spasie voor en na die gelykteken verwyder is.
|
|
|
|
#### Omseiling van waarde-analisering met koekie-skeiding
|
|
|
|
Laastens sou verskillende agterdeure in 'n string verskillende koekies saamvoeg wat in verskillende koekie-koptekste deurgegee word soos in:
|
|
```
|
|
GET / HTTP/1.1
|
|
Host: example.com
|
|
Cookie: param1=value1;
|
|
Cookie: param2=value2;
|
|
```
|
|
Wat kan toelaat om 'n WAF te omseil soos in hierdie voorbeeld:
|
|
```
|
|
Cookie: name=eval('test//
|
|
Cookie: comment')
|
|
|
|
Resulting cookie: name=eval('test//, comment') => allowed
|
|
```
|
|
### Ekstra Kwetsbare Koekies Kontroles
|
|
|
|
#### **Basiese kontroles**
|
|
|
|
- Die **koekie** is die **selfde** elke keer wanneer jy **aanmeld**.
|
|
- Meld af en probeer om dieselfde koekie te gebruik.
|
|
- Probeer om met 2 toestelle (of blaaiers) na dieselfde rekening aan te meld met die selfde koekie.
|
|
- Kontroleer of die koekie enige inligting daarin het en probeer om dit te wysig.
|
|
- Probeer om verskeie rekeninge met amper dieselfde gebruikersnaam te skep en kyk of jy ooreenkomste kan sien.
|
|
- Kontroleer die "**onthou my**" opsie indien dit bestaan om te sien hoe dit werk. As dit bestaan en kwesbaar kan wees, gebruik altyd die koekie van **onthou my** sonder enige ander koekie.
|
|
- Kontroleer of die vorige koekie werk selfs nadat jy die wagwoord verander.
|
|
|
|
#### **Geavanceerde koekie-aanvalle**
|
|
|
|
As die koekie dieselfde bly (of amper) wanneer jy aanmeld, beteken dit waarskynlik dat die koekie verband hou met 'n veld van jou rekening (waarskynlik die gebruikersnaam). Dan kan jy:
|
|
|
|
- Probeer om baie **rekeninge** met gebruikersname wat baie **soortgelyk** is te skep en probeer om te **raai** hoe die algoritme werk.
|
|
- Probeer om die **gebruikersnaam te bruteforce**. As die koekie slegs as 'n verifikasiemetode vir jou gebruikersnaam stoor, kan jy 'n rekening met die gebruikersnaam "**Bmin**" skep en elke enkele **bit** van jou koekie **bruteforce** omdat een van die koekies wat jy sal probeer die een behoort aan "**admin**".
|
|
- Probeer **Padding** **Oracle** (jy kan die inhoud van die koekie ontsleutel). Gebruik **padbuster**.
|
|
|
|
**Padding Oracle - Padbuster voorbeelde**
|
|
```bash
|
|
padbuster <URL/path/when/successfully/login/with/cookie> <COOKIE> <PAD[8-16]>
|
|
# When cookies and regular Base64
|
|
padbuster http://web.com/index.php u7bvLewln6PJPSAbMb5pFfnCHSEd6olf 8 -cookies auth=u7bvLewln6PJPSAbMb5pFfnCHSEd6olf
|
|
|
|
# If Base64 urlsafe or hex-lowercase or hex-uppercase --encoding parameter is needed, for example:
|
|
padBuster http://web.com/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6
|
|
7B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2
|
|
```
|
|
Padbuster sal verskeie pogings doen en jou vra watter voorwaarde die foutvoorwaarde is (die een wat nie geldig is nie).
|
|
|
|
Dan sal dit begin om die koekie te ontsleutel (dit kan 'n paar minute neem).
|
|
|
|
As die aanval suksesvol uitgevoer is, kan jy probeer om 'n string van jou keuse te enkripteer. Byvoorbeeld, as jy sou wil **encrypt** **user=administrator**
|
|
```
|
|
padbuster http://web.com/index.php 1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== 8 -cookies thecookie=1dMjA5hfXh0jenxJQ0iW6QXKkzAGIWsiDAKV3UwJPT2lBP+zAD0D0w== -plaintext user=administrator
|
|
```
|
|
Hierdie uitvoering sal jou die koekie korrek versleuteld en gekodeer met die string **user=administrator** binne-in gee.
|
|
|
|
**CBC-MAC**
|
|
|
|
Miskien kan 'n koekie 'n waarde hê en kan dit onderteken word met CBC. Dan is die integriteit van die waarde die handtekening wat geskep is deur CBC met dieselfde waarde te gebruik. Aangesien dit aanbeveel word om 'n nulvektor as IV te gebruik, kan hierdie tipe integriteitskontrole kwesbaar wees.
|
|
|
|
**Die aanval**
|
|
|
|
1. Kry die handtekening van gebruikersnaam **administ** = **t**
|
|
2. Kry die handtekening van gebruikersnaam **rator\x00\x00\x00 XOR t** = **t'**
|
|
3. Stel in die koekie die waarde **administrator+t'** (**t'** sal 'n geldige handtekening wees van **(rator\x00\x00\x00 XOR t) XOR t** = **rator\x00\x00\x00**
|
|
|
|
**ECB**
|
|
|
|
As die koekie met ECB versleuteld is, kan dit kwesbaar wees.\
|
|
Wanneer jy aanmeld, moet die koekie wat jy ontvang altyd dieselfde wees.
|
|
|
|
**Hoe om te detecteer en aan te val:**
|
|
|
|
Skep 2 gebruikers met byna dieselfde data (gebruikersnaam, wagwoord, e-pos, ens.) en probeer om 'n patroon binne die gegewe koekie te ontdek.
|
|
|
|
Skep 'n gebruiker genaamd byvoorbeeld "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" en kyk of daar enige patroon in die koekie is (aangesien ECB met dieselfde sleutel elke blok versleutelt, kan dieselfde versleutelde bytes verskyn as die gebruikersnaam versleuteld word).
|
|
|
|
Daar moet 'n patroon wees (met die grootte van 'n gebruikte blok). So, deur te weet hoe 'n klomp "a" versleuteld is, kan jy 'n gebruikersnaam skep: "a"\*(grootte van die blok)+"admin". Dan kan jy die versleutelde patroon van 'n blok van "a" uit die koekie verwyder. En jy sal die koekie van die gebruikersnaam "admin" hê.
|
|
|
|
## Verwysings
|
|
|
|
- [https://blog.ankursundara.com/cookie-bugs/](https://blog.ankursundara.com/cookie-bugs/)
|
|
- [https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd](https://www.linkedin.com/posts/rickey-martin-24533653_100daysofhacking-penetrationtester-ethicalhacking-activity-7016286424526180352-bwDd)
|
|
- [https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie](https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie)
|
|
|
|
{{#include ../../banners/hacktricks-training.md}}
|