原文鏈接：https://www.freebuf.com/articles/web/250308.html

大家好，我是鳥哥，一個半路出家的程序員。

這幾天一直再出搭建個人網站的文章，為了進一步提高大家的積極性，我準備搭建一個美女圖片的網站，于是就開始找相關的主題，結果就看到了今天要分享的這篇文章。很不錯，也很刺激，決定分享給大家。希望大家本著技術第一，看圖第二的態度認真閱讀。

某天在無聊的瀏覽網頁的過程中，偶然間，偶然的點進了某個美女圖片網站。
想著也是無聊，就隨便看看唄。結果一個圖集就放出3張圖，剩余的就要VIP（充錢），太可惡了！無聊的我就想看看能不能繞過限制，直接看到整個圖集。

一. 基本判斷

這個網站看上去沒有使用一些現成的網站框架，比如wordpress，所以有可能出現低級錯誤。

如果使用的是網站框架，那我基本就直接放棄了，低版本框架雖然會有通用的漏洞（我沒能力利用），但低級錯誤基本沒有的。

先創建了個賬戶，登錄之后查看了下存儲，發現沒有使用cookie，反而使用了sessionStorage和localStorage：

cookie

sessionStorage

localStorage：略，沒什么有價值的內容。

從這里以及文章最開始的圖來判斷，這個網站使用了不少前端的東西，很可能有些功能就是在前端實現的，或者使用了ajax技術。

二. 登錄、權限認定

登錄賬戶后，先判斷圖集加載頁面怎么認定用戶的權限的，看看會不會用到sessionStorage的uid或者token。

這里就要介紹下怎么使用火狐瀏覽器分析前端的代碼了。

按F12打開開發者工具，然后按照圖中的說明，查看加載圖集頁面時所發起的ajax請求：

從上圖得知，一共發起了4次ajajx請求，根據相應的內容，getContentInfo接口返回了圖集的數據。

從url這個字段來看，也剛好返回了3個圖片的url（用英文逗號分隔即可），也就是可以免費看的那3張圖。

那看看發起請求的代碼是怎么樣的吧，選中堆棧跟蹤，可以看到請求代碼的調用過程，從下至上：

意思就是，在windows.onload中調用了getContentInfo函數，getContentInfo函數中又調用了ajaxGetUser函數……

具體的位置，我們通過點擊堆棧跟蹤函數名右側的藍色鏈接，就可以直接跳轉過去：

window.onload

getContentinfo

這里可以看到傳入了一個object，就是getData，里面的token就是sessionStorage的token：

至于cid，就是圖集的id，這里我懶得去找在哪賦值的了。

如果前端代碼編寫不規范（比如這里對前端代碼都沒有混淆），那么變量很可能暴露在全局環境中。

直接在開發者工具的控制臺中輸出cid就能看到值了：

那其實到這我又沒法進行下去了，傳入token是為了判斷用戶身份，傳入cid是判斷是哪一個圖集。

而對于token我也沒辦法對它做什么事情，也沒法冒充其他用戶的身份。
如果他傳入的是uid，也就是用戶id，那倒還可以試一試。

最后跟著代碼走下去的結果果然是這樣，沒有什么可以插手的地方。

三. 碰運氣

我的思路都是建立在對方犯低級錯誤的前提下的，那么這種不在后端實現全部的數據處理，而是在前端實現，限制對方觀看的某些資源的，還有哪些低級錯誤呢？

想了下，有沒有可能接口返回的數據是完整的，然后只是用js代碼將其隱藏而已……

但是最開始查看的返回數據的時候，返回的圖片的url就3個：

哦，另外，圖片的加載雖然不需要任何權限，基本沒有多少的防盜鏈措施（意思就是可以直接通過圖片地址訪問圖片），但圖片的地址是沒有規則可言的，如果是按照數字順序命名，那就可以直接獲取到整個圖集的圖片了。

我不死心，把所有的字段都看了遍，還真有發現，在圖集的下面，有一個推薦圖片：

所以也返回了這部分的數據：

點開一看，終于發現低級錯誤了，url沒做處理，返回了整個圖集圖片的url：

