Business Logic Vulnerabilities

這是是應用程式設計和實作中常見的缺陷,允許攻擊者引發意外行為。 這可能使攻擊者能夠操縱合法功能來實現惡意目標。 識別它們通常需要一定程度的人類知識,例如了解業務領域或攻擊者在給定上下文中可能有什麼目標。 這使得使用自動漏洞掃描器很難檢測到它們。 因此,Business Logic Vulnerabilities(業務邏輯漏洞)通常是錯誤賞金獵人和手動測試人員的重要目標。

邏輯漏洞的產生 ,是因為設計和開發團隊對使用者如何與應用程式互動做出了有缺陷的假設。常見的問題如下:

  • 過度信任使用者操作:例如未檢查使用者輸入
  • 輸入範圍處理不當:例如正負範圍未處理,數字邊界處理不當, 對異常輸入的處理不一致
  • 使用者不會總是遵循預期的順序:例如在特定流程輸入的合理性未驗證, 端點未隔離, 沒有完整的流程檢查, 可以跳過流程的檢查點
  • 特定於業務領域的邏輯缺陷:例如未檢查業務狀態, 利用業務規則套利

未檢查使用者輸入

使用者送出請求時直接將商品價格修改成低價,系統也接受這個價格

舉例如下

某一網站選擇商品放入購物車時,可以看到以請求,價格為1337

POST /cart HTTP/2
...omit...
product=1&redir=PRODUCT&quantity=1&price=1337

因為過度信任使用者操作,所以用戶可直接修改價格,如下

POST /cart HTTP/2
...omit...
product=1&redir=PRODUCT&quantity=1&price=1

此時到購物車後就會發現這個商品變成1元

Lab: Excessive trust in client-side controls


正負範圍未處理

送出請求時將購買數改成負數,導致買越多商品越便宜

舉例如下

某一網站選擇商品放入購物車時,輸入負金額網站不會阻擋,

因此可以先選擇商品,並將數量改成負數後放入購物車,如下

POST /cart HTTP/2
...omit...
product=2&redir=PRODUCT&quantity=-10&price=1337

在結帳頁面會發現結帳金額變負,但因為是負金額無法結帳

因此要在選擇其他商品放入購物車,一直到結帳金額變成正數,就可以正常結帳

Lab: High-level logic vulnerability


數字邊界處理不當

故意買很多商品,讓結帳金額突破正數上限值而轉成負數

舉例如下

某一網站購物車結帳時,金額超過2,147,483,647會變成-2,147,483,647

所以先選擇商品並將數量設定99後放入購物車,在把以下請求傳到burp intruder,選擇null payloads後設定Continue indefinitely發動攻擊

POST /cart HTTP/2
...omit...
product=1&redir=PRODUCT&quantity=99&price=1337

當攻擊正在進行時,刷新頁面監控總價,一但總價超過2,147,483,647就會變成-2,147,483,648,然後慢慢接近0

一旦快接近0就可以停止攻擊,並搭配選擇其他商品讓總價維持在0-100之間

Lab: Low-level logic flaw


對異常輸入的處理不一致

利用輸入長度截段特性,偽造特定帳號

舉例如下

某一網站在註冊帳號時,系統會把用@dontwannacry.com信箱註冊的帳號當做admin,而且只支持255個字元

所以先設計一個@dontwannacry.com域名的email帳號,長度要255字元如下

attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234verylongstringverylongstringverylongst@dontwannacry.com

在設計一個包含dontwannacry.com字符串的email域名,並加入其中,如下

attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234verylongstringverylongstringverylongst@dontwannacry.com.ac881fc51ee252ee80936d82019b0090.web-security-academy.net

確認該域名@dontwannacry.com.ac881fc51ee252ee80936d82019b0090.web-security-academy.net能收到信後,用這個email註冊,收到信點擊確認鏈結後,註冊成功並登入

但因為網站在登入註冊的邏輯上有問題,當帳戶超過255個字會被截段,因此網站會誤認為是用以下的@dontwannacry.com當做註冊帳號

attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234attack1234verylongstringverylongstringverylongst@dontwannacry.com

由於系統會把用@dontwannacry.com信箱註冊的帳號當做admin,因此成功獲得管理者權限

Lab: Inconsistent handling of exceptional input


在特定流程輸入的合理性未驗證

系統提供用戶改自己email的功能,但因為系統沒有對email做驗證,所以用戶可以將email改成任何值

舉例如下

某一網站會把用@dontwannacry.com信箱註冊的帳號當做admin

所以可先新註冊一個帳號,然後在把自己的email改為xxx@dontwannacry.com

但因為網站存在邏輯漏洞,沒有限制這個行為,而且系統只用email判斷管理者,當系統發現剛新註冊的帳號為xxx@dontwannacry.com,就會判定為管理者。 因此新註冊的帳號成功取得admin身份

Lab: Inconsistent security controls


端點未隔離

系統提供用戶改自己密碼的功能,但因為系統沒有做限制,所以用戶可以改任何人的密碼

舉例如下

某一網站提供用戶自己改密碼的功能,但並不需要輸入舊密碼如下

POST /my-account/change-password HTTP/2
...omit...
csrf=89efyur6238edkf34&username=wiener&new-password-1=123qwe&new-password-2=123qwe

因此可以直接把username換成administrator,然後直接administrator的密碼改成123qwe,如下

POST /my-account/change-password HTTP/2
...omit...
csrf=89efyur6238edkf34&username=administrator&new-password-1=123qwe&new-password-2=123qwe

Lab: Weak isolation on dual-use endpoint


沒有完整的流程檢查

使用者只要送出確認完成的參數,系統不檢查就判定流程完成

舉例如下

某一網站將商品放入購物車後,使用以下2步驟結帳

1.POST /cart/checkout (統計金額100)

2.GET /cart/order-confirmation?order-confirmation=true ( 確認金額100付款完成 )

但因為系統沒有完整檢查參數,因此攻擊者可以在第2步最後結帳完成確認前,加入其他商品,如下

1.1 POST /cart/checkout (統計金額100)

1.2 加入其他商品

2.GET /cart/order-confirmation?order-confirmation=true ( 確認金額100付款完成 )

只需要傳送購買結帳完成的參數,系統就會以為結帳完成,攻擊者就可以得到商品

Lab: Insufficient workflow validation


可以跳過流程的檢查點

在登入時避開權限設定的參數,導致系統無法將權限做調整,讓使用取得默認權限

舉例如下

某一網站登入流程如下

1 POST /login 輸入帳密登入

2 GET /role-selector 帳密確認成功後取得所有權限,所以會根據帳號角色將不必要的權限刪除

所以攻擊時只要把第2步的請求丟掉,網站就不會調整權限,因此就會維持所有權限的狀態

Lab: Authentication bypass via flawed state machine


未檢查業務狀態

業務規則執行時存在缺陷,在流程中沒有記錄重要狀態

舉例如下

某一網站提供coupon功能,一個coupon code只能用一次,連續使用會被系統禁止

但該系統有邏輯漏洞,只比較上一次的coupon code做判斷,因此能用以下方式繞過有缺陷的檢查機制

  • 第1次,使用coupon code a
  • 第2次,使用coupon code b
  • 第3次,使用coupon code a 可以成功,因為和上次coupon code b不同,所以系統以為沒用過

Lab: Flawed enforcement of business rules


利用業務規則套利

利用即有商業規則,找出可以套利的方法

某一網站提供以下機制

  • coupon code: 可免費取得, 不限制使用次數, 買任何商品可以打7折
  • gift card: 取得一張要花10元, 1張只能用1次, 可折扺商品價格10元也可換成等價現金

因此只要透過以下步驟就能套利

  1. 用coupon code買gift card只要7元
  2. 把gift card換成等價現金10元,就能現賺3元
  3. 重覆1-2步驟多次,就能買到任何價格的商品

Lab: Infinite money logic flaw