国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

web安全

lordharrd / 3165人閱讀

摘要：是一種經(jīng)常出現(xiàn)在應用中的計算機安全漏洞，它允許惡意用戶將代碼植入到提供給其它用戶使用的頁面中。如何攻擊要合理使用與為了省事兒，把應當提交的數(shù)據(jù)，做成請求。

XSS

XSS是一種經(jīng)常出現(xiàn)在web應用中的計算機安全漏洞，它允許惡意web用戶將代碼植入到提供給其它用戶使用的頁面中。 其實在web前端方面，可以簡單的理解為一種javascript代碼注入。舉個例子，我們有個社交網(wǎng)站，允許大家相互訪問空間，網(wǎng)站可能是這樣做的：

For example:


        
        
      

      
你輸入的內(nèi)容: {{{text}}}

submit點一下：

GG ~

如何防范?

目前來講，最簡單的辦法防治辦法，還是將前端輸出數(shù)據(jù)都進行轉義最為穩(wěn)妥。

比如，按照剛剛我們那個例子來說，其本質(zhì)是，瀏覽器遇到script標簽的話，則會執(zhí)行其中的腳本。但是如果我們將script標簽的進行轉義，則瀏覽器便不會認為其是一個標簽，但是顯示的時候，還是會按照正常的方式去顯示:

      

         
          
        

        
你輸入的內(nèi)容: {{text2}}

再試一下：

特殊情況？

大部分情況下，我們靠對 html 實體字符的轉義已經(jīng)能夠?qū)?XSS 風險控制在門外。但是一些特殊情況我們不得不進行非轉義字符串的輸出時，隱患就會再次出現(xiàn)。

后端數(shù)據(jù)直出

當我們需要后端直接將數(shù)據(jù)打印在 script 標簽中生成 js 變量的時候，我們通常不希望變量的值被轉義從而避免前端渲染的時候值被二次轉義的問題，所以我們的代碼會被輸出成:

  
    " };

試一下：

如何防范?

將特殊字符進行字符串轉義 比如 " " / 防止他們提前結束字符串、閉合 sciprt 標簽。后端使用 json.dump() 實現(xiàn)。js 的 JSON.stringify 不會做這些操作

將輸出變量字符進行 Unicode 編碼

將輸出變量字符進行 Hex 16進制編碼 編碼

    
      ",
        data1: "u003cu002fu0073u0063u0072u0069u0070u0074u003eu003cu0073u0063u0072u0069u0070u0074u003eu0061u006cu0065u0072u0074u0028u0030u0029u003cu002fu0073u0063u0072u0069u0070u0074u003e",
        data2: "x3cx2fx73x63x72x69x70x74x3ex3cx73x63x72x69x70x74x3ex61x6cx65x72x74x28x30x29x3cx2fx73x63x72x69x70x74x3e"
      };

再試一下：

轉義就萬無一失了？

naive ! 點個鏈接一秒中招！

點我

鏈接中如果存在 javacript: 開頭的協(xié)議，點擊鏈接時瀏覽器會執(zhí)行后面的代碼，這個時候光轉義是沒有用的，需要對 url 協(xié)議進行白名控制，只允許 http, https, http, mailto 等安全協(xié)議

包括圖片 src 屬性img src="{{xss}}", iframe iframe src="{{xss}}" 都會存在這樣的問題，都需要白名單處理。

處理方案總結

CSRF

CSRF（Cross-site request forgery跨站請求偽造，也被稱為“One Click Attack”或者Session Riding，通常縮寫為CSRF或者XSRF，是一種對網(wǎng)站的惡意利用。 其實就是網(wǎng)站中的一些提交行為，被黑客利用，你在訪問黑客的網(wǎng)站的時候，進行的操作，會被操作到其他網(wǎng)站上(如：你所使用的網(wǎng)絡銀行的網(wǎng)站)。

如何攻擊？

要合理使用post與get, 為了省事兒，把應當提交的數(shù)據(jù)，做成get請求。 殊不知，這不僅僅是違反了http的標準而已，也同樣會被黑客所利用。

