您當前位置: 南順網絡>> 官方資訊>> 建站知識

常見六大Web安全攻防解析

一、XSS

XSS (Cross-Site Scripting),跨站腳本攻擊,因為縮寫和 CSS重疊,所以只能叫 XSS??缯灸_本攻擊是指通過存在安全漏洞的Web網站注冊用戶的瀏覽器內運行非法的HTML標簽或JavaScript進行的一種攻擊。

跨站腳本攻擊有可能造成以下影響:

  • 利用虛假輸入表單騙取用戶個人信息。

  • 利用腳本竊取用戶的Cookie值,被害者在不知情的情況下,幫助攻擊者發送惡意請求。

  • 顯示偽造的文章或圖片。

XSS 的原理是惡意攻擊者往 Web 頁面里插入惡意可執行網頁腳本代碼,當用戶瀏覽該頁之時,嵌入其中 Web 里面的腳本代碼會被執行,從而可以達到攻擊者盜取用戶信息或其他侵犯用戶安全隱私的目的。

XSS 的攻擊方式千變萬化,但還是可以大致細分為幾種類型。

1.非持久型 XSS(反射型 XSS )

非持久型 XSS 漏洞,一般是通過給別人發送帶有惡意腳本代碼參數的 URL,當 URL 地址被打開時,特有的惡意代碼參數被 HTML 解析、執行。


非持久型 XSS 漏洞攻擊有以下幾點特征:

  • 即時性,不經過服務器存儲,直接通過 HTTP 的 GET 和 POST 請求就能完成一次攻擊,拿到用戶隱私數據。

  • 攻擊者需要誘騙點擊,必須要通過用戶點擊鏈接才能發起

  • 反饋率低,所以較難發現和響應修復

  • 盜取用戶敏感保密信息

為了防止出現非持久型 XSS 漏洞,需要確保這么幾件事情:

  • Web 頁面渲染的所有內容或者渲染的數據都必須來自于服務端。

  • 盡量不要從 URL,document.referrer,document.forms 等這種 DOM API 中獲取數據直接渲染。

  • 盡量不要使用 evalnew Function(),document.write(),document.writeln(),window.setInterval(),window.setTimeout(),innerHTML,document.createElement() 等可執行字符串的方法。

  • 如果做不到以上幾點,也必須對涉及 DOM 渲染的方法傳入的字符串參數做 escape 轉義。

  • 前端渲染的時候對任何的字段都需要做 escape 轉義編碼。

2.持久型 XSS(存儲型 XSS)

持久型 XSS 漏洞,一般存在于 Form 表單提交等交互功能,如文章留言,提交文本信息等,黑客利用的 XSS 漏洞,將內容經正常功能提交進入數據庫持久保存,當前端頁面獲得后端從數據庫中讀出的注入代碼時,恰好將其渲染執行。



舉個例子,對于評論功能來說,就得防范持久型 XSS 攻擊,因為我可以在評論中輸入以下內容



主要注入頁面方式和非持久型 XSS 漏洞類似,只不過持久型的不是來源于 URL,referer,forms 等,而是來源于后端從數據庫中讀出來的數據 。持久型 XSS 攻擊不需要誘騙點擊,黑客只需要在提交表單的地方完成注入即可,但是這種 XSS 攻擊的成本相對還是很高。

攻擊成功需要同時滿足以下幾個條件:

  • POST 請求提交表單后端沒做轉義直接入庫。

  • 后端從數據庫中取出數據沒做轉義直接輸出給前端。

  • 前端拿到后端數據沒做轉義直接渲染成 DOM。

持久型 XSS 有以下幾個特點:

  • 持久性,植入在數據庫中

  • 盜取用戶敏感私密信息

  • 危害面廣

3.如何防御

對于 XSS 攻擊來說,通常有兩種方式可以用來防御。

1) CSP

CSP 本質上就是建立白名單,明確告訴瀏覽器哪些外部資源可以加載和執行。我們只需要配置規則,如何攔截是由瀏覽器自己實現的。我們可以通過這種方式來盡量減少 XSS 攻擊。

