web開發常見的幾大安全問題

1、SQL注入

SQL注入是一種常見的Web安全漏洞，攻擊者利用這個漏洞，能夠訪問或修改數據，或者利用潛在的數據庫漏洞進行攻擊。SQL注入，就是經過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。具體來講，它是利用現有應用程序，將（惡意的）SQL命令注入到後臺數據庫引擎執行的能力，它能夠經過在Web表單中輸入（惡意）SQL語句獲得一個存在安全漏洞的網站上的數據庫，而不是按照設計者意圖去執行SQL語句。

1.SQL注入的原理

咱們先舉一個萬能鑰匙的例子來講明其原理：

<form action="/login" method="POST"> <p>Username: <input type="text" name="username" /></p> <p>Password: <input type="password" name="password" /></p> <p><input type="submit" value="登錄" /></p> </form>

後端的 SQL 語句多是以下這樣的：

let querySQL = ` SELECT * FROM user WHERE username='${username}' AND psw='${password}' `; // 接下來就是執行 sql 語句...

這是咱們常常見到的登陸頁面，但若是有一個惡意攻擊者輸入的用戶名是 admin' --，密碼隨意輸入，就能夠直接登入系統了。why! ----這就是SQL注入

咱們以前預想的SQL 語句是:

SELECT * FROM user WHERE username='admin' AND psw='password'

可是惡意攻擊者用奇怪用戶名將你的 SQL 語句變成了以下形式：

SELECT * FROM user WHERE username='admin' --' AND psw='xxxx'

在 SQL 中,' --是閉合和註釋的意思，-- 是註釋後面的內容的意思，因此查詢語句就變成了：

SELECT * FROM user WHERE username='admin'

所謂的萬能密碼,本質上就是SQL注入的一種利用方式。

一次SQL注入的過程包括如下幾個過程：

• 獲取用戶請求參數
• 拼接到代碼當中
• SQL語句按照咱們構造參數的語義執行成功

SQL注入的必備條件：
1.能夠控制輸入的數據
2.服務器要執行的代碼拼接了控制的數據。

咱們會發現SQL注入流程中與正常請求服務器相似，只是黑客控制了數據，構造了SQL查詢，而正常的請求不會SQL查詢這一步，SQL注入的本質:數據和代碼未分離，即數據當作了代碼來執行。

2.危害

• 獲取數據庫信息
  • 管理員後臺用戶名和密碼
  • 獲取其餘數據庫敏感信息：用戶名、密碼、手機號碼、身份證、銀行卡信息……
  • 整個數據庫：脫褲
• 獲取服務器權限
• 植入Webshell，獲取服務器後門
• 讀取服務器敏感文件

3.如何防護

• 嚴格限制Web應用的數據庫的操做權限，給此用戶提供僅僅可以知足其工做的最低權限，從而最大限度的減小注入攻擊對數據庫的危害
• 後端代碼檢查輸入的數據是否符合預期，嚴格限制變量的類型，例如使用正則表達式進行一些匹配處理。
• 字符串長度驗證，僅接受指定長度範圍內的變量值。sql注入腳本必然會大大增長輸入變量的長度，經過長度限制，好比用戶名長度爲 8 到 20 個字符之間，超過就斷定爲無效值。
• 對進入數據庫的特殊字符（'，"，，<，>，&，*，; 等）進行轉義處理，或編碼轉換。基本上全部的後端語言都有對字符串進行轉義處理的方法，好比 lodash 的 lodash._escapehtmlchar 庫。
• 全部的查詢語句建議使用數據庫提供的參數化查詢接口，參數化的語句使用參數而不是將用戶輸入變量嵌入到 SQL 語句中，即不要直接拼接 SQL 語句。例如 Node.js 中的 mysqljs 庫的 query 方法中的 ? 佔位參數。

• 框架防護： mybatis

  ① # 符號做用爲 將傳入的數據都當成一個字符串，會對自動傳入的數據加一個雙引號。

  如：where user_id= #{id}

  若是傳入的值是111,那麼解析成sql時的值爲 where id ="111"

  若是傳入的值是 1’=or ’1’=‘1’ ，則解析成的sql爲 whereid 「1’=or ’1’=‘1’ 「

  ② $ 符號則是將傳入的數據直接生成在sql中。

  如：where user_id= ‘${id}’

  若是傳入的值是111,那麼解析成sql時的值爲 where id =‘111’

  若是傳入的值是 1’=or ’1’=‘1’，則解析成的sql爲 where _id =‘1’or ’1’=1’

  結論：# 符號可以防止SQL注入， $符號沒法防止SQL注入，$ 符號通常用於傳入數據庫對象，例如傳入表名

 

2、XSS

XSS (Cross-Site Scripting)，跨站腳本攻擊，由於縮寫和 CSS重疊，因此只能叫 XSS。跨站腳本攻擊是指經過存在安全漏洞的Web網站註冊用戶的瀏覽器內運行非法的HTML標籤或JavaScript進行的一種攻擊。

跨站腳本攻擊有可能形成如下影響:

• 利用虛假輸入表單騙取用戶我的信息。
• 利用腳本竊取用戶的Cookie值，被害者在不知情的狀況下，幫助攻擊者發送惡意請求。
• 顯示僞造的文章或圖片。

