<dd id="dbjz6"><noscript id="dbjz6"></noscript></dd>
    <th id="dbjz6"></th>
      1. <dd id="dbjz6"></dd>
        1. 滲透測試工程師面試經驗總結

          大型企業滲透測試個人去做怎么做?

          個人認為步驟應該是信息搜集,掃描,入侵,內網滲透這么個思路,實際上他在問的時候,我并不知道他想讓我回答什么內容。我剛提到信息搜集,就開始下一個問題了。

          安全模式下繞過php的disable fuction?

          DL函數,組件漏洞,環境變量。
          (這個當時沒答出來)

          SQL頭注入點?

          • UA
          • REFERER
          • COOKIE
          • IP

          php中命令執行涉及到的函數?

          eval()、assert()、popen()、system()、exec()、shell_exec()、passthru()、pcntl_exec()等函數。

          滲透測試工程師面試經驗總結

          金融行業常見邏輯漏洞?

          單針對金融業務的,我認為除了通用性以外的,主要是數據的篡改(涉及金融數據,或部分業務的判斷數據),由競爭條件或者設計不當引起的薅羊毛,交易/訂單信息泄露,水平越權對別人的賬戶查看或惡意操作,交易或業務步驟繞過。

          SSRF漏洞的成因 防御 繞過

          成因:模擬服務器對其他服務器資源進行請求,沒有做合法性驗證。

          利用:構造惡意內網IP做探測,或者使用其余所支持的協議對其余服務進行攻擊。

          防御:禁止跳轉,限制協議,內外網限制,URL限制。

          繞過:使用不同協議,針對IP,IP格式的繞過,針對URL,惡意URL增添其他字符,@之類的。301跳轉+dns rebindding。

          FFMPEG 本地文件讀取漏洞原理

          我認為簡而言之就是通過調用加密API將payload加密放入一個會被執行的段字節中。但是具體回答工程中我只回答了SSRF老洞,m3u8頭,偏移量,加密,還有其他部分模糊的提及了一下。感覺還應該提一個文件格式的問題。

          常用WEB開發JAVA框架

          STRUTS,SPRING

          常見的java框架漏洞

          其實面試官問這個問題的時候我不太清楚他要問什么,我提到struts的045 048,java常見反序列化。然后面試官說RMI什么什么的,當時這段話沒太聽清,由于我不知道他想問什么我就提了知道的幾個漏洞。

          • 045 錯誤處理引入了ognl表達式;
          • 048 封裝action的過程中有一步調用getstackvalue遞歸獲取ognl表達式;
          • 反序列化 操作對象,通過手段引入。apache common的反射機制、readobject的重寫,其實具體的我也記不清楚。。。然后這部分就結束了

          開發相關,做過什么開發沒有

          沒有開發過內容,只有思路想法,然后直接下一問題。

          同源策略

          同源策略限制不同源對當前document的屬性內容進行讀取或設置。

          不同源的區分:協議、域名、子域名、IP、端口,以上有不同時即不同源。

          DOM型和反射型的區別?

          反射型XSS:通過誘導用戶點擊,我們構造好的惡意payload才會觸發的XSS。反射型XSS的檢測我們在每次請求帶payload的鏈接時頁面應該是會帶有特定的畸形數據的。

          DOM型:通過修改頁面的DOM節點形成的XSS。

          DOM-based XSS由于是通過js代碼進行dom操作產生的XSS,所以在請求的響應中我們甚至不一定會得到相應的畸形數據。

          根本區別在我看來是輸出點的不同。

          對于XSS怎么提修補建議

          輸入點檢查:對用戶輸入的數據進行合法性檢查,使用filter過濾敏感字符或對進行編碼轉義,針對特定類型數據進行格式檢查。針對輸入點的檢查最好放在服務器端實現。

          輸出點檢查:對變量輸出到HTML頁面中時,對輸出內容進行編碼轉義,輸出在HTML中時,對其進行HTMLEncode,如果輸出在Javascript腳本中時,對其進行JavascriptEncode。

          對使用JavascriptEncode的變量都放在引號中并轉義危險字符,data部分就無法逃逸出引號外成為code的一部分。還可以使用更加嚴格的方法,對所有數字字母之外的字符都使用十六進制編碼。此外,要注意在瀏覽器中,HTML的解析會優先于Javascript的解析,編碼的方式也需要考慮清楚,針對不同的輸出點,我們防御XSS的方法可能會不同。

          除此之外,還有做HTTPOnly對Cookie劫持做限制。

          DOM型XSS 自動化測試或人工測試

          人工測試思路:找到類似document.write、innerHTML賦值、outterHTML賦值、window.location操作、寫javascript:后內容、eval、setTimeout 、setInterval 等直接執行之類的函數點。找到其變量,回溯變量來源觀察是否可控,是否經過安全函數。

          自動化測試思路:從輸入入手,觀察變量傳遞的過程,最終檢查是否有在危險函數輸出,中途是否有經過安全函數。但是這樣就需要有一個javascript解析器,否則會漏掉一些通過js執行帶入的部分內容。

          (在回答這段問題的時候,由于平時對客戶的檢測中,基本是憑借不同功能點的功能加上經驗和直覺來進行檢測,對不同類型的XSS檢測方式實際上并沒有太過細分的標準化檢測方式,所以回答的很爛。。。)

          token和referer做橫向對比,誰安全等級高?

          token安全等級更高,因為并不是任何服務器都可以取得referer,如果從HTTPS跳到HTTP,也不會發送referer。并且FLASH一些版本中可以自定義referer。

          但是token的話,要保證其足夠隨機且不可泄露。(不可預測性原則)

          對referer的驗證,從什么角度去做?如果做,怎么杜絕問題

          對header中的referer的驗證,一個是空referer,一個是referer過濾或者檢測不完善。

          為了杜絕這種問題,在驗證的白名單中,正則規則應當寫完善。

          針對token,對token測試會注意哪方面內容,會對token的哪方面進行測試?

          引用一段請教前輩的回答:

          針對token的攻擊,一是對它本身的攻擊,重放測試一次性、分析加密規則、校驗方式是否正確等,二是結合信息泄露漏洞對它的獲取,結合著發起組合攻擊;

          信息泄露有可能是緩存、日志、get,也有可能是利用跨站;

          很多跳轉登錄的都依賴token,有一個跳轉漏洞加反射型跨站就可以組合成登錄劫持了;

          另外也可以結合著其它業務來描述token的安全性及設計不好怎么被繞過比如搶紅包業務之類的

          如何生成一個安全的隨機數?

          上一頁12下一頁
          ?

          留言

          chinesemature老熟妇oldman