[webscraping] x-csrftoken opvragen

[Red devil]

Wel, ik heb een beetje een deja vu: [webscraping] Authorization bearer opvragen
Maar dit keer is het een andere website die niet meer werkt. Zelfde verhaal, geen officiële API maar de analyses worden getolereerd. Echter, geen support dus als er iets omvalt (zoals mijn third party service), dan moet je het zelf maar uitzoeken.

Het probleem ligt hem nu in een een x-csrftoken, althans daar ga ik vanuit want ik kan die namelijk niet goed vinden en meegeven. Tijdens het inloggen van de website wordt er gebruik gemaakt van een POST:

code:

:authority: auth.23andme.com
:method: POST
:path: /login/?next=/authorize/%3Fredirect_uri%3Dhttps%253A%252F%252Fyou.23andme.com%252Fauth_callback%252F%26response_type%3Dcode%26client_id%3Dyou%26scope%3Dopenid%26state%3D%257B%2522origin_uri%2522%253A%2B%2522%252F%2522%257D
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9,fr;q=0.8,nl;q=0.7,de;q=0.6,af;q=0.5,hu;q=0.4
content-length: 59
content-type: application/x-www-form-urlencoded; charset=UTF-8
cookie: uuid=ef9de61a7e1540a082af7882441f5842; __cfduid=dbf739ad352c36c1d65062c1fc5bc205e1585156717; gdpr_visited=true; ttam_user=1; G_ENABLED_IDPS=google; csrftoken=qD8KQqVrHVkPlLWP28V3U3rFTR75n2whCTn3rwNmmy50qTVs97zk94nPc61cyucA
origin: https://auth.23andme.com
referer: https://auth.23andme.com/login/?next=/authorize/%3Fredirect_uri%3Dhttps%253A%252F%252Fyou.23andme.com%252Fauth_callback%252F%26response_type%3Dcode%26client_id%3Dyou%26scope%3Dopenid%26state%3D%257B%2522origin_uri%2522%253A%2B%2522%252F%2522%257D
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-origin
user-agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Mobile Safari/537.36
x-csrftoken: 6VGEEjMmHsZf0mB03zc63uZ0H0tG5AHXibVXfpEhm5Kq5uADayQnivVa0fnNg2ng
x-newrelic-id: UwAFVF5aGwcIV1RQDgEB
x-requested-with: XMLHttpRequest

Maar de vraag is wederom, waar komt die x-csrftoken vandaan? Als ik x-csrftoken wat google dan lijkt het een extra securitylaagje toe te voegen. Deze is cookie based en daar zul je waarschijnlijk de info vinden.

Heb dit keer alles gelijk gedaan in Chrome incognito modus en alle cookies bekeken. Helemaal niks. Wel staat er in de page source van de login pagina een reguliere csrftoken, maar die is dus niet hetzelfde als de x-csrftoken.

Overigens zie ik ook openid verwijzingen in de headers maar verder niet dezelfde requests als de vorige keer. Dus ik focus me vooralsnog maar even op de x-csrftoken

Anyone?

[Juup]

Err... die csrf staat gewoon letterlijk in de source van https://auth.23andme.com/login/:

JavaScript:

<script type="text/javascript" nonce=8KdfgdfgAvrlBflRNPR3D0b>
        window.addEventListener('load', function () {
            ttam_auth.renderAuth({
                ...
                csrfToken: "C70zWXOfVkL9p7nbl1vlRVkS188c1Av24eYdct6H0DC4FIGHPX1viJFKPhsUk9rO",
            });
        });
    </script>

[Red devil]

Juup schreef op woensdag 25 maart 2020 @ 19:00:
Err... die csrf staat gewoon letterlijk in de source van https://auth.23andme.com/login/:

JavaScript:

<script type="text/javascript" nonce=8KdfgdfgAvrlBflRNPR3D0b>
        window.addEventListener('load', function () {
            ttam_auth.renderAuth({
                ...
                csrfToken: "C70zWXOfVkL9p7nbl1vlRVkS188c1Av24eYdct6H0DC4FIGHPX1viJFKPhsUk9rO",
            });
        });
    </script>

Ah nee dat is de csrfToken, ik ben op zoek naar de x-csrfToken. Maar zou het misschien kunnen dat de csrfToken wordt omgezet via javascript naar de x-csrfToken?

[Juup]

Ah nu snap ik de verwarring.
Een CSRF token is een nonce die in het form staat wat gepost wordt en ook in het cookie (of een header, bij ajax) komt te staan.
Deze twee moeten overeen komen om cross site request forgery te voorkomen.
Die header zal dus overeen moeten komen met de POST parameter.

[Red devil]

Juup schreef op woensdag 25 maart 2020 @ 19:08:
Ah nu snap ik de verwarring.
Een CSRF token is een nonce die in het form staat wat gepost wordt en ook in het cookie (of een header, bij ajax) komt te staan.
Deze twee moeten ovreen komen om cross site requet forgery te voorkomen.
Die header zal dus overeen moeten komen met de POST parameter.

Ik denk dat ik het snap maar ik probeer nu die CSRF token te gebruiken en het lijkt al beter te gaan, bedankt voor de tip! Nog even verder testen