API威脅防護實踐之天清Web應用安全網關係統
隨著 Web 2.0 時代的到來,由於 JSON 數據格式簡單,容易開發。開發者更喜歡使用 JSON 格式來編寫 API,Web API 也呈現爆發性的增長。特別是近幾年來,隨著社交媒體和在線服務的發展,服務的提供者更喜歡對外提供開放的 Web API 供開發者調用。開發者通過網路調用 Web API 實現登錄認證、消息推送、訂單支付等功能,API 之間的相互調用極大的提高了開發效率,開發者可以在短時間內完成應用的設計與開發。只要服務提供者對外公開了 API,開發者就可以很簡單的將服務集成進自己的應用,直接的享用該服務,不同的服務提供者集合在一起謀求共同發展。
Web API 是指使用 HTTP 協議進行網路調用的API(Application Programming Interface),是一個應用的外部介面。對於一個應用程序,人們通常不關注內部結構實現細節,只關心外部功能的使用。那麼調用應用程序完成某個功能的規範方法即可稱之為程序的 API。
◆Web API 安全隱患◆
由於 Web API的廣泛普及與使用,與傳統的 Web 安全問題一樣,也存在敏感信息被惡意獲取,用戶許可權被惡意使用等問題。除了天氣預報、地理位置等這類公共服務信息的提供,幾乎所有的 API 服務都存在用戶認證、許可權控制等,以便於服務提供商進行管理和收費。
近年來隨著移動應用、雲端應用的普及,Web 站點與 Web API 配套開發的情形越來越多,API 安全問題也是與日俱增。假如 Web API 缺陷被惡意利用,用戶隱私被公開或者盜用,那麼服務提供者將會失去信用、失去用戶,可能導致服務提供者破產倒閉,永遠無法再次贏得用戶的信任。
例如Instagram 在2017年由於 API 存在 bug,不少認證用戶都發現自己的個人資料(包括郵箱地址、電話號碼等)可輕易被他人獲取。事情發生後,Instagram 雖然並未對漏洞細節做過多解釋,只是表示漏洞已經修復。Instagram 對所有的註冊用戶發了電子郵件,提醒他們提防此次攻擊,並小心可能會出現的釣魚攻擊,還有那些通過社工手段(郵件,簡訊,電話等方式)所帶來的攻擊。
● 安全隱患一:
客戶端與伺服器之間的監聽與嗅探
Web API 和普通的 Web 站點一樣,通過 HTTP 協議在互聯網上進行數據傳輸,由於HTTP協議本身並未有任何加密的設計,因此不能保證通信過程中不被監聽。越來越多的公共Wi-Fi被黑客盯上,通常黑客設法和受害用戶連接在同一區域網內,只要打開嗅探監聽工具,受害者在網路中的傳輸過的敏感信息將被黑客獲取。如果被竊取的信息中直接含有個人信息和密碼,黑客可能通過這個信息直接登錄受害人的用戶,進一步可能造成信息泄露或財產損失。另外一種,黑客也可能劫持受害者用戶的會話,伺服器將無法區分受害者還是黑客,黑客可以進行受害者許可權範圍內的一切操作。
Web API 在通信時使用了 HTTPS 協議通信,將極大增強會話的安全性。那麼是不是只要使用了HTTPS協議通信就能保證會話不被劫持,敏感信息不被獲取呢?答案是否定的。
2014年4月爆發的Heartbleed安全漏洞,導致攻擊者可能獲取到伺服器上保存的明文信息。另外,使用 HTTPS加密通信時,也有可能存在中間人攻擊,因此需要保證使用有效的SSL證書進行加密認證。
● 安全隱患二:
使用瀏覽器訪問API時產生的安全意外
Web API 是專門為程序間相互調用而設計的,如果意外的使用瀏覽器來訪問 Web API 則也可能存在安全問題。
? XSS攻擊
XSS攻擊將用戶的非法輸入的JavaScript腳本在響應頁面的HTML中執行。攻擊者可能利用XSS漏洞劫持會話、盜取Cookie、篡改頁面等操作。在Web API 返回 JSON 數據時,如果Content-Type 設置不合理便會造成 XSS 漏洞攻擊。
例如,假設有以下JSON數據
{「data」:」」}
當伺服器返回該 JSON 數據時,將響應頭中的Content-Type設置為test/html 或者設置為Content-Type: text/plain(IE下可以執行)時,該 JSON 數據被解釋為 HTML 代碼,瀏覽器直接執行了其中的JavaScript代碼。
? CSRF攻擊
Web API 防護CSRF 攻擊的方法和常規的 Web 網站並沒有什麼不同。通常需要禁止通過GET方法修改服務端的數據,而是採用 POST、PUT、DELETE等方法進行標準化操作。即使設置了不允許GET方式修改伺服器數據,CSRF依然可以通過Form表單使用POST方法發起攻擊,而且不受同源策略的影響。
● 安全隱患三:
業務層面的惡意訪問
? 篡改ID非法獲取用戶敏感信息
篡改請求參數獲取敏感信息,攻擊者可以通過修改客戶端發送到伺服器的參數,企圖獲取許可權範圍之外的敏感信息。例如使用以下形式的
URL:
https://api.example.com/v1/user/123?info=email
從形式上來看,URL中的123可能為用戶ID,假如提交該URL請求可以獲取到ID為123用戶的email信息,那麼攻擊者通過修改用戶ID就能獲取到其他用戶的email信息。
下面具體分析一下這個問題,一般的有些Web API 設計友好,通常在URL裡面使用user關鍵字或者在參數裡面使用email關鍵字來表明業務的一些相關信息。設計者初衷是為了開發者更加簡單明了的使用API來實現程序調用,但是也給攻擊者帶來可乘之機。攻擊者通過分析URL的形式特徵並結合具體的業務對關鍵字進行篡改,企圖非法獲取敏感信息。
? 參數異常輸入導致未授權操作
API的設計者在設計之初是為了方便的使用API進行程序間的調用,有時考慮不到太多的異常輸入造成的安全隱患。例如知名的WordPress網站系統曾經存在REST API 由於異常輸入造成許可權繞過,攻擊者可以通過API篡改網站頁面內容。
WordPress 4.7以上的版本,WordPress REST API提供了一組易於使用的HTTP端點,用戶可以以簡單的JSON格式訪問網站的數據,包括用戶,帖子,分類等。檢索或更新數據與發送HTTP請求一樣簡單。API 提供了對用戶、文章、分類等不同功能的控制,也可以通過 API 檢索或修改文章。在WorePress 4.7.0和4.7.1版本中存在漏洞,由於許可權控制失效導致內容注入或修改,攻擊者通過修改id為一個異常值就可以完成網站內容的篡改,而不需要任何認證信息。
WordPress 提供的部分 API 功能:
查看文章列表
GET /index.php/wp-json/wp/v2/posts
檢索文章
GET /index.php/wp-json/wp/v2/posts/1
修改文章
POST /index.php/wp-json/wp/v2/posts/1?id=1
Content-Type: application/json
{"title":"test"}
提交以上修改文章的請求,伺服器返回401 未認證。
如果稍微修改以上的URL內容,例如修改為POST /index.php/wp-json/wp/v2/posts/1?id=1abc,即將id參數的值由1修改為1abc,再次嘗試提交。伺服器返回200 OK,WordPress網站的第一篇文章標題被修改為test,攻擊成功。
◆WAF檢測與防護◆
Web API和普通的應用相似都是通過HTTP協議對外服務,普通Web應用中存在的漏洞和缺陷,在Web API 中同樣也會存在。啟明星辰WAF產品有專門API防護模塊,通過該防護模塊與WAF功能相結合可對Web API的問題進行檢測與防護,Web API防護模塊及API攻擊檢測上報事件,如下:
啟明星辰WAF產品適應從小型企業到大型數據中心等各種規模和客戶業務模型下的網路環境,並廣泛應用於金融、運營商、政府、能源、大企業、煙草、稅務、交通、衛生、教育等行業領域。
啟明星辰作為中國信息安全行業的領航企業,一直秉承誠信和創新精神,致力於提供具有國際競爭力的、自主創新的WAF安全產品。啟明星辰WAF產品入圍Gartner魔力象限,根據第三方Frost& Sullivan權威機構WAF市場佔有率連續5年排名第一,啟明星辰WAF產品連續多年在大中國區WAF市場名列前茅。
?
END
?
往期回顧
▼
※最新Adobe Flash 0day漏洞攻擊出現,啟明星辰APT產品無需升級即可檢測
TAG:啟明星辰 |