XSS 的原理是惡意攻擊者往 Web 頁面裏插入惡意可執行網頁腳本代碼，當用戶瀏覽該頁之時，嵌入其中 Web 裏面的腳本代碼會被執行，從而能夠達到攻擊者盜取用戶信息或其餘侵犯用戶安全隱私的目的。

XSS 的攻擊方式變幻無窮，但仍是能夠大體細分爲幾種類型。

1.非持久型 XSS（反射型 XSS ）

非持久型 XSS 漏洞，通常是經過給別人發送帶有惡意腳本代碼參數的 URL，當 URL 地址被打開時，特有的惡意代碼參數被 HTML 解析、執行。

舉一個例子，好比頁面中包含有如下代碼：

<select> <script> document.write('' + '<option value=1>' + location.href.substring(location.href.indexOf('default=') + 8) + '</option>' ); document.write('<option value=2>English</option>'); </script> </select>

攻擊者能夠直接經過 URL (相似：https://xxx.com/xxx?default=<script>alert(document.cookie)</script>) 注入可執行的腳本代碼。不過一些瀏覽器如Chrome其內置了一些XSS過濾器，能夠防止大部分反射型XSS攻擊。

非持久型 XSS 漏洞攻擊有如下幾點特徵：

• 即時性，不通過服務器存儲，直接經過 HTTP 的 GET 和 POST 請求就能完成一次攻擊，拿到用戶隱私數據。
• 攻擊者須要誘騙點擊,必需要經過用戶點擊連接才能發起
• 反饋率低，因此較難發現和響應修復
• 盜取用戶敏感保密信息

爲了防止出現非持久型 XSS 漏洞，須要確保這麼幾件事情：

• Web 頁面渲染的全部內容或者渲染的數據都必須來自於服務端。
• 儘可能不要從 URL，document.referrer，document.forms 等這種 DOM API 中獲取數據直接渲染。
• 儘可能不要使用 eval, new Function()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，innerHTML，document.createElement() 等可執行字符串的方法。
• 若是作不到以上幾點，也必須對涉及 DOM 渲染的方法傳入的字符串參數作 escape 轉義。
• 前端渲染的時候對任何的字段都須要作 escape 轉義編碼。

2.持久型 XSS（存儲型 XSS）

持久型 XSS 漏洞，通常存在於 Form 表單提交等交互功能，如文章留言，提交文本信息等，黑客利用的 XSS 漏洞，將內容經正常功能提交進入數據庫持久保存，當前端頁面得到後端從數據庫中讀出的注入代碼時，剛好將其渲染執行。

舉個例子，對於評論功能來講，就得防範持久型 XSS 攻擊，由於我能夠在評論中輸入如下內容

主要注入頁面方式和非持久型 XSS 漏洞相似，只不過持久型的不是來源於 URL，referer，forms 等，而是來源於後端從數據庫中讀出來的數據 。持久型 XSS 攻擊不須要誘騙點擊，黑客只須要在提交表單的地方完成注入便可，可是這種 XSS 攻擊的成本相對仍是很高。

攻擊成功須要同時知足如下幾個條件：

• POST 請求提交表單後端沒作轉義直接入庫。
• 後端從數據庫中取出數據沒作轉義直接輸出給前端。
• 前端拿到後端數據沒作轉義直接渲染成 DOM。

持久型 XSS 有如下幾個特色：

• 持久性，植入在數據庫中
• 盜取用戶敏感私密信息
• 危害面廣

3.如何防護

對於 XSS 攻擊來講，一般有兩種方式能夠用來防護。

1) CSP

CSP 本質上就是創建白名單，開發者明確告訴瀏覽器哪些外部資源能夠加載和執行。咱們只須要配置規則，如何攔截是由瀏覽器本身實現的。咱們能夠經過這種方式來儘可能減小 XSS 攻擊。

一般能夠經過兩種方式來開啓 CSP：

• 設置 HTTP Header 中的 Content-Security-Policy
• 設置 meta 標籤的方式

這裏以設置 HTTP Header 來舉例：

• 只容許加載本站資源

Content-Security-Policy: default-src 'self'

• 只容許加載 HTTPS 協議圖片

Content-Security-Policy: img-src https://*

• 容許加載任何來源框架

Content-Security-Policy: child-src 'none'

如需瞭解更多屬性，請查看Content-Security-Policy文檔

對於這種方式來講，只要開發者配置了正確的規則，那麼即便網站存在漏洞，攻擊者也不能執行它的攻擊代碼，而且 CSP 的兼容性也不錯。

2) 轉義字符

用戶的輸入永遠不可信任的，最廣泛的作法就是轉義輸入輸出的內容，對於引號、尖括號、斜槓進行轉義

