Web Security Notes

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 36 – SOLVE SQL INJECTION 作者：John Melton What is it and why should I care? SQL注入漏洞是因為沒分開處理程式碼和資料而產生。一般而言，開發者善意的設想使用者輸入內容都是資料，但攻擊者自訂輸入內容讓資料庫誤認為命令執行。這裡有些 SQL注入攻擊事件 ，造成財務的、政治的或名譽的損失。若你了解C語言exec函數的問題，你應該認同防護SQL注入的重要性。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 35 – SOLVE SECURITY PROBLEMS ONE AT A TIME 作者：John Melton What is it and why should I care? 本篇文章與技術沒有太大關係，主要是討論解決資安問題的流程。 真實生活中的資安廠商通常跟消防員一樣。一通電話"救命阿，我們的網站被駭了，快幫我們修好！"是一天中最平凡的開場白。我們常常忙於亡羊補牢，而沒有解決問題來源，也沒有減少弱點被人利用的機會。 所以，問題持續存在。 要根本解決Web的安全問題，我們不能等到事情發生才關心。我們必須要提早想到可能的問題，並提出解決方案。 building security in  網站教你從開發階段就該注意的事情， bsimm.com  則收集了許多知名軟體公司對於安全所做的努力。 然而，我們常犯了想要同時解決所有看起來都很嚴重問題的毛病。卻忘了風險優先順序。只有讓所有相關人員來開會，詳細說明安全問題，才能釐清問題順序。 假設以下兩種跟效能( performance )有關的情境。 1. 當你有一個跑得很慢卻又常常被執行的函式。有天你看不下去了，直接改寫成更有效率的版本，並取代舊版本。系統效能立即提升，減少浪費的時間。 2.當你有個跑得很慢的跨應用程式查詢句。你可以升級資料庫的硬體、更換資料庫供應商、增加應用程式的快取空間、最佳化查詢句等等。但是這些調整都牽涉到很多軟硬體的設定，你需要計畫，不能說改就改。 某些資安的問題也是一樣，有些問題可以像1.的情境，直接修改。有些問題(sql injection、xss)則像2.，需要妥善的計畫。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 34 – SEPARATE ADMIN FUNCTIONALITY 作者：John Melton What is it and why should I care? 或許有人會認為將管理者功能從系統中切出來很奇怪。但作者定義的管理者功能是更高的權限(使用者、群組、角色的管理)，因為非法提權(privilege escalation)會對應用程式產生很大的影響。作者對於管理功能的想法是： 擁有可以管理使用者的重要功能 假設被人以不正方式利用，使用者的權限可以增加或被移除 不管任何狀況，作者並不相信可以完美的保護這些功能 你可能不同意作者，尤其是第三點，你也許覺得自己的應用程式超安全。作者的經驗中，大部分應用程式本身都有設計上的漏洞，如果管理者功能被有心人利用，那被公布的系統弱點造成的影響就更大了。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 33 – ACCESS CONTROL (3) 作者：John Melton What is it and why should I care? 前前一篇  已經提過 Access Control 的定義了。 What should I do about it? part1  我們談到以功能性來限制使用者的行為、 part2  我們將資料存取也列入考量。接下來，我們將討論更多普遍適用於限制使用者的因素。根據資料的不同類型我們可以增加某些情境資訊來限制使用者的行為。我將列出幾點常見的情境，由你來繼續列下去，並套用到你的應用程式環境中。 Date / Time 每天的某些時段可當作是否允許存取應用程式的重要條件。例如，你可以限定員工在星期一到星期五的AM 08:00-PM 18:00 才能進入系統。上班時段以外，員工只能有少許的使用權限。另外一種方式是，限制每24小時只有6小時能執行特殊工作，減少資料被竄改的機會。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 32 – ACCESS CONTROL (2) 作者：John Melton What is it and why should I care? 上一篇 已經提過 Access Control 的定義了。 What should I do about it? 前面提到我們可以用功能性來限制使用者的行為。第二種限制使用者行為的做法是，以資料區分─特定使用者只能存取特定資料。舉例：雖然所有登入網路銀行的使用者都能執行查詢餘額的功能，但只能顯示自己的數字。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 31 – ACCESS CONTROL (1) 作者：John Melton What is it and why should I care? 存取控制(Access control)，又稱做使用者授權(Authorization)，是身分鑑別成功之後的下一步驟。存取控制的流程是以使用者身分為基礎決定資源的存取權限。假設使用者身分已經被確認，之後才能決定是否讓使用者存取特定資源。 存取控制是系統中最容易被利用的，通常存取控制的實作都存在一些問題，控制點沒有完全覆蓋應用程式，留下許多漏洞形成資安隱憂。 存取控制的問題可以用不同的存取控制模型 MAC、DAC、RBAC 來解決。然而，Web應用程式有一些特別的地方，接下來我將介紹不同之處在哪。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 30 – AUTHENTICATION 作者：John Melton What is it and why should I care? 請靠近點，以便鑑別您的身分。 鑑別(Authentication)是一個確認你的身分是否為真的過程。通常使用者會以自己的ID和相關證據以證明身分。實際的情況是，使用者用代號和密碼來通過系統的認證。鑑別是應用程式安全中最重要的部分，因為他是使用者所有行為的起點。許多資安解決方案都是基於使用者身分已通過鑑別的前提，也就是假設使用者身分無誤。然而鑑別身分是有難度的，需要花很多心力來做。

