詳解WEB攻擊之CSRF攻擊與防護_安全相關

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

1、DoS和DDoS攻擊(DoS(Denial of Service),即拒絕服務,造成遠程服務器拒絕服務的行為被稱為DoS攻擊。其目的是使計算機或網絡無法提供正常的服務。最常見的DoS攻擊有計算機網絡帶寬攻擊和連通性攻擊)防范:(1)反欺騙:對數據包的地址及端口的正確性進行驗證,同時進行反向探測。(2)協議棧行為模式分析:每個數據包類型需要符合RFC規定,這就好像每個數據包都要有完整規范的著裝,只要不符合規范,就自動識別并將其過濾掉。(3)特定應用防護:非法流量總是有一些特定特征的,這就好比即便你混進了顧客群中,但你的行為還是會暴露出你的動機,比如老重復問店員同一個問題,老做同樣的動作,這樣你仍然還是會被發現的。(4)帶寬控制:真實的訪問數據過大時,可以限制其最大輸出的流量,以減少下游網絡系統的壓力。2、CSRF(Cross Site Request Forgery),即跨站請求偽造,是一種常見的Web攻擊,但很多開發者對它很陌生。CSRF也是Web安全中最容易被忽略的一種攻擊。防范:(1)驗證碼。應用程序和用戶進行交互過程中,特別是賬戶交易這種核心步驟,強制用戶輸入驗證碼,才能完成最終請求。在通常情況下,驗證碼夠很好地遏制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錯誤。3、XSS(Cross Site Scripting),跨站腳本攻擊。為和層疊樣式表(Cascading Style Sheets,CSS)區分開,跨站腳本在安全領域叫做“XSS”。防范:(1)輸入過濾。永遠不要相信用戶的輸入,對用戶輸入的數據做一定的過濾。如輸入的數據是否符合預期的格式,比如日期格式,Email格式,電話號碼格式等等。這樣可以初步對XSS漏洞進行防御。上面的措施只在web端做了限制,攻擊者通抓包工具如Fiddler還是可以繞過前端輸入的限制,修改請求注入攻擊腳本。因此,后臺服務器需要在接收到用戶輸入的數據后,對特殊危險字符進行過濾或者轉義處理,然后再存儲到數據庫中。(2)輸出編碼。服務器端輸出到瀏覽器的數據,可以使用系統的安全函數來進行編碼或轉義來防范XSS攻擊。在PHP中,有htmlentities()和htmlspecialchars()兩個函數可以滿足安全要求。相應的JavaScript的編碼方式可以使用JavascriptEncode。(3)安全編碼。開發需盡量避免Web客戶端文檔重寫、重定向或其他敏感操作,同時要避免使用客戶端數據,這些操作需盡量在服務器端使用動態頁面來實現。(4)HttpOnly Cookie。預防XSS攻擊竊取用戶cookie最有效的防御手段。Web應用程序在設置cookie時,將其屬性設為HttpOnly,就可以避免該網頁的cookie被客戶端惡意JavaScript竊取,保護用戶cookie信息。(5)WAF(Web Application Firewall),Web應用防火墻,主要的功能是防范諸如網頁木馬、XSS以及CSRF等常見的Web漏洞攻擊。由第三方公司開發,在企業環境中深受歡迎。4、SQL注入(SQL Injection),應用程序在向后臺數據庫傳遞SQL(Structured Query Language,結構化查詢語言)時,攻擊者將SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串,最終達到欺騙服務器執行惡意的SQL命令。防范:(1)防止系統敏感信息泄露。設置php.ini選項display_errors=off,防止php腳本出錯之后,在web頁面輸出敏感信息錯誤,讓攻擊者有機可乘。(2)數據轉義。設置php.ini選項magic_quotes_gpc=on,它會將提交的變量中所有的’(單引號),”(雙引號),\\(反斜杠),空白字符等都在前面自動加上\\。或者采用mysql_real_escape()函數或addslashes()函數進行輸入參數的轉義。(3)增加黑名單或者白名單驗證。白名單驗證一般指,檢查用戶輸入是否是符合預期的類型、長度、數值范圍或者其他格式標準。黑名單驗證是指,若在用戶輸入中,包含明顯的惡意內容則拒絕該條用戶請求。在使用白名單驗證時,一般會配合黑名單驗證。5、上傳漏洞在DVBBS6.0時代被黑客們利用的最為猖獗,利用上傳漏洞可以直接得到WEBSHELL,危害等級超級高,現在的入侵中上傳漏洞也是常見的漏洞。該漏洞允許用戶上傳任意文件可能會讓攻擊者注入危險內容或惡意代碼,并在服務器上運行。防范:(1)檢查服務器是否判斷了上傳文件類型及后綴。(2)定義上傳文件類型白名單,即只允許白名單里面類型的文件上傳。(3)文件上傳目錄禁止執行腳本解析,避免攻擊者進行二次攻擊。Info漏洞 Info漏洞就是CGI把輸入的參數原樣輸出到頁面,攻擊者通過修改輸入參數而達到欺騙用戶的目的www.13333515.buzz防采集請勿采集本網。