也就是說，雖然這頁面的圖集本身的其余圖片我沒法看到，但是它頁面中推薦的圖集的圖片我全都可以看到：

注意：直接使用圖片地址其實還是不能查看到圖片，需要在地址后面加上一個參數：

但是這個參數每次登錄后都是固定的，可以從localStorage中得到，也可以從免費可觀看的圖片地址中得到，意義不大。

四. 弱口令

理論上有這招就可以把查看到大部分圖集的所有圖片了，不過我不是無聊嗎，又閑著看了看有沒有其他可以做的。

在圖集的下面，有一個評論區，當然，也是接口返回的數據。

在這里還是沒進行處理，把所有評論用戶的用戶名全暴露了（手機號碼），當然這些客戶的口令一般也不會出現很弱的口令，所以我沒去嘗試。

但是上傳這些圖集的賬戶的口令，那就不好說了，關注圖集上傳者后：

在個人主頁的關注部分，接口返回的數據中依然沒進行處理，可以直接看到被關注者的用戶名：

我也就隨便一試，居然還真使用了弱口令，下圖是登錄成功后”我的作品“頁面：

點擊一個作品進去，顯示已購買：

五. 對后臺管理的滲透

這個就不截圖詳細說明了，思路和上面的差不多，也主要是發現對方在前端的低級錯誤。

僅僅知道登錄頁面A的地址，然后查看登錄頁面的Js文件。

發現登錄成功后使用js進行跳轉，跳轉到主頁面B，并且登錄成功后的在sessionStorage中設置了一些字段。

先直接訪問主頁面B，發現會先將頁面的框架加載完畢后，再跳轉回頁面A。由此可以得出判斷，B頁面的跳轉語句和A頁面差不多，都是使用Js語句實現的。禁用Js功能，再進入B頁面，發現果然停止了跳轉。但是雖然頁面框架正常加載，但卻沒載任何數據。查看B頁面加載的Js文件，在跳轉回A頁面的代碼前后找到了判斷語句，使用sessionStorage中的字段進行判斷。

于是設置sessionStorage中的相關字段，繞過了登錄的過程，數據正常加載了，達到了滲透的目的。

六. 感想

其實從開發的角度，如果要保證代碼至少在邏輯方面沒有明顯的漏洞，還是有些繁瑣的。

舉個簡單的例子，如網站的數據檢驗功能，不允許前端提交不符合當前要求規范的數據（比如年齡文本框部分不能提交字母）。

那么為了實現這個功能，首先開發者肯定要在前端實現該功能，直接在前端阻止用戶提交不符規范的數據，否則用戶體驗會很差，且占用服務器端的資源。但是沒有安全意識或覺得麻煩的開發者就會僅僅在前端用Js進行校驗，后端沒有重復進行校驗。

這樣就很容易給惡意用戶機會：比如不通過前端頁面，直接向后端接口發送數據：或者，前端代碼編寫不規范，用戶可以直接在瀏覽器控制臺中用自己寫的Js代碼覆蓋原有的Js代碼；或者，用戶還可以直接在瀏覽器中禁用Js；等等。總之，前端的傳過來的數據可信度基本上可以認為比較低，太容易被利用了。

而我的思路都是很簡單的，就是關注比較重要的幾個節點，看看有沒有可乘之機。如登錄、權限判定、數據加載等前后，對方是怎么做的，用了什么樣的技術，有沒有留下很明顯的漏洞可以讓我利用。像這兩個網站，加載的Js文件都沒有進行混淆，注釋也都留著，還寫得很詳細。比較湊巧的是，這兩個網站都用到了比較多的前端的技術，也都用到了sessionStorage。特別的，它們都把很多的業務功能放在前端實現，于是存在明顯漏洞的可能性就比較大，就值得我去嘗試。

END

推薦閱讀牛逼！Python常用數據類型的基本操作（長文系列第①篇） 牛逼！Python的判斷、循環和各種表達式（長文系列第②篇）牛逼！Python函數和文件操作（長文系列第③篇）牛逼！Python錯誤、異常和模塊（長文系列第④篇）

總結

以上是生活随笔為你收集整理的拿下了一个美女图片网站！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。