微服務(wù)
安全問(wèn)題
1. 如何防范常見(jiàn)的Web攻擊幽七、如何防范SQL注入
1.1 DoS和DDoS攻擊
Denial of Service拒絕服務(wù)茎活，造成遠(yuǎn)程服務(wù)器拒絕服務(wù)的攻擊行為疑枯。其目的是使計(jì)算機(jī)或網(wǎng)絡(luò)無(wú)法提供正常的服務(wù)硬爆。最常見(jiàn)的DoS攻擊有計(jì)算機(jī)網(wǎng)絡(luò)帶寬攻擊和連通性攻擊呻拌。
1.2 CSRF攻擊
Cross Site Request Forgery跨站請(qǐng)求偽造膀藐。
HTTP Referer是header的一部分萌朱，當(dāng)瀏覽器向web服務(wù)器發(fā)送請(qǐng)求時(shí)宴树，一般會(huì)帶上Referer信息告訴服務(wù)器是從哪個(gè)頁(yè)面鏈接過(guò)來(lái)的，服務(wù)器籍此可以獲得一些信息用于處理晶疼【票幔可以通過(guò)檢查請(qǐng)求的來(lái)源來(lái)防御CSRF攻擊。
1.3 XSS攻擊
Cross Site Scripting跨站腳本攻擊翠霍。
惡意攻擊者往Web頁(yè)面里注入惡意Script代碼锭吨，當(dāng)用戶瀏覽這些網(wǎng)頁(yè)時(shí)，就會(huì)執(zhí)行其中的惡意代碼寒匙，可對(duì)用戶進(jìn)行盜取cookie信息耐齐、會(huì)話劫持等各種攻擊。
開發(fā)需盡量避免Web客戶端文檔重寫蒋情、重定向或其他敏感操作埠况，同時(shí)要避免使用客戶端數(shù)據(jù)，這些操作需盡量在服務(wù)器端使用動(dòng)態(tài)頁(yè)面來(lái)實(shí)現(xiàn)棵癣。
1.4 SQL注入攻擊
SQL Injection辕翰，應(yīng)用程序在向后臺(tái)數(shù)據(jù)庫(kù)傳遞SQL(Structured Query Language，結(jié)構(gòu)化查詢語(yǔ)言)時(shí)狈谊，攻擊者將SQL命令插入到Web表單提交或輸入域名或頁(yè)面請(qǐng)求的查詢字符串喜命，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令。
除過(guò)使用preparedStatement之外河劝，可以使用數(shù)據(jù)轉(zhuǎn)義來(lái)防范sql注入壁榕。此外可以通過(guò)限制用戶的輸入來(lái)防范。
參考：
《Web常見(jiàn)幾種攻擊與預(yù)防方式》
2. 服務(wù)端通信安全攻防
2.1 Base64加密傳輸
Base64是網(wǎng)絡(luò)上最常見(jiàn)的用于傳輸8Bit字節(jié)代碼的編碼方式之一赎瞎，但是它其實(shí)并不是一種用于安全領(lǐng)域的加密解密算法牌里。
但是，Base64編碼的數(shù)據(jù)并不會(huì)被人用肉眼所直觀的理解，所以也有人使用Base64來(lái)進(jìn)行加密解密牡辽，這里所說(shuō)的加密與解密實(shí)際是指編碼和解碼的過(guò)程喳篇。
這種，加密傳輸?shù)陌踩允欠浅５偷奶粒珺ase64加密非常容易被人識(shí)別并解碼麸澜。
2.2 DES對(duì)稱加密
DES也是一種非常常用的加密方案，我們會(huì)將敏感的信息在通信過(guò)程中通過(guò)DES進(jìn)行加密傳輸奏黑，然后在客戶端和服務(wù)端直接進(jìn)行解碼炊邦。
此時(shí)，作為讀者的你熟史，可能會(huì)有個(gè)疑問(wèn)铣耘，那如何保管密鑰呢？其實(shí)以故，想想蜗细，答案就復(fù)出水面了，因?yàn)榭蛻舳撕头?wù)端都需要進(jìn)行解碼怒详，所以兩者都要存一份密鑰炉媒。其實(shí)，還有一種方案是通過(guò)服務(wù)端下發(fā)昆烁，但是下發(fā)的時(shí)候通信的安全性也是沒(méi)有很好的保障吊骤。
所以，DES對(duì)稱加密也是存在一定的安全隱患：密鑰可能會(huì)泄漏静尼。這邊白粉，舉個(gè)真實(shí)的案例，某個(gè)APP的資源不錯(cuò)鼠渺，同事想抓包分析下其服務(wù)端通信的信息結(jié)構(gòu)鸭巴，但是發(fā)現(xiàn)它既然全部采用了DES加密方案，本來(lái)想放棄了拦盹，但是我們又回頭想想客戶端肯定需要密鑰對(duì)接口的加密的內(nèi)容做解碼才能正常展現(xiàn)鹃祖，那么密鑰肯定在app包中，因此我們又對(duì)app進(jìn)行了反編譯普舆，結(jié)果成功的獲取到了密鑰恬口，對(duì)服務(wù)端通信的加密信息進(jìn)行了解碼。
2.3 AES對(duì)稱加密
AES和DES類似沼侣，相較于DES算法而言祖能，AES算法有著更高的速度和資源使用效率，安全級(jí)別也較之更高蛾洛。一般情況下养铸，用于文件的加密。我們之前做個(gè)不準(zhǔn)確測(cè)試，AES和DES分別對(duì)一個(gè)大文件加密揭厚，AES的速度大概是DES的5倍。（因?yàn)榛诠ぞ吆铜h(huán)境問(wèn)題扶供，這個(gè)數(shù)據(jù)不是很準(zhǔn)確喲）筛圆。
仍然存在一個(gè)相同的問(wèn)題：密鑰可能會(huì)泄漏。因此椿浓，保管好密鑰很關(guān)鍵太援。
2.4 升級(jí)到HTTPS
這個(gè)可以參考上篇博客《HTTPS原理剖析與項(xiàng)目場(chǎng)景》的內(nèi)容。
HTTPS的價(jià)值在于：
內(nèi)容加密扳碍，第三方無(wú)法竊聽(tīng)提岔。
身份認(rèn)證，一旦被篡改笋敞，通信雙方會(huì)立刻發(fā)現(xiàn)碱蒙。
數(shù)據(jù)完整性。防止內(nèi)容冒充或者篡改夯巷。
這個(gè)方案赛惩，沒(méi)法保護(hù)敏感數(shù)據(jù)，如果需要對(duì)敏感數(shù)據(jù)進(jìn)行加密趁餐，還是需要考慮加密方案喷兼。
2.5 URL簽名
基于OAuth2協(xié)議，進(jìn)行URL簽名后雷。這個(gè)方案季惯，有很多話題可以分享，后面另開一篇來(lái)詳細(xì)講解臀突。
值得注意的是勉抓，URL簽名只能垂直權(quán)限管理，但沒(méi)法保護(hù)敏感數(shù)據(jù)候学，如果需要對(duì)敏感數(shù)據(jù)進(jìn)行保護(hù)琳状，還是需要考慮加密方案。
2.6 雙向RSA加密
RSA雙向認(rèn)證盒齿，就是用對(duì)方的公鑰加密是為了保密念逞，這個(gè)只有對(duì)方用私鑰能解密。用自己的私鑰加密是為了防抵賴边翁，能用我的公鑰解開翎承，說(shuō)明這是我發(fā)來(lái)的。
例如符匾，支付寶的支付接口就是非常典型的RSA雙向認(rèn)證的安全方案叨咖。此外，我們之前的教育資源、敏感驗(yàn)證碼出于安全性考慮都借鑒了這個(gè)方案甸各。
3. HTTPS原理剖析垛贤、降級(jí)攻擊、HTTP與HTTPS的對(duì)比
Https的簡(jiǎn)介及其與Https的對(duì)比請(qǐng)參見(jiàn)之前的部分
降級(jí)攻擊：
ssl v3.0是一個(gè)存在了很久的協(xié)議了趣倾，現(xiàn)在大多數(shù)瀏覽器為了兼容性都會(huì)支持這個(gè)協(xié)議聘惦，但是并不會(huì)首先使用這個(gè)協(xié)議，中間人攻擊者可以駁回瀏覽器協(xié)商高版本協(xié)議的請(qǐng)求儒恋，只放行ssl v3.0協(xié)議善绎。
