除了SSL之外，有沒有一種方法可以在網頁上進行安全輸入？

Question

我想在GitHub上設置一個項目頁面，以便它充當一個活動站點。

該網站需要一個API sid &令牌（無論是長文本字符串），在自託管環境中，用戶只需添加到配置文件中。

如果我通過GitHub項目頁面託管，用戶將通過表單提供其sid /令牌。帶表格的頁面需要通過SSL提供，以便sid /令牌不會以明文形式傳輸。問題是GitHub項目頁面不允許使用SSL。因此，如果我可以找到另一種安全的方式來通過除了使用SSL之外的窗體進行輸入，那麼我可以通過GitHub項目頁面託管整個託管服務。

該項目將是開源的，所以我不期望任何種類的編碼/哈希方案的工作，因爲方法將公開。

sid /令牌正在捲曲調用API中使用，其中是通過SSL發送。也許有一種方法可以將表單輸入直接指向該SSL URL，而不是通過非SSL GitHub項目頁面...

任何想法？

Answer 1

如果可能的話，您可以僅爲目標腳本的HTTPS URL提供action屬性。

你也可以使用某種使用Javascript的Challenge-Response加密/散列方案。算法是這樣的：

1. 服務器生成唯一的隨機令牌，將其保存並與HTML格式一起發送給客戶端。
2. 在客戶端，Javascript攔截表單提交併將敏感表單數據與服務器生成的令牌散列爲鹽。
3. 服務器現在可以檢查哈希是否等於它自己計算的哈希值

無論其

一個人在這方面的中間人攻擊者通過修改通信（例如能力ARP欺騙，DHCP或DNS欺騙）總是可以從服務的HTML中剝離所有客戶端保護機制。查看SSLStrip，瞭解重寫HTTPS URL以便即時解密HTTP URL的工具。挑戰 - 響應可能會被擊敗，像這樣：

1. 保存服務器發送的令牌，從HTML表單中刪除Javascript。
2. 由於表單提交現在沒有被攔截，我們得到原始輸入數據。
3. 使用與Javascript執行的算法相同的算法對數據進行哈希處理。
4. 謝謝你所有的魚。

你看，攔截攻擊者可能會打敗你試圖彌補的任何防禦機制。