function escape(str) { str = str.replace(/&/g, '&amp;') str = str.replace(/</g, '&lt;') str = str.replace(/>/g, '&gt;') str = str.replace(/"/g, '&quto;') str = str.replace(/'/g, '&#39;') str = str.replace(/`/g, '&#96;') str = str.replace(/\//g, '&#x2F;') return str }

可是對於顯示富文原本說，顯然不能經過上面的辦法來轉義全部字符，由於這樣會把須要的格式也過濾掉。對於這種狀況，一般採用白名單過濾的辦法，固然也能夠經過黑名單過濾，可是考慮到須要過濾的標籤和標籤屬性實在太多，更加推薦使用白名單的方式。

const xss = require('xss') let html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");</script>') // -> <h1>XSS Demo</h1>&lt;script&gt;alert("xss");&lt;/script&gt; console.log(html)

以上示例使用了 js-xss 來實現，能夠看到在輸出中保留了 h1 標籤且過濾了 script 標籤。

3) HttpOnly Cookie。

這是預防XSS攻擊竊取用戶cookie最有效的防護手段。Web應用程序在設置cookie時，將其屬性設爲HttpOnly，就能夠避免該網頁的cookie被客戶端惡意JavaScript竊取，保護用戶cookie信息。

 

3、CSRF

 

CSRF(Cross Site Request Forgery)，即跨站請求僞造，是一種常見的Web攻擊，它利用用戶已登陸的身份，在用戶絕不知情的狀況下，以用戶的名義完成非法操做。

 

1. CSRF攻擊的原理

 

下面先介紹一下CSRF攻擊的原理：

 

 

完成 CSRF 攻擊必需要有三個條件：

 

• 用戶已經登陸了站點 A，並在本地記錄了 cookie
• 在用戶沒有登出站點 A 的狀況下（也就是 cookie 生效的狀況下），訪問了惡意攻擊者提供的引誘危險站點 B (B 站點要求訪問站點A)。
• 站點 A 沒有作任何 CSRF 防護

 

咱們來看一個例子： 當咱們登入轉帳頁面後，忽然眼前一亮驚現"XXX隱私照片，不看後悔一生"的連接，耐不住心裏躁動，立馬點擊了該危險的網站（頁面代碼以下圖所示），但當這頁面一加載，便會執行submitForm這個方法來提交轉帳請求，從而將10塊轉給黑客。

 

 

2.如何防護

 

防範 CSRF 攻擊能夠遵循如下幾種規則：

 

• Get 請求不對數據進行修改
• 不讓第三方網站訪問到用戶 Cookie
• 阻止第三方網站請求接口
• 請求時附帶驗證信息，好比驗證碼或者 Token

 

1) SameSite

 

能夠對 Cookie 設置 SameSite 屬性。該屬性表示 Cookie 不隨着跨域請求發送，能夠很大程度減小 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錯誤。

 

4) 驗證碼

 

應用程序和用戶進行交互過程當中，特別是帳戶交易這種核心步驟，強制用戶輸入驗證碼，才能完成最終請求。在一般狀況下，驗證碼夠很好地遏制CSRF攻擊。但增長驗證碼下降了用戶的體驗，網站不能給全部的操做都加上驗證碼。因此只能將驗證碼做爲一種輔助手段，在關鍵業務點設置驗證碼。

 

4、點擊劫持

 

點擊劫持是一種視覺欺騙的攻擊手段。攻擊者將須要攻擊的網站經過 iframe 嵌套的方式嵌入本身的網頁中，並將 iframe 設置爲透明，在頁面中透出一個按鈕誘導用戶點擊。

 

1. 特色

 

• 隱蔽性較高，騙取用戶操做
• "UI-覆蓋攻擊"
• 利用iframe或者其它標籤的屬性

 

2. 點擊劫持的原理

 

用戶在登錄 A 網站的系統後，被攻擊者誘惑打開第三方網站，而第三方網站經過 iframe 引入了 A 網站的頁面內容，用戶在第三方網站中點擊某個按鈕（被裝飾的按鈕），其實是點擊了 A 網站的按鈕。
接下來咱們舉個例子：我在優酷發佈了不少視頻，想讓更多的人關注它，就能夠經過點擊劫持來實現

 

iframe {
width: 1440px; height: 900px; position: absolute; top: -0px; left: -0px; z-index: 2; -moz-opacity: 0; opacity: 0; filter: alpha(opacity=0); } button { position: absolute; top: 270px; left: 1150px; z-index: 1; width: 90px; height:40px; } </style> ...... <button>點擊脫衣</button> <img src="http://pic1.win4000.com/wallpaper/2018-03-19/5aaf2bf0122d2.jpg"> <iframe src="http://i.youku.com/u/UMjA0NTg4Njcy" scrolling="no"></iframe>

 

 

從上圖可知，攻擊者經過圖片做爲頁面背景，隱藏了用戶操做的真實界面，當你按耐不住好奇點擊按鈕之後，真正的點擊的實際上是隱藏的那個頁面的訂閱按鈕，而後就會在你不知情的狀況下訂閱了。

 

 

3. 如何防護

 

1）X-FRAME-OPTIONS

 

X-FRAME-OPTIONS是一個 HTTP 響應頭，在現代瀏覽器有一個很好的支持。這個 HTTP 響應頭 就是爲了防護用 iframe 嵌套的點擊劫持攻擊。

 

該響應頭有三個值可選，分別是

 

• DENY，表示頁面不容許經過 iframe 的方式展現
• SAMEORIGIN，表示頁面能夠在相同域名下經過 iframe 的方式展現
• ALLOW-FROM，表示頁面能夠在指定來源的 iframe 中展現

 

2）JavaScript 防護

 

對於某些遠古瀏覽器來講，並不能支持上面的這種方式，那咱們只有經過 JS 的方式來防護點擊劫持了，Frame Busting ：這種方式是經過寫JavaScript來禁止iframe嵌套，可是能夠輕易饒過。

 

