**SQL 注入** 在眾多安全性漏洞中,SQL注入絕對是最嚴(yán)重但也是最好處理的一種安全漏洞。在數(shù)據(jù)庫執(zhí)行查詢句時,如果將惡意用戶給出的參數(shù)直接拼接在查詢句上,就有可能發(fā)生。 舉個例子,假設(shè)原本某網(wǎng)站登錄" />
摘要:在中加上屬性,確保僅能在自己的網(wǎng)站使用??偨Y(jié)除了文中提到的四種常見的網(wǎng)站安全漏洞外,一個網(wǎng)站還有很多細(xì)節(jié)需要考慮,例如不要用明碼存儲密碼等敏感信息,針對來源做流量限制防止等等。所以在進(jìn)行網(wǎng)站開發(fā)時要保持安全意識,盡可能做好基本的防護(hù)措施。
經(jīng)過一番 996,精心打造的網(wǎng)站眼看就要部屬上線了,但在網(wǎng)站正式上線之前,你有沒有想過自己的網(wǎng)站是否安全嗎?盡管你的網(wǎng)站用了很多高大上的技術(shù),但是如果網(wǎng)站的安全性不足,無法保護(hù)網(wǎng)站的數(shù)據(jù),甚至成為惡意程序的寄生溫床,那前面堆砌了再多的美好也都成了枉然。
SQL 注入
在眾多安全性漏洞中,SQL注入絕對是最嚴(yán)重但也是最好處理的一種安全漏洞。在數(shù)據(jù)庫執(zhí)行查詢句時,如果將惡意用戶給出的參數(shù)直接拼接在查詢句上,就有可能發(fā)生。
舉個例子,假設(shè)原本某網(wǎng)站登錄驗(yàn)證的查詢句長這樣:
而惡意用戶輸入的參數(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;"
這樣一來,賬號密碼就形同虛設(shè),甚至可以拿到整個數(shù)據(jù)庫的結(jié)構(gòu)(SELECT * FROM sys.tables)、任意修改、查詢數(shù)據(jù),整個網(wǎng)站的數(shù)據(jù)就全部泄露了。
不過解決方法也很簡單,只要通過參數(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)容時。例如論壇、留言板等可以輸入任意文字的網(wǎng)站,惡意用戶如果寫入一小段
看起來很恐怖,那么該如何解決呢?除了前面所說的 CSRF Token 外,許多大公司還采用了另一種有趣的解決方式。即 API 的響應(yīng)內(nèi)容開頭為 for (;;);,這也是利用 了