A happy robot is doing his job. 繼續上一篇的  介紹文章  後，若是我們想要跟機器人互動該怎麼作？身為一個稱職的MSN機器人，必定要學會互動文字對答，提供特定服務。今天就來試試看如何互動。 怎麼實作？ MSN機器人互動最方便的作法就是文字應答。輸入特定指令後，機器人依據指令進行特定服務(例如：檢查server狀態、檢查聯若人清單、找尋檔案等等)。除了文字應答，另外一個重要的互動功能就是檔案傳輸，依據指令找尋檔案並自動傳輸檔案。 以下為我的應答流程： 1.傳送指令 2.機器人讀取指令 3.回應結果

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 29 – MANAGE RESOURCES 作者：John Melton What is it and why should I care? 用完後記得將工具歸位喔。 資源管理長久以來都是程式設計中一個重要議題，而且跟資安三大目標CIA中的Availability更是息息相關。資源管理好壞影響著你存取時系統是否順利的回傳，故你不會隨意的釋放相關資源(硬碟空間、記憶體、網路連線等等)。 雖然不像是因為使用者帳戶和密碼的加密機制過於簡單(像是 ROT-13 )而被破解一樣受人注目，但是資源洩漏造成的系統當機也頗為尷尬。不良的資源管理機制將導致系統崩潰、不穩定。若你剛好是每天凌晨兩點因為機器崩潰被主管狂 call 的工程師，那你應該懂我的意思。

