常見的網(wǎng)站安全問題

2022-10-03    分類: 網(wǎng)站建設(shè)

盡管你的網(wǎng)站用了很多高大上的技術(shù),但是如果網(wǎng)站的安全性不足,無法保護(hù)網(wǎng)站的數(shù)據(jù),甚至成為惡意程序的寄生溫床,那前面堆砌了再多的美好也都成了枉然。

常見的網(wǎng)站安全問題

SQL注入

在眾多安全性漏洞中,SQL 注入絕對(duì)是最嚴(yán)重但也是最好處理的一種安全漏洞。在數(shù)據(jù)庫執(zhí)行查詢句時(shí),如果將惡意用戶給出的參數(shù)直接拼接在查詢句上,就有可能發(fā)生。

舉個(gè)例子,假設(shè)原本某網(wǎng)站登錄驗(yàn)證的查詢句長這樣:

strSQL = "SELECT * FROM users WHERE (name = '" + userName + "') and (pw = '"+ passWord +"');" 

而惡意用戶輸入的參數(shù)為:

userName = "1' OR '1'='1";  passWord = "1' OR '1'='1"; 

由于代碼中是直接將參數(shù)與查詢句做字串做的拼接,所以 SQL 就成為了這樣:

strSQL = "SELECT * FROM users WHERE (name = '1' OR '1'='1') and (pw = '1' OR '1'='1');"  // 相當(dāng)于  strSQL = "SELECT * FROM users;" 

這樣一來,賬號(hào)密碼就形同虛設(shè),甚至可以拿到整個(gè)數(shù)據(jù)庫的結(jié)構(gòu)(SELECT * FROM sys.tables)、任意修改、查詢數(shù)據(jù),整個(gè)網(wǎng)站的數(shù)據(jù)就全部泄露了。

常見的網(wǎng)站安全問題

不過解決方法也很簡單,只要通過參數(shù)化查詢來避免直接將參數(shù)與查詢句拼接,并進(jìn)行適當(dāng)?shù)妮斎霗z查、插入轉(zhuǎn)義字符、嚴(yán)格設(shè)定程序權(quán)限,就能夠有效避免 SQL 注入了。

XSS

XSS(跨站攻擊)也叫JavaScript 注入,是現(xiàn)代網(wǎng)站最頻繁出現(xiàn)的問題之一,它指的是網(wǎng)站被惡意用戶植入了其他代碼,通常發(fā)生在網(wǎng)站將用戶輸入的內(nèi)容直接放到網(wǎng)站內(nèi)容時(shí)。例如論壇、留言板等可以輸入任意文字的網(wǎng)站,惡意用戶如果寫入一小段 <script>,并且前、后端都沒有針對(duì)輸入內(nèi)容做字符轉(zhuǎn)換和過濾處理,直接把用戶輸入的字串作為頁面內(nèi)容的話,就有可能遭到 XSS。

常見的 XSS 有幾個(gè)類型:將惡意代碼寫入數(shù)據(jù)庫,當(dāng)數(shù)據(jù)被讀取出來時(shí)就會(huì)執(zhí)行的儲(chǔ)存型 XSS;將用戶輸入的內(nèi)容直接帶回頁面上的反射型 XSS;以及利用 DOM 的特性,各種花式執(zhí)行惡意代碼的DOM-based 型 XSS。

儲(chǔ)存型及反射型都很好理解,DOM-based 型就非常有意思了;可以參考OSWAP 整理的XSS Filter Evasion Cheat Sheet[1],絕大多數(shù)的 XSS 方式,都是通過各個(gè)元素的 background-image 屬性或者元素上的各種事件回調(diào)來實(shí)現(xiàn);其中特別值得注意的是 SVG,由于 SVG 中可以寫入任意 HTML,還可以加上 onload 事件,如果把 SVG 當(dāng)成普通圖片處理,直接作為網(wǎng)站內(nèi)容使用,如果遇到惡意用戶的話,后果不堪設(shè)想。所以在上線上傳圖片功能時(shí),務(wù)必要把 SVG 過濾掉!

避免 XSS 的方法其實(shí)也很簡單,只要在數(shù)據(jù)輸入輸出時(shí)做好字符轉(zhuǎn)換,使惡意代碼不被執(zhí)行,而是被解析成字符就可以了。

CSRF

CSRF(跨站請(qǐng)求偽造)是一種利用 Cookie 及 Session 認(rèn)證機(jī)制進(jìn)行攻擊的手段;由于 Session 認(rèn)證的其實(shí)不是用戶本人,而是瀏覽器,那么只要通過網(wǎng)頁DOM 元素可以跨域的機(jī)制,對(duì)已經(jīng)得到認(rèn)證的網(wǎng)站發(fā)出請(qǐng)求,就可以假冒用戶,從而拿到敏感信息。

