Web中常見的攻擊方式

Web常見的攻擊方式

按照攻擊頻率佔比排序:php

跨站腳本XSS攻擊
SQL注入
DOS攻擊
跨站僞造CSRF
釣魚網站

DOS攻擊

名爲：Denial-of-service attackhtml

原理：攻擊者會發送大量的請求，或者模擬大量合法用戶的訪問，佔用服務器資源直至耗盡，致使真正有需求的用戶沒法訪問此網站。前端

好比18年，阮一峯的網站被DDOS攻擊。vue

釣魚網站

用戶經過搜索引擎或者跳轉連接進入仿冒的網站（UI、域名和正版網站很類似），用戶在仿冒網站中輸入了用戶名和密碼，致使帳戶信息泄漏。sql

SQL注入

SQL注入是一種代碼注入的技術，攻擊者能夠將惡意SQL語句插入到輸入字段中執行。數據庫

場景舉例：後端

有這樣一個功能：網站前端有一個查詢輸入框，當輸入用戶的姓名時，查詢並展現擁有該姓名的全部用戶。當後端接收到查詢參數戶，作sql語句的拼接，而後執行sql，返回查詢結果。瀏覽器

let username = req.body.username
let sql = "SELECT * FROM users WHERE name ='+ username +'";
exec(sql)
複製代碼

當用戶輸入的查詢參數若是是這樣的字符時:安全

a';DROP TABLE users;SELECT * FROM userinfo WHERE 't' ='t
複製代碼

則在服務器查詢時至關於執行了：服務器

let sql = "SELECT * FROM users WHERE name = 'a';DROP TABLE users;SELECT * FROM userinfo WHERE 't' ='t'";
複製代碼

這樣的結果會致使一次查詢就能刪除用戶庫，固然也能作其餘任何數據庫的操做。

應對措施：

方法1：使用ORM庫，調用API，而不是直接運行SQL語句
方法2：在運行SQL語句前對拼接的查詢字段進行轉義

XSS（跨站腳本攻擊）

Cross-site scripting。縮寫成CSS與層疊樣式表縮寫的CSS容易混淆，故改稱XSS。

因爲網站存在漏洞，使得攻擊者能夠在網站輸入惡意代碼，並讓惡意代碼在其餘用戶瀏覽器運行，竊取用戶信息。

非持久性攻擊(反射性攻擊)

反射性XSS，也就是被動的非持久性XSS。

誘騙用戶點擊URL帶攻擊代碼的連接，服務器解析後響應，在返回的響應內容中隱藏和嵌入攻擊者的XSS代碼，被瀏覽器執行，從而攻擊用戶。

場景舉例：

小明逛淘寶，在訪問淘寶網時會登陸，會留下瀏覽器和服務器分別保存認證Cookie用戶識別小明的身份。
攻擊者發現了淘寶網的商品搜索欄有XSS漏洞
攻擊者構造連接http://taobao.com/search?q=手機<script>惡意代碼</script>並把連接發佈到各個社交平臺，看成廣告並誘惑用戶去點擊。
當小明看到廣告，點開連接，這時，惡意代碼就存在在了小明的瀏覽器上，因爲小明的淘寶處於登陸狀態，因此惡意代碼能夠獲取小明的Cookie，故也能看到小明的因此信息，並模擬小明的全部操做。

持久性攻擊

利用相似於留言板的功能將惡意代碼寫進數據庫，當用戶下次訪問該網站時，由於網站會從數據庫中獲取數據展現信息，因此用戶只要打開這個網站就會中招。

場景舉例：

攻擊者發現淘寶網的商品評論框有XSS漏洞
攻擊者發了一條評論，內容是：「該物品買到就是賺到！<script src="http://xss.com/xxx.js">」。這個信息會展現到評論列表中，其中script標籤會嵌入頁面中。
其餘用戶打開該頁面時，閱讀評論的同時實際上惡意代碼已經在偷偷執行。攻擊者就會獲取用戶的Cookie劫持用戶信息。

防範措施

對於富文本編輯器，過濾script等不安全標籤
對用戶輸入的內容進行轉義，好比把<script></script>轉義
代碼須要動態展現內容時，用innerText來代替 innerHTML， vue使用v-text取代v-html。
服務端使用 Set Cookie時，帶上HttpOnly字段，阻止JavaScript獲取Cookie
對於上傳圖片的場景，禁止使用用戶填寫的圖片地址。特別是MarkDown編輯器。