<head> <style id="click-jack"> html { display: none !important; } </style> </head> <body> <script> if (self == top) { var style = document.getElementById('click-jack') document.body.removeChild(style) } else { top.location = self.location } </script> </body>

 

以上代碼的做用就是當經過 iframe 的方式加載頁面時，攻擊者的網頁直接不顯示全部內容了。

 

給你們推薦一個好用的BUG監控工具Fundebug，歡迎免費試用！

 

5、URL跳轉漏洞

 

定義：藉助未驗證的URL跳轉，將應用程序引導到不安全的第三方區域，從而致使的安全問題。

 

1.URL跳轉漏洞原理

 

黑客利用URL跳轉漏洞來誘導安全意識低的用戶點擊，致使用戶信息泄露或者資金的流失。其原理是黑客構建惡意連接(連接須要進行假裝,儘量迷惑),發在QQ羣或者是瀏覽量多的貼吧/論壇中。
安全意識低的用戶點擊後,通過服務器或者瀏覽器解析後，跳到惡意的網站中。

 

 

惡意連接須要進行假裝,常常的作法是熟悉的連接後面加上一個惡意的網址，這樣才迷惑用戶。

 

 

諸如假裝成像以下的網址，你是否可以識別出來是惡意網址呢？

 

http://gate.baidu.com/index?act=go&url=http://t.cn/RVTatrd http://qt.qq.com/safecheck.html?flag=1&url=http://t.cn/RVTatrd http://tieba.baidu.com/f/user/passport?jumpUrl=http://t.cn/RVTatrd

 

2.實現方式：

 

• Header頭跳轉
• Javascript跳轉
• META標籤跳轉

 

這裏咱們舉個Header頭跳轉實現方式：

 

<?php $url=$_GET['jumpto']; header("Location: $url"); ?> http://www.wooyun.org/login.php?jumpto=http://www.evil.com

 

這裏用戶會認爲www.wooyun.org都是可信的，可是點擊上述連接將致使用戶最終訪問www.evil.com這個惡意網址。

 

3.如何防護

 

1)referer的限制

 

若是肯定傳遞URL參數進入的來源，咱們能夠經過該方式實現安全限制，保證該URL的有效性，避免惡意用戶本身生成跳轉連接

 

2)加入有效性驗證Token

 

咱們保證全部生成的連接都是來自於咱們可信域的，經過在生成的連接里加入用戶不可控的Token對生成的連接進行校驗，能夠避免用戶生成本身的惡意連接從而被利用，可是若是功能自己要求比較開放，可能致使有必定的限制。

 

 

6、OS命令注入攻擊

OS命令注入和SQL注入差很少，只不過SQL注入是針對數據庫的，而OS命令注入是針對操做系統的。OS命令注入攻擊指經過Web應用，執行非法的操做系統命令達到攻擊的目的。只要在能調用Shell函數的地方就有存在被攻擊的風險。假若調用Shell時存在疏漏，就能夠執行插入的非法命令。

命令注入攻擊能夠向Shell發送命令，讓Windows或Linux操做系統的命令行啓動程序。也就是說，經過命令注入攻擊可執行操做系統上安裝着的各類程序。

1.原理

黑客構造命令提交給web應用程序，web應用程序提取黑客構造的命令，拼接到被執行的命令中，因黑客注入的命令打破了原有命令結構，致使web應用執行了額外的命令，最後web應用程序將執行的結果輸出到響應頁面中。

咱們經過一個例子來講明其原理，假如須要實現一個需求：用戶提交一些內容到服務器，而後在服務器執行一些系統命令去返回一個結果給用戶

// 以 Node.js 爲例，假如在接口中須要從 github 下載用戶指定的 repo const exec = require('mz/child_process').exec; let params = {/* 用戶輸入的參數 */}; exec(`git clone ${params.repo} /some/path`);

若是 params.repo 傳入的是 https://github.com/admin/admin.github.io.git 確實能從指定的 git repo 上下載到想要的代碼。
可是若是 params.repo 傳入的是 https://github.com/xx/xx.git && rm -rf /* && 剛好你的服務是用 root 權限起的就糟糕了。

2.如何防護

• 後端對前端提交內容進行規則限制（好比正則表達式）。
• 在調用系統命令前對全部傳入參數進行命令行參數轉義過濾。
• 不要直接拼接命令語句，藉助一些工具作拼接、轉義預處理，例如 Node.js 的 shell-escape npm包

 

7、DOS攻擊

一、概念的理解

 DoS：Denial of Service，拒絕服務，即沒法及時接收並處理外界合法請求。

DoS攻擊：指形成DoS的攻擊行爲，目的是使攻擊目標計算機沒法提供正常的服務。最多見的DoS攻擊有計算機網絡帶寬攻擊和連通性攻擊。其中，帶寬攻擊是指以極大通訊量衝擊通往目標計算機的網絡，使得全部可用網絡資源都被消耗殆盡，致使合法的用戶請求沒法經過，沒法到達目標計算機。而連通性攻擊則是指用大量的鏈接請求攻擊目標計算機，使得全部可用的操做系統資源都被消耗殆盡，致使目標計算機沒法處理合法用戶的請求。

DDoS攻擊：DDoS即Distributed Denial of Service，DDoS攻擊便是分佈式DoS攻擊。攻擊者藉助客戶/服務器技術，控制並利用多個傀儡機（肉雞），對一個或多個攻擊目標發起DDoS攻擊，從而成倍地提升DoS攻擊的威力。