發生什麼事？ 這些年，收到垃圾郵件、釣魚郵件都見怪不怪，反正hotmail、gmail會幫我過濾那些郵件。但如果是好朋友們的信就無法第一時間過濾掉，因此某些msn的內含惡意聯結的郵件仍持續散佈。 今天我收到的惡意郵件沒有主旨，只有寄件人和收件人，內容只有一行 http://cr.site-sales.biz/blog/不要點喔wp-content/plugins/zaieccpauio/google.html?otv=fgfh.psml&ygu=onnm.hkml&gwyj=tjbm

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 27 – PENETRATION TESTING 作者：John Melton Developer: I'm ready, Sir ! What is it and why should I care? 滲透測試(  Penetration testing  )是藉由模擬的攻擊行為來評估電腦系統或網路安全性的方法。此方法主動的分析系統所有弱點的可能性，並揭露潛在攻擊者。通常又被稱作 pen testing 或ethical hacking。 滲透測試類似於雇用駭客去探測實際運作的系統，且努力找出安全問題。測試結果很有價值也很有說服力，不僅顯示弱點存在，也可以被利用。根據經驗，誠實的測試結果可以成為開發者和資訊安全之間溝通橋梁，並設定可達成的目標促使開發者修正問題。而該如何處理人人都討厭的誤報(False Positive)結果也是很有趣的議題。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 26 – DO CODE REVIEWS 作者：John Melton Holmes: Found any bugs? Waston: You mean ...besides 5000 compiling errors? What is it and why should I care? 原始碼檢查(  Code Review  )源自單純的 Double Check 概念，讓其他人以系統化的方式找出錯誤。雖然步驟簡單，效果卻很好。 研究 指出透過 Code Review 可以找出程式碼中 25-75%的錯誤，若結合其他品管方法，能達到更完美的程式碼。 雖然 Code Review 是開發者用來找出程式碼中所有錯誤，但本系列文章以資安為主，作者只會討論安全性議題。安全性 Code Review 會忽視無關安全性的錯誤。一般性和安全性議題的差別是檢查目的並非檢查方法。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 25 – USE DYNAMIC ANALYSIS 作者：John Melton Opps !! You killed me. What is it and why should I care? 動態分析   就是 分析執行中的程式 。基本上，動態分析會自動執行應用程式，並進行分析。 動態分析當然不只限於應用程式的安全領域，還包括其他領域，但本篇文章將著重於安全領域。目前市面上的產品又稱為 Dynamic Application Security Testing (or DAST)。 動態分析工具怎麼辦到的？Web應用程式安全的領域中，動態分析工具會模擬為使用者的瀏覽器，並送出具有攻擊目的 Request 給應用程式。不論攻擊是否成功，都能依據輸出結果，推論 應用程式 可能的弱點。以下是偵測 XSS 弱點的邏輯： 第一，瀏覽 Web 應用程式中的表單。 第二，填入javescript alert。 第三，送出表單。 第四，如果得到alert，則表單存在 XSS 弱點。 可以從 這個簡單例子， 看出動態分析工具的執行邏輯，而真正的動態分析工具可以做到更多測試。動態分析和靜態分析相反，他能提供攻擊行為真實可行的證據。做 靜態分析時， 開發者會以「其實我們有安全控制措施來防範 X 弱點，^_^」，然後忽視靜態分析報告。但動態分析是針對已經上線的應用程式進行測試，當你發現營運中網站的弱點，其他人很難忽視實際上被攻擊的可能性。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 24 – USE STATIC ANALYSIS 作者：John Melton What is it and why should I care? 靜態分析(Static Analysis)是一種分析，能夠自動化檢查程式碼而不需要實際執行程式。靜態分析工具很多，可以達到的複雜度也不同 。作者大致介紹兩種類： Grep+ 和 資料流/控制流分析。 Grep+ Grep 是很棒的內文搜尋工具，但無法成為正式的靜態分析工具。以前人們認為總有一天可以用 Grep 發展出實用的靜態分析工具，但受限於只能搜尋符合某些特徵的程式碼，Grep 終究無法成為稱職工具 。Grep 能用在許多地方，但今日的靜態分析工具已經超越單純的內文搜尋工具。 資料流 / 控制流分析 Data/Control Flow Analysis 進階版的靜態分析工具所使用的技巧就是  資料流分析  和 控制流分析 。這種概念是從編譯器理論( Dragon book  )而來的，尤其是最佳化技術。雖然這不是新的概念，大家仍花了很多心力才 應用到靜態分析 。 一般而言，這些工具會建立應用程式的資料結構模型(又稱抽象語法樹 Abstract Syntax Tree)，然後以不同方法遍歷抽象語法樹( AST )的結構，找出問題。 其實開發者最熟悉的 IDE 工具已經再利用上述的概念，當你寫程式時， IDE 會建立靜態的抽象語法樹，並即時顯示 警告和 錯誤。某些 IDE 工具甚至會從程式外部，檢查 AST 的安全性。 註：雖然靜態分析並不只是針對安全領域，但身為資安專家的作者自然是以安全為主。作者提醒大家，不只資安，靜態分析也可以解決其他問題。而目前資安市場中相關的產品又稱為 Static Application Security Test。

