安全性測試之續(xù)課件

1、 安全性測試之續(xù)12019/1/302019/1/30 網站安全性問題一直是一個大家所需要重視，但有時候缺總是感覺缺乏這種資源或是這個范圍太廣而無法全部覆蓋到把，但一旦被人利用就會造成很多不利影響。所以這個問題最好從源頭開始杜絕，而不是靠后期測試人員或者使用者發(fā)現(xiàn)再去修復，想到這個周末便對都是開發(fā)童鞋的oschina進行了一次友情測試，并得到了不錯的效果。 首先認證釣魚這個問題是由于一個引用網絡圖片問題而導致的，這個實在影響太大，包括qq，百度，人人，163郵箱，qq郵箱等著名網站。 那么為什么一個引用網絡圖片會導致這個認證釣魚呢，因為http認證的關系，好了，下面具體看圖把。22022/7/

2、27測試新浪郵箱，欺騙窗口彈出32022/7/27前面一段時間作為wooyun的一員，一直致力于網絡安全，發(fā)現(xiàn)各類網站及郵箱都會有一個高危漏洞，即認證釣魚，包括淘寶論壇，支付寶論壇，百度貼吧，qq空間，163郵箱，qq郵箱等網站，當用戶打開頁面的時候會引發(fā)了一個http認證，如果用戶不注意就會輸入用戶名密碼進去，因為基于對網站的信任，這個時候黑客就會受到用戶輸入的用戶名和密碼，即可登錄該網站，危害很大，特別是郵箱那么我就以163郵箱為例演示下這個過程吧首先我先寫一封郵件42022/7/2752022/7/27點擊發(fā)送，然后到163郵箱查看收到內容，并打開郵件看到62022/7/27這個時候不注

3、意的用戶就會看到提示登錄的彈框，很可能輸入用戶名密碼，那么我輸入下看看，結果輸入的用戶名密碼發(fā)到了我所對應的地址72022/7/27首先，我先找個能夠引用網絡圖片的地方，其實不引用也可以，只要插如img src=“即可82022/7/27之后刷新看效果吧，因為指定的圖片地址引用了一個http認證92022/7/27這個時候重新打開頁面就會觸發(fā)一個釣魚認證，沒有警惕性的用戶發(fā)現(xiàn)是要連接關于訪問網站，就輸入了該網站的用戶名和密碼，點擊確定以后其實這個密碼就發(fā)給我了，因為這個釣魚認證是我搞的，好了看看效果把。102022/7/27看來我已經收到有人輸如的oschina的用戶名和密碼了112022/7

4、/27看了真的有人中招了，好了那么登陸發(fā)發(fā)消息看看這個就是我使用剛才收到的用戶名密碼所發(fā)的一條信息，因為之前沒有測試就聯(lián)系紅薯了，只是他找周公去了，所以發(fā)一條消息再下 。 至此測試成功，之后就有程序猿發(fā)現(xiàn)了這個情況并發(fā)帖，看來程序猿的警惕性還是很高的，不過也說明他們也對安全性的知識比較缺乏，并不知道這是一個認證釣魚。122022/7/27132022/7/27就此測試結束，第二天聯(lián)系紅薯把事情講清楚后，紅薯特地在首頁搞了一個置頂貼，看來他也認識到了問題的嚴重性，畢竟他的網站至少還是可以的142022/7/27 至此，大家應該對認證釣魚這個有所認識，網站安全性問題一直層出不窮，這個不但給黑客有了

5、圖利的機會，更給用戶很多不安定因素，造成對網站的不信任。很多東西涉及范圍太廣我們也無法全部覆蓋到，只能一點點積累。 比如xss這個問題，最簡單的當然使用白名單，但很多時候是無法避免一些比如onload的標簽的，那么就只能過濾，這個時候問題就會層出不窮，大家有興趣可以看一下騰訊圍脖10+的xss慮全面啊，測試童鞋很多時候也無法全部覆蓋，只有大家通力協(xié)作才能把網站做的更好。 下面就是一個新蛋的彈窗，只是在這個地方利用方式比較復雜，最簡單的就是你登陸我輸個代碼cookies就發(fā)到我指定地方了，不過這個還是開發(fā)童鞋過濾不嚴導致的，千里之堤，潰于蟻穴，安全無小事啊。152022/7/27162022/7

