如何破解伺服器介面

1. 08.如何保證API介面的安全性問題01

1.互聯網Api介面到底如何保證安全性問題？
2.代碼落地實戰防禦XSS、CSRF攻擊
3.代碼落地如何防禦介面數據被黑客抓包篡改？
4.介面數據加密對稱還是非對稱加密好

XSS攻擊通常指的是通過利用 網頁 開發時留下的漏洞，通過巧妙的方法注入惡意指令代碼到網頁，使用戶載入並執行攻擊者惡意製造的網頁程序。這些惡意網頁程序通常是JavaScript，但實際上也可以包括 Java 、 VBScript 、 ActiveX 、 Flash 或者甚至是普通的HTML。攻擊成功後，攻擊者可能得到包括但不限於更高的許可權（如執行一些操作）、私密網頁內容、會話和cookie等各種內容。 [1]

腳本攻擊：利用JavaScript 注入 到後台資料庫中，在通過展示數據載入該腳本 該腳本中（

1.使用js獲取cookie信息（jwt）

2.將該jwt數據 上傳黑客伺服器（ajax）

）

獲取jwt---用戶會話信息 讓後模擬請求形式使用該jwt登錄。

xss攻擊典型網站：論壇、評論區

http://127.0.0.1:8080/getUserInfo?userName=

http://127.0.0.1:8080/getUserInfo?userName=

前端傳遞 js 腳本到伺服器端

後端介面將該腳本存放資料庫中

前端html

將用戶前端所提交的參數進行過濾。

html 大於> 小於號 <

>

該方式的缺陷：每個參數都需要像這樣寫 代碼非常冗餘

介面接受參數 ？傳遞參數形式---

傳遞參數都是json數據形式

spring mvc 接受 json數據提供 api回調

1.可以使用第三方抓包工具，對請求前後實現代理，可以修改參數請求內容和參數響應內容,抓包工具http調試工具

2.Fiddler4下載地址：https://pc.qq.com/detail/10/detail_3330.html

使用Fiddler4篡改請求之前：

使用MD5可以直接驗證簽名參數 MD5 屬於單向加密，只能夠暴力破解。

MD5應用場景 在nacos分布式配置中心中，使用MD5 比對文件內容是否發生改變

HasherPro比對文件內容是否發生改變。

MD5在線暴力破解地址：https://www.cmd5.com/

String userName= "123456" ;
System. out .println( DigestUtils. md5Hex (userName));

黑客如何破解？自己需要根據參數內容 生成簽名

如果只是改了參數內容---沒有用的 所以我們需要該簽名

{"password":"123456","phoneNumber":"phoneNumber","channel":"安卓","equipment":""}

{sign=, timestamp=1652537015771}

2. 如何查看伺服器所開放的埠

1、首先打開電腦之後，在鍵盤上按下組合鍵 win+r 打開運行對話框，如下圖所示。

3. web伺服器如何訪問socket伺服器的介面

