Good Day, Commander!

SSRF: Server Side Request Forgery 服務端請求偽造。 攻擊者構造形成看似由服務器發起請求的一個安全漏洞。基本上，SSRF的目標是外網無法Access的內部系統。 SSRF如何產生? SSRF形成原因大多是server side從其他server應用獲取data時沒有對於目標位址做過濾跟限制。 比如說從指定的URL獲取了response，像是內容、圖片、下載等等。 當一個可以接受URL的API沒有對URL進行過濾時，那麼駭客可以利用URL的response去探測內網。 SSRF的出現情境 1. 社交分享功能: 獲取超連結的標題與內容並進行顯示。 2. 轉碼服務: 通過URL地址把原地址的網頁內容調優使它適合手機閱覽(內容重新矲版整理) 3. 網頁翻譯: 將網址的網頁內容做文字翻譯 4. 圖片加載/下載: 通過URL在網頁的文本編輯器裡面顯示圖片或下載圖片 5. 圖片/文章收藏功能: 和1的情境差不多 6. 雲端服務: 雲端server可以由遠端執行命令來判斷網站是否存活，如果可以捕獲相應的訊息，就可以進行SSRF 7. 網站採集: 有些網站會對你輸入的URL進行一些訊息採集的工作 8. Database的內置功能: database中像是copy database的function 9. Mail System: 比如接收郵件服務器的位址 10 從遠端伺服器請求資源 SSRF的應對之道 1. 過濾response訊息:如果API要獲取某一種類型的訊息，再獲取response時需要先去過濾它是否符合標準。 2. 統一錯誤訊息 3. 設置URL白名單或是gethostbyname()判斷是否為內網IP 4. 限制請求的端口(Port)，如限制為80, 443, 8080, 8090 5. 禁止跳轉 6. 進用不需要的協議(僅允許http和https請求)

XSS, Cross-site scripting. 在於未充分檢查使用者輸入的訊息，導致使用者有機會去使用scripting language在server執行程式碼，程式撰寫者必須去檢查使用者的資料格式來避免這個問題。 XSS通常會發生在 1. 使用者的http request未檢查 2. 在web application動態產生網頁時，可能會包含未被檢查的內容 3. 在產生網頁時，並沒有方式讓網頁內容不去執行scripting 4. user在瀏覽 gen出來的網頁時成了內含惡意script的犧牲者 Type 1: Reflected XSS (or Non-Persistent) 就是在http request裡面加入惡意的執行指令，然後在web server回應到使用者的browser執行。 Type 2: Stored XSS (or Persistent) 如果Web Server意外把含有惡意的執行指令碼存在server的storage中，然後在使用者使用服務時，藉機在執行指令以獲得一些敏感的隱私資料。 Type 0: DOM-Based XSS DOM-Based XSS 就是指網頁上的 JavaScript 在執行過程中，沒有詳細檢查資料使得操作 DOM 的過程代入了惡意指令。 應對之道:  1. 檢查任何使用者或是Web application所承接近來的input，並檢查裡面有沒有埋藏指令碼。 2. 記得輸出到使用者的response需要經過OWASP的Encoder處理，來避免裡面有駭客埋藏的指令碼。 針對Java的處理Encoder, OWASP的資源提供如下 http://owasp.github.io/owasp-java-encoder/encoder/index.html

物件序列化 簡單來說就是將 物件 變成資料流，可以將物件儲存成 檔案 ，可以永久儲存在硬碟中，而且可以在2台電腦之間傳遞物件，是非常實用的功能。 物件反序列化 就是將 檔案 還原成 物件 ，並拿來使用。 重點  : 要被虛列化的物件必須加入Serializable介面，如果該類別也使用到其他類別的物件，那麼其他類別也必須使用Serializable介面，否則執行時期會發生錯誤。 Source:  http://lolikitty.pixnet.net/blog/post/36759934-java-%E5%BA%8F%E5%88%97%E5%8C%96-%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96-%28serialization-deserialization%29