6、/27172022/7/27或者這樣利用，窗口是模態(tài)的182022/7/27輸入用戶名密碼后的效果192022/7/27 好了，測試同學肯定覺得上面的和自己關系不是很大，那么下面的內容我覺得是對于web測試應該掌握的，當然開發(fā)同學肯定要很了解其本質。 首先我們必須明晰Session的概念，Session是由服務器維持的一個服務器端的存儲空間，用戶在連接服務器時，會由服務器生成一個唯一的SessionID,用該SessionID為標識符來存取服務器端的Session存儲空間。SessionID可以由cookie保存，用戶訪問網站時，SessionID將會隨cookie提交到服務器端。服務器也可以

7、通過URL重寫的方式來傳遞SessionID的值，但是在URL中傳遞SessionID是存在很大的安全風險的，黑客可能獲取HTTP請求的來源信息等手段直接就得到了客戶端的SessionID。 其次我們應該認識到cookie和session的區(qū)別，因為這里的概念是混淆和模糊的。HTTP協(xié)議是無狀態(tài)的，客戶端與服務端無法長期的保存身份認證及會話狀態(tài)，所以便需要cookie機制，在客戶端以文件的形式保存會話狀態(tài)。而session機制則是在服務器端保持狀態(tài)，不需要長期保持會話狀態(tài)，但是服務器端保持狀態(tài)的同時在客戶端也需要保存一個標識，前面我提到了使用URL傳遞SessionID的安全風險，所以sess

8、ion機制需要借助于cookie機制。原理上cookie只是做為SessionID的一個載體，我們只需要區(qū)分cookie機制和session機制即可。202022/7/27 同源策略是被提起比較多的一個安全概念，這個策略是瀏覽器的安全基礎，cookie做為瀏覽器的一個功能，自然也考慮到了同源策略，cookie的同源策略分為兩個方面，第一個方面涉及到cookie的domain和path兩個值，瀏覽器根據這兩個值判斷什么樣的域名和頁面能夠讀取cookie。第二個方面是第一方cookie和第三方cookie兩個概念，第一方cookie是指當前正在查看的網站的cookie,在這個情況下對同源的HTTP

9、請求都讀取cookie發(fā)送，自然沒有任何限制。而第三方cookie來自當前正在查看的網站以外的網站的cookie，第三方cookie可以是會話cookie和持久化cookie，我們正在查看的網站可能包含了第三方的資源，在這種情況下瀏覽器會因為考慮到同源策略，而判斷從當前瀏覽的網站對站外的請求是否允許讀取第三方cookie發(fā)送。 cookie的同源策略可能比較晦澀，但是并不難理解，我們拿javascript的同源策略類比，比如AJAX不允許跨域的GET和POST請求，而正常的HTML代碼中帶有文件請求的標簽實際上是屬于GET請求，當網站嵌入了第三方的文件資源，也就產生了跨域的請求，同源策略是不可

10、能干預這類正常的請求的，但是從安全的角度仍然有必要限制第三方cookie的存取。212022/7/27 一個應用程序在設計的過程中，為了實現(xiàn)對資源和請求進行管理，用戶信息認證是非常重要的一環(huán)。由于HTTP請求的無連接性，一般的應用程序都是通過Cookie或者Session來完成認證工作，通過將加密的用戶認證信息存儲到Cookie中，或者通過賦予客戶端的一個Token，通常也就是所說的SessionId來在服務器端直接完成認證和取得用戶的身份信息，不管哪一種方式，實際上在HTTP協(xié)議里都是通過Cookie來實現(xiàn)的，不同的是Cookie可能可以比較長期地存儲在客戶端上，而Session往往在會話結

