平安性測試之續(xù)

By-jacob小胖胖_要減肥(新浪圍脖).

網(wǎng)站平安性問題一直是一個大家所需要重視，但有時候缺總是感覺缺乏這種資源或是這個范圍太廣而無法全部覆蓋到把，但一旦被人利用就會造成很多不利影響。所以這個問題最好從源頭開始杜絕，而不是靠后期測試人員或者使用者發(fā)現(xiàn)再去修復，想到這個周末便對都是開發(fā)童鞋的oschina進行了一次友情測試，并得到了不錯的效果。首先認證釣魚這個問題是由于一個引用網(wǎng)絡圖片問題而導致的，這個實在影響太大，包括qq，百度，人人，163郵箱，qq郵箱等著名網(wǎng)站。那么為什么一個引用網(wǎng)絡圖片會導致這個認證釣魚呢，因為認證的關系，好了，下面具體看圖把。.測試淘寶論壇，欺騙窗口彈出.測試支付寶論壇，欺騙窗口彈出.測試網(wǎng)易郵箱，欺騙窗口彈出.測試新浪郵箱，欺騙窗口彈出.前面一段時間作為wooyun的一員，一直致力于網(wǎng)絡平安，發(fā)現(xiàn)各類網(wǎng)站及郵箱都會有一個高危漏洞，即認證釣魚，包括淘寶論壇，支付寶論壇，百度貼吧，qq空間，163郵箱，qq郵箱等網(wǎng)站，當用戶翻開頁面的時候會引發(fā)了一個認證，如果用戶不注意就會輸入用戶名密碼進去，因為基于對網(wǎng)站的信任，這個時候黑客就會受到用戶輸入的用戶名和密碼，即可登錄該網(wǎng)站，危害很大，特別是郵箱那么我就以163郵箱為例演示下這個過程吧首先我先寫一封郵件以qq郵箱為例子，發(fā)送到163郵箱，引用網(wǎng)絡圖片，地址為://*******/authtest.php?id=*****&info=%3A%2F%2Ftwebmail.mail.163#.jpg..點擊發(fā)送，然后到163郵箱查看收到內容，并翻開郵件看到.這個時候不注意的用戶就會看到提示登錄的彈框，很可能輸入用戶名密碼，那么我輸入下看看，結果輸入的用戶名密碼發(fā)到了我所對應的地址.首先，我先找個能夠引用網(wǎng)絡圖片的地方，其實不引用也可以，只要插如imgsrc=“即可.之后刷新看效果吧，因為指定的圖片地址引用了一個認證.這個時候重新翻開頁面就會觸發(fā)一個釣魚認證，沒有警惕性的用戶發(fā)現(xiàn)是要連接關于訪問網(wǎng)站的，就輸入了該網(wǎng)站的用戶名和密碼，點擊確定以后其實這個密碼就發(fā)給我了，因為這個釣魚認證是我搞的，好了看看效果把。.看來我已經(jīng)收到有人輸如的oschina的用戶名和密碼了.看了真的有人中招了，好了那么登陸發(fā)發(fā)消息看看這個就是我使用剛剛收到的用戶名密碼所發(fā)的一條信息，因為之前沒有測試就聯(lián)系紅薯了，只是他找周公去了，所以發(fā)一條消息再@下。至此測試成功，之后就有程序猿發(fā)現(xiàn)了這個情況并發(fā)帖，看來程序猿的警惕性還是很高的，不過也說明他們也對平安性的知識比較缺乏，并不知道這是一個認證釣魚。..就此測試結束，第二天聯(lián)系紅薯把事情講清楚后，紅薯特地在首頁搞了一個置頂貼，看來他也認識到了問題的嚴重性，畢竟他的網(wǎng)站至少還是可以的.帖子內容.這樣根本就在oschina普及了這個平安性方面的知識，我的目的也到達了，個人認為從程序猿抓起才是最好的方式把。之后也在qq空間和百度貼吧做相應測試也收到了用戶名密碼.至此，大家應該對認證釣魚這個有所認識，網(wǎng)站平安性問題一直層出不窮，這個不但給黑客有了圖利的時機，更給用戶很多不安定因素，造成對網(wǎng)站的不信任。很多東西涉及范圍太廣我們也無法全部覆蓋到，只能一點點積累。比方xss這個問題，最簡單的當然使用白名單，但很多時候是無法防止一些比方onload的標簽的，那么就只能過濾，這個時候問題就會層出不窮，大家有興趣可以看一下騰訊圍脖10+的xss:///corps/騰訊/page/1騰訊/page/1所以開發(fā)童鞋很多時候自己也要把問題考慮全面啊，測試童鞋很多時候也無法全部覆蓋，只有大家通力協(xié)作才能把網(wǎng)站做的更好。下面就是一個新蛋的彈窗，只是在這個地方利用方式比較復雜，最簡單的就是你登陸我輸個代碼cookies就發(fā)到我指定地方了，不過這個還是開發(fā)童鞋過濾不嚴導致的，千里之堤，潰于蟻穴，平安無小事啊。...或者這樣利用，窗口是模態(tài)的.輸入用戶名密碼后的效果.在講根底知識之前先看一個漏洞，雖然利用很簡單，就是一個參數(shù)沒有對負數(shù)進行控制，但影響很大，之后我就會講利用手法，就是fiddler工具的使用，上次已經(jīng)講解過反向代理工具burp的使用了。.好了，測試同學肯定覺得上面的和自己關系不是很大，那么下面的內容我覺得是對于web測試應該掌握的，當然開發(fā)同學肯定要很了解其本質。首先我們必須明晰Session的概念，Session是由效勞器維持的一個效勞器端的存儲空間，用戶在連接效勞器時，會由效勞器生成一個唯一的SessionID,用該SessionID為標識符來存取效勞器端的Session存儲空間。SessionID可以由cookie保存，用戶訪問網(wǎng)站時，SessionID將會隨cookie提交到效勞器端。效勞器也可以通過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的平安風險，所以session機制需要借助于cookie機制。原理上cookie只是做為SessionID的一個載體，我們只需要區(qū)分cookie機制和session機制即可。.同源策略是被提起比較多的一個平安概念，這個策略是瀏覽器的平安根底，cookie做為瀏覽器的一個功能，自然也考慮到了同源策略，cookie的同源策略分為兩個方面，第一個方面涉及到cookie的domain和path兩個值，瀏覽器根據(jù)這兩個值判斷什么樣的域名和頁面能夠讀取cookie。第二個方面是第一方cookie和第三方cookie兩個概念，第一方cookie是指當前正在查看的網(wǎng)站的cookie,在這個情況下對同源的HTTP請求都讀取cookie發(fā)送，自然沒有任何限制。而第三方cookie來自當前正在查看的網(wǎng)站以外的網(wǎng)站的cookie，第三方cookie可以是會話cookie和持久化cookie，我們正在查看的網(wǎng)站可能包含了第三方的資源，在這種情況下瀏覽器會因為考慮到同源策略，而判斷從當前瀏覽的網(wǎng)站對站外的請求是否允許讀取第三方cookie發(fā)送。cookie的同源策略可能比較晦澀，但是并不難理解，我們拿javascript的同源策略類比，比方AJAX不允許跨域的GET和POST請求，而正常的HTML代碼中帶有文件請求的標簽實際上是屬于GET請求，當網(wǎng)站嵌入了第三方的文件資源，也就產(chǎn)生了跨域的請求，同源策略是不可能干預這類正常的請求的，但是從平安的角度仍然有必要限制第三方cookie的存取。.一個應用程序在設計的過程中，為了實現(xiàn)對資源和請求進行管理，用戶信息認證是非常重要的一環(huán)。由于HTTP請求的無連接性，一般的應用程序都是通過Cookie或者Session來完成認證工作，通過將加密的用戶認證信息存儲到Cookie中，或者通過賦予客戶端的一個Token，通常也就是所說的SessionId來在效勞器端直接完成認證和取得用戶的身份信息，不管哪一種方式，實際上在HTTP協(xié)議里都是通過Cookie來實現(xiàn)的，不同的是Cookie可能可以比較長期地存儲在客戶端上，而Session往往在會話結束之后效勞器監(jiān)視會話不處于活動狀態(tài)而予以銷毀。有的完全將認證信息〔用戶密碼信息〕加密存儲到客戶端里，只要用戶密碼信息不修改，就可以一直利用這個認證信息來登錄應用程序。也有的是將認證通過后應用程序賦予客戶端一個Token，這個Token存儲在Cookie里，這樣當客戶端登錄的時候就可以通過這個Token獲得對應的身份，這樣只要這個Cookie不被刪除，就可以永遠的處于登錄狀態(tài)。而另外的一些應用程序將Token放置到Session里，當客戶端退出應用程序之后或者客戶端在一段時間無響應之后，效勞器就銷毀這個Session，而且因為是Session里，所以客戶端瀏覽器關閉之后，這個Session也從瀏覽器內存里銷毀了。.譬如163郵箱，譬如baidu的認證機制。我們可以經(jīng)常遇到這樣的情況，我在一個瀏覽器里開了webmail然后新翻開一個瀏覽器開了webmail，然后我第一個瀏覽器退出了并不影響第二個的賬戶，兩者互不影響，其實是因為他們獲取到了兩個SessionId，這在應用程序里可能是作為用戶體驗考慮的，但是正是這種機制存在巨大的平安漏洞。

