三大問題
Moore先生在最近召開的CanSecWest會議上介紹了他的發現（你可以在digitaloffensecom上看到他的文章）在介紹完他在ASPNET平台上發現的三個安全問題後Moore示范了如何利用它們來攻擊系統其中的某些攻擊手段特別是利用cookieless會話（session）會讓你覺得簡單的不可思議
Cookieless會話漏洞
cookieless會話利用了ASPNET中cookieless會話管理模式的一個漏洞它包括了任何URL中的會話標識（id）尤其是當新會話的id交給服務器時新會話就創建了而不是服務器負責創建這些會話這個漏洞使得攻擊者可以竊取會話並裝扮成一個合法用戶自由訪問程序
按照Moore的說法攻擊過程大致如下提交一個有效但是偽造的會話id這個過程實現起來並不困難因為會話id並沒有加密處理
把上述的會話id嵌入到一個URL中並通過電子郵件或者其它手段發送到用戶手中
當用戶點擊這個URL並進入URL對應的頁時會話id仍保持有效這時攻擊者就有了被欺騙的用戶的所用系統訪問的權限
不良配置控制帶來的信息洩漏Moore還發現一個潛在攻擊者可以用來檢查有問題的應用程序的結構甚至在某些情況下程序實際代碼的方法這個問題部分出於應用程序的開發者不良配置控制部分歸咎於錯誤的技術資料
ASPNET可以在應用程序出錯時可以向用戶顯示出自定義錯誤信息當調試應用程序時常常關閉這個特性這就造成服務器向客戶返回堆棧軌跡（stack trace）以及調試信息（不僅僅是常見的發生一個錯誤消息）如果自定義錯誤信息未被使能調試信息仍會保留在正式發布的應用程序中（這是Visual StudioNET默認設置）文家名和路徑以及源代碼環境中的任何錯誤都會返回給用戶
Moore說這些信息嵌入在錯誤頁的HTML內容中所以你只有查看頁面的源代碼才可以看到它但是這造成了一個潛在的危險問題這些信息可能會給攻擊者偵察你的應用程序幫了大忙這些信息還可能幫助你的競爭對手對你的程序進行反向工程（破解）
如果上面說得這些對你來說還不夠的話那麼讓我們看看ISAPI文件擴展名過濾器的情況吧它用來保護特定類型的文件不被任意下載和浏覽不過它不會自動保護txtcsv和xml格式的文件不被身份通過驗證的用戶訪問如果你沒有看出這裡出現的問題請參考微軟操作規程建議中關於用xml文件來進行用戶身份鑒定的部分假定你把usersxml文件放到根目錄下這樣任何一個有合法身份的用戶都可以下載並查看該文件這樣他/她就會得到該應用程序所有用戶的口令了
Moore說新版的微軟操作規程建議建議把該文件保存到一個受保護的目錄下這樣這個門就關閉起來了但是工程中剩余的文件（例如擴展名為sln和slo的文件）和其它可能引發問題的東西仍可能被訪問到他建議在應用程序發布之前刪除這些文件並建議開發者不要在根目錄上存放任何文件以防被他人看到
一個傳統的缺陷
Moore還發現aspnet_state會話句柄類容易受到溢出性攻擊而攻擊者可以通過溢出性攻擊來執行任意的代碼這種缺陷是很普遍的在普通應用程序中發現幾十個也不希奇所以從表面上看來Moore在ASPNET中發現這個問題並沒有什麼好吃驚的那到底是什麼使得他感到吃驚（其實他感到的是極其的吃驚）呢？這就是NET管理運行時的環境因此它應該排除在應用程序中出現未受保護的內存的可能性並確保這種攻擊無效
安全問題＝別人的事情？ Moore說開發者被微軟公司發布的不准確信息所蒙蔽並對此一無所知各種各樣的技術文章的作者也應當為這些安全問題的出現受到一定的指責他說例如他發現許多書籍雜志和微軟公司的文章都沒有深入討論如何驗證用戶輸入的有效性而這個方法正可以防止上面提到的溢出性缺陷的出現
我們很容易傾向定性為上述事件是微軟公司掩飾安全問題或者認為微軟過於匆忙的將一個不安全的產品推向市場然而我認為開發者應該堅定這個信念安全問題並不是別人的事情我們傾向於把安全的責任推給網絡工程師或者開發工具提供商卻單單忘了自己我們還養成了依靠二手資料的壞習慣二手資料常常不准確在獲取技術信息上遠遠不如我們自己挖掘第一手材料例如文檔不相信我？那麼出版印刷技術書籍是怎麼成為一個價值數以百萬美元的產業？
當然在如此弱智的利用usersxml文件進行攻擊的方法微軟技術文檔中沒有提到這就體現了自學和常識的重要性了這裡的教訓就是任何技術都不是絕對安全的我們也不應該這麼指望——即使它貼著Microsoft的標簽
From:http://tw.wingwit.com/Article/program/net/201311/15581.html