11、束之后服務器監(jiān)視會話不處于活動狀態(tài)而予以銷毀。 有的完全將認證信息（用戶密碼信息）加密存儲到客戶端里，只要用戶密碼信息不修改，就可以一直利用這個認證信息來登錄應用程序。也有的是將認證通過后應用程序賦予客戶端一個Token，這個Token存儲在Cookie里，這樣當客戶端登錄的時候就可以通過這個Token獲得對應的身份，這樣只要這個Cookie不被刪除，就可以永遠的處于登錄狀態(tài)。而另外的一些應用程序將Token放置到Session里，當客戶端退出應用程序之后或者客戶端在一段時間無響應之后，服務器就銷毀這個Session，而且因為是Session里，所以客戶端瀏覽器關閉之后，這個Session也從

12、瀏覽器內存里銷毀了。222022/7/27 譬如163郵箱，譬如baidu的認證機制。我們可以經常遇到這樣的情況，我在一個瀏覽器里開了webmail然后新打開一個瀏覽器開了webmail，然后我第一個瀏覽器退出了并不影響第二個的賬戶，兩者互不影響，其實是因為他們獲取到了兩個SessionId，這在應用程序里可能是作為用戶體驗考慮的，但是正是這種機制存在巨大的安全漏洞。Session信息是以一個SessionId或者表現(xiàn)為臨時Cookie的Token的形式發(fā)送的，而我們在實現(xiàn)了XSS的時候其實是可以操作Cookie的了，可以想象，如果我們賦給瀏覽器一個和Session Cookie名字相同而值不

13、同的Cookie會怎么樣？通過我們的測試發(fā)現(xiàn)，實際上兩個Cookie都是被發(fā)送出去的，在HTTP頭里表現(xiàn)為出現(xiàn)兩個一樣的COOKIE，那么服務器會選擇哪個Cookie作為實際取得的COOKIE變量呢？測試的時候發(fā)現(xiàn)實際上是以第一個出現(xiàn)的COOKIE為準的，而不管發(fā)送過來的是Session Cookie還是Store Cookie，所以我們就可以利用Javascript改變客戶端的Session Token了。232022/7/27 跨域web攻擊指的是利用網站跨域安全設置缺陷進行的web攻擊，有別于傳統(tǒng)的攻擊，跨域web攻擊可以從網站某個不重要的業(yè)務直接攻擊和影響核心業(yè)務。傳統(tǒng)的安全思維教會我

14、們按資產、功能等需求劃分核心業(yè)務，優(yōu)先保護核心業(yè)務等，非核心業(yè)務的安全等級一般沒有核心業(yè)務高，給我們錯覺是非核心業(yè)務受到攻擊的話，所造成損失不會很大，也不會影響到核心業(yè)務，所以了解跨域web攻擊這一概念還是非常有意義的。 基于ajax跨域設置的跨域攻擊 使用ajax技術讓人頭痛的地方就是如何跨域，受同源策略所限不同域名包括子域名在內是無法進行AJAX請求的，隨后衍生出一類技術可以通過設置document.domain實現(xiàn)跨域。如和,當兩個網站通過javascript操作DOM接口 document.domain= 將網站的域設置為后，兩個網站就處于同一個域內，可以進行各種跨域操作。在開發(fā)人員方

15、面這是很方便的跨域技術，但是在攻擊者眼中這簡直就是一個大后門，黑客只需要找到*.下任意一個XSS漏洞，在任意一個子域名里的網頁都可以跨域攻擊和。 說到這里就不得不說說騰訊的架構問題，騰訊圍脖和QQ郵箱的cookies都沒有設置httponly，現(xiàn)在騰訊業(yè)務線很長，騰訊網站很多地方程序員都是從 document.cookie里讀取skey來使用的，一旦http-only的話，很多程序都要修改。 鑒于成本和可能出現(xiàn)的難以預料的問題就沒有改，但這個時候只要先關騰訊的網站有一個xss，我們就能夠通過這個xss構造一個短地址發(fā)在圍脖或發(fā)給郵箱用戶，只要點擊就會執(zhí)行第三方腳本，從而導致qq相關cookie

