GraphQL zaifliklari odatda joriy qilish va dizayn kamchiliklari sababli yuzaga keladi. Masalan, introspection funksiyasi yoqilgan qoldirilsa, hujumchilar API'ga so'rov yuborib uning sxemasi haqida ma'lumot to'plashi mumkin. GraphQL hujumlari odatda zararli so'rovlar ko'rinishida bo'lib, hujumchiga ma'lumot olish yoki ruxsatsiz amallarni bajarishga imkon beradi. Bu hujumlar jiddiy ta'sirga ega bo'lishi mumkin, ayniqsa foydalanuvchi so'rovlarni manipulyatsiya qilib admin imtiyozlarini olsa yoki CSRF ekspluatini bajarsa.
GraphQL API'ni sinashdan oldin uning endpointini topishingiz kerak. GraphQL API'lar barcha so'rovlar uchun bir xil endpointdan foydalangani sabab, bu qimmatli ma'lumot.
Agar har qanday GraphQL endpointga query{__typename} yuborsangiz, javobda {"data": {"__typename": "query"}} satri bo'ladi. Bu universal so'rov deb ataladi va URL GraphQL xizmatiga tegishli ekanini tekshirishda foydali. Bu ishlaydi, chunki har bir GraphQL endpointda __typename rezerv maydoni bor — u so'ralgan obyekt turini string sifatida qaytaradi.
GraphQL xizmatlari ko'pincha o'xshash endpoint suffikslaridan foydalanadi. Universal so'rovlarni quyidagi joylarga yuborib ko'ring:
/graphql
/api
/api/graphql
/graphql/api
/graphql/graphqlAgar bu keng tarqalgan endpointlar GraphQL javobini qaytarmasa, yo'lga /v1 qo'shib ko'rishingiz mumkin.
GraphQL endpointlarini topishning keyingi qadami — turli so'rov metodlarini sinash. Eng yaxshi amaliyot — production endpointlari faqat application/json content-type'li POST so'rovlarni qabul qilishi (bu CSRF'dan himoya qiladi). Biroq ba'zi endpointlar GET yoki x-www-form-urlencoded content-type'li POST so'rovlarni ham qabul qilishi mumkin. Agar POST bilan topolmasangiz, universal so'rovni muqobil HTTP metodlar bilan qayta yuboring.
Agar API obyektlarga to'g'ridan-to'g'ri kirish uchun argumentlardan foydalansa, u access control zaifliklariga (insecure direct object reference, IDOR) zaif bo'lishi mumkin. Foydalanuvchi shunchaki ma'lumotga mos keladigan argument berib, ko'rmasligi kerak bo'lgan ma'lumotga kirishi mumkin. Masalan, quyidagi so'rov onlayn-do'kon uchun mahsulotlar ro'yxatini so'raydi:
query {
products {
id
name
listed
}
}Qaytarilgan ro'yxatda faqat "listed" (ro'yxatdagi) mahsulotlar bor. Bundan mahsulotlarga ketma-ket ID berilishini va ID 3 ro'yxatda yo'qligini (ehtimol o'chirilgani uchun) bilib olamiz. Yo'q mahsulot ID'sini so'rab, uning tafsilotlarini olishimiz mumkin, garchi u do'konda ko'rsatilmagan bo'lsa ham:
query {
product(id: 3) {
id
name
listed
}
}API'ni sinashning keyingi qadami — asosiy sxema haqida ma'lumot to'plash. Buning eng yaxshi yo'li — introspection so'rovlaridan foydalanish. Introspection — GraphQL'ning o'rnatilgan funksiyasi bo'lib, serverdan sxema haqida so'rov yuborishga imkon beradi. U API bilan qanday o'zaro ta'sir qilishni tushunishga yordam beradi, hamda description maydonlari kabi maxfiy ma'lumotni ham oshkor qilishi mumkin.
Sxema ma'lumotini aniqlash uchun __schema maydonini so'rang — u barcha so'rovlarning root turida mavjud. Introspection production'da o'chirilishi eng yaxshi amaliyot, lekin bu maslahatga har doim ham amal qilinmaydi. Introspection yoqilganini quyidagi oddiy so'rov bilan tekshirishingiz mumkin:
{
"query": "{__schema{queryType{name}}}"
}Introspection yoqilgan bo'lsa, javob barcha mavjud so'rovlar nomlarini qaytaradi. So'ng to'liq introspection so'rovini yuborib, sxema haqida iloji boricha ko'proq ma'lumot (barcha query, mutation, subscription, type va fragmentlar) olishingiz mumkin.
Agar introspection so'rovlarini ishga tushira olmasangiz, __schema kalit so'zidan keyin maxsus belgi qo'shib ko'ring. Dasturchilar introspection'ni o'chirganda, so'rovlarda __schema kalit so'zini regex bilan istisno qilishi mumkin. GraphQL e'tiborsiz qoldiradigan, lekin buzuq regex qoldirmaydigan belgilarni (bo'sh joy, yangi qator, vergul) sinang. Masalan, dasturchi faqat __schema{ ni istisno qilgan bo'lsa, quyidagi so'rov istisno qilinmaydi:
{
"query": "query{__schema
{queryType{name}}}"
}Agar bu ishlamasa, probeni muqobil so'rov metodı orqali yuboring — introspection faqat POST orqali o'chirilgan bo'lishi mumkin. GET so'rovni yoki x-www-form-urlencoded content-type'li POST'ni sinang.
Odatda GraphQL obyektlari bir xil nomli bir nechta xususiyatga ega bo'lolmaydi. Alias'lar bu cheklovni chetlab o'tishga imkon berib, siz API qaytarishni istagan xususiyatlarni aniq nomlashga imkon beradi — ya'ni bitta so'rovda bir xil turdagi obyektning bir nechta nusxasini qaytarish mumkin. Alias'lar API chaqiruvlari sonini kamaytirish uchun mo'ljallangan bo'lsa-da, ular GraphQL endpointini brute force qilishda ham ishlatilishi mumkin. Ko'p rate limiter'lar endpointda bajarilgan amallar soniga emas, HTTP so'rovlar soniga qarab ishlaydi — alias'lar esa bitta HTTP xabarda bir nechta so'rov yuborishga imkon berib, bu cheklovni chetlab o'tadi:
query isValidDiscount($code: Int) {
isValidDiscount(code:$code){
valid
}
isValidDiscount2:isValidDiscount(code:$code){
valid
}
isValidDiscount3:isValidDiscount(code:$code){
valid
}
}CSRF zaifliklari hujumchiga foydalanuvchilarni o'zlari niyat qilmagan amallarni bajarishga undash imkonini beradi. GraphQL CSRF hujumlari uchun vektor sifatida ishlatilishi mumkin. CSRF zaifligi GraphQL endpoint so'rovlarning content type'ini tekshirmasa va CSRF tokenlar joriy qilinmagan bo'lsa yuzaga keladi. application/json content-type'li POST so'rovlar (content type tekshirilsa) soxta so'rovga qarshi xavfsiz. Biroq GET yoki x-www-form-urlencoded content-type'li so'rovlarni brauzer yuborishi mumkin va endpoint ularni qabul qilsa, foydalanuvchilarni hujumga ochiq qoldiradi.
Ko'p keng tarqalgan GraphQL hujumlarining oldini olish uchun API'ni production'ga deploy qilganda:
hideSchemaDetailsFromClientErrors opsiyasidan foydalaning.