比如，的網(wǎng)站中，有一個修改標題的操作使用的是 get 請求:

http://example.com/api?changetitle=CSRF

那么惡意攻擊者可以使用:

這樣的話，用戶只需要訪問一次黑客的網(wǎng)站，其實就相當于在你的網(wǎng)站中，操作了一次。然而用戶卻沒有感知。

csrf攻擊升級

如果你使用了post請求來處理關鍵業(yè)務，并且我們校驗了請求中的 cookie 是否包含了當前用戶的登錄狀態(tài)。是否就是萬無一失了呢。我們來看下面這個真實的例子。

docs 中創(chuàng)建文檔的 API 是 https://xxx.xxx/api/explorer/create/ 需求通過 post 請求，帶上 type 類型就可以創(chuàng)建一個新的文檔。

攻擊者在自己的網(wǎng)站中寫下以下代碼:

你當打開攻擊者網(wǎng)站，并且通過誘導你成功點擊按鈕的時候，你就成功的發(fā)起了一次創(chuàng)建文檔的請求。之前在我們的網(wǎng)站中就存在這樣的問題，現(xiàn)在已經(jīng)修復:

點擊一下:

為什么這種攻擊方法能生效？

瀏覽器表單發(fā)起 POST 的時候，會給這次請求自動帶上所請求域名的 cookie，這個 cookie 中保存著我們在源站中的登錄信息，（通常為 sessionid:123456qwertyu 這種)。

應對方法

每個 post 請求都帶上一個與前用戶 session 綁定的唯一 token，每次收到請求都去校驗這個 token 是否合法。

每個 post 請求都去校驗請求的 referer 是否來自于源站，否則就拒絕。但這種方法有弊端，因為瀏覽器可以設置 請求中不帶 referer，并且低端瀏覽器可以偽造 referer

現(xiàn)代瀏覽器可以通過設置 cookie 的 SameSite屬性，來防止跨域調(diào)用時帶上包含 sessionid 的 cookie set-cookie: xxx-session=4050e145-043a-4ed0-977a-47d88cd4bbc7; SameSite=Lax

目前我們的文檔 采用了 1、3兩種方法。

光說不練假把式，攻擊一個試試

你還別說，隨便一找，真找到一個網(wǎng)站，沒有校驗 csrf token，我們?nèi)ビ亚樵囂揭幌?/p>

嚴正聲明，我是保持學習的態(tài)度，去試一試這個網(wǎng)站是否存在漏洞，所以找了一個提交工單的功能，來測試我們的跨站請求是否執(zhí)行成功。請勿模仿

http://user.zhuolaoshi.com/m/...

為了防止裝逼失敗，先貼一張昨天實驗成功的截圖

攻擊一下：

攻擊成功。

一個被忽略了很久的漏洞 window.opener

帶有 target="_blank" 跳轉的網(wǎng)頁擁有了瀏覽器 window.opener 對象賦予的對原網(wǎng)頁的跳轉權限，這可能會被惡意網(wǎng)站利用，例如一個惡意網(wǎng)站在某 UGC 網(wǎng)站 Po 了其惡意網(wǎng)址，該 UGC 網(wǎng)站用戶在新窗口打開頁面時，惡意網(wǎng)站利用該漏洞將原 UGC 網(wǎng)站跳轉到偽造的釣魚頁面，用戶返回到原窗口時可能會忽視瀏覽器 URL 已發(fā)生了變化，偽造頁面即可進一步進行釣魚或其他惡意行為:

代碼如下

想象一下，你在瀏覽淘寶的時候，點擊了網(wǎng)頁聊天窗口的一條外鏈，出去看了一眼，回來之后淘寶網(wǎng)已經(jīng)變成了另一個域名的高仿網(wǎng)站，而你卻未曾發(fā)掘，繼續(xù)買東西把自己的錢直接打到騙子手里。

修復方法

為 target="_blank" 加上 rel="noopener noreferrer" 屬性。

外跳的地址