16、s被竊取，那么所有騰訊網站就都可以登陸了。242022/7/27 上面的基礎知識不知道童鞋們能體會多少，現(xiàn)在就到了fiddler工具的使用，這個就比較實際了，開發(fā)童鞋應該都很熟練了。 當今web程序的開發(fā)技術真是百家爭鳴，ASP.NET, PHP, JSP，Perl, AJAX 等等。 無論Web技術在未來如何發(fā)展，理解Web程序之間通信的基本協(xié)議相當重要, 因為它讓我們理解了Web應用程序的內部工作。 協(xié)議是指計算機通信網絡中兩臺計算機之間進行通信所必須共同遵守的規(guī)定或規(guī)則，超文本傳輸協(xié)議(HTTP)是一種通信協(xié)議，它允許將超文本標記語言(HTML)文檔從Web服務器傳送到客戶端的瀏覽器。

17、目前我們使用的是HTTP/1.1 版本 http協(xié)議是無狀態(tài)的，同一個客戶端的這次請求和上次請求是沒有對應關系，對http服務器來說，它并不知道這兩個請求來自同一個客戶端。 為了解決這個問題， Web程序引入了Cookie機制來維護狀態(tài)。252022/7/27262022/7/27 我們再看Response消息的結構, 和Request消息的結構基本一樣。 同樣也分為三部分,第一部分叫Response line, 第二部分叫Response header，第三部分是body. header和body之間也有個空行, 結構如下圖 HTTP/version-number表示HTTP協(xié)議的版本號，

18、status-code 和message 。 我們用Fiddler 捕捉一個博客園首頁的Response然后分析下它的結構, 在Inspectors tab下以Raw的方式可以看到完整的Response的消息272022/7/27282022/7/27Get和Post方法的區(qū)別 Http協(xié)議定義了很多與服務器交互的方法，最基本的有4種，分別是GET,POST,PUT,DELETE. 一個URL地址用于描述一個網絡上的資源，而HTTP中的GET, POST, PUT, DELETE就對應著對這個資源的查，改，增，刪4個操作。 我們最常見的就是GET和POST了。GET一般用于獲取/查詢資源信息，

19、而POST一般用于更新資源信息.我們看看GET和POST的區(qū)別1. GET提交的數(shù)據會放在URL之后，以?分割URL和傳輸數(shù)據，參數(shù)之間以&相連，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數(shù)據放在HTTP包的Body中.2. GET提交的數(shù)據大小有限制（因為瀏覽器對URL的長度有限制），而POST方法提交的數(shù)據沒有限制.3. GET方式需要使用Request.QueryString來取得變量的值，而POST方式通過Request.Form來獲取變量的值。4. GET方式提交數(shù)據，會帶來安全問題，比如一個登錄頁面，通過GET方式提交數(shù)據時，

20、用戶名和密碼將出現(xiàn)在URL上，如果頁面可以被緩存或者其他人可以訪問這臺機器，就可以從歷史記錄獲得該用戶的賬號和密碼.292022/7/27 Inspectors tab下有很多查看Request或者Response的消息。 其中Raw Tab可以查看完整的消息，Headers tab 只查看消息中的header. 如下圖302022/7/27QuickExec命令行的使用Fiddler的左下角有一個命令行工具叫做QuickExec,允許你直接輸入命令。常見得命令有help 打開官方的使用頁面介紹，所有的命令都會列出來cls 清屏 (Ctrl+x 也可以清屏)select 選擇會話的命令?.pn

21、g 用來選擇png后綴的圖片bpu 截獲request312022/7/27Fiddler中設置斷點修改Request Fiddler最強大的功能莫過于設置斷點了，設置好斷點后，你可以修改httpRequest 的任何信息包括host, cookie或者表單中的數(shù)據。設置斷點有兩種方法第一種：打開Fiddler 點擊Rules- Automatic Breakpoint -Before Requests(這種方法會中斷所有的會話)如何消除命令呢？ 點擊Rules- Automatic Breakpoint -Disabled第二種: 在命令行中輸入命令: bpu (這種方法只會中斷)如何消除命令呢？ 在命令行中輸入命令 bpu322022/7/27332022/7/27Fiddler中設置斷點修改Response 當然Fiddler中也能修改Response第一種：打開Fiddler 點擊Rules- Automatic Breakpoint -After Response