GraphQL API turvalisus: viis testi enne avalikku käivitamist

Käivitage need viis testi oma GraphQL API staging-keskkonnas enne, kui lõpp-punkt avalikuks muutub. Seadistage staging samamoodi nagu tootmiskeskkond, muidu on tulemustel vähe väärtust.

Testid järgivad OWASP GraphQL Cheat Sheet'i nelja valdkonda: sisendi valideerimine, kulukad päringud, juurdepääsukontroll ja ebaturvalised vaikeseaded.

1. Kontrollige vaikeseadeid

Liiga detailsed veateated, introspektsioon ja GraphiQL on tavalised ebaturvalised vaikeseaded. Testige kõiki kolme. Alustage kõige lühema introspektsioonipäringuga:

{__schema{types{name}}}

Vaadake, kas server vastab skeemi üksikasjadega või keeldub. Seejärel otsige brauserist GraphiQL-i. Lõpuks saatke vigane päring ja päring vale argumendiga ning lugege veateadet. Kui vastuses on resolverite nimesid, stack trace'e või andmebaasi teateid, on see ründajale kaart.

Parandus on konfiguratsioonis. Lülitage introspektsioon ja GraphiQL välja seal, kus API-d ei ole mõeldud avastamiseks, tagastage üldised veateated ning hoidke detailid serveripoolsetes logides.

2. Suunake igasse argumenti vaenulik sisend

Kasutaja annab kaasa identifikaatorid ja andmehankijad kasutavad neid seejärel HTTP-päringutes, andmebaasipäringutes ja muudes kutsetes. Just seal tekib injection. Testige iga päringu ja mutatsiooni kõiki argumente samade payload'idega, mida kasutaksite iga teise API puhul: SQL- ja NoSQL-injection, OS-käsusüst, SSRF ja CRLF-injection.

Et testimist saaks skriptida, genereerige argumentide loendid skeemist, kuni introspektsioon on stagingus veel sees, käivitage oma payload'id nende peal tsüklis ja lülitage introspektsioon seejärel välja.

Mida jõustada:

• Konkreetsed GraphQL-i tüübid, näiteks skalaarid ja enumid, ning mutatsioonide sisendile defineeritud skeemid.
• Lubatud märkide loend (allowlist), mitte keelatud märkide loend. Heaks lähtepunktiks on tähtnumbriline mitte-unicode sisend, sest see välistab paljud rünnakud.
• Parameetritega päringud kõige jaoks, mis antakse edasi interpretaatorile. Kui kasutate ORM-i või ODM-i, kasutage seda dokumentatsiooni järgi, sest ORM-injection on endiselt võimalik.
• Vigase sisendi tagasilükkamine ilma paljastamata, kuidas valideerimine töötab.

3. Leidke kulukas päring

API on haavatav, kui mõni ressursipiirang puudub või on valesti seatud. OWASP kirje piiramatu ressursikasutuse kohta nimetab täitmise ajalõppe, maksimaalset eraldatavat mälu, file descriptor'eid, protsesse, üleslaaditava faili suurust, kirjeid lehe kohta, operatsioone kliendi päringu kohta ja kululimiite kolmandate osapoolte teenusepakkujate juures.

Testimiseks koostage sügavaim päring, mida teie skeem lubab, järgides seoseid tsüklis. Kohandage nimed oma skeemile:

{ users { orders { customer { orders { customer { email } } } } } }

Lisage tasemeid, kuni server keeldub või aeglustub. Seejärel küsige väga suurt lehesuurust ja saatke ülemõõduline payload.

Cheat Sheet'i soovitus on lisada kontrollid, mis piiravad või takistavad liiga kulukaid päringuid. Kombineerige seda lehesuuruse ülempiiri, täitmise ajalõpu ning stringide, massiivide ja üleslaadimiste maksimaalsete suurustega. Häälestage väärtused nädala tegelike liikl& logide põhjal, et legitiimsed kliendid jääksid piiridesse.

4. Batching'uga rate limiterist mööda

Batching on jõuründ, mille puhul päringute arv on peidetud. OWASP kirje teises stsenaariumis asub üleslaadimismutatsioon rate limiteri ja suurusekontrolli taga. Ründaja saadab ühe POST-päringu aadressile /graphql, mis sisaldab massiivi peaaegu tuhande operatsiooniga. Limiter näeb ühte päringut ja serveril saab mälu otsa. Kui teie API võtab vastu üleslaadimisi, käsitleb seda poolt meie artikkel turvaliste failiüleslaadimiste kavandamisest ja testimisest.