DRDoS攻擊：DRDoS即Distributed Reflection Denial of Service，DRDoS攻擊便是分佈式反射DoS攻擊。DRDoS攻擊與DoS攻擊、DDoS攻擊不一樣，它不是直接對攻擊目標發起請求，而是經過IP欺騙，發送大量源IP地址爲攻擊目標IP地址的數據包給攻擊主機（第三方），而後攻擊主機對IP地址源（即攻擊目標）作出大量回應，從而造成DoS攻擊。攻擊者每每會選擇那些響應包遠大於請求包的第三方服務來利用，以達到放大反射攻擊的效果，這樣的服務包括DNS、NTP、SSDP、Chargen、Memcached等。

       今天最多見的DoS攻擊有對計算機網絡的帶寬攻擊和連通性攻擊。帶寬攻擊指以極大的通訊量衝擊網絡，使得全部可用網絡資源都被消耗殆盡，最後致使合法的用戶請求沒法經過。連通性攻擊指用大量的鏈接請求衝擊計算機，使得全部可用的操做系統資源都被消耗殆盡，最終計算機沒法再處理合法用戶的請求。

       傳統上，攻擊者所面臨的主要問題是網絡帶寬，因爲較小的網絡規模和較慢的網絡速度的限制，攻擊者沒法發出過多的請求。雖然相似「the ping of death」的攻擊類型只須要較少許的包就能夠摧毀一個沒有打過補丁的UNIX系統，但大多數的DoS攻擊仍是須要至關大的帶寬的，而以我的爲單位的黑客們很難使用高帶寬的資源。爲了克服這個缺點，DoS攻擊者開發了分佈式的攻擊。攻擊者簡單利用工具集合許多的網絡帶寬來同時對同一個目標發動大量的攻擊請求，這就是DDoS攻擊。

不管是DoS攻擊仍是DDoS攻擊，簡單的看，都只是一種破壞網絡服務的黑客方式，雖然具體的實現方式變幻無窮，但都有一個共同點，就是其根本目的是使受害主機或網絡沒法及時接收並處理外界請求，或沒法及時迴應外界請求。其具體表現方式有如下幾種：

  （1） 製造大流量無用數據，形成通往被攻擊主機的網絡擁塞，使被攻擊主機沒法正常和外界通訊。

  （2） 利用被攻擊主機提供服務或傳輸協議上處理重複鏈接的缺陷，反覆高頻的發出攻擊性的重複服務請求，使被攻擊主機沒法及時處理其它正常的請求。

  （3）利用被攻擊主機所提供服務程序或傳輸協議的自己實現缺陷，反覆發送畸形的攻擊數據引起系統錯誤的分配大量系統資源，使主機處於掛起狀態甚至死機。

 

