API介面是什麼？API介面常見的安全問題與安全措施有哪些？

前言：如今具有開放式的業務體系結構將是下一代網路的重要特徵之一。其中，關鍵的技術之一就是網路控制與應用層之間的應用程式介面(API)。面對API介面的安全問題，我們可以採取幾種安全措施。

近日，網路安全研究人員發現一組異常的移動應用程式，這些應用程式向民眾公開了 Twitter API 金鑰。據統計，此類應用程式多達3200個。

網路安全公司CloudSEK首次發現了這一問題，該公司在檢查大型應用程式集合是否存在資料洩漏時，發現了大量應用程式洩露了Twitter API金鑰。

據悉，造成這一現象的主要原因是開發者在整合移動應用與Twitter 時，會得到一個特殊的認證金鑰，允許其移動應用與 Twitter API互動。當使用者使其 Twitter賬戶與移動應用聯絡起來時，這些金鑰允許其他人代表使用者行事，例如透過 Twitter 登入，建立推文，傳送 DM 等。

設法得到這些金鑰後，就能夠以關聯的 Twitter 使用者身份進行操作，建議大家不要將金鑰直接儲存在移動應用中，避免找到並利用它們。CloudSEK 強調，API 金鑰洩漏一般是應用程式開發人員造成的，他們在開發過程中將認證金鑰嵌入到Twitter API 中，但是之後並未刪除。

如今具有開放式的業務體系結構將是下一代網路的重要特徵之一。其中，關鍵的技術之一就是網路控制與應用層之間的應用程式介面(API)。透過應用程式介面，業務開發商 、獨立軟體提供商 (ISV)等第三方應用可以獲得使用現有網路資源的能力 ，從而方便 、靈活地為客戶提供所需的業務。API介面已經深入應用到各個網頁與APP中。

API其實就是應用程式介面(Application Programming Interface)的簡稱。API 是一些功能、定義或者協議的集合，提供應用程式或者程式開發人員基於軟體訪問一組例程的能力，對外封裝完善，呼叫時無需學習 API內部原始碼，依據 API文件功能說明書來使用即可。

API介面的資料格式有哪些？

目前 API 介面支援 XLSX、JSON、XML、CSV、RDF 等資料格式，其中 JSON 和 XML 是主流的資料格式，幾乎所有 API 介面都支援這兩種資料格式。

JSON (JavaScript Object Notation)是一種輕量級的資料交換格式，具有良好的可讀和便於快速編寫的特性，可在不同平臺之間進行資料交換。

XML 是擴充套件標記語言(Extensible Markup Language)，用於標記電子檔案使其具有結構性的標記語言，可以用來標記資料、定義資料型別，是一種允許使用者對自己的標記語言進行定義的源語言。

JSON與XML相比，兩者各有不同的特點。

JSON與XML 相比是一種更加輕量級的資料格式，而且更加易於解析，支援多種語言，這使得 JSON 在大資料時代備受歡迎，而且隨著應用程式和平臺的不斷髮展，應用程式的功能變得越來越複雜，但為了保證使用者體驗的最佳化，需要透過重構程式碼，將複雜的邏輯封裝在內部，保持其對外提供的 API 仍然簡潔。JSON 也正因為簡潔這一優勢逐漸超越了XML，成為了應用間的首選資料交換格式。

API介面的安全問題

如今API介面的運用已經十分廣泛，API 介面如果沒有經過安全處理，則很容易出現三類安全問題： 資訊截獲、篡改與洩露。Twitter API 金鑰洩露事件就是如此，所以API 介面的安全問題不容小覷。

面對API介面的安全問題，我們可以採取以下安全措施：

一、非對稱加密

非對稱加密是加密演算法中的一種，和對稱加密演算法只有一個金鑰檔案不同的是，非對稱加密有兩個金鑰檔案，也就是公鑰與私鑰。顧名思義，公鑰是對外公開狀態，而私鑰則是屬於保密狀態，如果駭客只有公鑰而沒有私鑰，及時擷取到報文也沒有任何影響。在1978年，Ron Rivest、Adi Shamir、Leonard Adleman 三人共同提出了RSA非對稱加密技術，該技術的名字便是取自於這三人的首字母。以現在的情況來看，RSA 非對稱加密技術屬於最有影響力的加密演算法，因為該技術能夠抵禦已知大多數的密碼，所以被推薦為加密資料的標準。

