摘要: 安全第一!javascript
Fundebug遵循創意共享3.0許可證轉載,版權歸原做者全部。php
SQL 注入就是經過給 web 應用接口傳入一些特殊字符,達到欺騙服務器執行惡意的 SQL 命令。html
SQL 注入漏洞屬於後端的範疇,但前端也可作體驗上的優化。前端
緣由java
當使用外部不可信任的數據做爲參數進行數據庫的增、刪、改、查時,若是未對外部數據進行過濾,就會產生 SQL 注入漏洞。git
好比:github
name = "外部輸入名稱";
sql = "select * from users where name=" + name;
複製代碼
上面的 SQL 語句目的是經過用戶輸入的用戶名查找用戶信息,由於因爲 SQL 語句是直接拼接的,也沒有進行過濾,因此,當用戶輸入 '' or '1'='1'
時,這個語句的功能就是搜索 users
全表的記錄。web
select * from users where name='' or '1'='1';
複製代碼
解決方案sql
具體的解決方案不少,但大部分都是基於一點:不信任任何外部輸入。shell
因此,對任何外部輸入都進行過濾,而後再進行數據庫的增、刪、改、查。
此外,適當的權限控制、不曝露必要的安全信息和日誌也有助於預防 SQL 注入漏洞。
參考 Web 安全漏洞之 SQL 注入 - 防護方法 瞭解具體的解決方案。
推薦參考
XSS 攻擊全稱跨站腳本攻擊(Cross-Site Scripting),簡單的說就是攻擊者經過在目標網站上注入惡意腳本並運行,獲取用戶的敏感信息如 Cookie、SessionID 等,影響網站與用戶數據安全。
XSS 攻擊更偏向前端的範疇,但後端在保存數據的時候也須要對數據進行安全過濾。
緣由
當攻擊者經過某種方式向瀏覽器頁面注入了惡意代碼,而且瀏覽器執行了這些代碼。
好比:
在一個文章應用中(如微信文章),攻擊者在文章編輯後臺經過注入 script
標籤及 js
代碼,後端未加過濾就保存到數據庫,前端渲染文章詳情的時候也未加過濾,這就會讓這段 js
代碼執行,引發 XSS 攻擊。
解決方案
一個基本的思路是渲染前端頁面(不論是客戶端渲染仍是服務器端渲染)或者動態插入 HTML 片斷時,任何數據都不可信任,都要先作 HTML 過濾,而後再渲染。
參考 前端安全系列(一):如何防止XSS攻擊? - 攻擊的預防 瞭解具體的解決方案。
推薦參考
CSRF 攻擊全稱跨站請求僞造(Cross-site Request Forgery),簡單的說就是攻擊者盜用了你的身份,以你的名義發送惡意請求。
緣由
一個典型的 CSRF 攻擊有着以下的流程:
a.com
,並保留了登陸憑證(Cookie)b.com
b.com
向 a.com
發送了一個請求:a.com/act=xx
(瀏覽器會默認攜帶 a.com
的 Cookie)a.com
接收到請求後,對請求進行驗證,並確認是受害者的憑證,誤覺得是受害者本身發送的請求a.com
以受害者的名義執行了 act=xx
a.com
執行了本身定義的操做注:上面的過程摘自 前端安全系列之二:如何防止CSRF攻擊?
解決方案
防止 CSRF 攻擊須要在服務器端入手,基本的思路是能正確識別是不是用戶發起的請求。
參考 前端安全系列之二:如何防止CSRF攻擊? - 防禦策略 瞭解具體的解決方案。
推薦參考
DoS 攻擊全稱拒絕服務(Denial of Service),簡單的說就是讓一個公開網站沒法訪問,而 DDoS 攻擊(分佈式拒絕服務 Distributed Denial of Service)是 DoS 的升級版。
這個就徹底屬於後端的範疇了。
緣由
攻擊者不斷地提出服務請求,讓合法用戶的請求沒法及時處理,這就是 DoS 攻擊。
攻擊者使用多臺計算機或者計算機集羣進行 DoS 攻擊,就是 DDoS 攻擊。
解決方案
防止 DDoS 攻擊的基本思路是限流,限制單個用戶的流量(包括 IP 等)。
參考 DDoS的攻擊及防護 - 防護 瞭解具體的解決方案。
推薦參考
XXE 漏洞全稱 XML 外部實體漏洞(XML External Entity),當應用程序解析 XML 輸入時,若是沒有禁止外部實體的加載,致使可加載惡意外部文件和代碼,就會形成任意文件讀取、命令執行、內網端口掃描、攻擊內網網站等攻擊。
這個只在可以接收 XML 格式參數的接口才會出現。
解決方案
參考 xxe漏洞的學習與利用總結 瞭解具體的解決方案。
推薦參考
JSON 劫持(JSON Hijacking)是用於獲取敏感數據的一種攻擊方式,屬於 CSRF 攻擊的範疇。
緣由
一些 Web 應用會把一些敏感數據以 json 的形式返回到前端,若是僅僅經過 Cookie 來判斷請求是否合法,那麼就能夠利用相似 CSRF 的手段,向目標服務器發送請求,以得到敏感數據。
好比下面的連接在已登陸的狀況下會返回 json 格式的用戶信息:
http://www.test.com/userinfo
複製代碼
攻擊者能夠在本身的虛假頁面中,加入以下標籤:
<script src="http://www.test.com/userinfo"></script>
複製代碼
若是當前瀏覽器已經登陸了 www.test.com
,而且 Cookie 未過時,而後訪問了攻擊者的虛假頁面,那麼該頁面就能夠拿到 json 形式的用戶敏感信息,由於 script
標籤會自動解析 json 數據,生成對應的 js 對象。而後再經過:
Object.prototype.__defineSetter__
複製代碼
這個函數來觸發本身的惡意代碼。
可是這個函數在當前的新版本 Chrome 和 Firefox 中都已經失效了。
注:上面的過程摘自 JSON和JSONP劫持以及解決方法
解決方案
X-Requested-With
標識推薦參考
這個通常針對密碼而言,弱密碼(Weak Password)很容易被別人(對你很瞭解的人等)猜到或被破解工具暴力破解。
解決方案
HTTP/1.1(RFC2616)規範定義了 HTTP TRACE 方法,主要是用於客戶端經過向 Web 服務器提交 TRACE 請求來進行測試或得到診斷信息。
當 Web 服務器啓用 TRACE 時,提交的請求頭會在服務器響應的內容(Body)中完整的返回,其中 HTTP 頭極可能包括 Session Token、Cookies 或其它認證信息。攻擊者能夠利用此漏洞來欺騙合法用戶並獲得他們的私人信息。
解決方案
禁用 HTTP TRACE 方法。
因爲 Web 服務器或應用程序沒有正確處理一些特殊請求,泄露 Web 服務器的一些敏感信息,如用戶名、密碼、源代碼、服務器信息、配置信息等。
因此通常需注意:
攻擊者向 Web 服務器發送請求,經過在 URL 中或在有特殊意義的目錄中附加 ../
、或者附加 ../
的一些變形(如 ..\
或 ..//
甚至其編碼),致使攻擊者可以訪問未受權的目錄,以及在 Web 服務器的根目錄之外執行命令。
命令執行漏洞是經過 URL 發起請求,在 Web 服務器端執行未受權的命令,獲取系統信息、篡改系統配置、控制整個系統、使系統癱瘓等。
若是對文件上傳路徑變量過濾不嚴,而且對用戶上傳的文件後綴以及文件類型限制不嚴,攻擊者可經過 Web 訪問的目錄上傳任意文件,包括網站後門文件(webshell
),進而遠程控制網站服務器。
因此通常需注意:
webshell
攻擊通常業務漏洞是跟具體的應用程序相關,好比參數篡改(連續編號 ID / 訂單、1 元支付)、重放攻擊(假裝支付)、權限控制(越權操做)等。
另外能夠參考:6種常見web漏洞坑
更多博客,查看 github.com/senntyou/bl…
版權聲明:自由轉載-非商用-非衍生-保持署名(創意共享3.0許可證)