如上圖所示代碼，在進行外部url調用的時候，引入了SSRF檢測：ssrfChecker.checkUrlWithoutConnection(url)機制。
SSRF安全威脅：
很多web應用都提供了從其他的服務器上獲取數據的功能。使用用戶指定的URL，web應用可以獲取圖片，下載文件，讀取文件內容等。這個功能如果被惡意使用，可以利用存在缺陷的web應用作為代理攻擊遠程和本地的服務器。當攻擊者提供的是一個企業私網IP時，服務器可能會訪問對應網址后，把結果返回，這種形式的攻擊稱為服務端請求偽造攻擊（Server-side Request Forgery）。
如果應用程序對用戶提供的URL和遠端服務器返回的信息沒有進行合適的驗證和過濾，就可能存在這種服務端請求偽造的缺陷。Google,Facebook,Adobe,baidu,tencent等知名公司都被發現過這種漏洞。攻擊者利用ssrf可以實現的攻擊主要為繞過網絡限制攻擊企業內網：
- 信息收集：可以對外網、服務器所在內網、本地進行端口掃描，獲取一些服務的banner信息;
- 信息收集：對內網web應用進行指紋識別，通過訪問默認文件實現;
- 執行指令：攻擊內外網的web應用，主要是使用get參數就可以實現的攻擊（比如struts2，sqli等）;
- 執行指令（溢出）：攻擊運行在內網或本地的應用程序（比如溢出）;
- 信息收集：利用file協議讀取本地文件等。
以下業務場景容易出現這種漏洞：
1、應用從用戶指定的url獲取圖片。然后把它用一個隨即文件名保存在硬盤上，並展示給用戶；
2、應用獲取用戶制定url的數據（文件或者html）。這個函數會使用socket跟服務器建立tcp連接，傳輸原始數據；
3、應用根據用戶提供的URL，抓取用戶的web站點，並且自動生成移動wap站；
4、應用提供測速功能，能夠根據用戶提供的URL，訪問目標站點，以獲取其在對應經緯度的訪問速度；
如上圖代碼，黑客可以通過如下方式：
http://xxx.alibaba-inc.com/ajax/Hservice.do?url=http://172.24.191.64:3333/aaa.htm&_mf_req={"xx":"xx"}&charset=utf8&_mf_callback=2222
針對上述問題，解決方案如下：
(1)判斷業務需求是否只需要對幾個特定的域名作請求。如果是，將這幾個特定的域名加入到白名單，拒絕白名單域名之外的請求。
(2)判斷業務方請求來源是否為固定的幾個IP或域名。如果是，將這幾個特定的IP/域名加入到白名單，拒絕白名單域名之外的請求。
(3)如果業務需求向任意URL發送請求，需要請求前通過安全包提供的函數來判斷，如果業務需要跟隨302跳轉，每次請求時都需要經過安全包函數判斷。
(4)如果在情況3的前提下，不能使用安全包需要讓開發自己實現SSRF修復邏輯。
(5)其他情況拉安全工程師一起判斷。
附：
1.解決jar包沖突：引入jar包的過程中，出現了jar包沖突，導致編譯正常，運行時找不到類而拋錯誤。通過查看jar包依賴，使用exclusion來排除jar包。通過mvn dependency:tree或者open with Maven POM Editor.jar包仲裁機制。
2.NoClassDefFoundError和ClassNotFoundException的區別。NoClassDefFoundError錯誤的發生，是因為Java虛擬機在編譯時能找到合適的類，而在運行時不能找到合適的類導致的錯誤。與ClassNotFoundException的不同在於，這個錯誤發生只在運行時需要加載對應的類不成功，而不是編譯時發生。
NoClassDefFoundError發生在JVM在動態運行時，根據你提供的類名，在classpath中找到對應的類進行加載，但當它找不到這個類時，就發生了java.lang.NoClassDefFoundError的錯誤，而ClassNotFoundException是在編譯的時候在classpath中找不到對應的類而發生的錯誤。ClassNotFoundException比NoClassDefFoundError容易解決，是因為在編譯時我們就知道錯誤發生，並且完全是由於環境的問題導致。而如果你在J2EE的環境下工作，並且得到NoClassDefFoundError的異常，而且對應的錯誤的類是確實存在的，這說明這個類對於類加載器來說，可能是不可見的。
參考地址：
1.http://www.freebuf.com/articles/web/20407.html
2.阿里jar包倉庫：http://mvnrepo.alibaba-inc.com/nexus/