這是我參與8月更文挑戰的第7天,活動詳情查看:8月更文挑戰程序員
繼以前聊到了 Web 安全以後,好多朋友也在關注這個話題,今天特地再寫一篇。正則表達式
安全世界觀一詞是《白帽子講 Web 安全》一書的開篇章節,多年後再讀經典,仍然受益不淺!算法
正如開篇所說的:「互聯網原本是安全的,自從有了研究安全的人,互聯網就不安全了。」 世上沒有攻不破的系統,只有還沒攻破的系統,有多少條路能夠通羅馬,大概就有多少種攻克之道。數據庫
「破壞每每比建設容易」,但凡事都不是絕對的。後端
跟機場安全檢查進行類比。經過一個安全檢查(過濾,淨化)的過程,能夠梳理未知的人或物,使其變得可信任。被劃分出來的具備不一樣信任級別的區域,咱們成爲信任域,劃分兩個不一樣信任域之間的邊界,咱們稱之爲信任邊界。安全
數據從高等級的信任域流向低等級的信任域,是不須要通過安全檢查的;數據從低等級的信任域流向高等級的信任域,是須要通過信任邊界的安全檢查。服務器
安全問題的本質是信任的問題。markdown
一切的安全方案設計的基礎,都是創建在信任關係上的。咱們必須相信一些東西,必需要有一些最基本的假設,安全方案才能得以創建。cookie
安全的三要素是安全的基本組成元素,分別爲:網絡
機密性要求數據內容不能泄露,加密是實現機密性要求的常見手段。若是不將文件存在抽屜裏,而是放在透明的盒子裏,那麼雖然沒法獲得這個文件,可是文件的內容將會被泄露。
完整性則要求保護數據內容是完整,沒有被篡改的。常見的保證一致性的技術手段是數字簽名。
可用性要求保護資源是「隨需而得」。
舉例來講,假若有 100 個車位,有一天一個壞人搬了 100 塊大石頭將車位全佔了,那麼停車場沒法再提供正常服務。在安全領域中叫作拒絕服務攻擊,簡稱 DoS(Denial of Service)。拒絕服務攻擊破壞的是安全的可用性。
1)黑名單、白名單
實際上,Secure By Default 原則,也能夠概括爲白名單,黑名單的思想。若是更多地使用白名單,那麼系統就會變得更安全。
2)最小權限原則
最小原則要求系統只授予主體必要的權限,而不要過分受權,這樣能有效地減小系統,網絡,應用,數據庫出錯的機會。
若是網站只提供 Web 服務,只容許開啓 80,443 端口,屏蔽其它端口。
縱深防護原則包含兩層含義:
1)要在各個不一樣層面,不一樣方面實施安全方案,避免出現疏漏,不一樣安全方案之間須要相互配合,構成一個總體;
2)要在正確的地方作正確的事情,即:在解決根本問題的地方實施針對性的安全方案。
這一原則適用於各類因爲「注入」而引起安全問題的場景。
實際上,緩衝區溢出,也能夠認爲是程序違背了這一原則的後果——程序在棧或者堆中,將用戶數據當作代碼執行,混淆了代碼與數據的邊界,從而致使安全問題的發生。
微軟使用的 ASLR 技術,在較新版本的 Linux 內核中也支持。在 ASLR 的控制下,一個程序每次啓動時,其進程的棧基址都不相同,具備必定的隨機性,對於攻擊者來講,這就是「不可預測性」。
不可預測性,能有效地對抗基於篡改,僞造的攻擊。
不可預測性的實現每每須要用到加密算法,隨機數算法,哈希算法,好好利用這條規則,在設計安全方案時每每會事半功倍。
XSS (Cross Site Script),跨站腳本攻擊,由於縮寫和 CSS (Cascading Style Sheets) 重疊,因此只能叫 XSS。
XSS 的原理是惡意攻擊者往 Web 頁面裏插入惡意可執行網頁腳本代碼,當用戶瀏覽該頁之時,嵌入其中 Web 裏面的腳本代碼會被執行,從而能夠達到攻擊者盜取用戶信息或其餘侵犯用戶安全隱私的目的。XSS 的攻擊方式變幻無窮,但仍是能夠大體細分爲幾種類型:
非持久型 XSS
也叫反射型 XSS 漏洞,通常是經過給別人發送帶有惡意腳本代碼參數的 URL,當 URL 地址被打開時,特有的惡意代碼參數被 HTML 解析、執行。
持久型 XSS
持久型 XSS 攻擊不須要誘騙點擊,黑客只須要在提交表單的地方完成注入便可,可是這種 XSS 攻擊的成本相對仍是很高。
未經驗證的跳轉 XSS
一些場景是後端須要對一個傳進來的待跳轉的 URL 參數進行一個 302 跳轉,可能其中會帶有一些用戶的敏感(cookie)信息。
CSRF(Cross-Site Request Forgery),名爲:跨站請求僞造攻擊。
那麼 CSRF 到底可以幹嗎呢?
你能夠這樣簡單的理解:攻擊者能夠盜用你的登錄信息,以你的身份模擬發送各類請求。攻擊者只要藉助少量的社會工程學的詭計。
例如經過 QQ 等聊天軟件發送的連接(有些還假裝成短域名,用戶沒法分辨),攻擊者就能迫使 Web 應用的用戶去執行攻擊者預設的操做。例如,當用戶登陸網絡銀行去查看其存款餘額,在他沒有退出時,就點擊了一個 QQ 好友發來的連接,那麼該用戶銀行賬戶中的資金就有可能被轉移到攻擊者指定的賬戶中。
因此遇到 CSRF 攻擊時,將對終端用戶的數據和操做指令構成嚴重的威脅。當受攻擊的終端用戶具備管理員賬戶的時候,CSRF 攻擊將危及整個 Web 應用程序。
CSRF 原理
下圖大概描述了 CSRF 攻擊的原理:
CSRF 攻擊必需要有三個條件 :
1. 用戶已經登陸了站點 A,並在本地記錄了 cookie
2 . 在用戶沒有登出站點 A 的狀況下(也就是 cookie 生效的狀況下),訪問了惡意攻擊者提供的引誘危險站點 B (B 站點要求訪問站點 A)。
3 . 站點 A 沒有作任何 CSRF 防護
預防 CSRF
CSRF 的防護能夠從服務端和客戶端兩方面着手,防護效果是從服務端着手效果比較好,如今通常的 CSRF 防護也都在服務端進行。服務端的預防 CSRF 攻擊的方式方法有多種,但思路上都是差很少的,主要從如下兩個方面入手 :
1 . 正確使用 GET,POST 請求和 cookie
2 . 在非 GET 請求中增長 token
CSRF 的防護能夠根據應用場景的不一樣自行選擇。CSRF 的防護工做確實會在正常業務邏輯的基礎上帶來不少額外的開發量,可是這種工做量是值得的,畢竟用戶隱私以及財產安全是產品最基礎的根本。
SQL 注入漏洞(SQL Injection)是 Web 開發中最多見的一種安全漏洞。攻擊者利用這個漏洞,能夠訪問或修改數據,或者利用潛在的數據庫漏洞進行攻擊。
而形成 SQL 注入的緣由是由於程序沒有有效的轉義過濾用戶的輸入,使攻擊者成功的向服務器提交惡意的 SQL 查詢代碼,程序在接收後錯誤的將攻擊者的輸入做爲查詢語句的一部分執行,致使原始的查詢邏輯被改變,額外的執行了攻擊者精心構造的惡意代碼。
如何預防
防止 SQL 注入主要是不能容許用戶輸入的內容影響正常的 SQL 語句的邏輯,當用戶的輸入信心將要用來拼接 SQL 語句的話,咱們應該永遠選擇不相信,任何內容都必須進行轉義過濾,固然作到這個仍是不夠的,下面列出防護 SQL 注入的幾點注意事項:
嚴格限制 Web 應用的數據庫的操做權限,給此用戶提供僅僅可以知足其工做的最低權限,從而最大限度的減小注入攻擊對數據庫的危害;
後端代碼檢查輸入的數據是否符合預期,嚴格限制變量的類型,例如使用正則表達式進行一些匹配處理;
對進入數據庫的特殊字符(',",\,<,>,&,*,; 等)進行轉義處理,或編碼轉換;
全部的查詢語句建議使用數據庫提供的參數化查詢接口,參數化的語句使用參數而不是將用戶輸入變量嵌入到 SQL 語句中,即不要直接拼接 SQL 語句。
DDoS 又叫分佈式拒絕服務,全稱 Distributed Denial of Service。
其原理就是利用大量的請求形成資源過載,致使服務不可用,這個攻擊應該不能算是安全問題,這應該算是一個另類的存在,由於這種攻擊根本就是耍流氓的存在,「傷敵一千,自損八百」的行爲。
DDoS 攻擊能夠理解爲:「你開了一家店,隔壁家店看不慣,就僱了一大堆黑社會人員進你店裏乾坐着,也不消費,其餘客人也進不來,致使你營業慘淡」。
也許你的站點遭受過 DDoS 攻擊,具體什麼緣由怎麼解讀見仁見智。DDos 攻擊從層次上可分爲網絡層攻擊與應用層攻擊,從攻擊手法上可分爲快型流量攻擊與慢型流量攻擊,但其原理都是形成資源過載,致使服務不可用。
主要分類
網絡層的 DDoS 攻擊究其本質實際上是沒法防護的,咱們能作得就是不斷優化服務自己部署的網絡架構,以及提高網絡帶寬。
應用層 DDoS 攻擊不是發生在網絡層,是發生在 TCP 創建握手成功以後,應用程序處理請求的時候,如今不少常見的 DDoS 攻擊都是應用層攻擊。
應用層的防護有時比網絡層的更難,由於致使應用層被 DDoS 攻擊的因素很是多,有時每每是由於程序員的失誤,致使某個頁面加載須要消耗大量資源,有時是由於中間件配置不當等等。
而應用層 DDoS 防護的核心就是區分人與機器(爬蟲),由於大量的請求不多是人爲的,確定是機器構造的。所以若是能有效的區分人與爬蟲行爲,則能夠很好地防護此攻擊。
Web 安全的對於 Web 從業人員來講是一個很是重要的課題。本文介紹了安全世界觀,以及常見 Web 相關的三種安全防護知識,但願你們之後的工做中不要誤入踩雷,但願對你們有所幫助!
安全是一門樸素的學問,也是一種平衡的藝術,不管是傳統安全,仍是互聯網安全,其內在原理都是同樣的。咱們只需抓住安全問題的本質,以後不管遇到任何安全問題,都會無往而不利!
做者:架構精進之路,十年研發風雨路,大廠架構師,CSDN 博客專家,專一架構技術沉澱學習及分享,職業與認知升級,堅持分享接地氣兒的乾貨文章,期待與你一塊兒成長。
關注並私信我回復「01」,送你一份程序員成長進階大禮包,歡迎勾搭。
Thanks for reading!