CSRF攻擊

Cross-site request forgery，跨站點請求僞造。

攻擊者誘導受害者進入第三方網站，在第三方網站中，向被攻擊的網站發送跨站請求。利用受害者在被攻擊網站已經獲取的註冊憑證，繞事後臺的用戶驗證，以達到冒充用戶對被攻擊的網站執行某項操做的目的。

場景舉例：

受害者登陸了淘寶網，並保留了登陸憑證（Cookie）
攻擊者引誘受害者去訪問第三方網站 b.com
b.com 會向淘寶網發送一個請求，瀏覽器會默認帶上受害者登陸淘寶時的Cooike
這時淘寶網接收到請求後，對請求進行驗證，並確認是受害者的憑證，誤覺得是受害者本身發送的情求。
這時攻擊者就在受害者不知情的狀況下，冒充受害者，讓淘寶網執行了本身定義的一些操做。

攻擊類型

GET類型的CSRF:

一個常見的場景匿名點贊，服務端會根據匿名訪問者的IP來區別用戶。攻擊者把這個點贊接口集成到本身網站的圖片裏，任何人訪問攻擊者的網站都至關於給攻擊者作了嫁衣幫忙店了一次贊。

<img src="http://zan.example/thumbup?amount=1&for=hacker">
複製代碼

POST類型的CSRF:

有些服務器的接口是使用 POST 方法的，因此黑客須要在他的站點上僞造 POST 請求，當用戶打開黑客的站點時，是自動提交 POST 請求

<form id= 'hacker-form' action="https://bank.example/withdraw" method=POST>
    <input type="hidden" name="userll" value="hacker" />
    <input type="hidden" name="numberll" value="100" />
</form>
複製代碼

在上段代碼中，咱們能夠看到攻擊者在它的頁面上構建了一個隱藏的表單，該表單內容就是一個某網站的轉帳接口，當用戶打開該站點以後，這個表單就會被自動執行提交；當表單被提交以後，服務器會執行轉帳操做。所以使用構建自動提交表單的這種返回就，能夠自動實現跨站點POST數據提交

連接類型的CSRF:

這種須要用戶本身動手點擊連接纔會觸發。這種類型一般會在各個社交平臺發佈的圖片中嵌入惡意連接，或者以廣告的形式來誘導用戶去點擊。

<a href="http://test.com/csrf/withdwaw.php?amount=100&for=hacker" target="_blank">重磅消息！！<a/>
複製代碼

因爲以前用戶登陸了信任的網站A，而且保存了登陸狀態。這時只要用戶主動訪問了上面的這個PHP頁面，則表示攻擊成功。

防禦措施

因爲CSRF與XSS不一樣，CSRF攻擊不會往頁面注入惡意腳本，所以攻擊者是沒法經過CSRF攻擊來獲取用戶頁面數據的；主要是找到服務器的漏洞，因此對CSRF來講攻擊能夠從提高服務器安全性的方面來防禦。

1. 利用好Cookie的SameSite屬性

由於攻擊者會利用用戶登陸狀態來發起CSRF攻擊，而Cookie正式瀏覽器和服務器之間維護登陸狀態的一個關鍵數據，所以要阻止CSRF攻擊，須要在Cookie上設置一些東西。

而CSRF攻擊一般是第三方站點發起的，所以能夠利用Cookie 中的 SameSite 屬性來阻止CSRF攻擊

2. 在Cookie裏寫入csrftoken的值

<form action="https://time.geekbang.org/sendcoin" method="POST">
    <input type="hidden" csrftoken="afe3f94cnisar">
    <input type="text" name="username" value="">
    <input type="password" name="password" value="">
 </form>
複製代碼

當用戶提交表單或者發送Ajax情求時，在情求參數或者請求頭帶上以前埋入的csrftoken。請求到服務器後服務器會從用戶的請求參數裏拿出token和請求自帶的cookie裏的token作對比，若是都存在且一致，則請求經過。

由於這個token是埋在該網站的，攻擊者從第三方網站僞造請求時是得不到這個token因此沒法在請求參數中帶上token，請求就會失敗