Airing

Airing

哲学系学生 / 小学教师 / 程序员,个人网站: ursb.me
github
email
zhihu
medium
tg_channel
twitter_id

HPP 的攻擊舉例與防範

HPP 的攻擊原理#

HPP,即 HTTP Parameter Pollution,HTTP 參數污染。在 HTTP 協議中是運行同樣名稱的參數出現多次,攻擊者通過傳播參數的時候傳輸 key 相同而 value 不同的參數,從而達到繞過某些防護與參數校驗的後果。它是一種注入型的漏洞,攻擊者通過在 HTTP 請求中插入特定的參數來發起攻擊。

舉一個栗子:

2015 年,有人發現了 HackerOne 社交分享按鈕的 HPP 漏洞

漏洞報告中是將 URL:

https://hackerone.com/blog/introducing-signal 

修改為:

https://hackerone.com/blog/introducing-signal?&u=https://me.ursb.me

當通過社交媒體鏈接分析內容時,此鏈接就會變成:

https://www.facebook.com/sharer.php?u=https://hackerone.com/blog/introducing-signal?&u=https://me.ursb.me

這裡,最後的參數 u 就會擁有比第一個更高的優先級,在 Facebook 分享時,Facebook 會跳轉到 https://me.ursb.me 而非 hackerone。

這裡來一個小 demo,更形象化的複現這個問題:

const express = require('express')
const bodyParser = require('body-parser')
const app = express()

app.use(bodyParser.json())

app.post('/login', (req, res, next) => {
  const { account } = req.body
  return res.json({ message: `login sccessful: ${account}` });
})

app.listen(3000)

請求一下這個模擬的登錄接口,假設這裡用戶在前端輸入了 airing,預想登錄賬戶 airing。但是請求被篡改,這裡附帶了兩個一樣的 account 參數,一個值為 airing,另一個為 ursb,在後端不做校驗的情況下,最終登錄的是 ursb 而非 airing。

POST /login HTTP/1.1
Host: localhost:3000
Content-Type: application/json

{
    "account": "airing",
    "account": "ursb"
}

HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Content-Length: 35
ETag: W/"23-/iZ+yuhJ7IhuWOkYuK395opzCZI"
Date: Thu, 11 Apr 2019 13:09:53 GMT
Connection: close

{
  "message": "login sccessful: ursb"
}

HPP 的防範措施#

HPP 的行為主要取決於後端收到多個名稱相同的參數時會如何處理。不同伺服器處理方式不同。

我們需要注意 HTTP 協議是允許同名的參數的,在整個應用的處理過程中要意識到這一點從而根據業務的特徵對這樣的情況作正確的處理。當然要防止 HPP 漏洞,最重要的是後端一定要做好對輸入參數的校驗。

參考資料#

載入中......
此文章數據所有權由區塊鏈加密技術和智能合約保障僅歸創作者所有。