二、攻擊流程

 

 要理解dos攻擊，首先要理解TCP鏈接的三次握手過程(Three-wayhandshake)。在TCP/IP協議中，TCP協議提供可靠的鏈接服務，採用三次握手創建一個鏈接。

 

    1.第一次握手:創建鏈接時，客戶端發送SYN包((SYN=i)到服務器，並進入SYN SEND狀態，等待服務器確認;

 

    2.第二次握手:服務器收到SYN包，必須確認客戶的SYN (ACK=i+1 )，同時本身也發送一個SYN包((SYN=j)}即SYN+ACK包，此時服務器進入SYN_RECV狀態;

 

    3.第三次握手:客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ACK=j+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手，客戶端與服務器開始傳送數據。

 1. 半鏈接:收到SYN包而還未收到ACK包時的鏈接狀態稱爲半鏈接，即還沒有徹底完成三次握手的TCP鏈接。

   2. 半鏈接隊列:在三次握手協議中，服務器維護一個半鏈接隊列，該隊列爲每一個客戶端的SYN包(SYN=i )開設一個條目，該條目代表服務器已收到SYN包，並向客戶發出確認，正在等待客戶的確認包。這些條目所標識的鏈接在服務器處於SYN_ RECV狀態，當服務器收到客戶的確認包時，刪除該條目，服務器進入ESTABLISHED狀態。

   3. Backlog參數:表示半鏈接隊列的最大容納數目。

   4. SYN-ACK重傳次數:服務器發送完SYN-ACK包，若是未收到客戶確認包，服務器進行首次重傳，等待一段時間 仍未收到客戶確認包，進行第二次重傳，若是重傳次數超過系統規定的最大重傳次數，系統將該鏈接信息、從半鏈接隊列中刪除。注意，每次重傳等待的時間不必定相同。

   5. 半鏈接存活時間:是指半鏈接隊列的條目存活的最長時間，也即服務從收到SYN包到確認這個報文無效的最長時間，該時間值是全部重傳請求包的最長等待時間總和。有時也稱半鏈接存活時間爲Timeout時間、SYN_RECV存活時間。

 

上面三個參數對系統的TCP鏈接情況有很大影響。

    SYN洪水攻擊屬於DoS攻擊的一種，它利用TCP協議缺陷，經過發送大量的半鏈接請求，耗費CPU和內存資源。 SYN攻擊除了能影響主機外，還能夠危害路由器、防火牆等網絡系統，事實上SYN攻擊並無論目標是什麼系統，只要這些系統打開TCP服務就能夠實施。從圖 4-3可看到，服務器接收到鏈接請求(SYN=i )將此信息加入未鏈接隊列，併發送請求包給客戶端( SYN=j,ACK=i+1 )，此時進入SYN_RECV狀態。當服務器未收到客戶端的確認包時，重發請求包，一直到超時，纔將此條目從未鏈接隊列刪除。配合IP欺騙，SYN攻擊能 達到很好的效果，一般，客戶端在短期內僞造大量不存在的IP地址，向服務器不斷地發送SYN包，服務器回覆確認包，並等待客戶的確認，因爲源地址是不存 在的，服務器須要不斷的重發直至超時，這些僞造的SYN包將長時間佔用未鏈接隊列，正常的SYN 請求被丟棄，目標系統運行緩慢，嚴重者引發網絡堵塞甚至系統癱瘓。過程以下:

 

       攻擊主機C(地址假裝後爲C)-----大量SYN包---->被攻擊主機

       C<-------SYN/ACK包----被攻擊主機

 

因爲C地址不可達，被攻擊主機等待SYN包超時。攻擊主機經過發大量SYN包填滿未鏈接隊列，致使正常SYN包被拒絕服務。另外，SYN洪水攻擊還能夠經過發大量ACK包進行DoS攻擊。

 

三、攻擊手段

 

 拒絕服務攻擊是一種對網絡危害巨大的惡意攻擊。今天，DoS具備表明性的攻擊手段包括Ping of Death、TearDrop、UDPflood、SYNflood、LandAttack、IPSpoofingDoS等。看看它們又是怎麼實現的。 

 

   （1） 死亡之ping (ping of death)

 

    ICMP(InternetControlMessageProtocol，Internet控制信息協議)在Internet上用於錯誤處理和傳遞控制信息。它的功能之一是與主機聯繫，經過發送一個「迴音請求」（echorequest）信息包看看主機是否「活着」。最普通的ping程序就是這個功能。而在TCP/IP的RFC文檔中對包的最大尺寸都有嚴格限制規定，許多操做系統的TCP/IP協議棧都規定ICMP包大小爲64KB，且在對包的標題頭進行讀取以後，要根據該標題頭裏包含的信息來爲有效載荷生成緩衝區。"Ping of Death"就是故意產生畸形的測試Ping（PacketInternetGroper）包，聲稱本身的尺寸超過ICMP上限，也就是加載的尺寸超過64KB上限，使未採起保護措施的網絡系統出現內存分配錯誤，致使TCP/IP協議棧崩潰，最終接收方宕機。

 

   （2）淚滴 (tear drop)

 

   淚滴攻擊利用在TCP/IP協議棧實現中信任IP碎片中的包的標題頭所包含的信息來實現本身的攻擊。IP分段含有指示該分段所包含的是原包的哪一段的信息，某些TCP/IP協議棧（例如NT在servicepack4之前）在收到含有重疊偏移的僞造分段時將崩潰。

 

   （3）UDP泛洪(UDP flood)

 

    UDPflood攻擊：現在在Internet上UDP（用戶數據包協議）的應用比較普遍，不少提供WWW和Mail等服務設備一般是使用Unix的服務器，它們默認打開一些被黑客惡意利用的UDP服務。如echo服務會顯示接收到的每個數據包，而本來做爲測試功能的chargen服務會在收到每個數據包時隨機反饋一些字符。UDPflood假冒攻擊就是利用這兩個簡單的TCP/IP服務的漏洞進行惡意攻擊，經過僞造與某一主機的Chargen服務之間的一次的UDP鏈接，回覆地址指向開着Echo服務的一臺主機，經過將Chargen和Echo服務互指，來回傳送毫無用處且佔滿帶寬的垃圾數據，在兩臺主機之間生成足夠多的無用數據流，這一拒絕服務攻擊飛快地致使網絡可用帶寬耗盡。

 

   （4） SYN泛洪(SYNflood)

 

    SYNflood攻擊：咱們知道當用戶進行一次標準的 TCP（TransmissionControlProtocol）鏈接時，會有一個3次握手過程。首先是請求服務方發送一個 SYN（SynchronizeSequenceNumber）消息，服務方收到SYN後，會向請求方回送一個SYN-ACK表示確認，當請求方收到 SYN-ACK後，再次向服務方發送一個ACK消息，這樣一次TCP鏈接創建成功。「SYNFlooding」則專門針對TCP協議棧在兩臺主機間初始化鏈接握手的過程進行DoS攻擊，其在實現過程當中只進行前2個步驟：當服務方收到請求方的SYN-ACK確認消息後，請求方因爲採用源地址欺騙等手段使得服務方收不到ACK迴應，因而服務方會在必定時間處於等待接收請求方ACK消息的狀態。而對於某臺服務器來講，可用的TCP鏈接是有限的，由於他們只有有限的內存緩衝區用於建立鏈接，若是這一緩衝區充滿了虛假鏈接的初始信息，該服務器就會對接下來的鏈接中止響應，直至緩衝區裏的鏈接企圖超時。若是惡意攻擊方快速連續地發送此類鏈接請求，該服務器可用的TCP鏈接隊列將很快被阻塞，系統可用資源急劇減小，網絡可用帶寬迅速縮小，長此下去，除了少數幸運用戶的請求能夠插在大量虛假請求間獲得應答外，服務器將沒法向用戶提供正常的合法服務。

 

    （5）Land（LandAttack）攻擊

 

    在Land攻擊中，黑客利用一個特別打造的SYN包--它的原地址和目標地址都被設置成某一個服務器地址進行攻擊。此舉將致使接受服務器向它本身的地址發送SYN-ACK消息，結果這個地址又發回ACK消息並建立一個空鏈接，每個這樣的鏈接都將保留直到超時，在Land攻擊下，許多UNIX將崩潰，NT變得極其緩慢（大約持續五分鐘）。

 

     （6）IP欺騙dos攻擊

 

     這種攻擊利用TCP協議棧的RST位來實現，使用IP欺騙，迫使服務器把合法用戶的鏈接復位，影響合法用戶的鏈接。假設如今有一個合法用戶（100.100.100.100）已經同服務器創建了正常的鏈接，攻擊者構造攻擊的TCP數據，假裝本身的IP爲100.100.100.100，並向服務器發送一個帶有RST位的TCP數據段。服務器接收到這樣的數據後，認爲從100.100.100.100發送的鏈接有錯誤，就會清空緩衝區中已創建好的鏈接。這時，合法用戶100.100.100.100再發送合法數據，服務器就已經沒有這樣的鏈接了，該用戶就被拒絕服務而只能從新開始創建新的鏈接。

 

     （7）Smurf攻擊

 

    Smurf是一種簡單但有效的DDoS攻擊技術，它利用了ICMP(Internet控制信息協議）。ICMP在Internet上用於錯誤處理和傳遞控制信息。它的功能之一是與主機聯繫，經過發送一個「迴音請求」（echo request）信息包看看主機是否「活着」。最普通的ping程序就使用了這個功能。Smurf是用一個偷來的賬號安裝到一個計算機上的，而後用一個僞造的源地址連續ping一個或多個計算機網絡，這就致使全部計算機所響應的那個計算機並非實際發送這個信息包的那個計算機。這個僞造的源地址，實際上就是攻擊的目標，它將被極大數量的響應信息量所淹沒。對這個僞造信息包作出響應的計算機網絡就成爲攻擊的不知情的同謀。

 

四、常見的dos攻擊與防禦

 

（1）SYN Flood攻擊
      原理：
    問題就出在TCP鏈接的三次握手中，假設一個用戶向服務器發送了SYN報文後忽然死機或掉線，那麼服務器在發出SYN+ACK應答報文後是沒法收到客戶端的 ACK報文的（第三次握手沒法完成），這 種狀況下服務器端通常會重試（再次發送SYN+ACK給客戶端）並等待一段時間後丟棄這個未完成的鏈接，這段時間的長度咱們稱爲SYN Timeout，通常來講這個時間是分鐘的數量級（大約爲30秒 -2分鐘）；一個用戶出現異常致使服務器的一個線程等待1分鐘並非什麼很大的問題，但若是有一個惡意的攻擊者大量模擬這種狀況，服務器端將爲了維護一個 很是大的半鏈接列表而消耗很是 多的資源----數以萬計的半鏈接，即便是簡單的保存並遍歷也會消耗很是多的CPU時間和內存，況且還要不斷對這個列表中的IP進行SYN+ACK的重試。實際上若是服務器的TCP/IP棧不夠強大，最後的結果每每是堆棧溢出崩潰---即便服務器端的系統足夠強大，服務器端也將忙於處理攻擊者僞造的TCP鏈接請求而無暇理睬客戶的正常請求（畢竟客戶端的正常請求比率很是之小），此時從正常客戶的角度看來，服務器失去響應，這種狀況咱們稱做：服務器端受到了SYN Flood攻擊（SYN洪水攻擊）。
      防範：
    第一種是縮短SYN Timeout時間 
    第二種方法是設置SYN Cookie，就是給每個請求鏈接的IP地址分配一個Cookie，若是短期內連續受到某個IP的重複SYN報文，就認定是受到了攻擊，之後從這個IP地址來的包會被一律丟棄。
           >netstat -n -p tcp >result.txt

 

  （2）Smurf攻擊：
       原理：
    發送假裝的ICMP數據包，目的地址設爲某個網絡的廣播地址，源地址設爲要攻擊的目的主機，使全部收到此ICMP數據包的主機都將對目的主機發出一個迴應，使被攻擊主機在某一段時間內收到成千上萬的數據包
       防範：
     在cisco路由器上配置以下能夠防止將包傳遞到廣播地址上:
         Router(config-if)# no ip directed-broadcast

 

    （3）Ping of Death
       原理：
     "ping of death"攻擊就是咱們常說的"死亡Ping"
這種攻擊經過發送大於65536字節的ICMP包使操做系統崩潰；一般不可能發送大於65536個字節的ICMP包，但能夠把報文分割成片斷，而後在目標主機上重組；最終會致使被攻擊目標緩衝區溢出，引發拒絕服務攻擊。有些時候致使telnet和http服務中止，有些時候路由器重啓。

 

    （4）淚滴攻擊
       原理：
     對於一些大的IP數據包，每每須要對其進行拆分傳送，這是爲了迎合鏈路層的MTU（最大傳輸單元）的要求。好比，一個6000字節的IP包，在MTU爲2000的鏈路上傳輸的時候，就須要分紅3個IP 包。在IP報頭中有一個偏移字段和一個拆分標誌（MF）。若是MF標誌設置爲1，則表示這個IP包是一個大IP包的片斷，其中偏移字段指出了這個片斷在整 個IP包中的位置。例如，對一個6000字 節的IP包進行拆分（MTU爲2 000），則3個片斷中偏移字段的值依次爲0，2000，4000。這樣接收端在所有接收完IP數據包後，就能夠根據這些信息從新組裝這幾個分次接收的拆分IP包。在這 裏就有一個安全漏洞能夠利用了，就是若是黑客們在截取IP數據包後，把偏移字段設置成不正確的值，這樣接收端在收到這些分拆的數據包後，就不能按數據包中 的偏移字段值正確組合這些拆 分的數據包，但接收端會不斷嘗試，這樣就可能導致目標計算機操做系統因資源耗盡而崩潰。

 

     （5） DRDOS
        原理：
    攻擊時，攻擊者巧妙的利用了反彈服務器羣來將洪 水數據包反彈給目標主機 反彈服務是指某些服務器在收到一個請求數據報後就會產生一個迴應數據報。全部的 Web 服務器、DNS 服務器及路 由器都是反彈服務器，他們會對 SYN 報文或其餘 TCP 報文迴應 SYNACKs 或 RST 報文， 以及對一些 IP 報文迴應 ICMP 數據報超時或目的地不可達消息的數據 報。任何用於普通目的 TCP 連 接許可的網絡服務器均可以用作數據包反射服務器

 

 

 

 

8、session劫持

       基於session的攻擊有不少種方式。大部分的手段都是首先經過捕獲合法用戶的session, 而後冒充該用戶來訪問系統。也就是說，攻擊者至少必需要獲取到一個有效的session標識符，用於接下來的身份驗證。　

      攻擊者至少能夠經過如下三種方式來獲取一個有效的session標識符:

　　一、預測：攻擊者須要猜想出系統中使用的有效的session標識符（PHP中格式爲PHPSESSID=1234），有點相似暴力破解。 php內部session的實現機制雖然不是很安全，可是關於生成session id的關節仍是比較安全的，這個隨機的session id每每是極其複雜的而且難於被預測出來，因此說，這種攻擊方式基本上是不太可能成功的。

        二、捕獲（劫持）：會話劫持（Session hijacking），這是一種經過獲取用戶Session ID後，使用該Session ID登陸目標帳號的攻擊方法，此時攻擊者其實是使用了目標帳戶的有效Session。會話劫持的第一步是取得一個合法的會話標識來假裝成合法用戶，所以須要保證會話標識不被泄漏。

                    攻擊步驟：

                    （1）目標用戶須要先登陸站點；

                    （2）登陸成功後，該用戶會獲得站點提供的一個會話標識SessionID；

                    （3）攻擊者經過某種攻擊手段捕獲Session ID；

                    （4）攻擊者經過捕獲到的Session ID訪問站點便可得到目標用戶合法會話。

                     Session劫持防護：

                    （1）更改Session名稱。PHP中Session的默認名稱是PHPSESSID，此變量會保存在Cookie中，若是攻擊者不分析站點，就不能猜到Session名稱，阻擋部分攻擊。

                    （2）關閉透明化Session ID。透明化Session ID指當瀏覽器中的Http請求沒有使用Cookie來存放Session ID時，Session ID則使用URL來傳遞。

                    （3）設置HttpOnly。經過設置Cookie的HttpOnly爲true，能夠防止客戶端腳本訪問這個Cookie，從而有效的防止XSS攻擊。

                    （4）關閉全部phpinfo類dump request信息的頁面。

                    （5） 驗證HTTP頭部信息，在http訪問頭文件：[Accept-Charset、Accept-Encoding、Accept-Language、User-Agent]，瀏覽器通常發出的頭部不會改

　　　         （6）加入Token校驗。一樣是用於檢測請求的一致性，給攻擊者製造一些麻煩，使攻擊者即便獲取了Session ID，也沒法進行破壞，可以減小對系統形成的損失。但Token須要存放在客戶端，若是攻擊者有辦法獲取到Session ID，那麼也一樣能夠獲取到Token。

        三、固定：會話固定（Session fixation）是一種誘騙受害者使用攻擊者指定的會話標識（SessionID）的攻擊手段。這是攻擊者獲取合法會話標識的最簡單的方法。（讓合法用戶使用黑客預先設置的sessionID進行登陸，從而是Web再也不進行生成新的sessionID，從而致使黑客設置的sessionId變成了合法橋樑。）

會話固定也能夠當作是會話劫持的一種類型，緣由是會話固定的攻擊的主要目的一樣是得到目標用戶的合法會話，不過會話固定還能夠是強迫受害者使用攻擊者設定的一個有效會話，以此來得到用戶的敏感信息。

      攻擊步驟： 

一、 攻擊者經過某種手段重置目標用戶的SessionID，而後監聽用戶會話狀態；

二、 目標用戶攜帶攻擊者設定的Session ID登陸站點；

三、 攻擊者經過Session ID得到合法會話

 

參考：

https://www.cnblogs.com/fundebug/p/details-about-6-web-security.html

https://blog.csdn.net/TT_love9527/article/details/82150726