騰訊公司招聘cc程序員筆試題-資料下載頁

　　

【正文】 作。雖然每個月都講相同的內容想起來就覺得是一件很乏味的事情，但每次的聽眾都不同，而你也可以在講的過程中不斷地進步，比如說，深化內容，講得更有趣更生動。照組內另一位同事所說，要達到這樣的一種境界：一份只有寥寥數字的提綱的PPT，能講到可長即長，可短即短，隨手拈來，那才是水平。 參考：　　在第一篇文章里，芒果說到應用安全的兩大塊內容：客戶端的安全和Web服務的安全。就技術方面，從本質上來說，我們當下所做的事情，其實是一種特殊形式的軟件測試而已。也許大家還記得軟件工程書上說的什么白盒啊黑盒啊，什么測試用例啊，這些概念也能在安全測試中用到。相對于一般的功能測試與性能測試，安全測試有一個專門的稱謂：滲透測試，聽起來就像我們正在一個看不見的戰場上向敵方陣地滲透進去一樣，無形中就增添了一份神秘感。 　　不過說到底，滲透測試還是某種形式的測試而已。一般的測試是看軟件或系統是否實現了既定的功能，它運行起來是否與預期的一致，它跑得夠不夠快。在具體做的時候，一般都有專業的軟件來做這些事情：輸入一些數據，看輸出來是否是正常行為所預期的數據。滲透測試呢，卻是看你的軟件或系統在完成正常的功能之外，還能不能做一些理應不被允許的事情。具體做的時候，也是輸入一些數據，但看輸出來是否是異常行為所預期的數據。 　　舉個例子來說，的自定義表情包功能，普通的測試會準備一堆這些表情包，打開自定義表情的菜單，調出一個對話框，然后選擇一個表情包，按下導入按鈕，再在聊天窗口中使用剛才導入的表情包中的一個表情。在這個過程中，測試員只需驗證表情包是否導入成功、導入進去的表情包內容與源包是否一致，最后能否在聊天中正常使用。而滲透測試呢，基本上也是這樣的過程，但是關注點有些差異。在這個例子里，我們關心這個操作的發起權是否完全掌握在正常用戶手里（例如：是否可以通過網頁調用的方式發起這個操作，就像彈出一個“與我交談”的臨時對話框一樣）；在與操作系統交互時，是否能夠逾越既定的限制（比如說，釋放這個表情包的時候，它能不能夠跳出用戶所指定的保存目錄）；在解析非正常的數據文件時，程序會不會崩潰；諸如此類。測試的時候呢，也是有一定的方法依循的，比如說路徑操作，一般就是在路徑名中加入..\(或者是../)；文件解析呢，就是拿一些非正常的文件讓它去讀取在這里，非正常的意思是很直觀的，就是除了正常格式以外的所有文件，比如說新建一個txt，在里面胡亂輸入一段文字，就形成了一個“非正常的”表情包文件。 　　一般來說，軟件或者應用的正常行為都是一個很小的集合，我們通過有限的用例就能夠遍歷所有的可能性從而驗證它是否實現了預期的功能。這樣很容易就能想到，軟件的非正常行為則可能是一個巨大的充滿了未知數的集合，要進行測試則是非常困難的：首先，我們要測試和驗證什么，這是不甚明確的；其次，即使是驗證一個可能的問題，需要的測試用例可能是數量巨大的。想一下表情包的例子：一個測試員要證明它能正常解析，他只需準備數百個不同大小不同內容的正常表情包，全部跑一遍，如果每一個都正確導入了，他就可以聲明這個功能是正常的，它通過了測試。 相反，一個安全測試員如果要想驗證，在非正常的文件格式下，這個程序會崩潰，那么他就得準備幾乎是天文數字的表情包，用一臺專門的機器連續跑上幾天幾夜（是的，我們客戶端測試小組就是這樣做的），看它會不會死掉。想想看，即使只用4個字節，就能構造出43億個不同內容的文件，要想找出那些會使程序死掉的文件格式，無異于海里尋針。一般在實際操作的時候，也只是選取一些特定的排列格式（比如說全0或者全是0xff或者0與0xff相間）。 　　這樣的測試我們有時候也叫做Fuzz。文件格式的Fuzz只是一個方面，網絡協議的Fuzz是另一個方面，簡單地說就是動態改變一個數據包的內容，看接收方的程序會不會死掉或者崩潰。可以想象，這并不比文件格式Fuzz好做多少。在業界，關于Fuzz已經有不少參考資料，也有各種各樣的Fuzz工具，我們的工作，也就是參考這些已有的資料，以及各樣的工具平臺，然后自己摸索來發現問題的，負責這一塊的，也都是007年畢業的學生。由此可見，做安全研究，其實也沒有太大的門檻的。只不過在學校里太閉塞，又沒有好的指引，所以覺得渺茫而已。大家有興趣的，可以下載這些工具來試著玩玩找個流行的IM工具（不獨是，MSN啊，Yahoo通啊），沒事的時候就讓Fuzz工具來跑跑，興許能發現一兩個0day（所謂的0day就是外界沒有公開的漏洞），然后用來做一些有趣的事情，比如說，給一個看著不爽的家伙發一個消息，他的IM就立馬崩潰…… 參考：　　嗯，趁著興頭再寫一篇吧，反正明天是放假，一年里有兩三個晚上睡得晚一點也不算太過份~~ 　　上一篇講到在客戶端安全方面，我們可以做些什么事情，又是怎么做的。這一篇就講一下另一塊，在web安全這方面，我們在做的，又是什么樣的事情，使用的是什么樣的技術。　　讓我先把時間回退到大學時代：那時候聽到很多故事，什么中美黑客大戰啦，大陸與臺灣的黑客大戰啦，白宮的官方網站被黑啦，誰家的小孩因為入侵什么重要的系統被抓啦，諸如此類的非常多，那時覺得很神奇，也對信息安全這個專業充滿幻想，以為學到最后，我們也能如傳說中的黑客那樣，在網絡上自由自在地游弋。不過幻想始終是幻想，直到畢業了我也不知道在實際中我怎樣才能“黑”掉一臺服務器。雖然幻想沒有實現，不過我也知道不要把傳說太當真。不過在大三的時候，發生了一件讓我難以接受的事情：同班同學告訴我，我們學院網站的數據庫被別的學校的一個學生用什么方法下載了！這個消息讓我非常沮喪：一是我們計算機學院的網站（很多人都會有一種看法，即某個機構的網站在一定程度上代表這個機構的計算水平）竟然這樣不堪一擊；二是我們一直引以為傲的信息安全，所教導的學生，卻無法做到一件一個不太入流的大學里的一個普通學生所能做到的事情，這很讓我對自己所受的教育產生懷疑。 　　直到參加工作一段時間之后，當初的懷疑與沮喪才消除：從根本上來說，怎樣攻占站點其實只是一種實際的技術而已，這種技術和學習某一門編程語言一樣，是可以通過自學與實踐很快就掌握的，會與不會只是一個誰先學誰后學的問題。但更重要的，卻是解決問題的思維方式與方法論，而這則會決定一個人以后能在多大的天地做出貢獻。 　　有點羅嗦了，呵呵。把主題集中回web安全這里：web安全往具體里說也包括很多，滲透測試是其中很重要的一個方面。我在騰訊一年半的時間里，做的都是這個事情。從本質上來說，web滲透測試就是一種黑盒測試，但比起客戶端軟件來說，做起來就容易很多。這是由web應用的特點所決定的：傳統上，每一個web程序都是一個功能單一、體積小巧的獨立程序，輸入有限，輸出有限，能訪問的資源也有限。這樣無論是普通的功能與性能測試，還是安全滲透測試，都比較容易進行。 　　總的來說，web滲透測試就是給目標程序提交各種“變態”的參數，看這個程序能不能訪問到正常情況下不允許訪問的數據、文件，是否輸出了一些不太安全的內容到返回頁面上。所需的全部家當呢，就是一個瀏覽器了，可能還得加上一個可以查看HTTP請求的工具。 　　比如說，我們查看山水的一篇帖子，是在瀏覽器地址欄里面輸入這樣形式的地址來進行的： 　　　　在這里，id就是這個程序的輸入參數，2525就是一個具體的輸入數據實例。我們可以猜測，這個web程序以這個id為索引，去后臺數據庫里查找一條匹配的記錄，然后把內容復制到一個網頁框架里，再返回來給我們的瀏覽器；也有可能，論壇的帖子是以文件形式存放的，這個web程序用這個id形成一個具體的文件名，然后 　　首先，這個程序是一個黑盒子，我是不知道它里面的具體實現的。但是我可以通過一些固定的模式來測試去得到足夠的信息來猜測它是怎么做的。這樣的模式是通用而且非常簡單的：我在看到“?id=2525”這樣形式的鏈接地址時，就會習慣地在參數后面多加一個引號（或者是雙引號），再按下回車讓瀏覽器發送這樣的一個請求： 　　39。 　　為什么是單雙引號呢？因為這個符號可以構成一個很奇妙的測試用例：（1）原本是一串數字的2525，現在因為末尾的引號而變成了一個不合法的數字，程序怎樣處理一個原本期望是數字串但實際卻含有非數字字符的輸入呢？（2）對于使用數據來做存儲的應用來說，它極有可能利用輸入參數來構造一個SQL語句傳給后臺數據庫，才能最終完成的請求，我們可以猜想這個語句具有這樣的形式： select * from article where aid=2525 。而我們額外添加的引號有可能原封不動地添加到這個SQL語句的末尾而這如果傳到DB中去的話，勢必會引起一個語法錯誤，這時的web程序，又是怎么應對呢？（3）如果使用文件來做存儲，它可能會把id=2525映射成一個實際的路徑：/data/bbs/，類似這樣的形式，那么多余的一個引號如果也原樣傳進來，最后構成的一個路徑十有八九是不存在的文件路徑，讀取文件失敗，程序又會怎樣響應呢？ 　　在考慮不周的程序中，非正常的輸入會導致程序運行失敗（通常返回一個“內部服務器錯誤”的頁面），有些程序員會把錯誤信息打印出來，比如說類型不對啊，SQL語句非法啊，讀取什么文件失敗啊在這一步，程序已經開口告訴我們很多信息了。在網上有非常多的站點都存在這樣的問題的，不信你可以試試（只需簡單地在地址欄的參數后面加一個引號）。 　　也有可能程序對錯誤進行了處理，在操作失敗的時候輸出一個提示信息（比如說，對不起，系統繁忙之類的），從而掩蓋了底層的出錯信息。但是如果程序沒有對輸入進行過濾的話，我們還是有辦法知道的：因為一個失敗的操作所得到的結果和一個成功的操作所得到的結果是不一樣的，這種不一樣必然又會反映到最終返回的頁面上。我們要做的，就是用其它的的例子繼續測試，直到我們能夠確認它有問題或者沒有問題為止，而這些用例的數量是很有限的，可以在數分鐘內就能測試完畢。 　　比如說，對于文件類型的存儲，要確認是否有問題的話，就在參數后面有序地添加../序列（我們知道這會返回到上一層的目錄），并指向一個可能的文件（比如windows的c:/，linux的/etc/passwd），一直到5~6層（再高也不太可能了），如果有漏洞的話，它就會在某一層成功，打開你所指定的文件，并把這個文件的內容讀取出來返回到你的瀏覽器上。這就是文件型漏洞的測試方法。而對于SQL型呢，你就在腦海中想著一個正常的SQL語句，后面跟著你輸入的參數，你怎樣在這個SQL語句中“插入”其它的語句來控制它呢？用“ and 1=1 ”和“ and 1=2 ”來對比一下如何？熟悉SQL的同學會明白，and 1=1是一個為真的條件，附加在原SQL語句后對查詢結果無影響，但and 1=2是一個為假的條件，附在原SQL語句后卻會使得整個查詢返回一個空集。DB有沒有數據給web程序，是可以在瀏覽器上一目了然地看到的，所以我們就能知道我們能否通過URL參數來控制后臺DB。這種漏洞就是SQL注入漏洞，網上很多入侵的案例，都是通過這種漏洞來進行的。大家想驗證一下的，也可以在google中找些來試下（比如說：在google中查找 inurl:id inurl:?id=yyy形式的鏈接）。這種漏洞還是非常普遍的。 　　至于另外一種比較典型的漏洞跨站腳本漏洞，就是在參數后面加入一段HTML的代碼，比如說這樣的形式id=2525scriptalert(39。xss39。)/script，看最后返回來的頁面中有沒有包含你輸入的這段HTML代碼，如果有的話，就是有跨站漏洞了。對于論壇、發帖等形式的也一樣，在輸入中包含HTML代碼，保存，如果最后這段代碼能夠原封不動地顯示出來，那就是有這個問題了（也就意味著，你也可以制造一只類似于百度蠕蟲一樣的跨站蠕蟲了）。 　　嗯，基本上，web測試的原理就這樣，不過要做到純熟，還是需要很多的練習，并且要多看一些有深度的文檔，這樣才有進步。30 /