Proovige sama sisselogimise või OTP mutatsiooni vastu:

[
  {"query": "mutation {login(user: \"alice\", pass: \"guess1\") {token}}"},
  {"query": "mutation {login(user: \"alice\", pass: \"guess2\") {token}}"}
]

Kontrollige, kas teie limiit loeb kokku iga massiivi operatsiooni ja kas ebaõnnestunud katsed jõuavad ikkagi teie lukustusloogikani. Seejärel proovige kõiki muid viise, kuidas teie server lubab mitu operatsiooni ühte päringusse pakkida.

Piirake operatsioonide arvu kliendi päringu kohta ja piirake, kui tihti üks klient võib käivitada sama tundlikku operatsiooni, näiteks OTP kinnitamist. Piirake ka kulu: kirje esimeses stsenaariumis käivitab skript unustatud parooli voo kaudu kümneid tuhandeid tasulisi SMS-e. Seadke kolmandate osapoolte teenusepakkujate juures kululimiidid ning seal, kus limiite seada ei saa, arvelduse teavitused.

5. Küsige kellegi teise välja

Autentimine ütleb, kes kutsub. See ei otsusta, milliseid välju tohib ta lugeda. GraphQL-i autoriseerimisjuhend ütleb, et täitmine peaks algama pärast seda, kui autentimise middleware on identiteedi kinnitanud, ja et server peab ikkagi iga küsitud välja kohta eraldi otsustama, kas kasutaja tohib seda näha.

Testige kahe tavalise kontoga. Küsige konto A sessiooniga konto B objekte ID järgi ning seejärel jõudke nendeni seotud objekti kaudu, mida mõlemad kontod näevad. Kohandage nimed oma skeemile:

# Direct lookup: should be refused for account A
{ customer(id: "CUSTOMER_ID_OF_B") { email } }

# Same data through a shared parent: must also be refused
{ product(id: "SHARED_PRODUCT_ID") { orders { customer { email } } } }

Kui esimene päring lükatakse tagasi, aga teine tagastab B e-posti aadressi, asub kontroll ülemise taseme otsingul ja seda ei ole pesastatud tüübile kunagi rakendatud. Korrake testi ilma sessioonita. Kui samu andmeid pakutakse REST-i või mobiili-API kaudu, testige ka neid sisenemispunkte. Sama lähenemist väljaspool GraphQL-i käsitleb meie artikkel kõigi ID-de testimisest IDOR-i ja BOLA suhtes.

Autoriseerimine väljaresolveri sees sobib prototüüpidele, kuid peate seda dubleerima iga sisenemispunkti jaoks. Kui koopiad hakkavad lahknema, näevad kasutajad olenevalt kasutatavast API-st erinevaid andmeid. Viige loogika äriloogika kihti, et tõe allikas oleks üks. Juhendi näites saab postRepository.getBody kätte kasutaja ja postituse ning tagastab sisu ainult autorile. Andke edasi täielikult täidetud kasutajaobjekt, mitte läbipaistmatu token või API võti.

Mida skanner teile ei ütle

Automaatsed tööriistad annavad laiuse, kuid OWASP Web Security Testing Guide toonitab, et need on loodud rakenduste jaoks üldiselt, mitte teie kohandatud koodi ja ärireeglite jaoks. Kõige tõsisemad vead on sageli läbi põimunud äriloogikaga.

Testid 1 kuni 3 on enamasti skriptitavad. Test 5 nõuab käsitööd, sest keegi peab aru saama, milline üürnik (tenant) millist objekti omab, ja seetõttu tasub just see anda välisele meeskonnale. Seda katab meie läbistustestimise teenus.

Kust alustada

1. Saatke stagingus introspektsioonipäring ja avage GraphiQL. Lülitage välja kõik, mis vastab, ning testige veateateid uuesti vigase päringuga.
2. Koostage loend kõigist päringute ja mutatsioonide argumentidest. Veenduge, et igaühel on konkreetne tüüp või enum ja allowlist-validaator.
3. Saatke sügavalt pesastatud päring, suure lehesuurusega päring ja ülemõõduline payload. Seadke limiidid, saatke päringud uuesti ja kinnitage, et igaüks lükatakse tagasi.
4. Saatke massiivina batch oma sisselogimise ja OTP mutatsioonide vastu. Jõustage limiit päringu kohta ning tundlike operatsioonide kordamisele.
5. Tehke kahe konto test, sh pesastatud seostega, igal tüübil, mis sisaldab isiku- või ärikriitilisi andmeid. Viige kõik resolverist leitud kontrollid äriloogika kihti.