Session信息是以一個SessionId或者表現(xiàn)為臨時Cookie的Token的形式發(fā)送的，而我們在實現(xiàn)了XSS的時候其實是可以操作Cookie的了，可以想象，如果我們賦給瀏覽器一個和SessionCookie名字相同而值不同的Cookie會怎么樣？通過我們的測試發(fā)現(xiàn)，實際上兩個Cookie都是被發(fā)送出去的，在HTTP頭里表現(xiàn)為出現(xiàn)兩個一樣的COOKIE，那么效勞器會選擇哪個Cookie作為實際取得的COOKIE變量呢？測試的時候發(fā)現(xiàn)實際上是以第一個出現(xiàn)的COOKIE為準的，而不管發(fā)送過來的是SessionCookie還是StoreCookie，所以我們就可以利用Javascript改變客戶端的SessionToken了。.跨域web攻擊指的是利用網(wǎng)站跨域平安設置缺陷進行的web攻擊，有別于傳統(tǒng)的攻擊，跨域web攻擊可以從網(wǎng)站某個不重要的業(yè)務直接攻擊和影響核心業(yè)務。傳統(tǒng)的平安思維教會我們按資產(chǎn)、功能等需求劃分核心業(yè)務，優(yōu)先保護核心業(yè)務等，非核心業(yè)務的平安等級一般沒有核心業(yè)務高，給我們錯覺是非核心業(yè)務受到攻擊的話，所造成損失不會很大，也不會影響到核心業(yè)務，所以了解跨域web攻擊這一概念還是非常有意義的?；赼jax跨域設置的跨域攻擊使用ajax技術讓人頭痛的地方就是如何跨域，受同源策略所限不同域名包括子域名在內是無法進行AJAX請求的，隨后衍生出一類技術可以通過設置document.domain實現(xiàn)跨域。如a.test和b.test,當兩個網(wǎng)站通過javascript操作DOM接口document.domain=’test’將網(wǎng)站的域設置為test后，兩個網(wǎng)站就處于同一個域內，可以進行各種跨域操作。在開發(fā)人員方面這是很方便的跨域技術，但是在攻擊者眼中這簡直就是一個大后門，黑客只需要找到*.test下任意一個XSS漏洞，在任意一個子域名里的網(wǎng)頁都可以跨域攻擊a.test和b.test。說到這里就不得不說說騰訊的架構問題，騰訊圍脖和QQ郵箱的cookies都沒有設置only，現(xiàn)在騰訊業(yè)務線很長，騰訊網(wǎng)站很多地方程序員都是從document.cookie里讀取skey來使用的，一旦-only的話，很多程序都要修改。鑒于本錢和可能出現(xiàn)的難以預料的問題就沒有改，但這個時候只要先關騰訊的網(wǎng)站有一個xss，我們就能夠通過這個xss構造一個短地址發(fā)在圍脖或發(fā)給郵箱用戶，只要點擊就會執(zhí)行第三方腳本，從而導致qq相關cookies被竊取，那么所有騰訊網(wǎng)站就都可以登陸了。.上面的根底知識不知道童鞋們能體會多少，現(xiàn)在就到了fiddler工具的使用，這個就比較實際了，開發(fā)童鞋應該都很熟練了。當今web程序的開發(fā)技術真是百家爭鳴，ASP.NET,PHP,JSP，Perl,AJAX等等。無論Web技術在未來如何開展，理解Web程序之間通信的根本協(xié)議相當重要,因為它讓我們理解了Web應用程序的內部工作。協(xié)議是指計算機通信網(wǎng)絡中兩臺計算機之間進行通信所必須共同遵守的規(guī)定或規(guī)那么，超文本傳輸協(xié)議(HTTP)是一種通信協(xié)議，它允許將超文本標記語言(HTML)文檔從Web效勞器傳送到客戶端的瀏覽器。