通??梢酝ㄟ^兩種方式來開啟 CSP:

  • 設置 HTTP Header 中的 Content-Security-Policy

  • 設置 meta 標簽的方式

這里以設置 HTTP Header 來舉例:

  • 只允許加載本站資源

Content-Security-Policy: default-src 'self'
  • 只允許加載 HTTPS 協議圖片

Content-Security-Policy: img-src https://*
  • 允許加載任何來源框架

Content-Security-Policy: child-src 'none'

對于這種方式來說,只要配置了正確的規則,那么即使網站存在漏洞,攻擊者也不能執行它的攻擊代碼,并且 CSP 的兼容性也不錯。

2) 轉義字符

用戶的輸入永遠不可信任的,最普遍的做法就是轉義輸入輸出的內容,對于引號、尖括號、斜杠進行轉義

但是對于顯示富文本來說,顯然不能通過上面的辦法來轉義所有字符,因為這樣會把需要的格式也過濾掉。對于這種情況,通常采用白名單過濾的辦法,當然也可以通過黑名單過濾,但是考慮到需要過濾的標簽和標簽屬性實在太多,更加推薦使用白名單的方式。

3) HttpOnly Cookie。

這是預防XSS攻擊竊取用戶cookie最有效的防御手段。Web應用程序在設置cookie時,將其屬性設為HttpOnly,就可以避免該網頁的cookie被客戶端惡意JavaScript竊取,保護用戶cookie信息。

二、CSRF

CSRF(Cross Site Request Forgery),即跨站請求偽造,是一種常見的Web攻擊,它利用用戶已登錄的身份,在用戶毫不知情的情況下,以用戶的名義完成非法操作。

1.CSRF攻擊的原理

下面先介紹一下CSRF攻擊的原理:



完成 CSRF 攻擊必須要有三個條件:

  • 用戶已經登錄了站點 A,并在本地記錄了 cookie

  • 在用戶沒有登出站點 A 的情況下(也就是 cookie 生效的情況下),訪問了惡意攻擊者提供的引誘危險站點 B (B 站點要求訪問站點A)。

  • 站點 A 沒有做任何 CSRF 防御

我們來看一個例子: 當我們登入轉賬頁面后,突然眼前一亮驚現"XXX隱私照片,不看后悔一輩子"的鏈接,耐不住內心躁動,立馬點擊了該危險的網站(頁面代碼如下圖所示),但當這頁面一加載,便會執行submitForm這個方法來提交轉賬請求,從而將10塊轉給黑客。



2.如何防御

防范 CSRF 攻擊可以遵循以下幾種規則:

  • Get 請求不對數據進行修改

  • 不讓第三方網站訪問到用戶 Cookie

  • 阻止第三方網站請求接口

  • 請求時附帶驗證信息,比如驗證碼或者 Token

1) SameSite

可以對 Cookie 設置 SameSite 屬性。該屬性表示 Cookie 不隨著跨域請求發送,可以很大程度減少 CSRF 的攻擊,但是該屬性目前并不是所有瀏覽器都兼容。

2) Referer Check

HTTP Referer是header的一部分,當瀏覽器向web服務器發送請求時,一般會帶上Referer信息告訴服務器是從哪個頁面鏈接過來的,服務器籍此可以獲得一些信息用于處理??梢酝ㄟ^檢查請求的來源來防御CSRF攻擊。正常請求的referer具有一定規律,如在提交表單的referer必定是在該頁面發起的請求。所以通過檢查http包頭referer的值是不是這個頁面,來判斷是不是CSRF攻擊。

但在某些情況下如從https跳轉到http,瀏覽器處于安全考慮,不會發送referer,服務器就無法進行check了。若與該網站同域的其他網站有XSS漏洞,那么攻擊者可以在其他網站注入惡意腳本,受害者進入了此類同域的網址,也會遭受攻擊。出于以上原因,無法完全依賴Referer Check作為防御CSRF的主要手段。但是可以通過Referer Check來監控CSRF攻擊的發生。

3)  Anti CSRF Token