缺點: 應為禁止了跳轉帶上 referrer，目標網(wǎng)址沒辦法檢測來源地址。

還有一種方法是，所有的外部鏈接都替換為內(nèi)部的跳轉連接服務，點擊連接時，先跳到內(nèi)部地址，再由服務器 redirect 到外部網(wǎng)址。現(xiàn)在很多站點都是這么做的,不僅可以規(guī)避風險，還可以控制非法站點的打開

http://xxx.yyy.com
終。

文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/95542.html

相關文章

  • 離大廠近一點《阿里巴巴集團Web安全測試規(guī)范》獨家版

    摘要：今天，我們就離大廠更近一點，共同學習阿里這份阿里巴巴集團安全測試規(guī)范阿里巴巴集團安全測試規(guī)范阿里巴巴集團安全測試規(guī)范背景簡介為了規(guī)避安全風險規(guī)范代碼的安全開發(fā)，以及如何系統(tǒng)的進行安全性測試，目前缺少相應的理論和方法支撐。 很多人都知道，在學校學的技術，初創(chuàng)公司的技術，外包公司的技術，自研公司...

    wudengzan 評論0 收藏0

  • #WEB安全基礎 : HTML/CSS | 文章索引

    摘要：黑體本系列講解安全所需要的和黑體安全基礎我的第一個網(wǎng)頁黑體安全基礎初識黑體安全基礎初識標簽黑體安全基礎文件夾管理網(wǎng)站黑體安全基礎模塊化黑體安全基礎嵌套列表黑體安全基礎標簽拓展和屬性的使用黑體安全基礎嵌套本系列講解WEB安全所需要的HTML和CSS #WEB安全基礎 : HTML/CSS | 0x0 我的第一個網(wǎng)頁 #WEB安全基礎 : HTML/CSS | 0x1初識CSS #WEB安全基...

    EscapedDog 評論0 收藏0

  • UCloud 開啟負載均衡+WAF一鍵聯(lián)動，云原生能力賦能Web防護創(chuàng)新模式

    摘要：為使用七層負載均衡的用戶，提供安全高效的應用防護能力。基于負載均衡集群的運維能力，可快速進行擴容容災遷移的部署。伴隨著互聯(lián)網(wǎng)+時代的到來，Web系統(tǒng)作為企業(yè)IT業(yè)務的基本負載平臺，承載著各種不同種類的信息業(yè)務。但近年來針對Web應用的攻擊事件頻發(fā)，也讓Web應用的安全防御面臨著諸多挑戰(zhàn)。國家互聯(lián)網(wǎng)應急中心報告就曾顯示，僅2020上半年國家信息安全漏洞共享平臺（CNVD）收錄通用型安全漏洞11...

    Tecode 評論0 收藏0

  • 信息安全入門指南

    摘要：以下所列出的鏈接均為在線文檔，有志于信息安全的愛好者可由此作為入門指南。 以下所列出的鏈接均為在線文檔，有志于信息安全的愛好者可由此作為入門指南。 常規(guī)知識 Sun認證-Solaris 9&10安全管理員學習指南 PicoCTF資料 應用軟件安全 OWASP安全編碼規(guī)范 漏洞挖掘 Windows ISV軟件安全防御 移動安全 OWASP十大移動手機安全風險 網(wǎng)...

    jay_tian 評論0 收藏0

  • clojure的web安全比你想象的還要差

    摘要：的安全比你想象的還要差大會結束了，發(fā)表了題為的演說。宣稱，根據(jù)可供選擇的類庫來倒騰你自己的棧，這種思想方法導致了系統(tǒng)級的安全問題。對于而言，安全的會話管理只有非常少量的被證明過的最佳實踐。安全頭在應用程序，沒有集中的類庫來居中管理安全頭。 Clojure的web安全比你想象的還要差 ClojureWest大會結束了，Aaron Bedra發(fā)表了題為 Clojure.web/with-...

    opengps 評論0 收藏0

發(fā)表評論

0條評論

最新活動
閱讀需要支付1元查看
<