目前我們使用的是HTTP/1.1版本協(xié)議是無狀態(tài)的，同一個客戶端的這次請求和上次請求是沒有對應關系，對效勞器來說，它并不知道這兩個請求來自同一個客戶端。為了解決這個問題，Web程序引入了Cookie機制來維護狀態(tài)。.HTTP消息的結構先看Request消息的結構,

Request消息分為3局部，第一局部叫Requestline,第二局部叫Requestheader,第三局部是body.header和body之間有個空行，結構如以下圖第一行中的Method表示請求方法,比方"POST","GET",

Path-to-resoure表示請求的資源，Http/version-number表示HTTP協(xié)議的版本號當使用的是"GET"方法的時候，body是為空的比方我們翻開博客園首頁的request如下GET://wwwblogs/HTTP/1.1

Host:wwwblogs抽象的東西，難以理解，老感覺是虛的，所謂眼見為實,實際見到的東西，我們才能理解和記憶。我們今天用Fiddler，實際的看看Request和Response.下面我們翻開Fiddler捕捉一個博客園登錄的Request然后分析下它的結構,在Inspectorstab下以Raw的方式可以看到完整的Request的消息..我們再看Response消息的結構,和Request消息的結構根本一樣。同樣也分為三局部,第一局部叫Responseline,第二局部叫Responseheader，第三局部是body.header和body之間也有個空行,