無法查看此摘要。請 按這裡查看文章。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 22 – HTTP PARAMETER POLLUTION 作者：John Melton What is it and why should I care? HTTP 參數汙染是一種自訂字串語句然後複寫 HTTP GET/POST 參數的注入技術。2009年的一篇 文章  提出這個名詞後，逐漸普及。只要你能發揮創意填補HTTP的參數，多次送出相同的參數，就有機會造成WEB應用程式出乎意料的反應。如果有人利用這個request /mypage.jsp?query=abc&acct=4 改成這樣，會發生什麼事呢？ /mypage.jsp?query=abc&acct=5&acct=4 當你呼叫 request.getParameter("acct") 會得到什麼值？不同的 server 會有不同的反應，還好，這裡有一份 PPT 可以讓你參考各家 server 的反應。JAVA 的朋友們，你通常會得到相同參數的第一個值─也就是  request.getParameter("acct") = "5"。 所以勒？有這麼嚴重嗎？是的，這個弱點會產生複寫參數、修改行為、存取變數、繞過輸入驗證等等的漏洞。 作者認為這和HTTP 路徑參數問題(Http Path Parameter Issue)  很像，共同點是你可以自訂授權檢查的 URL 後面的參數，然後 request 到不一樣的值。上面的例子進行授權檢查時，"acct" 變數可能得到 "4" ，然後使用者將被認定是 acct=4 的身分。然而，實際上你的資料庫收到的  request.getParameter("acct") 卻是帳號 "5" ，所以使用者 "4" 就可以繞過授權檢查存取使用者 "5" 的資料。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 21 – ANTI-CACHING HEADERS 作者：John Melton What is it and why should I care? It's under the mat, I knew it. 快取( Caching )是一種技巧，將伺服器上遠地的資料儲存一份副本在本地端，減少重複下載的動作，增加使用效能。只考慮效能的話，快取真是太棒。從資安的角度來看，可能成為很嚴重的問題。 假設現在螢幕上顯示你的個人銀行帳戶或醫療紀錄，下個使用者甚至不需要登入就可以看到剛剛的資料。 幸運的是，我們可以藉由指令啟用或關閉快取。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 20 – TRUST NOTHING 作者：John Melton Don't worry ^_^ What is it and why should I care? 信任感是很有趣的議題，我們潛意識中相信人性本善，開發者也是。看看以下這個例子： //bad bad do not use executeDbQuery("select * from my_table where id = " + request.getParameter("my_id")); //bad bad do not use 開發者相信使用者不會竄改 my_id 所以放心的直接帶入 executeDbQuery()。這太天真了，正確作法應該是用 my_id 參數傳入到 Prepare Statement 以防止 SQL Injection 同時檢查 my_id 的內容是否正確。 為何要如此大費周章？因為我們不能隨便相信輸入值，不能相信使用者會依照我們的期望使用系統。我們必須建造好用的、能承受攻擊的、強壯且吃苦耐勞的系統。無論你的系統是甚麼類型，作者建議不要信任( Trust )系統會接觸到的環境。 「不能信任系統環境」到底代表什麼意涵？是為了避免 XSS 和 SQL injection 嗎？是，但更深一層的意涵是以不同的方式了解應用程式。應用程式其實是規模不同的輸入-處理-輸出的過程，輸入值可能是 request parameters、headers、database input 等等，處理包括身分驗證、邏輯，輸出到資料庫、螢幕、檔案等等。整個應用程式可以當成所有系統元件的輸入值、處理、輸出的結合，並縮放規模到適合的系統和組織。 所謂的「環境」因人而異，「你不能相信任何人」也是因地制宜。作者的建議是我們應分辨可以相信的和不能相信的，不能相信的資料應視之為已經被汙染的資料。 威脅模擬( Threat Modeling )中包含許多此類議題，日後的文章作者會介紹。