不需要有IP分配的知識，伺服器需要有操作系統 windows socket Windows Sockets 規范以U.C. Berkeley 大學BSD UNIX 中流行的Socket 介面為範例定義了一套microsoft Windows 下網路編程介面。它不僅包含了人們所熟悉的Berkeley Socket 風格的庫函數；也包含了一組針對Windows 的擴展庫函數，以使程序員能充分地利用Windows 消息驅動機制進行編程。 Windows Sockets 規範本意在於提供給應用程序開發者一套簡單的API，並讓各家網路軟體供應商共同遵守。此外，在一個特定版本Windows 的基礎上，Windows Sockets 也定義了一個二進制介面（ABI），以此來保證應用WindowsSockets API 的應用程序能夠在任何網路軟體供應商的符合Windows Sockets 協議的實現上工作。因此這份規范定義了應用程序開發者能夠使用，並且網路軟體供應商能夠實現的一套庫函數調用和相關語義。 遵守這套Windows Sockets 規范的網路軟體，我們稱之為Windows Sockets兼容的，而Windows Sockets 兼容實現的提供者，我們稱之為Windows Sockets提供者。一個網路軟體供應商必須百分之百地實現Windows Sockets 規范才能做到現Windows Sockets 兼容。 任何能夠與Windows Sockets 兼容實現協同工作的應用程序就被認為是具有Windows Sockets 介面。我們稱這種應用程序為Windows Sockets 應用程序。 Windows Sockets 規范定義並記錄了如何使用API 與Internet 協議族（IPS，通常我們指的是TCP/IP）連接，尤其要指出的是所有的Windows Sockets 實現都支持流套介面和數據報套介面。 SOCKET用於在兩個基於TCP/IP協議的應用程序之間相互通信。最早出現在UNIX系統中，是UNIX系統主要的信息傳遞方式。在WINDOWS系統中，SOCKET稱為WINSOCK。 兩個基本概念：客戶方和服務方。當兩個應用之間需要採用SOCKET通信時，首先需要在兩個應用之間（可能位於同一台機器，也可能位於不同的機器）建立SOCKET連接，發起呼叫連接請求的一方為客戶方，接受呼叫連接請求的一方成為服務方。客戶方和服務方是相對的，同一個應用可以是客戶方，也可以是服務方。 在客戶方呼叫連接請求之前，它必須知道服務方在哪裡。所以需要知道服務方所在機器的IP地址或機器名稱，如果客戶方和服務方事前有一個約定就好了，這個約定就是PORT（埠號）。也就是說，客戶方可以通過服務方所在機器的IP地址或機器名稱和埠號唯一的確定方式來呼叫服務方。在客戶方呼叫之前，服務方必須處於偵聽狀態，偵聽是否有客戶要求建立連接。一旦接到連接請求，服務方可以根據情況建立或拒絕連接。連接方式有兩種，同步方式（Blocking）和(noBlocking). 客戶方發送的消息可以是文本，也可以是二進制信息流。當客戶方的消息到達服務方埠時，會自動觸發一個事件（event），服務方只要接管該事件，就可以接受來自客戶方的消息了。 戴

支持你一下

4. iOS請求webservice介面，參數類型是buffer流，怎麼破

數據流在ios客戶端向伺服器端提交數據時使用的類型可以用NSData. 這需要你將客戶端要提交的數據先轉成NSData類型。如我們在ios客戶端向伺服器端上傳圖片時，就需要將UIImage對象轉成NSData並提交到伺服器端。

5. 如何有效的防止Java程序被反編譯和破解

由於Java位元組碼的抽象級別較高，因此它們較容易被反編譯。下面介紹了幾種常用的方法，用於保護Java位元組碼不被反編譯。通常，這些方法不能夠絕對防止程序被反編譯，而是加大反編譯的難度而已，因為這些方法都有自己的使用環境和弱點。
1.隔離Java程序
最簡單的方法就是讓用戶不能夠訪問到Java Class程序，這種方法是最根本的方法，具體實現有多種方式。例如，開發人員可以將關鍵的Java Class放在伺服器端，客戶端通過訪問伺服器的相關介面來獲得服務，而不是直接訪問Class文件。這樣黑客就沒有辦法反編譯Class文件。目前，通過介面提供服務的標准和協議也越來越多，例如 HTTP、Web Service、RPC等。但是有很多應用都不適合這種保護方式，例如對於單機運行的程序就無法隔離Java程序。
2.對Class文件進行加密
為了防止Class文件被直接反編譯，許多開發人員將一些關鍵的Class文件進行加密，例如對注冊碼、序列號管理相關的類等。在使用這些被加密的類之前，程序首先需要對這些類進行解密，而後再將這些類裝載到JVM當中。這些類的解密可以由硬體完成，也可以使用軟體完成。
在實現時，開發人員往往通過自定義ClassLoader類來完成加密類的裝載(注意由於安全性的原因，Applet不能夠支持自定義的ClassLoader)。自定義的ClassLoader首先找到加密的類，而後進行解密，最後將解密後的類裝載到JVM當中。在這種保護方式中，自定義的ClassLoader是非常關鍵的類。由於它本身不是被加密的，因此它可能成為黑客最先攻擊的目標。如果相關的解密密鑰和演算法被攻克，那麼被加密的類也很容易被解密。
3.轉換成本地代碼
將程序轉換成本地代碼也是一種防止反編譯的有效方法。因為本地代碼往往難以被反編譯。開發人員可以選擇將整個應用程序轉換成本地代碼，也可以選擇關鍵模塊轉換。如果僅僅轉換關鍵部分模塊，Java程序在使用這些模塊時，需要使用JNI技術進行調用。當然，在使用這種技術保護Java程序的同時，也犧牲了Java的跨平台特性。對於不同的平台，我們需要維護不同版本的本地代碼，這將加重軟體支持和維護的工作。不過對於一些關鍵的模塊，有時這種方案往往是必要的。為了保證這些本地代碼不被修改和替代，通常需要對這些代碼進行數字簽名。在使用這些本地代碼之前，往往需要對這些本地代碼進行認證，確保這些代碼沒有被黑客更改。如果簽名檢查通過，則調用相關JNI方法。
4.代碼混淆
代碼混淆是對Class文件進行重新組織和處理，使得處理後的代碼與處理前代碼完成相同的功能(語義)。但是混淆後的代碼很難被反編譯，即反編譯後得出的代碼是非常難懂、晦澀的，因此反編譯人員很難得出程序的真正語義。從理論上來說，黑客如果有足夠的時間，被混淆的代碼仍然可能被破解，甚至目前有些人正在研製反混淆的工具。但是從實際情況來看，由於混淆技術的多元化發展，混淆理論的成熟，經過混淆的Java代碼還是能夠很好地防止反編譯。下面我們會詳細介紹混淆技術，因為混淆是一種保護Java程序的重要技術。

