摘要:前言全網(wǎng)勢(shì)在必行全稱,是為了保證客戶端與服務(wù)器之間數(shù)據(jù)傳輸?shù)陌踩o法證明報(bào)文的完整性,可能已遭到篡改所謂完整性是指信息的準(zhǔn)確度。簡(jiǎn)單來說,與組合使用的被稱為超文本傳輸安全協(xié)議或。通過這種方式來保持加密方法的安全性。
前言:全網(wǎng)HTTPS勢(shì)在必行
HTTPS(全稱:HyperText Transfer Protocol over Secure Socket Layer),是為了保證客戶端與服務(wù)器之間數(shù)據(jù)傳輸?shù)陌踩?近兩年,Google、Baidu、Facebook 等這樣的互聯(lián)網(wǎng)巨頭,不謀而合地開始大力推行 HTTPS, 國(guó)內(nèi)外的大型互聯(lián)網(wǎng)公司很多也都已經(jīng)啟用了全站 HTTPS,這也是未來互聯(lián)網(wǎng)發(fā)展的趨勢(shì),作為前端工程師,了解HTTPS的原理也是必修課之一。
2019年離全網(wǎng)使用HTTPS已經(jīng)不遠(yuǎn)了,列舉幾個(gè)各大互聯(lián)網(wǎng)公司為鼓勵(lì)使用HTTPS而提出的要求:
1.Google的搜索引擎算法,讓采用 HTTPS 的網(wǎng)站在搜索中排名更靠前;
2.蘋果要求App Store中的所有應(yīng)用都必須使用 HTTPS 加密連接;
3.微信小程序也要求必須使用 HTTPS 協(xié)議;
4.新一代的 HTTP/2 協(xié)議的支持需以 HTTPS 為基礎(chǔ);
5.新版本chrome已將HTTP協(xié)議網(wǎng)站標(biāo)記不安全
HTTP協(xié)議從誕生至今已經(jīng)具有相當(dāng)優(yōu)秀和方便的一面,然而HTTP并非只有好的一面,事物皆具兩面性,它的不足之處也是很明顯:
通信使用明文傳輸,內(nèi)容可能會(huì)被竊聽
不驗(yàn)證通信方的身份,因此有可能遭遇偽裝
無法證明報(bào)文的完整性,所以有可能已經(jīng)遭到篡改
除此之外,HTTP本身還有很多缺點(diǎn)。而且,還有像某些特定的Web服務(wù)器和特定的Web瀏覽器在實(shí)際應(yīng)用中存在的不足(也可以說成是脆弱性或安全漏洞),另外,用Java和PHP等編程語言開發(fā)的Web應(yīng)用也可能存在安全漏洞。
1. 通信使用明文可能會(huì)被竊聽由于HTTP本身不具備加密的功能,所以也無法做到對(duì)通信整體(使用HTTP協(xié)議通信的請(qǐng)求和響應(yīng)的內(nèi)容)進(jìn)行加密。所以,HTTP報(bào)文使用明文方式發(fā)送。如果要問為什么通信時(shí)不加密是一個(gè)缺點(diǎn),這是因?yàn)椋碩CP/IP協(xié)議族的工作機(jī)制,通信內(nèi)容在所有的通信線路上都有可能遭到窺視。
所謂互聯(lián)網(wǎng),是由能連通到全世界的網(wǎng)絡(luò)組成,無論世界哪個(gè)角落的服務(wù)器在和客戶端通信時(shí),在此通信線路上的某些網(wǎng)絡(luò)設(shè)備、光纜、計(jì)算機(jī)等都不可能是個(gè)人的私有物,所以不排除某個(gè)環(huán)節(jié)中會(huì)遭到惡意窺視行為。
即使已經(jīng)過加密處理的通信,也會(huì)被窺視到通信內(nèi)容,這點(diǎn)和未加密的通信是相同的。只是說如果通信經(jīng)過加密,就有可能讓人無法破解報(bào)文信息的含義,但加密處理后的報(bào)文信息本身還是會(huì)被看到。
竊聽相同段上的通信并非難事。只需要收集在互聯(lián)網(wǎng)上流動(dòng)的數(shù)據(jù)包就行。對(duì)于收集來的數(shù)據(jù)包的解析工作,可以交給那些抓包或嗅探工具。
HTTP協(xié)議中的請(qǐng)求和相應(yīng)不會(huì)對(duì)通信方進(jìn)行確認(rèn)。也就是說存在“服務(wù)器是否就是發(fā)送請(qǐng)求中URI真正指定的主機(jī),返回的響應(yīng)是否真的返回到實(shí)際提出請(qǐng)求的客戶端”等類似問題。
在HTTP協(xié)議通信時(shí),由于不存在確認(rèn)通信方的處理步驟,任何人都可以發(fā)送請(qǐng)求,同時(shí),服務(wù)器只要接收到請(qǐng)求,只要發(fā)送端的IP地址和端口號(hào)沒有被Web服務(wù)器設(shè)定限制訪問,不管對(duì)方是誰都會(huì)返回一個(gè)響應(yīng),因此會(huì)存在以下各種隱患:
無法確定請(qǐng)求發(fā)送至目標(biāo)的Web服務(wù)器是否是按真實(shí)意圖返回響應(yīng)的那臺(tái)服務(wù)器,有可能是已偽裝的Web服務(wù)器。
無法確定響應(yīng)返回到的客戶端是否是按真實(shí)意圖接收響應(yīng)的那個(gè)客戶端,有可能是已偽裝的客戶端。
無法確定正在通信的對(duì)方是否具備訪問權(quán)限。因?yàn)槟承¦eb服務(wù)器上保存著重要的信息,指向發(fā)給特定用戶通信的權(quán)限。
無法判定請(qǐng)求是來自何方、出自誰手。
及時(shí)是無意義的請(qǐng)求也會(huì)照單全收。無法阻止海量請(qǐng)求下的DoS攻擊(Denial of Service,拒絕服務(wù)攻擊)。
3. 無法證明報(bào)文的完整性,可能已遭到篡改所謂完整性是指信息的準(zhǔn)確度。若無法證明其完整性,通常也就意味著無法判斷信息是否準(zhǔn)確。
因此,在請(qǐng)求或響應(yīng)送出之后知道對(duì)方接收之前的這段時(shí)間內(nèi),即使請(qǐng)求或相應(yīng)的內(nèi)容遭到篡改,也沒有辦法獲悉。
換句話說,沒有任何辦法確認(rèn),發(fā)出的請(qǐng)求、響應(yīng)和接收到的請(qǐng)求、響應(yīng)是前后相同的。文件內(nèi)容在傳輸中可能已經(jīng)被村改為其他內(nèi)容,像這樣,請(qǐng)求或響應(yīng)在傳輸途中遭攻擊者攔截并篡改內(nèi)容的攻擊成為中間人攻擊(Man-in-the-Middle attack,MITM)。
上面提了那么多HTTP的缺點(diǎn)自然在HTTPS中我們得解決它,下面我們來看看HTTPS是如何保證我們數(shù)據(jù)傳輸安全的。
1. HTTPS其實(shí)是身披SSL外殼的HTTPHTTPS并非是應(yīng)用層的一種新協(xié)議。知識(shí)HTTP通信接口部分用SSL(Secure Socket Layer,安全套階層)和TLS(Transport Layer Security,安全傳輸層協(xié)議)協(xié)議代替而已。
通常,HTTP直接和TCP通信。當(dāng)使用SSL時(shí),則變成先和SSL通信,再由SSL和TCP通信了。簡(jiǎn)單來說,與SSL組合使用的HTTP被稱為HTTPS(HTTP Secure,超文本傳輸安全協(xié)議)或HTTP over SSL。
采用了SSL后,HTTP就擁有了HTTPS的加密、證書和完整性保護(hù)這些功能。SSL是獨(dú)立于HTTP的協(xié)議,所以不光是HTTP協(xié)議,其它運(yùn)行在應(yīng)用層的SMTP和Telnet等協(xié)議均可配合SSL協(xié)議使用。可以說SSL是當(dāng)今世界上應(yīng)用最為廣泛的網(wǎng)絡(luò)安全技術(shù)。
近代的加密算法中加密算法是公開的,而密鑰是保密的。通過這種方式來保持加密方法的安全性。
加密和解密要用到密鑰,如果沒有密鑰就沒有辦法對(duì)密碼解密。換句話來說,任何人只要持有密鑰就能夠?qū)γ芪倪M(jìn)行解密。
HTTPS在加密過程中使用了非對(duì)稱加密技術(shù)和對(duì)稱加密技術(shù)。
對(duì)稱加密算法采用單鑰密碼系統(tǒng)的加密方式,同一個(gè)密鑰可以同時(shí)做信息的加密和解密,這種加密的方法稱為對(duì)稱加密,也稱為單密鑰加密。
下面會(huì)把對(duì)稱加密算法稱為共享密鑰加密算法。
假如現(xiàn)在,SSL在通信過程中,使用了對(duì)稱加密算法,也就是說客戶端和服務(wù)器同時(shí)共享一個(gè)密鑰。
于是,以共享密鑰的方式加密,必須將密鑰發(fā)給對(duì)方。這個(gè)時(shí)候,假如通信過程被監(jiān)聽,密鑰被攻擊者獲取了,那么這個(gè)時(shí)候也就失去了加密的意義了。
那么,有沒有辦法解決這個(gè)問題呢?答案是肯定的,也就是使用兩把密鑰。
下面先看使用兩把密鑰的非對(duì)稱加密算法。
非對(duì)稱加密算法與對(duì)稱加密算法相反,非對(duì)稱加密算法需要兩個(gè)密鑰來進(jìn)行加密和解密,這兩個(gè)密鑰是配對(duì)的,分別是公開密鑰(公鑰)和私有密鑰(私鑰)。
一般情況下,公鑰是可以被公開的,它主要用來加密明文。而相應(yīng)的,私鑰不能被公開,用來解密公鑰加密的密文。
值得注意的是:公鑰加密后的密文只能通過對(duì)應(yīng)的私鑰來解密,而私鑰加密的密文卻可以通過對(duì)應(yīng)的公鑰來解密。
以上,公鑰加密私鑰解密用來加密,私鑰加密公鑰解密用來簽名。相關(guān)用途后面會(huì)講到。
下面會(huì)把非對(duì)稱加密算法稱為公開密鑰加密算法。
于是現(xiàn)在,假設(shè)現(xiàn)在由服務(wù)器來生成一對(duì)公鑰和密鑰。
當(dāng)客戶端第一次發(fā)請(qǐng)求和服務(wù)器協(xié)商的時(shí)候,服務(wù)器就生成了一對(duì)公鑰和私鑰。
緊接著,服務(wù)器把公鑰發(fā)給客戶端(明文,不需要做任何加密),客戶端接收后,隨機(jī)生成一個(gè)密鑰,使用服務(wù)器發(fā)過來的公鑰進(jìn)行加密。
再接著,客戶端把使用公鑰加密的密鑰發(fā)給服務(wù)器,服務(wù)器接收到了以后,用配對(duì)的私鑰進(jìn)行解密,就得到了客戶端隨機(jī)生成的那個(gè)密鑰。
這個(gè)時(shí)候,客戶端和服務(wù)端所持的密鑰都是相同的。此時(shí),交換密鑰環(huán)節(jié)就完成了。
于是通信開始時(shí)就可進(jìn)行上面所述的共享密鑰加密方式來進(jìn)行加密。
同時(shí)使用可能,有小伙伴就會(huì)問,為什么要大費(fèi)周章使用非對(duì)稱加密的方式,然后再得到相同的密鑰,進(jìn)行共享密鑰加密的通信呢?
由于公開密鑰加密處理起來比共享密鑰加密方式更為復(fù)雜,因此在通信的時(shí)候使用公開密鑰加密的方式,效率很低。
于是,我們需要使用非對(duì)稱加密的方式來保證密鑰共享的過程中密鑰的安全性,而后在通信的過程中使用對(duì)稱加密算法,這是最合理的設(shè)計(jì)方式,在保證安全性的同時(shí)又保證了性能。
所以,HTTPS采用共享密鑰加密和公開密鑰加密兩者并用的混合加密機(jī)制。在交換密鑰使用環(huán)節(jié)使用公開密鑰加密方式,之后建立的通信交換報(bào)文階段則使用共享密鑰加密方式。
以上,大概就是使用對(duì)稱加密和非對(duì)稱加密的過程。看似過程很完美,其實(shí)還存在著一個(gè)問題,就是:如何保證服務(wù)器傳過來的公開密鑰的正確性。換句話說,就是保證它不被攔截篡改。
使用證書保證公鑰的正確性假如現(xiàn)在正準(zhǔn)備和某臺(tái)服務(wù)器建立公開密鑰加密方式下的通信,如何證明客戶端收到的公開密鑰就是原本預(yù)想的那臺(tái)服務(wù)器發(fā)行的公開密鑰呢?或許,在公開密鑰傳輸?shù)倪^程中,真正的公開密鑰可能已經(jīng)被攻擊者替換掉了。
為了解決這個(gè)問題,可以使用由數(shù)字證書機(jī)構(gòu)和其相關(guān)頒發(fā)的公開密鑰證書。
下面闡述一下數(shù)字證書認(rèn)證機(jī)構(gòu)(簡(jiǎn)稱CA)的業(yè)務(wù)流程:
首先,服務(wù)器的運(yùn)營(yíng)人員向數(shù)字證書機(jī)構(gòu)提出公開密鑰的申請(qǐng)。數(shù)字證書認(rèn)證機(jī)構(gòu)在判明提出申請(qǐng)者的身份之后,會(huì)對(duì)已申請(qǐng)的公開密鑰做數(shù)字簽名,然后分配這個(gè)已簽名的公開密鑰,并將該公開密鑰放入公鑰證書后綁定在一起。
我們用白話文來翻譯一下上面這段話:
首先,CA會(huì)向申請(qǐng)者頒發(fā)一個(gè)證書,這個(gè)證書里面的內(nèi)容有:簽發(fā)者、證書用途、服務(wù)器申請(qǐng)的時(shí)候附帶的公鑰、服務(wù)器的加密算法、使用的HASH算法、證書到期的時(shí)間等等。
緊接著,把上面所提到的內(nèi)容,做一次HASH求值,得到一個(gè)HASH值。
再接著,用CA的私鑰進(jìn)行加密,這樣就完成了數(shù)字簽名。而用CA的私鑰加密后,就生成了類似人體指紋的簽名,任何篡改證書的嘗試,都會(huì)被數(shù)字簽名發(fā)現(xiàn)。
最后,把數(shù)字簽名,附在數(shù)字證書的末尾,傳輸回來給服務(wù)器。
接下來,服務(wù)器會(huì)把這份由數(shù)字證書認(rèn)證機(jī)構(gòu)頒發(fā)的公鑰證書發(fā)給客戶端。這個(gè)時(shí)候,客戶端可以使用數(shù)字證書機(jī)構(gòu)的公開密鑰對(duì)其進(jìn)行驗(yàn)證。一旦驗(yàn)證成功,客戶端便能夠確定這個(gè)公開密鑰是可信的。
我們?cè)儆冒自捨膩矸g一下:
客戶端拿到這個(gè)數(shù)字證書以后,用CA私鑰對(duì)應(yīng)的公鑰,可以解密數(shù)字證書末尾的數(shù)字簽名,得到原始的HASH值。
緊接著,客戶端按照證書中的HASH算法,對(duì)證書的內(nèi)容求HASH值。如果通過CA公鑰解密的HASH和通過計(jì)算求得的HASH值相同,那么認(rèn)證通過,否則失敗。
如果認(rèn)證通過,就可以取得服務(wù)器的公開密鑰。
那客戶端上面的CA公鑰是從哪里來的呢?
多數(shù)瀏覽器開發(fā)商發(fā)布版本時(shí),會(huì)事先在內(nèi)部植入常用認(rèn)證機(jī)關(guān)的公開密鑰。這樣,就方便客戶端對(duì)于數(shù)字證書真實(shí)性的驗(yàn)證。
其具體過程是這樣子的(圖中簡(jiǎn)化了數(shù)字簽名的過程):
這里其實(shí)就用到了非對(duì)稱加密算法,只不過現(xiàn)在這個(gè)加密算法用來簽名而不是加密。
使用私鑰加密,公鑰解密,用于公鑰的持有者驗(yàn)證通過私鑰加密的內(nèi)容是否被篡改,但是不用來保證內(nèi)容是否被他人獲得。
而使用公鑰加密,私鑰解密,則是相反的,它不保證信息被他人截獲篡改,但是保證信息無法被中間人獲得。
客戶端證書HTTPS中不僅可以使用服務(wù)器證書,還可以使用客戶端證書。以客戶端證書進(jìn)行客戶端認(rèn)證,它的作用與服務(wù)器證書是相同的。
由于客戶端獲取證書需要用戶自行安裝客戶端證書,同時(shí)也面臨著費(fèi)用的問題。
因此,現(xiàn)狀是,安全性極高的認(rèn)證機(jī)構(gòu)可辦法客戶端證書但是僅用于特殊用途的業(yè)務(wù)。比如那些可支撐客戶端證書支出費(fèi)用的業(yè)務(wù)。
例如,銀行的網(wǎng)上銀行就采用了客戶端證書。在登錄網(wǎng)銀時(shí)不僅要求用戶確認(rèn)輸入ID和密碼,還會(huì)要求用戶的客戶端證書,以確認(rèn)用戶是否從特定的終端訪問網(wǎng)銀。
HTTPS的安全通信機(jī)制為了更好的理解HTTPS,小肆給大家畫了下圖來一起觀察一下HTTPS的通信步驟:
步驟1:客戶端通過發(fā)送Client Hello報(bào)文開始SSL通信。報(bào)文中包含客戶端支持的SSL的指定版本、加密組件列表(所使用的加密算法及密鑰長(zhǎng)度等)。
步驟2:服務(wù)器可進(jìn)行SSL通信時(shí),會(huì)以Server Hello報(bào)文作為應(yīng)答。和客戶端一樣,在報(bào)文中包含SSL版本以及加密組件。服務(wù)器的加密組件內(nèi)容是從接收到的客戶端加密組件內(nèi)篩選出來的。
步驟3:之后服務(wù)器發(fā)送Certificate報(bào)文。報(bào)文中包含公開密鑰證書。
步驟4:最后服務(wù)器發(fā)送Server Hello Done報(bào)文通知客戶端,最初階段的SSL握手協(xié)商部分結(jié)束。
步驟5:SSL第一次握手結(jié)束之后,客戶端以Client Key Exchange報(bào)文最為回應(yīng)。報(bào)文中包含通信加密中使用的一種被稱為Pre-master secret的隨機(jī)密碼串。該報(bào)文已用步驟3中的公開密鑰進(jìn)行加密。
步驟6:接著客戶端繼續(xù)發(fā)送Change Cipher Spec報(bào)文。該報(bào)文會(huì)提示服務(wù)器,在此報(bào)文之后的通信會(huì)采用Pre-master secret密鑰加密。
步驟7:客戶端發(fā)送Finished報(bào)文。該報(bào)文包含連接至今全部報(bào)文的整體效驗(yàn)值。這次握手協(xié)商是否能夠成功,要以服務(wù)器是否能夠正確解密該報(bào)文作為判定標(biāo)準(zhǔn)。
步驟8:服務(wù)器同樣發(fā)送Change Cipher Spec報(bào)文。
步驟9:服務(wù)器同樣發(fā)送Finished報(bào)文。
步驟10:服務(wù)器和客戶端的Finished報(bào)文交換完畢之后,SSL連接就算建立完成,當(dāng)然,通信會(huì)受到SSL的保護(hù)。從此處開始進(jìn)行應(yīng)用層協(xié)議的通信,即發(fā)送HTTP請(qǐng)求。
步驟11:應(yīng)用層協(xié)議通信,即發(fā)送HTTP響應(yīng)。
步驟12:最后由客戶端斷開連接。斷開連接時(shí),發(fā)送close_notify報(bào)文。上圖做了一些省略,這步之后再發(fā)送TCP FIN報(bào)文來關(guān)閉與TCP的通信。
在以上流程中,應(yīng)用層發(fā)送數(shù)據(jù)時(shí)會(huì)附加一種叫做MAC(Message Authentication Code)的報(bào)文摘要。MAC能夠查知報(bào)文是否遭到篡改,從而保護(hù)報(bào)文的完整性。
那現(xiàn)在有一個(gè)問題,整個(gè)過程中產(chǎn)生的三個(gè)隨機(jī)數(shù)有什么用呢?還有,后面進(jìn)行HTTP通信的時(shí)候,是用哪一個(gè)密鑰進(jìn)行加密,還有怎么保證報(bào)文的完整性。
看下面這張圖。
當(dāng)其生成了Pre-master secret之后,會(huì)結(jié)合原來的A、B隨機(jī)數(shù),用DH算法計(jì)算出一個(gè)master secret,緊接著根據(jù)這個(gè)master secret推導(dǎo)出hash secret和session secret。
對(duì)于服務(wù)端:當(dāng)其解密獲得了Pre-master secret之后,會(huì)結(jié)合原來的A、B隨機(jī)數(shù),用DH算法計(jì)算出一個(gè)master secret,緊接著根據(jù)這個(gè)master secret推導(dǎo)出hash secret和session secret。
在客戶端和服務(wù)端的master secret是依據(jù)三個(gè)隨機(jī)數(shù)推導(dǎo)出來的,它是不會(huì)在網(wǎng)絡(luò)上傳輸?shù)模挥须p方知道,不會(huì)有第三者知道。同時(shí),客戶端推導(dǎo)出來的session secret和hash secret與服務(wù)端也是完全一樣的。
那么現(xiàn)在雙方如果開始使用對(duì)稱算法加密來進(jìn)行通訊,使用哪個(gè)作為共享的密鑰呢?過程是這樣子的:
雙方使用對(duì)稱加密算法進(jìn)行加密,用hash secret對(duì)HTTP報(bào)文做一次運(yùn)算生成一個(gè)MAC,附在HTTP報(bào)文的后面,然后用session-secret加密所有數(shù)據(jù)(HTTP+MAC),然后發(fā)送。
接收方則先用session-secret解密數(shù)據(jù),然后得到HTTP+MAC,再用相同的算法計(jì)算出自己的MAC,如果兩個(gè)MAC相等,證明數(shù)據(jù)沒有被篡改。
至此,整個(gè)過程介紹完畢。
技術(shù)放肆聊公眾號(hào),每日干貨,最前沿的技術(shù)知識(shí),掃描下方二維碼關(guān)注:文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://specialneedsforspecialkids.com/yun/100925.html
摘要:所針對(duì)的問題相當(dāng)簡(jiǎn)單可以用一個(gè)簡(jiǎn)單的比喻你的另一半中午打電話給你當(dāng)你在一個(gè)會(huì)議上并詢問你告訴他們你的網(wǎng)上銀行賬戶的密碼因?yàn)樗麄冃枰獔?zhí)行一個(gè)銀行轉(zhuǎn)賬以確保你兒子的教育費(fèi)用按時(shí)支付。正如我提到的,你正在開會(huì),需要拼寫你的網(wǎng)上銀行密碼。 showImg(https://segmentfault.com/img/bVbo62g?w=800&h=533); 想閱讀更多優(yōu)質(zhì)文章請(qǐng)猛戳GitHub博...
摘要:前言全網(wǎng)勢(shì)在必行全稱,是為了保證客戶端與服務(wù)器之間數(shù)據(jù)傳輸?shù)陌踩o法證明報(bào)文的完整性,可能已遭到篡改所謂完整性是指信息的準(zhǔn)確度。簡(jiǎn)單來說,與組合使用的被稱為超文本傳輸安全協(xié)議或。通過這種方式來保持加密方法的安全性。 前言:全網(wǎng)HTTPS勢(shì)在必行 HTTPS(全稱:HyperText Transfer Protocol over Secure Socket Layer),是為了保證客戶...
摘要:還可有效防止時(shí)序攻擊以下是使用的例子需要澄清的一點(diǎn)是密碼哈希并不是密碼加密。哈希是將目標(biāo)文本轉(zhuǎn)換成具有相同長(zhǎng)度的不可逆的雜湊字符串或叫做消息摘要,而加密是將目標(biāo)文本轉(zhuǎn)換成具有不同長(zhǎng)度的可逆的密文。 showImg(https://segmentfault.com/img/remote/1460000018748362?w=750&h=422); 文章轉(zhuǎn)自:https://learnku...
摘要:是現(xiàn)行架構(gòu)下最安全的解決方案,雖然不是絕對(duì)安全,但它大幅增加了中間人攻擊的成本。最關(guān)鍵的,證書的信用鏈體系并不安全,特別是在某些國(guó)家可以控制根證書的情況下,中間人攻擊一樣可行。 一、前提背景 超文本傳輸協(xié)議HTTP協(xié)議被用于在Web瀏覽器和網(wǎng)站服務(wù)器之間傳遞信息,HTTP協(xié)議以明文方式發(fā)送內(nèi)容,不提供任何方式的數(shù)據(jù)加密,如果存在攻擊情況,將會(huì)泄漏其中的信息,比如信用卡密碼等等。 安...
摘要:截至年月日,將網(wǎng)站標(biāo)記為不安全。管理密碼使用密碼哈希以純文本格式存儲(chǔ)密碼是最糟糕的事情之一。是中密碼哈希的主要接口,如下所示提供了幾種實(shí)現(xiàn),最受歡迎的是和。 Spring Boot大大簡(jiǎn)化了Spring應(yīng)用程序的開發(fā)。它的自動(dòng)配置和啟動(dòng)依賴大大減少了開始一個(gè)應(yīng)用所需的代碼和配置量,如果你已經(jīng)習(xí)慣了Spring和大量XML配置,Spring Boot無疑是一股清新的空氣。 Spring ...
閱讀 3323·2021-11-25 09:43
閱讀 3008·2021-10-15 09:43
閱讀 1965·2021-09-08 09:36
閱讀 2918·2019-08-30 15:56
閱讀 742·2019-08-30 15:54
閱讀 2684·2019-08-30 15:54
閱讀 2973·2019-08-30 11:26
閱讀 1237·2019-08-29 17:27