CSRF 背景與介紹

在Web應用程序側防御CSRF漏洞,一般都是利用referer、token或者驗證碼,Nexus 的文章[7]已經寫的很全面了;superhei也有提出bypass的思路[8],請參考他們的文章。還有一個思路是在客戶端防御,貌似可以做

CSRF定義: 跨站請求偽造(英語:Cross-site request forgery),也被稱為 one-click attack 或者 session riding,通常縮寫為 CSRF 或者 XSRF, 是一種挾制用戶在當前已登錄的Web應用程序上執行非本意的操作的攻擊方法。

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

簡單地說,是攻擊者通過一些技術手段欺騙用戶的瀏覽器去訪問一個自己曾經認證過的網站并執行一些操作(如發郵件,發消息,甚至財產操作如轉賬和購買商品)。由于瀏覽器曾經認證過,所以被訪問的網站會認為是真正的用戶操作而去執行。這利用了web中用戶身份驗證的一個漏洞:簡單的身份驗證只能保證請求發自某個用戶的瀏覽器,卻不能保證請求本身是用戶自愿發出的。

常見的web攻擊有滲透攻擊和SYN Flood、UDP Flood、ICMP Flood、TCP Flood以及CC在內的多種DDoS攻擊

CSRF地位:是一種網絡攻擊方式,是互聯網重大安全隱患之一,NYTimes.com(紐約時報)、Metafilter,YouTube、Gmail和百度HI都受到過此類攻擊。

CSRF攻擊是指惡意網站,電子郵件或程序導致用戶的瀏覽器在用戶當前已對其進行身份驗證的受信任站點上執行不需要的操作時發生的攻擊。4、無法限制URL訪問 Web應用程序在呈現受保護的鏈接和按鈕之前檢查URL

對比XSS:跟跨網站腳本(XSS)相比,XSS 利用的是用戶對指定網站的信任,CSRF 利用的是網站對用戶網頁瀏覽器的信任。