例如某家銀行的轉(zhuǎn)賬 API 的URL 是這樣的:

http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName 

而惡意用戶如果在網(wǎng)站中塞進(jìn)一個(gè) 常見的網(wǎng)站安全問題 的話:

<img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman"> 

當(dāng)不知情的用戶瀏覽到攻擊者的網(wǎng)站時(shí),常見的網(wǎng)站安全問題 會(huì)自動(dòng)發(fā)出這個(gè)請(qǐng)求,如果用戶登錄銀行的 Session 尚未過期,那么這個(gè)請(qǐng)求很可能就會(huì)被銀行接受,最后會(huì)在用戶本人不知情的情況下“被”轉(zhuǎn)帳。

這種攻擊方式可以與前面所說的 XSS 是相輔相成,例如在沒有防范 XSS 的論壇網(wǎng)站中植入 常見的網(wǎng)站安全問題,那么其 src 屬性就應(yīng)該是獲取敏感信息的 API URL。

解決方法主要有以下幾種:

檢查 Referer:在服務(wù)器端檢查請(qǐng)求頭中 Referer 的值,也就是檢查請(qǐng)求的來源,如果是來自允許的網(wǎng)站,才會(huì)正常執(zhí)行 API 的功能。 CSRF Token:在 Cookie 及請(qǐng)求發(fā)送的數(shù)據(jù)中都加上 csrftoken,并檢查值是否相同,如果請(qǐng)求來源是自己的網(wǎng)站驗(yàn)證就會(huì)通過;反之,由于外部網(wǎng)站無法在代碼中得到其他網(wǎng)站的 Cookie,因此無法在請(qǐng)求中帶上 csrftoken。 SameSite Cookie:在 Cookie 中加上 SameSite 屬性,確保 Cookie 僅能在自己的網(wǎng)站使用。

JSON 劫持

JSON 劫持是利用現(xiàn)代網(wǎng)站前后端通過 API 進(jìn)行數(shù)據(jù)交換的特性,只要能獲得使用者權(quán)限,并調(diào)用獲取資料的 API,再加上改寫原生的 JavaScript 對(duì)象,就可以竊取用戶的敏感信息。

獲得權(quán)限的部分于 CSRF 相同,通過 <script> 可以跨域的特性直接使用瀏覽器用戶的 Cookie;攻擊者只需要在網(wǎng)頁上通過 <script> 調(diào)用獲取數(shù)據(jù)的 API 完成對(duì)數(shù)據(jù)的竊取。

例如:

Object.prototype.__defineSetter__('user',function(obj){    for(var i in obj) {      alert(i + '=' + obj[i]);    }  }); 

當(dāng)回傳的數(shù)據(jù)中含有 user 屬性時(shí),由于 Setter 通過 Object.prototype.__defineSetter__ 改寫了,user 中的值會(huì)被全部讀取。

然而 Object.prototype.__defineSetter__ 可以修改原生對(duì)象所造成的問題,早已經(jīng)在 ES4 中就被修復(fù)了,JSON 劫持也因此銷聲匿跡,但是從 ES6 開始又添加了 Proxy,使 JSON 劫持又再次成為可能:

<script>  <script>    Object.setPrototypeOf(      __proto__,      new Proxy(__proto__, {        has: function(target, name) {          alert(            name.replace(/./g, function(c) {              c = c.charCodeAt(0)              return String.fromCharCode(c >> 8, c & 0xff)            })          )        }      })    )  </script>  <script charset="UTF-16BE" src="external-script-with-array-literal"></script> 

看起來很恐怖,那么該如何解決呢?除了前面所說的 CSRF Token 外,許多大公司還采用了另一種有趣的解決方式。即 API 的響應(yīng)內(nèi)容開頭為 for (;;);,這也是利用 了<script> 引入的 JavaScript 會(huì)立即執(zhí)行的特性,把攻擊者的網(wǎng)站卡死在循環(huán)里。

總結(jié)

除了文中提到的四種常見的網(wǎng)站安全漏洞外,一個(gè)網(wǎng)站還有很多細(xì)節(jié)需要考慮,例如不要用明碼存儲(chǔ)密碼等敏感信息,針對(duì)來源 IP 做流量限制防止 DOS 等等。所以在進(jìn)行網(wǎng)站開發(fā)時(shí)要保持安全意識(shí),盡可能做好基本的防護(hù)措施。

標(biāo)題名稱:常見的網(wǎng)站安全問題
標(biāo)題URL:http://www.muchs.cn/news48/201248.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供云服務(wù)器、服務(wù)器托管、品牌網(wǎng)站設(shè)計(jì)、App設(shè)計(jì)小程序開發(fā)、定制開發(fā)

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)

外貿(mào)網(wǎng)站制作