來源：John Melton's Weblog 標題： YEAR OF SECURITY FOR JAVA – WEEK 19 – REDUCE THE ATTACK SURFACE 作者：John Melton Police: Suspect is not going to get through. What is it and why should I care ? 減少應用程式的攻擊進入點(  attack surface   )代表減少與應用程式互動的方式，且可能減少應用程式的功能性。 對於一秒幾十萬上下的老闆們可真是個壞消息。然而我們只是要回歸系統的初衷─簡單化。其實簡單化對於企業是件好事。你很少看到有人因為某個產品超難用，反而感到心情愉悅。最方便的設計就是簡單好用，最安全的設計也是。 那該如何簡化？作者最愛的例子是 Google  標準搜尋框  和  進階搜尋頁面 ，大約99.99%的人不會用的進階搜尋功能被設計在安分的角落。假設Google移除進階功能，可以相對的簡化"搜尋"功能，可以簡化應用程式的腳印、節省記憶體、達到更好的顧客經驗。 許多開發人員都想做些很酷很炫的功能，結果程式碼發展的比計畫中還要肥大，也干擾使用者的心情。請無情地移除不必要的功能、優雅的簡化，就能改善使用者經驗和提升安全性，還可以省錢和省時間。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 18 – PERFORM APPLICATION LAYER INTRUSION DETECTION 作者：John Melton I'm watching you...( ´థ_థ）σ What is it and why should I care? 作者認為應用程式的保護機制中，  應用層的入侵偵測機制  是非常有效的。目前為止的主題都是關於軟體生命週期的開發階段，但這篇文章卻橫越整個應用程式範圍，從需求到規劃，最終上線階段。 基本概念是擬定計畫、實作並監控"不好的事件"。這種系統的特性是尋找意料外的事件並持續追蹤。經過一段時間後，再判斷是否應將那些事件列為攻擊事件。 很多開發者都已經下了功夫去偵測事件，看看以下的範例pseudo-code： if (使用者有權存取資料) {     get 資料     redirect 檢視(或編輯)的頁面 } else {     log 例外狀況     send 錯誤訊息給使用者 } 作者看過太多上述的例子。其中有個問題是管理例外狀況。通常，人們寧願盯著螢幕發呆或打掃環境也不願意檢查 logs，所以當攻擊者進攻你的應用程式，唯一看到錯誤訊息的只有他。只要增加通知功能、送出訊息到入侵偵測引擎，你就可以追蹤事件並了解應用程式的實際使用狀況。偵測到入侵事件後，你就能夠把入侵者吊起來打...我的意思是以合法的方式回應入侵行為。一般來說，你可以增加紀錄的頻率、操作使用者帳戶、或禁止存取某些功能。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 17 – SET A HARD SESSION TIMEOUT 作者：John Melton 內文： Bank website: Warning ! Push F5 before expired. What is it and why should I care? 對於應用程式來說，Session 逾時機制是很重要的安全控制措施。這機制主要是在使用者登入一段時間後，強制使用者重新進行身分鑑別。逾時機制分為兩種：軟性和硬性。 硬性 Session 機制限制使用者登入一段時間後，必定要重新登入。以下是個範例，假設我們有個應用程式是： 需要經過身分鑑別才能使用應用程式 嘗試瀏覽應用程式時會轉向到登入頁面 使用者登入後，無論動作中或停止，只要超過 9 小時就必須登出，因此你的硬性 Session 逾時機制上限為 9 小時。 最終效果是，當使用者回到桌面重新點選應用程式後，將會被轉向到登入頁面。 上一段主要是講解硬性機制如何使用，但是硬性機制能避免甚麼弱點？雖然軟性機制能避免 CSRF 和類似的攻擊，硬性逾時機制則是避免攻擊者能永久持有受害者的帳戶，因為他們勢必要重新鑑別身分。為了避免這樣的事情發生，當使用者修改密碼時也應該要重新鑑別身分。

來源： John Melton's Weblog 標題：YEAR OF SECURITY FOR JAVA – WEEK 16 – SET A SOFT SESSION TIMEOUT 作者：John Melton 內文： What is it and why should I care? 對於任何應用程式 ，Session 的定期逾時都是重要的安全控制機制。此機制定義一段時間內使用者都能以登入的身分使用應用程式，直到時間截止則需要重新進行身分鑑別(再次登入)。逾時機制分為兩種：軟性逾時和硬性逾時。今日作者將為你介紹軟性逾時。下周會介紹硬性逾時。 軟性逾時應用在，當使用者停止互動、閒置超過一段時間。 以下舉例，假設我們的應用程式是： 需要經過身分鑑別才能使用應用程式 嘗試瀏覽應用程式時會轉向到登入頁面 使用者登入後，突然有事離開20分鐘，而你只有15分鐘的逾時 綜合以上，當使用者回到桌面重新點選應用程式後，將會被轉向到登入頁面。 這樣的情境表達了軟性逾時如何運作，但究竟這樣的機制是在保護什麼？有關的問題很多，包括身分鑑別、授權、稽核、Session Hijacking，但最主要還是針對 CSRF 。一段合理的時間後的自動登出相當程度的降低 CSRF 類別的攻擊。更精確的說，任何想要利用使用者已登入的合法性進行攻擊，利用這樣簡單的機制都能有效的阻止，至少能提高複雜度。

Level 3 & 4 詳細的的驗證要求有哪些? ASVS 驗證要求細項共分為14大項。 V1. 建立安全架構的文件(Security Architecture) 為了滿足基礎安全，你應該了解應用程式架構並制定相關文件。如此檢測分析的結果才能對應到高階安全架構。Level 3 應滿足 ，Level 4 應滿足 ：    V1.1 能正確識別應用程式中所有的原始檔、函式庫、執行檔。    V1.2 能正確辨識不屬於應用程式內但被引用的元件。    V1.3 針對應用程式的高階架構建立文件。例如:  MVC 、 UML 、 企業流程 等。    V1.4 不屬於應用程式內但被引用的元件，應對應到企業功能或安全功能。    V1.5 提供威脅模擬資訊( Threat Modeling )。 V2. 身分鑑別(Authentication) 本項目將要求你安全的建立和控管使用者的認證資訊。Level 3 應滿足 ，Level 4 應滿足 ：    V2.1 除了公開資源以外，所有頁面和資源都須經過身分鑑別，才能存取。    V2.2 所有密碼不能以任何方式顯示在網頁上。    V2.3 當身分鑑別的失敗次數過多，應用程式需自動將該帳號鎖定，而鎖定時間至少要能抵抗暴力破解法(Brute Force Attack)。    V2.4 所有的身分鑑別控制措施都實作在 Server 端。    V2.5 身分鑑別的控制措施即使失效，也應安全的失效(  Fail Securely  )。    V2.6 身分鑑別的使用者憑證( Credential、Password )應具有一定強度，能抵抗開發環境的一般攻擊。    V2.7 使用者帳戶的管理功能應具有身分鑑別相同的安全強度，抵抗相同攻擊。    V2.8 使用者修改憑證的功能應具有身分鑑別相同的安全強度，抵抗相同攻擊。    V2.9 執行特別敏感的操作之前...