6. 保障介面安全的5種常見方式

一般有五種方式：
1、Token授權認證，防止未授權用戶獲取數據；
2、時間戳超時機制；
3、URL簽名，防止請求參數被篡改；
4、防重放，防止介面被第二次請求，防採集；
5、採用HTTPS通信協議，防止數據明文傳輸；

所有的安全措施都用上的話有時候難免太過復雜，在實際項目中需要根據自身情況作出取捨，比如可以只使用簽名機制就可以保證信息不會被篡改，或者定向提供服務的時候只用Token機制就可以了，如何取捨，全看項目實際情況和對介面安全性的要求。

HTTP協議是無狀態的，一次請求結束，連接斷開，下次伺服器再收到請求，它就不知道這個請求是哪個用戶發過來的，但是對我們有許可權訪問限制的模塊而言，它是需要有狀態管理的，以便服務端能夠准確的知道HTTP請求是哪個用戶發起的，從而判斷他是否有許可權繼續這個請求。

Token的設計方案是用戶在客戶端使用用戶名和密碼登錄後，伺服器會給客戶端返回一個Token，並將Token以鍵值對的形式存放在緩存（一般是Redis）中，後續客戶端對需要授權模塊的所有操作都要帶上這個Token，伺服器端接收到請求後進行Token驗證，如果Token存在，說明是授權的請求。

Token生成的設計要求：
1、應用內一定要唯一，否則會出現授權混亂，A用戶看到了B用戶的數據；
2、每次生成的Token一定要不一樣，防止被記錄，授權永久有效；
3、一般Token對應的是Redis的key，value存放的是這個用戶相關緩存信息，比如：用戶的id；
4、要設置Token的過期時間，過期後需要客戶端重新登錄，獲取新的Token，如果Token有效期設置較短，會反復需要用戶登錄，體驗比較差，我們一般採用Token過期後，客戶端靜默登錄的方式，當客戶端收到Token過期後，客戶端用本地保存的用戶名和密碼在後台靜默登錄來獲取新的Token，還有一種是單獨出一個刷新Token的介面，但是一定要注意刷新機制和安全問題；

根據上面的設計方案要求，我們很容易得到Token=md5(用戶ID+登錄的時間戳+伺服器端秘鑰)這種方式來獲得Token，因為用戶ID是應用內唯一的，登錄的時間戳保證每次登錄的時候都不一樣，伺服器端秘鑰是配置在伺服器端參與加密的字元串（即：鹽），目的是提高Token加密的破解難度，注意一定不要泄漏；

