API 安全測試的 31 個 Tips

TIP1

舊的API版本通常會包含更多的安全漏洞，他們缺乏一些安全機制。我們可以使用REST API的一些特徵來預測是否存在舊的API版本。比如當前有一個API被命名爲/api/v3/login ，我們可以檢查/api/v1/login是否存在。

TIP2

永遠不要假設只有一種方法來驗證API的身份。現代的應用程序有很多API接口用於認證:/api/mobile/login| /api/v3/login| /api/magic_link等。找出他們並測試所有的授權認證問題。

TIP3

sql注入

TIP4

測試一個Ruby on Rails的應用程序&注意到一個包含URL的HTTP參數?開發者有時會使用“Kernel#open”函數來訪問url == Game Over。只需要發送一個管道作爲第一個字符，然後發送一個shell命令(通過設計的命令注入)

TIP5

SSRF漏洞

內部端口探查
利用雲服務
使用http://webhook.com顯示IP地址和HTTP庫
下載大文件(7層DDOS)
反射SSRF，本地管理平臺泄露

TIP6

批量賦值是真實存在的。現代框架鼓勵開發人員在不瞭解安全性影響的情況下使用批量賦值。在使用過程中，不要猜測對象的屬性名，只需找到一個返回所有屬性的GET端點。

TIP7

一家公司向開發者公開了API接口，且在移動端和web端使用了相同的API程序。我們需要分開測試它們，不要假設它們實現了相同的安全機制。

TIP8

在測試api的時候，雖然REST API是當前最常見API形式，但是我們也還檢查一下API是否也支持SOAP。將content-type更改爲“application/xml”，在請求主體中添加一個簡單的xml，並查看API如何處理它。

有時身份驗證是在REST和SOAP API之間共享的不同組件中完成的== SOAP API可能支持JWT

TIP9

試圖找到BOLA(Broken Object Level Authorization)的弱點?HTTP bodies/headers 中的id往往比url中的id更容易受到攻擊。首先試着關注他們。

TIP10

利用REST的可預測特性來查找管理API endpoints!比如你看到一個api叫做GET /api/v1/users/<id>，我們可以試着修改請求方法POST/DELETE來create/delete users.

TIP11

檢查API是否使用授權頭？如果身份驗證機制不支持cookie，那麼這個API就被設計爲防止CSRF。

TIP12

即使ID是GUID或非數字類型的值，滲透測試人員也要嘗試發送一個數字值。例如: / ?user_id=111代替user_id=inon@traceable。有時身份認證機制同時支持這兩種方式，而且暴力破解數字更容易。

TIP13

使用大量分配繞過安全機制。例如，“輸入密碼”機制:

POST /api/reset_pass requires old password.
PUT /api/update_user is vulnerable to MA == can be used to update pass without sending the old one (For CSRF)*

TIP14

在API測試期間卡住了?擴大你的攻擊面!查找 sub/sibling domains 使用http://Virustotal.com和http://Censys.io。其中一些域可能使用不同的配置/版本公開相同的api。

TIP15

靜態資源包括照片、視頻.等，Web服務器(IIS、Apache)在授權時對靜態資源的對待是不同的。即使開發人員實現了良好的授權，也有很好的機會訪問其他用戶的靜態資源。

TIP16

即使您使用另一個web代理，始終在後臺使用Burp。@PortSwigger的人在幫助你管理pentest方面做得非常好。使用“樹視圖”(免費版本)功能查看您訪問過的所有API端點。

TIP17

移動證書鎖定？在你開始逆向工程和修補客戶端應用程序之前，檢查iOS和Android客戶端以及它們的舊版本。很有可能其中一個沒有啓用證書鎖定。

TIP18

公司和開發人員傾向於將更多的資源(包括安全性)投入到主要的api中。那些很少被人們使用過的API endpoints可以發掘一些有趣的漏洞。如POST /api/profile/upload_christmas_voice_greeting

TIP19

你覺得哪些功能更容易受到攻擊?

Organization's user management
Export to CSV/HTML/PDF
Custom views of dashboards
Sub user creation&management
Object sharing (photos, posts,etc)