結構如以下圖HTTP/version-number表示HTTP協(xié)議的版本號，

status-code和message。我們用Fiddler捕捉一個博客園首頁的Response然后分析下它的結構,在Inspectorstab下以Raw的方式可以看到完整的Response的消息..Get和Post方法的區(qū)別Http協(xié)議定義了很多與效勞器交互的方法，最根本的有4種，分別是GET,POST,PUT,DELETE.一個URL地址用于描述一個網(wǎng)絡上的資源，而HTTP中的GET,POST,PUT,DELETE就對應著對這個資源的查，改，增，刪4個操作。我們最常見的就是GET和POST了。GET一般用于獲取/查詢資源信息，而POST一般用于更新資源信息.我們看看GET和POST的區(qū)別1.GET提交的數(shù)據(jù)會放在URL之后，以?分割URL和傳輸數(shù)據(jù)，參數(shù)之間以&相連，如EditPosts.aspx?name=test1&id=123456.

POST方法是把提交的數(shù)據(jù)放在HTTP包的Body中.2.GET提交的數(shù)據(jù)大小有限制〔因為瀏覽器對URL的長度有限制〕，而POST方法提交的數(shù)據(jù)沒有限制.3.GET方式需要使用Request.QueryString來取得變量的值，而POST方式通過Request.Form來獲取變量的值。4.GET方式提交數(shù)據(jù)，會帶來平安問題，比方一個登錄頁面，通過GET方式提交數(shù)據(jù)時，用戶名和密碼將出現(xiàn)在URL上，如果頁面可以被緩存或者其他人可以訪問這臺機器，就可以從歷史記錄獲得該用戶的賬號和密碼..Fiddler的根本界面.Inspectorstab下有很多查看Request或者Response的消息。其中RawTab可以查看完整的消息，Headerstab只查看消息中的header.如以下圖.QuickExec命令行的使用Fiddler的左下角有一個命令行工具叫做QuickExec,允許你直接輸入命令。常見得命令有help

翻開官方的使用頁面介紹，所有的命令都會列出來cls

清屏

(Ctrl+x也可以清屏)select

選擇會話的命令?.png

用來選擇png后綴的圖片bpu

截獲request.Fiddler中設置斷點修改Request

Fiddler最強大的功能莫過于設置斷點了，設置好斷點后，你可以修改Request的任何信息包括host,cookie或者表單中的數(shù)據(jù)。設置斷點有兩種方法第一種：翻開Fiddler點擊Rules->AutomaticBreakpoint

->BeforeRequests(這種方法會中斷所有的會話)如何消除命令呢？

點擊Rules->AutomaticBreakpoint

->Disabled第二種:

在命令行中輸入命令:

bpubaidu

(這種方法只會中斷baidu)如何消除命令呢？

在命令行中輸入命令bpu

.看個實例，模擬博客園的登錄，在IE中翻開博客園的登錄頁面，輸入錯誤的用戶名和密碼，用Fiddler中斷會話，修改成正確的用戶名密碼。這樣就能成功登錄1.用IE翻開博客園的登錄界面

://passportblogs/login.aspx

2.翻開Fiddler,

在命令行中輸入bpu://passportblogs/login.aspx

3.輸入錯誤的用戶名和密碼點擊登錄

4.Fiddler能中斷這次會話，選擇被中斷的會話，點擊Inspectorstab下的WebFormstab修改用戶名密碼，然后點擊RuntoCompletion如以下圖所示。

5.結果