開放API 平臺在應用非對稱加密後，公鑰公開給那些需要對接 API 的人，這些對接 API 的人然後透過公鑰將使用者的相關資料進行加密和傳輸。如果想要對其解密，那麼就必須要用 API 平臺的私鑰，這個過程中，即便有駭客利用抓包工具將報文擷取、即便是報文相關資料被洩露出去，對方沒有私鑰來解密，那麼就算有報文資料也沒有任何意義。因此，為了防止使用者的一些敏感資訊被洩露，便可以將非對稱加密應用其中，能夠很好地解決問題。

非對稱加密流程：

如果在有條件的情況下，API介面則是可以使用 HTTPS 協議來將資料進行傳輸，因為相比於RSA 加密技術，HTTPS 的傳輸更為安全。

HTTPS 解決傳輸資料安全問題的方式是對雙方身份進行確定，從而在兩者之間建立其安全通道，而且 HTTPS 協議相比於 RSA 非對稱加密技術要更為完善，後者所具備的技術，前者都能夠實現，並且前者還應用到了對稱加密。

不過該項技術也有著一定的不足，主要包括需要購買證照、伺服器開銷大、維護成本高、效能較低等，所以在考慮成本的情況下，HTTPS 不是最優選，而 RSA 加密演算法是最適宜的選擇。

二、資訊摘要演算法5（MD5）

資訊摘要演算法5也叫MD5全稱為Message-Digest Algorithm 5。最大的特點就是其演算法不可逆，主要方法是對任意一段字串生成摘要。所以，資訊摘要演算法5大多時候是被用來儲存使用者的登入密碼，並且還能夠用來比對資訊是否一致。資訊摘要演算法5在目前是不會被真正破解的，所謂的破解方法也只不過是利用非常龐大的一個資料量來對其進行碰撞，簡單一點說，就是一個擁有著巨大資料的彩虹表中存了許多與資訊摘要演算法 5字串相對應的字串，因此在破解資訊摘要演算法5時，需要在這個基礎資料非常龐大的表裡檢索加密好的資訊摘要演算法5字串，檢索的時間是與該表中的資料成正比的，因此檢索所需要的時間會非常漫長，就算是透過反推法來破解資訊摘要演算法5的密碼，那也要耗費大量的精力與時間，所以資訊摘要演算法5算是比較安全的加密演算法。

資訊摘要演算法如何保護API介面？

一般情況下，API設計者首先需要在對外介面文件中約定好資訊摘要演算法5的加密欄位和順序，在對API介面進行呼叫時,則需要透過文件中API設計者所約定好的順序來對資訊摘要演算法5進行加密,而且為了能夠保證對比有意義，API後臺也需要根據約定的順序進行加密。

在對比時，如果發現接收到的資訊摘要演算法5摘要和獲取引數所生成的資訊摘要演算法5摘要不一致,如果不是在呼叫API介面時出現操作錯誤，那麼便能夠確定與之相關的資料已經處於篡改狀態，因此便需要拒絕處理這批資料。

相反的，如果所接收到的資訊摘要演算法5摘要和獲取引數生成的資訊摘要演算法5摘要一致,那麼便能夠確認資料並未被篡改。舉個例子，某公司在呼叫API介面時，需要按照公司的要求傳入產品編碼、購買數量以及資訊摘要演算法5摘要3個引數。公司在接到傳來的相關引數之和，需要透過同樣的方法來進行資訊摘要演算法5,之後對兩者之間的摘要檔案進行比對，不對等則表示有篡改風險，需要放棄該介面請求。

三、令牌鑑權

公網暴露API介面之後，便相當於豪宅的大門被敞開了一般，任何人都能夠自由出入，這也就使得豪宅內的財產變得非常不安全,因此就需要有安保人員來檢視進出人員的通行證，令牌便可以理解為該通行證，只有獲得了令牌的人才能夠進出，而沒有令牌的人則嚴禁入內，一律攔截在大門外。

令牌鑑權機制其實就是放API介面伺服器會使用者在登入之後生成一組不重複的字元,從而形成登入人的令牌，令牌作為KET在REDIS快取放置在伺服器。而 VALUE 則存放登入使用者的基本資訊，同時對token失效時間進行設定。

令牌鑑權校驗則更為快速有效，在呼叫開放API時需要攜帶令牌，而伺服器來對令牌進行校驗，包括存在與否、過期與否等，如果令牌過期或者不存在，則直接返回異常資訊，強制客戶重新登入獲取新令牌。

資料安全是一場攻防持久戰，需要不斷對其進行改進與完善，才能夠有效保障客戶權益與資料安全。如果等到資料洩露事件發生，再去應急的話，就已經錯過了最好的時機。