-
攻擊現象查看全部
-
代碼攻擊查看全部
-
4中攻擊方式查看全部
-
xss:非法javascript, 使用lexer過濾; csrf: 盜用身份偽造非法請求，使用token; sql注入： 構造非法sql, 使用PDO及占位符； 文件上傳： 上傳非法文件并執行，嚴格過濾及重命名等查看全部
-
保存上傳過來的文件名的時候不要用用戶本來的名稱,容易在中途被非法修改,從而變成.php這些可執行文件,造成損害查看全部
-
同理,可以用fiddler進行type的偽造等查看全部
-
用fiddler可以攔截請求,然后修改請求的內容,比如圖片中的文件名,修改成如上形式后,會生成一個php文件,然后在上傳后的目錄執行php文件會造成危害查看全部
-
$_FILES['xxx]['type']代表的意思查看全部
-
獲取拓展名的代碼...查看全部
-
進行敏感詞過濾,會使部分關鍵字用戶需要的過濾掉,不靠譜,而使用addslashes函數的話還是不靠譜,不同字符集對不同特殊輸入的時候可能沒有辦法完全正確轉義,也不靠譜查看全部
-
最后一段sql會使mysql執行select * from aticles,因為or其中一個條件成立了查看全部
-
注釋符"--",需要一個空格,應該是"-- ". mysql注釋符有三種： 1、#... 2、"-- ..." 3、/*...*/查看全部
-
防御措施: 檢查Referer字段 HTTP頭中有一個Referer字段，這個字段用以標明請求來源于哪個地址。在處理敏感數據請求時，通常來說，Referer字段應和請求的地址位于同一域名下。以上文銀行操作為例，Referer字段地址通常應該是轉賬按鈕所在的網頁地址，應該也位于www.examplebank.com之下。而如果是CSRF攻擊傳來的請求，Referer字段會是包含惡意網址的地址，不會位于www.examplebank.com之下，這時候服務器就能識別出惡意的訪問。 這種辦法簡單易行，工作量低，僅需要在關鍵訪問處增加一步校驗。但這種辦法也有其局限性，因其完全依賴瀏覽器發送正確的Referer字段。雖然http協議對此字段的內容有明確的規定，但并無法保證來訪的瀏覽器的具體實現，亦無法保證瀏覽器沒有安全漏洞影響到此字段。并且也存在攻擊者攻擊某些瀏覽器，篡改其Referer字段的可能。 添加校驗token 由于CSRF的本質在于攻擊者欺騙用戶去訪問自己設置的地址，所以如果要求在訪問敏感數據請求時，要求用戶瀏覽器提供不保存在cookie中，并且攻擊者無法偽造的數據作為校驗，那么攻擊者就無法再執行CSRF攻擊。這種數據通常是表單中的一個數據項。服務器將其生成并附加在表單中，其內容是一個偽亂數。當客戶端通過表單提交請求時，這個偽亂數也一并提交上去以供校驗。正常的訪問時，客戶端瀏覽器能夠正確得到并傳回這個偽亂數，而通過CSRF傳來的欺騙性攻擊中，攻擊者無從事先得知這個偽亂數的值，服務器端就會因為校驗token的值為空或者錯誤，拒絕這個可疑請求。查看全部
-
制造csrf攻擊的簡單例子查看全部
-
例子: 假如一家銀行用以執行轉賬操作的URL地址如下： http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName 那么，一個惡意攻擊者可以在另一個網站上放置如下代碼： <img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman"> 如果有賬戶名為Alice的用戶訪問了惡意站點，而她之前剛訪問過銀行不久，登錄信息尚未過期，那么她就會損失1000資金。 這種惡意的網址可以有很多種形式，藏身于網頁中的許多地方。此外，攻擊者也不需要控制放置惡意網址的網站。例如他可以將這種地址藏在論壇，博客等任何用戶生成內容的網站中。這意味著如果服務器端沒有合適的防御措施的話，用戶即使訪問熟悉的可信網站也有受攻擊的危險。 透過例子能夠看出，攻擊者并不能通過CSRF攻擊來直接獲取用戶的賬戶控制權，也不能直接竊取用戶的任何信息。他們能做到的，是欺騙用戶瀏覽器，讓其以用戶的名義執行操作。查看全部
舉報
0/150
提交
取消