目前比較完善的解決方案是加入Anti-CSRF-Token。即發送請求時在HTTP 請求中以參數的形式加入一個隨機產生的token,并在服務器建立一個攔截器來驗證這個token。服務器讀取瀏覽器當前域cookie中這個token值,會進行校驗該請求當中的token和cookie當中的token值是否都存在且相等,才認為這是合法的請求。否則認為這次請求是違法的,拒絕該次服務。

這種方法相比Referer檢查要安全很多,token可以在用戶登陸后產生并放于session或cookie中,然后在每次請求時服務器把token從session或cookie中拿出,與本次請求中的token 進行比對。由于token的存在,攻擊者無法再構造出一個完整的URL實施CSRF攻擊。但在處理多個頁面共存問題時,當某個頁面消耗掉token后,其他頁面的表單保存的還是被消耗掉的那個token,其他頁面的表單提交時會出現token錯誤。

4) 驗證碼

應用程序和用戶進行交互過程中,特別是賬戶交易這種核心步驟,強制用戶輸入驗證碼,才能完成最終請求。在通常情況下,驗證碼夠很好地遏制CSRF攻擊。但增加驗證碼降低了用戶的體驗,網站不能給所有的操作都加上驗證碼。所以只能將驗證碼作為一種輔助手段,在關鍵業務點設置驗證碼。

三、點擊劫持

點擊劫持是一種視覺欺騙的攻擊手段。攻擊者將需要攻擊的網站通過 iframe 嵌套的方式嵌入自己的網頁中,并將 iframe 設置為透明,在頁面中透出一個按鈕誘導用戶點擊。

1. 特點

  • 隱蔽性較高,騙取用戶操作

  • "UI-覆蓋攻擊"

  • 利用iframe或者其它標簽的屬性

2. 點擊劫持的原理

用戶在登陸 A 網站的系統后,被攻擊者誘惑打開第三方網站,而第三方網站通過 iframe 引入了 A 網站的頁面內容,用戶在第三方網站中點擊某個按鈕(被裝飾的按鈕),實際上是點擊了 A 網站的按鈕。 接下來我們舉個例子:我在優酷發布了很多視頻,想讓更多的人關注它,就可以通過點擊劫持來實現

[object Object][object Object]


3. 如何防御

1)X-FRAME-OPTIONS

X-FRAME-OPTIONS是一個 HTTP 響應頭,在現代瀏覽器有一個很好的支持。這個 HTTP 響應頭 就是為了防御用 iframe 嵌套的點擊劫持攻擊。

該響應頭有三個值可選,分別是

  • DENY,表示頁面不允許通過 iframe 的方式展示

  • SAMEORIGIN,表示頁面可以在相同域名下通過 iframe 的方式展示

  • ALLOW-FROM,表示頁面可以在指定來源的 iframe 中展示

2)JavaScript 防御

對于某些遠古瀏覽器來說,并不能支持上面的這種方式,那我們只有通過 JS 的方式來防御點擊劫持了。

四、URL跳轉漏洞

定義:借助未驗證的URL跳轉,將應用程序引導到不安全的第三方區域,從而導致的安全問題。

1.URL跳轉漏洞原理

黑客利用URL跳轉漏洞來誘導安全意識低的用戶點擊,導致用戶信息泄露或者資金的流失。其原理是黑客構建惡意鏈接(鏈接需要進行偽裝,盡可能迷惑),發在QQ群或者是瀏覽量多的貼吧/論壇中。 安全意識低的用戶點擊后,經過服務器或者瀏覽器解析后,跳到惡意的網站中。


惡意鏈接需要進行偽裝,經常的做法是熟悉的鏈接后面加上一個惡意的網址,這樣才迷惑用戶。


  • Header頭跳轉

  • Javascript跳轉

  • META標簽跳轉

這里我們舉個Header頭跳轉實現方式:

<?php $url=$_GET['jumpto']; header("Location: $url"); ?>
http://www.***.org/login.php?jumpto=http://www.***.com

這里用戶會認為www.****.org都是可信的,但是點擊上述鏈接將導致用戶最終訪問www.****.com這個惡意網址。

3.如何防御

1)referer的限制

如果確定傳遞URL參數進入的來源,我們可以通過該方式實現安全限制,保證該URL的有效性,避免惡意用戶自己生成跳轉鏈接

2)加入有效性驗證Token