TIP20

測試AuthN api ?如果您在生產環境中進行測試，那麼很有可能AuthN端點具有抗暴力破解保護。無論如何，DevOps工程師傾向於在非生產環境中禁用速率限制。不要忘記測試它們:)

A good example of this issue: Facebook Breach (Found by @sehacure) http://www.anandpraka.sh/2016/03/how-i-could-have-hacked-your-facebook.html

TIP21

在API測試期間卡住了?擴大攻擊面!使用http://archive.com，找到舊版本的web應用程序，探索新的API endpoints。不能使用客戶端?掃描.js文件尋找url。其中一些是API endpoints。

TIP22

api從設計上傾向於泄漏PII。BE工程師返回原始JSON對象，並依賴FE工程師過濾敏感數據。發現敏感資源(如收據)?找到所有返回它的EPs: /download_receipt，/export_receipt，等等。

有些端點可能會泄漏用戶無法訪問的過多數據。

TIP23

找到從網絡服務器下載任意文件的方法?將測試從黑盒測試轉爲白盒測試。下載app的源代碼(DLL files: use IL-spy; Compiled Java - use Luyten)閱讀代碼並發現新的問題!

TIP24

在API測試期間卡住了?擴大你的攻擊面!記住開發人員經常在非生產環境中禁用安全機制(qa/staging/etc);利用這一事實來繞過AuthZ, AuthN，速率限制和輸入驗證。

TIP25

發現“export to PDF”功能?開發者很有可能使用外部庫在後臺來轉換HTML——>PDF。嘗試注入HTML元素並導致Export Injection。

Learn more about Export Injection: https://medium.com/@inonst/export-injection-2eebc4f17117

TIP26

在api中尋找BOLA (IDOR) ?有401/403的錯誤嗎?AuthZ繞過技巧:

Wrap ID with an array{“id”:111} --> {“id”:[111]}
JSON wrap {“id”:111} --> {“id”:{“id”:111}}
Send ID twice URL?id=<LEGIT>&id=<VICTIM>
Send wildcard {"user_id":"*"}

在某些情況下，AuthZ機制需要一個普通字符串(在本例中是一個ID)，如果它接收到一個JSON，它就不會執行AuthZ檢查。然後，當輸入到數據獲取組件時，使用JSON而不是字符串(e。g:它扁平化了JSON)

TIP27

BE服務器不再負責保護XSS攻擊。api不返回HTML，而是返回JSON。如果API返回XSS payload? - E.g: {"name":"In<script>alert(21)</script>on}，所以在用戶側永遠都需要做XSS保護。

TIP28

如果我們在滲透的是一個.net編寫的app應用。找到一個包含文件路徑/名稱的參數?開發人員有時使用path. combine (path_1,path_2)來創建完整路徑。如果param#2是絕對路徑，那麼param#1被忽略。

Leverage it to control the path

Learn more: https://www.praetorian.com/blog/pathcombine-security-issues-in-aspnet-applications

TIP29

API暴露了應用程序的底層實現。滲透者應該利用這一事實來更好地瞭解用戶、角色、資源和它們之間的相關性，並發現很酷的漏洞和漏洞。始終對API響應保持好奇。

TIP30

在API測試期間卡住了?擴大你的攻擊面!如果API有移動客戶端，請下載APK文件的舊版本，以探索舊/遺留的功能，並發現新的API端點。

請記住:公司並不總是從一開始就實現安全機制，而且DevOps工程師也不會經常棄用舊的api。利用這些事實來發現沒有實現安全機制(授權、輸入過濾和速率限制)的影子API端點

Download old APK versions of android apps: https://apkpure.com

TIP31

發現一個limit / page參數?(例如:/api/news?limit=100)它可能容易受到7層DoS的攻擊。嘗試發送一個長值(例如:limit=999999999)，看看會發生什麼.

原文鏈接：https://github.com/inonshk/31-days-of-API-Security-Tips

原文作者：smodnix

本文轉自：https://cloud.tencent.com/developer/article/1805577