通過XSS可以比較容易地修改用戶數據、竊取用戶信息,以及造成其它類型的攻擊,例如CSRF攻擊 常見解決辦法:確保輸出到HTML頁面的數據以HTML的方式被轉義 二.跨站請求偽造攻擊(CSRF) 跨站請求偽造(CSRF,

CSRF 攻擊實例

daguanren(大官人)在銀行有一筆存款,輸入用戶名密碼登錄銀行網銀后發送請求進行個人名下賬戶轉賬 :

http://www.bank.example/withdraw?account=daguanren1&amount=999&for=daguanren2

將daguanren1中的999塊轉到了daguanren2賬號中。通常用戶登錄后,系統會保存用戶登錄的session值(可能是用戶手機號、賬號等)。但如果這時daguanren不小心新開一個tab頁面進入了一個黑客jinlian(金蓮)的網站,而金蓮網站的頁面中嵌有如下html標簽:

<!DOCTYPE html><html> <!--其他頁面元素--> <img src=http://www.bank.example/withdraw?account=daguanren1&amount=888&for=jinlian width='0' height='0'> <!--其他頁面元素--></html>

這個請求就會附帶上daguanren的session值,成功將大官人的888元轉至jinlian的賬戶上。但如果daguanren之前沒有登錄網銀,而是直接打開jinlian的網站,則由于沒有session值,不會被攻擊。以上示例雖然是get請求,post請求提交的表單同樣會被攻擊。

<iframe style="display:none" name="csrf-frame"></iframe><form method='POST' action='http://www.bank.example/withdraw' target="csrf-frame" id="csrf-form"> <input type='hidden' name='account' value='daguanren1'> <input type='hidden' name='amount' value='888'> <input type='hidden' name='for' value='jinlian'> <input type='submit' value='submit'></form><script>document.getElementById("csrf-form").submit()</script>

 

所以要被CSRF攻擊,必須同時滿足兩個條件:

1.登錄受信任網站A,并在本地生成Cookie。

2.在不登出A的情況下,訪問危險網站B。

CSRF 攻擊的對象

在討論如何抵御 CSRF 之前,先要明確 CSRF 攻擊的對象,也就是要保護的對象。從以上的例子可知,CSRF 攻擊是黑客借助受害者的 cookie(session) 騙取服務器的信任,但是黑客并不能拿到 cookie,也看不到 cookie 的內容。另外,對于服務器返回的結果,由于瀏覽器同源策略的限制,黑客也無法進行解析。因此,黑客無法從返回的結果中得到任何東西,他所能做的就是給服務器發送請求,以執行請求中所描述的命令,在服務器端直接改變數據的值,而非竊取服務器中的數據。所以,我們要保護的對象是那些可以直接產生數據改變的服務,而對于讀取數據的服務,則不需要進行 CSRF 的保護。比如銀行系統中轉賬的請求會直接改變賬戶的金額,會遭到 CSRF 攻擊,需要保護。而查詢余額是對金額的讀取操作,不會改變數據,CSRF 攻擊無法解析服務器返回的結果,無需保護。

故:增刪改需要防范CSRF攻擊,而讀無需防范。

當前防御 CSRF 的幾種策略

在業界目前防御 CSRF 攻擊主要有四種策略:

- 驗證 HTTP Referer 字段;

- 在請求地址中添加 token 并驗證;

- 在 HTTP 頭中自定義屬性并驗證;

- Chrome瀏覽器端啟用SameSite cookie

1、驗證 HTTP Referer 字段

什么是HTTP Referer?下面GIF圖是由百度跳轉到QQ郵箱頁面的Referer查看示意:

 

可以看出Referer為

Referer:https://www.baidu.com/

根據 HTTP 協議,在 HTTP 頭(request 的 header)中有一個字段叫 Referer,它記錄了該 HTTP 請求的來源地址。如果黑客要對銀行網站實施 CSRF 攻擊,當用戶通過黑客的網站發送請求到銀行時,該請求的 Referer 值是指向黑客的網站而不是用戶的網站。因此,要防御 CSRF 攻擊,銀行網站只需要對于每一個轉賬請求驗證其 Referer 值,如果是以 www.bank.example開頭的域名,則說明該請求是來自銀行網站自己的請求,是合法的。如果 Referer 是其他網站的話,則有可能是黑客的 CSRF 攻擊,拒絕該請求。

這種方法的顯而易見的好處就是簡單易行,網站的普通開發人員不需要操心 CSRF 的漏洞,只需要在最后給所有安全敏感的請求統一增加一個攔截器來檢查 Referer 的值就可以。特別是對于當前現有的系統,不需要改變當前系統的任何已有代碼和邏輯。

然而,這種方法并非萬無一失。Referer 的值是由瀏覽器提供的,雖然 HTTP 協議上有明確的要求,但是每個瀏覽器對于 Referer 的具體實現可能有差別,并不能保證瀏覽器自身沒有安全漏洞。使用驗證 Referer 值的方法,就是把安全性都依賴于第三方(即瀏覽器)來保障,從理論上來講,這樣并不安全。事實上,對于某些瀏覽器,比如 IE6 或 FF2,目前已經有一些方法可以篡改 Referer 值。如果 www.bank.example網站支持 IE6 瀏覽器,黑客完全可以把用戶瀏覽器的 Referer 值設為以 www.bank.example域名開頭的地址,這樣就可以通過驗證,從而進行 CSRF 攻擊。

即便是使用最新的瀏覽器,黑客無法篡改 Referer 值,這種方法仍然有問題。因為 Referer 值會記錄下用戶的訪問來源,有些用戶認為這樣會侵犯到他們自己的隱私權,特別是有些組織擔心 Referer 值會把組織內網中的某些信息泄露到外網中。因此,用戶自己可以設置瀏覽器使其在發送請求時不再提供 Referer。當他們正常訪問銀行網站時,網站會因為請求沒有 Referer 值而認為是 CSRF 攻擊,拒絕合法用戶的訪問。

另外,如果Referer的判斷邏輯寫的不嚴密的話,也容易被攻破,例如

const referer = request.headers.referer;if (referer.indexOf('www.bank.example') > -1) { // pass}

如果黑客的網站是www.bank.example.hack.com,則referer檢查無效。

2、在請求地址中添加 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 本身的安全。特別是在一些論壇之類支持用戶自己發表內容的網站,黑客可以在上面發布自己個人網站的地址。由于系統也會在這個地址后面加上 token,黑客可以在自己的網站上得到這個 token,并馬上就可以發動 CSRF 攻擊。為了避免這一點,系統可以在添加 token 的時候增加一個判斷,如果這個鏈接是鏈到自己本站的,就在后面添加 token,如果是通向外網則不加。不過,即使這個 csrftoken 不以參數的形式附加在請求之中,黑客的網站也同樣可以通過 Referer 來得到這個 token 值以發動 CSRF 攻擊。這也是一些用戶喜歡手動關閉瀏覽器 Referer 功能的原因。

3、在 HTTP 頭中自定義屬性并驗證

這種方法也是使用 token 并進行驗證,和上一種方法不同的是,這里并不是把 token 以參數的形式置于 HTTP 請求之中,而是把它放到 HTTP 頭中自定義的屬性里。通過 XMLHttpRequest 這個類,可以一次性給所有該類請求加上 csrftoken 這個 HTTP 頭屬性,并把 token 值放入其中。這樣解決了上種方法在請求中加入 token 的不便,同時,通過 XMLHttpRequest 請求的地址不會被記錄到瀏覽器的地址欄,也不用擔心 token 會透過 Referer 泄露到其他網站中去。

然而這種方法的局限性非常大。XMLHttpRequest 請求通常用于 Ajax 方法中對于頁面局部的異步刷新,并非所有的請求都適合用這個類來發起,而且通過該類請求得到的頁面不能被瀏覽器所記錄下,從而進行前進,后退,刷新,收藏等操作,給用戶帶來不便。另外,對于沒有進行 CSRF 防護的遺留系統來說,要采用這種方法來進行防護,要把所有請求都改為 XMLHttpRequest 請求,這樣幾乎是要重寫整個網站,這代價無疑是不能接受的。

4、Chrome瀏覽器端啟用SameSite cookie

下面介紹如何啟用SameSite cookie的設置,很簡單。

原本的 Cookie 的 header 設置是長這樣:

Set-Cookie: session_id=esadfas325

需要在尾部增加 SameSite 就好:

Set-Cookie: session_id=esdfas32e5; SameSite

SameSite 有兩種模式,Lax跟Strict模式,默認啟用Strict模式,可以自己指定模式:

Set-Cookie: session_id=esdfas32e5; SameSite=StrictSet-Cookie: foo=bar; SameSite=Lax

Strict模式規定 cookie 只允許相同的site使用,不應該在任何的 cross site request 被加上去。即a標簽、form表單和XMLHttpRequest提交的內容,只要是提交到不同的site去,就不會帶上cookie。

但也存在不便,例如朋友發送過來我已經登陸過的一個頁面鏈接,我點開后,該頁面仍然需要重新登錄。

有兩種處理辦法,第一種是與Amazon一樣,準備兩組不同的cookie,第一組用于維持登錄狀態不設定SameSite,第二組針對的是一些敏感操作會用到(例如購買、支付、設定賬戶等)嚴格設定SameSite。

基于這個思路,就產生了 SameSite 的另一一種模式:Lax模式。

Lax 模式打開了一些限制,例如

<a><link rel="prerender"><form method="GET">

這些都會帶上cookie。但是 POST 方法 的 form,或是只要是 POST, PUT, DELETE 這些方法,就不會帶cookie。

但一定注意將重要的請求方式改成POST,否則GET仍然會被攻擊。

PS:該方式目前僅Chrome支持。

后記

方式1通過驗證HTTP Referer頭信息來防止跨站請求偽造csrf,在java中可以通過filter來實現。方式2和方式3都是通過在請求中添加token來進行安全校驗的,spring security 提供的csrf防護就是采用這樣的方式,而且從spring security 4.0開始csrf防護是默認開啟的。對于一個新項目,可以幾種方式都用上,這樣更加安全。如果是一個已經完備的web程序,還是使用方式1修改起來方便,不然每個請求都加上csrfToken改動很大。關于spring security csrf可參考我的博文:http://www.13333515.buzz/article/157547.htm

SQL注入攻擊是注入攻擊最常見的形式(此外還有OS注入攻擊(Struts2的高危漏洞就是通過OGNL實施OS注入攻擊導致的)),當服務器使用請求參數構造SQL語句時,惡意的SQL被嵌入到SQL中交給數據庫執行。SQL注入攻擊需要攻擊者對數據庫結構有所了解才能進行,攻擊者想要獲得表結構有多種方式:(1)如果使用開源系統搭建網站,數據庫結構也是公開的(目前有很多現成的系統可以直接搭建論壇,電商網站,雖然方便快捷但是風險是必須要認真評估的);(2)錯誤回顯(如果將服務器的錯誤信息直接顯示在頁面上,攻擊者可以通過非法參數引發頁面錯誤從而通過錯誤信息了解數據庫結構,Web應用應當設置友好的錯誤頁,一方面符合最小驚訝原則,一方面屏蔽掉可能給系統帶來危險的錯誤回顯信息);(3)盲注。防范SQL注入攻擊也可以采用消毒的方式,通過正則表達式對請求參數進行驗證,此外,參數綁定也是很好的手段,這樣惡意的SQL會被當做SQL的參數而不是命令被執行,JDBC中的PreparedStatement就是支持參數綁定的語句對象,從性能和安全性上都明顯優于Statement。CSRF攻擊(Cross Site RequestForgery,跨站請求偽造)是攻擊者通過跨站請求,以合法的用戶身份進行非法操作(如轉賬或發帖等)。CSRF的原理是利用瀏覽器的Cookie或服務器的Session,盜取用戶身份,其原理如下圖所示。防范CSRF的主要手段是識別請求者的身份,主要有以下幾種方式:(1)在表單中添加令牌(token);(2)驗證碼;(3)檢查請求頭中的Referer(前面提到防圖片盜鏈接也是用的這種方式)。令牌和驗證都具有一次消費性的特征,因此在原理上一致的,但是驗證碼是一種糟糕的用戶體驗,不是必要的情況下不要輕易使用驗證碼,目前很多網站的做法是如果在短時間內多次提交一個表單未獲得成功后才要求提供驗證碼,這樣會獲得較好的用戶體驗內容來自www.13333515.buzz請勿采集。


  • 本文相關:
  • 使用springsecurity處理csrf攻擊的方法步驟
  • 詳解利用django中間件django.middleware.csrf.csrfviewmiddleware防止csrf攻擊
  • flask模擬實現csrf攻擊的方法
  • 詳解如何在spring boot中使用spring security防止csrf攻擊
  • 淺談asp.net mvc 防止跨站請求偽造(csrf)攻擊的實現方法
  • php開發中csrf攻擊的簡單演示和防范
  • yii框架防止sql注入,xss攻擊與csrf攻擊的方法
  • 切記ajax中要帶上antiforgerytoken防止csrf攻擊
  • discuz許愿池插件遠程包含漏洞
  • adsl入侵的防范
  • 阿d常用的一些注入命令整理小結
  • js和c#分別防注入代碼
  • 當菜鳥遇上黒客之二:端口掃描
  • 四個步驟加強網絡防護
  • 全力打造個人網絡安全之xp篇
  • 如何成為一名黑客全系列說明
  • 黑客攻擊方式的四種最新趨勢
  • 入侵oracle數據庫的一些技巧
  • sql攻擊和csrf攻擊的區別
  • web攻擊有哪些?怎么防護?
  • 常見的幾種web攻擊方式及原理
  • csrf攻擊能做哪些事情
  • 如何防止CSRF注入式攻擊
  • csrf的具體含義
  • 常見的web攻擊是什么?
  • Web應用常見的安全漏洞有哪些?
  • 網站被攻擊有哪些方式,對應的表現是什么樣的,詳細有加分
  • html form without csrf protection什么問題
  • 網站首頁網頁制作腳本下載服務器操作系統網站運營平面設計媒體動畫電腦基礎硬件教程網絡安全javascriptasp.netphp編程ajax相關正則表達式asp編程jsp編程編程10000問css/htmlflex腳本加解密web2.0xml/rss網頁編輯器相關技巧安全相關網頁播放器其它綜合dart首頁安全相關使用springsecurity處理csrf攻擊的方法步驟詳解利用django中間件django.middleware.csrf.csrfviewmiddleware防止csrf攻擊flask模擬實現csrf攻擊的方法詳解如何在spring boot中使用spring security防止csrf攻擊淺談asp.net mvc 防止跨站請求偽造(csrf)攻擊的實現方法php開發中csrf攻擊的簡單演示和防范yii框架防止sql注入,xss攻擊與csrf攻擊的方法切記ajax中要帶上antiforgerytoken防止csrf攻擊discuz許愿池插件遠程包含漏洞adsl入侵的防范阿d常用的一些注入命令整理小結js和c#分別防注入代碼當菜鳥遇上黒客之二:端口掃描四個步驟加強網絡防護全力打造個人網絡安全之xp篇如何成為一名黑客全系列說明黑客攻擊方式的四種最新趨勢入侵oracle數據庫的一些技巧看別人怎么查qq聊天記錄 比較詳細怎么查qq聊天記錄 怎樣恢復刪除的qq聊天記錄刪除了怎么恢復簡單方密碼破解全教程跨站式腳本(cross-sitescripting攻擊方式學習之sql注入(sql inje如何成為一名黑客全系列說明js和c#分別防注入代碼防止電腦被他人控制跨站腳本攻擊xss(cross site sc七個絕招應對網上銀行盜賊揭開面紗看看黑客用哪些工具(2)qq聊天記錄刪除了怎么恢復簡單方法查找與清除線程插入式木馬怎么查qq聊天記錄 怎樣恢復刪除的手機qq聊asp漏洞全接觸-入門篇黑客避開檢測的手段如何突破各種防火墻的防護超初級的linux后門制作方法irc后門病毒及手動清除方法
    免責聲明 - 關于我們 - 聯系我們 - 廣告聯系 - 友情鏈接 - 幫助中心 - 頻道導航
    Copyright © 2017 www.13333515.buzz All Rights Reserved
    3排列五开奖结果