31-days-of-API-Security-Tips - This challenge is Inon Shkedy's 31 days API Securi

项目说明

31-days-of-API-Security-Tips

This challenge is Inon Shkedy's 31 days API Security Tips

#### -API TIP: 1/31-

*Older APIs tend to be more and they lack security mechanisms.
Le the predictable nature of REST APIs to find old .
Saw a call to api/v3/login? Check if api/v1/login exists as well. It might be more .*

--------------------------------------------------------------------------------------------------------------------------

#### -API TIP: 2/31-

*Ne there’s only one way to authenticate to an API!
Modern apps have many API endpoints for AuthN: /api/mobile/login | /api/v3/login | /api/magic_link; etc..
Find and test all of them for AuthN problems.*

--------------------------------------------------------------------------------------------------------------------------

#### -API TIP:3/31-

*Remember how SQL Injections used to be extremely common 5-10 years ago, and you could break into almost every company?
BOLA (IDOR) is the new epidemic of API security.
As a pentester, if you understand how to exploit it, your glory is guaranteed.*

> Learn more about BOLA :
--------------------------------------------------------------------------------------------------------------------------

#### -API TIP: 4/31-

Testing a Ruby on Rails App & noticed an HTTP parameter containing a URL?
De sometimes use "Kernel#open" function to access URLs == 游戏 Over.
Just send a pipe as the first character and then a shell command (Command Injection by design)

> Learn more about the open function:
--------------------------------------------------------------------------------------------------------------------------

#### -API TIP:5/31-

*Found SSRF? use it for:*
* Internal port scanning
* Le cloud services(like 169.254.169.254)
* Use to reveal IP Address & HTTP Library
* Download a very large file (Layer 7 DoS)
* Reflective SSRF? disclose local mgmt consoles

--------------------------------------------------------------------------------------------------------------------------

#### -API TIP: 6/31-

*Mass Assignment is a real thing.
Modern frameworks encourage de to use MA without understanding the security implications.
During exploitation, don't guess object's properties names, simply find a GET endpoint that returns all of them.*
!Infographic

--------------------------------------------------------------------------------------------------------------------------

#### - API TIP: 7/31 -

*A company exposes an API for de?
This is not the same API which is used by mobile / web application. Always test them separately.
Don't assume they implement the same security mechanisms.*

--------------------------------------------------------------------------------------------------------------------------

#### - API TIP: 8/31 -

Pentest for REST API? Give it a chance and check if the API supports SOAP also.
Change the content-type to "application/xml", add a simple XML in the request body, and see how the API handles it.

> Sometimes the authentication is done in a different component that is shared between REST & SOAP APIs == SOAP API may support JWT

> If the API returns stack trace with a DUMPling, it's probably **

--------------------------------------------------------------------------------------------------------------------------

#### - API TIP: 9/31 -

*Pentest for APIs? Trying to find BOLA (IDOR) ? IDs in the HTTP bodies/headers tend to be more than IDs in URLs. Try to focus on them first.*

--------------------------------------------------------------------------------------------------------------------------

#### -API TIP: 10/31-

*Exploiting BFLA (Broken Function Le)?
Le the predictable nature of REST to find admin API endpoints!
E.g: you saw the following API call GET /api/v1/users/<id>
Give it a chance and change to DELETE / POST to create/delete users.*

--------------------------------------------------------------------------------------------------------------------------

#### - API TIP: 11/31 -

*The API uses Authorization header? Forget about CSRF!
If the authentication mechanism doesn't support cookies, the API is protected against CSRF by design.*

--------------------------------------------------------------------------------------------------------------------------

#### -API TIP : 12/31-

*Testing for BOLA (IDOR)?
Even if the ID is GUID or non-numeric, try to send a numeric value.
For example: /?user_id=111 instead of user_id=
Sometimes the AuthZ mechanism supports both and it's easier the brute force numbers.*

--------------------------------------------------------------------------------------------------------------------------

#### -API TIP: 13/31-

*Use Mass Assignment to bypass security mechanisms.
E.g., "enter password" mechanism:

--------------------------------------------------------------------------------------------------------------------------

#### - API TIP: 14/31 -

*Got stuck during an API pentest? Expand your attack surface! Find sub/sibling domains using &
Some of these domains might expose the same APIs with different configurations/.*

--------------------------------------------------------------------------------------------------------------------------

#### -API TIP:15/31-

*Static resource==photo,video,..
Web Servers(IIS, Apache) treat static resources differently when it comes to authorization.
Even if de implemented decent authorization, there's a good chance you can access static resources of other users.*

--------------------------------------------------------------------------------------------------------------------------

#### -API TIP: 16/31-

Even if you use another web proxy, always use Burp in the background.
The guys at
are doing a really good job at helping you manage your pentest.
Use the “tree view” (free ) feature to see all API endpoints you’.

--------------------------------------------------------------------------------------------------------------------------

#### -API TIP:17/31-

*Mobile Certificate Pinning?
Before you start reverse engineering & patching the 客户端 app, check for both iOS & Android clients and older of them.
There's a decent chance that the pinning isn't enabled in one of them. Save time.*

--------------------------------------------------------------------------------------------------------------------------

#### -API TIP: 18/31-

