Web安全與防禦措施
阿新 • • 發佈:2019-01-05
- 服務攻擊:針對程式漏洞進行攻擊常見的有:
- SQL注入攻擊
- 檔案上傳攻擊
- XSS跨站指令碼攻擊
- CSRF(Cross-site request forgery)跨站請求偽造
- 程式邏輯漏洞
- 暴力攻擊:如DDOS,窮舉密碼等
- C段攻擊 某臺伺服器被攻陷後通過內網進行ARP、DNS等內網攻擊
- 社會工程學 收集管理員等個人資訊等資料嘗試猜測其密碼或者取得信任等
最基本原則
永遠不要相信使用者提交上來的資料(包括header\cookie\seesionId),都可能造假
sql注入
原理:
後臺的SQL語句通過字串拼接後後導致執行各種意想不到的語句,配合sql語句的outfile功能,還能寫入一個指令碼檔案到伺服器。
例子:
- 比如根據使用者post來的ID來列出單個人的資訊 假設使用者提交的
id=1
拼接出來為select * from table where id=1
這時執行正常假設使用者提交的為id=1 and 1=1
拼接出來為select * from table where and 1=1
這時執行異常,所以內容都被查出來了 - 又如根據使用者提交的
job_rul=xxx
來拼接,但是攻擊者提交了job_rul=sql' or 1=1 limit 1--
//正常的語句 select * from job_info where job_url='sql' limt 10 //攻擊者提交的 “sql' or 1=1 limit 1-- ”後 變成下面這樣 注意--後面有空格 select * from job_info where job_url='
預防:
- 在SQL拼接時注意過濾替換使用者輸入的字串(但是本人不推薦這種方式)
- 最安全的是mysql的預編譯prepare,PHP的PDO將其實現了。因為語句先編譯好了,使用者怎麼傳都是一個引數。
檔案上傳攻擊
沒有過濾就接收使用者上傳的檔案(如.php
等檔案)或者沒有給檔案重新命名,最後通過攻擊者通過web請求導致惡意指令碼呼叫被執行
常見漏洞
- CGI漏洞 IIS7.5以下,nginx < 0.8.x通過
123.jpg/1.php
- apache,IIS解析漏洞
123.php.jpg
apache當成php來執行(IIS6,實測apache2.2.xx有這個問題,2.4.xx已經修復)
攻擊原理:攻擊者上傳帶有惡意指令碼的123.jpg
到網站,獲得了http://url.com/123.jpg
這個檔案路徑,然後通過http://url.com/123.jpg/1.php
觸發123.jpg所帶的程式程式碼
預防:
- 使用者上傳的檔案要重新命名,這樣的話即便攻擊者上傳了
.php
,.sh
等指令碼上來也會被重新命名成指定的檔案型別(如jpg)導致無法被攻擊者執行 - 確保使用的apache nginx等版本到最穩定的安全版本。
XSS攻擊
原理:
反射型: 比如根據$_GET['username']
顯示到網頁上 有可能被人username=<script src='xxx'></script>
注入程式碼發給使用者點選從而被攻擊.也有可能JS讀取了URL部分欄位導致的儲存型:通過發表文章等把程式碼存入資料庫別人看的時候沒過濾就執行出來。危害:盜取管理員密碼 cookie 控制使用者ajax等。預防:入庫過濾和顯示時過濾(htmlspeicalchar命令等)
csrf攻擊
原理:
被攻擊網站:使用者登入後因為session緣故,瀏覽器關閉前所有請求都是合法的(不用再精彩賬號密碼認證了)當用戶登入了網站A
,這時候訪問黑客的網站B
,B
站的js程式碼控制使用者去呼叫網站A的一個指令碼:
GET
方式 如<img src="http://A.com/deletePost.php">
這樣就相當於以使用者的身份去觸發了對A站http://A.com/deletePost.php
指令碼的操作POST
這種方式要複雜一點,但是還是可以被攻擊者利用(構造一個隱藏的html表單,通過js去提交到站點A)以使用者的名義去觸發操作,比如刪除修改密碼等,配合XSS攻擊效果更明顯。
預防:
採用驗證碼,token,敏感操作避免GET(因為可以src等方式觸發)
邏輯漏洞
比如刪除(或修改)使用者資訊通過GET或POST id=2
這樣去修改資訊支付漏洞:使用者提交上來的商品數量為負數-10
導致總價變化
轉自:http://www.51glacier.com/blog/web-safe.html