客戶端每次請求介面都帶上當前時間的時間戳timestamp，服務端接收到timestamp後跟當前時間進行比對，如果時間差大於一定時間（比如：1分鍾），則認為該請求失效。時間戳超時機制是防禦DOS攻擊的有效手段。

寫過支付寶或微信支付對接的同學肯定對URL簽名不陌生，我們只需要將原本發送給server端的明文參數做一下簽名，然後在server端用相同的演算法再做一次簽名，對比兩次簽名就可以確保對應明文的參數有沒有被中間人篡改過。

簽名演算法：
1、首先對通信的參數按key進行字母排序放入數組中（一般請求的介面地址也要參與排序和簽名，那麼需要額外添加url= http://url/getInfo 這個參數）；
2、對排序完的數組鍵值對用&進行連接，形成用於加密的參數字元串；
3、在加密的參數字元串前面或者後面加上私鑰，然後用md5進行加密，得到sign，然後隨著請求介面一起傳給伺服器。

注意： 對於客戶端的私鑰一定要妥善處理好，不能被非法者拿到，如果針對於H5的項目，H5保存私鑰是個問題，目前沒有更好的方法，也是一致困擾我的問題，如果大家有更好的方法可以留言一起探討。

客戶端第一次訪問時，將簽名sign存放到伺服器的Redis中，超時時間設定為跟時間戳的超時時間一致，二者時間一致可以保證無論在timestamp限定時間內還是外 URL都只能訪問一次，如果被非法者截獲，使用同一個URL再次訪問，如果發現緩存伺服器中已經存在了本次簽名，則拒絕服務。如果在緩存中的簽名失效的情況下，有人使用同一個URL再次訪問，則會被時間戳超時機制攔截，這就是為什麼要求sign的超時時間要設定為跟時間戳的超時時間一致。拒絕重復調用機制確保URL被別人截獲了也無法使用（如抓取數據）。

方案流程：
1、客戶端通過用戶名密碼登錄伺服器並獲取Token；
2、客戶端生成時間戳timestamp，並將timestamp作為其中一個參數；
3、客戶端將所有的參數，包括Token和timestamp按照自己的簽名演算法進行排序加密得到簽名sign
4、將token、timestamp和sign作為請求時必須攜帶的參數加在每個請求的URL後邊
5、服務端對token、timestamp和sign進行驗證，只有在token有效、timestamp未超時、緩存伺服器中不存在sign三種情況同時滿足，本次請求才有效；

眾所周知HTTP協議是以明文方式發送內容，不提供任何方式的數據加密，如果攻擊者截取了客戶端和伺服器之間的傳輸報文，就可以直接讀懂其中的信息，因此HTTP協議不適合傳輸一些敏感信息，比如信用卡號、密碼等。
為了解決HTTP協議的這一缺陷，需要使用另一種協議：安全套接字層超文本傳輸協議HTTPS，為了數據傳輸的安全，HTTPS在HTTP的基礎上加入了SSL協議，SSL依靠證書來驗證伺服器的身份，並為客戶端和伺服器之間的通信加密。
HTTPS也不是絕對安全的，如下圖所示為中間人劫持攻擊，中間人可以獲取到客戶端與伺服器之間所有的通信內容。
中間人截取客戶端發送給伺服器的請求，然後偽裝成客戶端與伺服器進行通信；將伺服器返回給客戶端的內容發送給客戶端，偽裝成伺服器與客戶端進行通信。 通過這樣的手段，便可以獲取客戶端和伺服器之間通信的所有內容。 使用中間人攻擊手段，必須要讓客戶端信任中間人的證書，如果客戶端不信任，則這種攻擊手段也無法發揮作用。
針對安全性要求一般的app，可採用通過校驗域名，證書有效性、證書關鍵信息及證書鏈的方式。

以上說的更多是設計階段的思路，如果API已經在運行的話，我們則需要通過其他方式，如API網關工具來保護我們的API，這里推薦的是Eolinker，對於上述的5個方面，都有對應的功能做到保護API，可以自己部署開源版本試用一下： www.eolinker.com