*Companies & de tend to put more resources (including security) into the main APIs.
Always look for the most niche features that nobody uses to find interesting .
POST /api/profile/upload_christmas_*

--------------------------------------------------------------------------------------------------------------------------

#### -API TIP:19/31-

*Which features do you find tend to be more ?*
*I'll start:*
* Organization's user management
* Export to CSV/HTML/PDF
* Custom views of dashboards
* Sub user creation&management
* Object sharing (photos, posts,etc)

--------------------------------------------------------------------------------------------------------------------------

#### - API TIP:20/31-

*Testing AuthN APIs?
If you test in production, there's a good chance that AuthN endpoints have anti brute-force protection.
Anyhow, DevOps engineers tend to disable rate limiting in non-production en. Don't forget to test them :)*

> A good example of this issue: Facebook Breach (Found by )
--------------------------------------------------------------------------------------------------------------------------

#### -API TIP:21/30-

*Got stuck during an API pentest? Expand the attack surface!
Use find old of the web-app and explore new API endpoints.
Can't use the 客户端? scan the .js files for URLs. Some of them are API endpoints.*

--------------------------------------------------------------------------------------------------------------------------

#### -API TIP:22/31-

*APIs tend to leak PII by design.
BE engineers return raw JSON objects and rely on FE engineers to filter out sensitive data.
Found a sensiti (e.g, receipt)? Find all the EPs that return it: /download_receipt,/export_receipt, etc..*

> Some of the endpoints might leak excessive data that should not be accessible by the user.

> This is an example for OWASP Top 10 For APIs - #3 - Excessive Data Exposure
--------------------------------------------------------------------------------------------------------------------------

#### -API TIP:23/31-

*Found a way to download arbitrary files from a web 服务端?
Shift the test from black-box to white-box.
Download the 源码 代码 of the app (DLL files: use IL-spy; Compiled Java - use Luyten)
Read the code and find new issues!*

--------------------------------------------------------------------------------------------------------------------------

#### -API TIP:24/31-

*Got stuck during an API pentest? Expand your attack surface!
Remember: de often disable security mechanisms in non-production en (qa/staging/etc);
Le this fact to bypass AuthZ, AuthN, rate limiting & input .*

--------------------------------------------------------------------------------------------------------------------------

#### -API TIP:25/31-

*Found an "export to PDF" feature?
There's a good chance the de use an external library to convert HTML --> PDF behind the scenes.
Try to inject HTML elements and cause "Export Injection".*

> Learn more about Export Injection:
--------------------------------------------------------------------------------------------------------------------------

#### -API TIP:26/31-

*Looking for BOLA (IDOR) in APIs? got 401/403 errors?
AuthZ bypass tricks:*
* Wrap ID with an array {“id”:111} --> {“id”:[111]}
* JSON wrap {“id”:111} --> {“id”:{“id”:111}}
* Send ID twice URL?id=<LEGIT>&id=<>
* Send wildcard {"user_id":"*"}

> In some cases, the AuthZ mechanism expects a plain string (an ID in this case), and if it receives a JSON instead it won't perform the AuthZ checks. Then, when the input goes to the data fetching component, it might be okay with a JSON instead of string(e.g: it flattens the JSON)
--------------------------------------------------------------------------------------------------------------------------

#### -API TIP:27/31-

*BE Servers no longer responsible for protecting against XSS.
APIs don't return HTML, but JSON instead.
If API returns XSS payload? -
E.g: {"name":"In<script>alert(21)</script>on}
That's fine! The protection always needs to be on the 客户端 side*

--------------------------------------------------------------------------------------------------------------------------

#### -API TIP:28/31-

*Pentest for .NET apps? Found a param containing file path/name? De sometimes use "Path.Combine(path_1,path_2)" to create full path. Path.Combine has weird behavior: if param#2 is absolute path, then param#1 is ignored.*
##### Le it to control the path

> Learn more:
--------------------------------------------------------------------------------------------------------------------------

#### -API TIP:29/30-

*APIs expose the underlying implementation of the app.
Pentesters should le this fact to better understand users, roles, resources & correlations between them and find cool & exploits.
Always be curious about the API responses.*

--------------------------------------------------------------------------------------------------------------------------

#### -API TIP:30/31-

*Got stuck during an API pentest? Expand your attack surface!
If the API has mobile clients, download old of the APK file to explore old/legacy functionality and discover new API endpoints.*

> Remember: companies don’t always implement security mechanisms from day one && DevOps engineers don’t often deprecate old APIs. Le these facts to find shadow API endpoints that don’t implement security mechanism (authorization, input filtering & rate limiting)

> Download old APK of android apps:
--------------------------------------------------------------------------------------------------------------------------

#### -API TIP: 31/31-

*Found a limit / page param? (e.g: /api/news?limit=100) It might be to Layer 7 DoS. Try to send a long value (e.g: limit=999999999) and see what happens :)*

--------------------------------------------------------------------------------------------------------------------------

Source

#### All of this information is taken from twitter of Inon Shkedy
##### Links:
* Inon Shkedy
* Traceableai
* OWASP API PROJECT

项目信息

开发语言：未知

Star 数：2241

技术要点

该项目属于黑客技术方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕This challenge is Inon Shkedy's 31 days API Security Tips.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。