我們保證所有生成的鏈接都是來自于我們可信域的,通過在生成的鏈接里加入用戶不可控的Token對生成的鏈接進行校驗,可以避免用戶生成自己的惡意鏈接從而被利用,但是如果功能本身要求比較開放,可能導致有一定的限制。

五、SQL注入

SQL注入是一種常見的Web安全漏洞,攻擊者利用這個漏洞,可以訪問或修改數據,或者利用潛在的數據庫漏洞進行攻擊。

1.SQL注入的原理

我們先舉一個鑰匙的例子來說明其原理:



這是我們經常見到的登錄頁面,但如果有一個惡意攻擊者輸入的用戶名是 admin' --,密碼隨意輸入,就可以直接登入系統了。why! ----這就是SQL注入

我們之前預想的SQL 語句是:

SELECT * FROM user WHERE username='admin' AND psw='password'

但是惡意攻擊者用奇怪用戶名將你的 SQL 語句變成了如下形式:

SELECT * FROM user WHERE username='admin' --' AND psw='xxxx'

在 SQL 中,' --是閉合和注釋的意思,-- 是注釋后面的內容的意思,所以查詢語句就變成了:

SELECT * FROM user WHERE username='admin' 復制代碼

所謂的密碼,本質上就是SQL注入的一種利用方式。

一次SQL注入的過程包括以下幾個過程:

  • 獲取用戶請求參數

  • 拼接到代碼當中

  • SQL語句按照我們構造參數的語義執行成功

SQL注入的必備條件: 1.可以控制輸入的數據 2.服務器要執行的代碼拼接了控制的數據。

我們會發現SQL注入流程中與正常請求服務器類似,只是黑客控制了數據,構造了SQL查詢,而正常的請求不會SQL查詢這一步,SQL注入的本質:數據和代碼未分離,即數據當做了代碼來執行。


2.危害

  • 獲取數據庫信息

    • 管理員后臺用戶名和密碼

    • 獲取其他數據庫敏感信息:用戶名、密碼、手機號碼、身份證、銀行卡信息……

    • 整個數據庫:脫褲

  • 獲取服務器權限

  • 植入Webshell,獲取服務器后門

  • 讀取服務器敏感文件

3.如何防御

  • 嚴格限制Web應用的數據庫的操作權限,給此用戶提供僅僅能夠滿足其工作的權限,從而限度的減少注入攻擊對數據庫的危害

  • 后端代碼檢查輸入的數據是否符合預期,嚴格限制變量的類型,例如使用正則表達式進行一些匹配處理。

  • 對進入數據庫的特殊字符(',",\,<,>,&,*,; 等)進行轉義處理,或編碼轉換?;旧纤械暮蠖苏Z言都有對字符串進行轉義處理的方法,比如 lodash 的 lodash._escapehtmlchar 庫。

  • 所有的查詢語句建議使用數據庫提供的參數化查詢接口,參數化的語句使用參數而不是將用戶輸入變量嵌入到 SQL 語句中,即不要直接拼接 SQL 語句。例如 Node.js 中的 mysqljs 庫的 query 方法中的 ? 占位參數。

六、OS命令注入攻擊

OS命令注入和SQL注入差不多,只不過SQL注入是針對數據庫的,而OS命令注入是針對操作系統的。OS命令注入攻擊指通過Web應用,執行非法的操作系統命令達到攻擊的目的。只要在能調用Shell函數的地方就有存在被攻擊的風險。倘若調用Shell時存在疏漏,就可以執行插入的非法命令。

命令注入攻擊可以向Shell發送命令,讓Windows或Linux操作系統的命令行啟動程序。也就是說,通過命令注入攻擊可執行操作系統上安裝著的各種程序。

1.原理


黑客構造命令提交給web應用程序,web應用程序提取黑客構造的命令,拼接到被執行的命令中,因黑客注入的命令打破了原有命令結構,導致web應用執行了額外的命令,web應用程序將執行的結果輸出到響應頁面中。


2.如何防御

  • 后端對前端提交內容進行規則限制(比如正則表達式)。

  • 在調用系統命令前對所有傳入參數進行命令行參數轉義過濾。




編輯:--ns868