黑帽SEO培訓篇數據加密、HTTPS、線上充值原理？
內容大綱.png
目的
面試很多時候都會問一些通用的東西，比如多線程,比如數據加密,比如HTTPS,換句話說,無論你從事前端還是后端,數據加密和HTTPS都是必須掌握的
數據加密
首先,我們?yōu)槭裁匆獢祿用?因為HTTP所有訪問都是明文的,只要能監(jiān)聽到網絡所有的請求數據都是透明的,比如任何瀏覽器的開發(fā)者工具就能很清楚的看到表單提交的參數和地址,在Android和iOS中也經常通過抓包的方式高仿其他的APP,比如Charles就是Mac上常用的抓包工具
表單加密傳輸
由于篇幅有限,這里就暫時拿JS舉例
比如我們平時使用的JS插件,凡是.min結尾的,里面的代碼都是混亂的,如圖:
這些JS都是經過壓縮的,他就是把注釋和空格去掉,把變量名變成短變量名,使得我們閱讀起來就很困難了.
其實目前沒有絕對的安全,因為安全本來就是一場攻防戰(zhàn),我們能做的,只能是加大解密的成本來防止解密,例如我們可以使用JS混淆,如圖:
從這里就可以看出,一段簡單的代碼加密壓縮后就變得如此復雜.但是細心的同學就發(fā)現,旁邊還有個解密的按鈕呢,所以這種方式的缺陷就在于,這種加密方式是可逆的,一旦得到了加密的JS,就能解密
對稱加密算法
此時回憶一下,我們之前是怎么加密的?我們都是前臺根據一定規(guī)則加密,后臺又根據這個規(guī)則解密.那么我們有沒有辦法做得更安全一點?
辦法是有的,比如我們加密的時候,向后臺請求一個隨機數,而這個隨機數,就作為前臺加密和后臺解密的鑰匙,我們把這個,稱之為密鑰
我們用一張圖來描述一下這個過程:
從序號3我們知道,只要拿不到隨機數(密鑰),那么將無法解密,但是萬一別人就是能拿到呢?所以,這個對稱加密最大的難點就在于,怎么有效的隱藏密鑰,以及后臺怎么管理這個密鑰池
非對稱加密算法
非對稱加密算法是我們平時用的最多的,那么什么是非對稱加密算法呢?
我們這么設想,有沒有一種算法加密過后,用逆向的解密是解不出來的?也就是比如原來的密碼是123,我們的加密算法是每一位+1,也就是變成了234,然后得到234后,我們每一位減一卻得不到123,而是需要另一種算法才能算出123
從上面這個例子我們知道,這個加密算法和解密算法完全就是兩碼事,這種加密的思想,就是非對稱加密算法的一種方式
另一種方式,也就是我們用得最多的,其中這個非對稱,就體現在鑰匙上面,之前我們的對稱加密算法,缺陷就是,前臺和后臺拿到的鑰匙是一樣的
非對稱加密算法采用公鑰/私鑰的方式,使用加密算法(明文,公鑰)生成密文,這個密文,就算知道了公鑰和加密算法,也沒辦法解密,必須要這個公鑰對應的私鑰才能解密.
也就是說,公鑰加密的,只能靠私鑰解密.私鑰加密的,也只能靠公鑰解密,所以我們的公鑰可以隨意向外公布,只需要隱藏好私鑰即可,具體實現如圖
所以,這種加密算法的缺陷在于,只要拿到了私鑰,所有的密文都能解開
非對稱加密算法中,RSA加密算法用得也比較多,RSA是由創(chuàng)建者的名字首字母組成的,由于篇幅有限,這里不過多介紹.
HTTPS
HTTPS簡單介紹
HTTPS相信大家都不會陌生,那么怎么認識HTTPS呢,我們從三個方面入手,也就是是什么,有什么用,為什么需要
是什么:
HTTPS是一種網絡協(xié)議,他是處于HTTP協(xié)議和TCP/IP協(xié)議之間的一個協(xié)議(如圖),所以,HTTPS其實不是我們寫代碼的時候需要處理的東西,他是browser和應用服務器(例如Tomcat)需要去處理的一個東西.但是,如果你是做Android或者iOS客戶端,要發(fā)送和處理一個HTTPS請求的時候,也需要做額外的處理
有什么用:
能夠讓瀏覽器明確訪問的網站是安全網站一旦HTTPS連接成功,瀏覽器和服務器之間的數據傳輸全部是加密傳輸(對稱加密)
為什么需要
HTTP上傳輸的所有數據都是明文，于是出現了SSL（Secure Sockets Layer安全套接字層）協(xié)議用于對HTTP協(xié)議進行加密傳輸, HTTP + SSL = HTTPS;IETF對SSL進行了升級,就是TLS（Transport Layer Security）,其實我們現在說的HTTPS都是使用的是TLS;
HTTPS的工作原理
假設我們訪問https://toby.com,這之間的握手協(xié)議如下圖
HTTPS的工作原理.png
文字解讀:
瀏覽器(客戶端)將自己支持的一套加密規(guī)則(SSL版本號,加密算法版本,哈希算法版本)發(fā)送給網站,網站接收到瀏覽器支持的算法版本,選擇一組對應的算法版本
網站把網站地址,加密公鑰,證書頒發(fā)結構等信息以SSL證書的形式發(fā)送給客戶端
客戶端接收網站發(fā)送的證書后,需要驗證該證書的合法性:從底層的SSL證書向上層證書進行驗證,只要在證書鏈中任意一級證書是可信的,那么這個證書是可信的
得到SSL證書中的域名,和當前訪問網站進行比對,比對通過,瀏覽器信任該站點
瀏覽器生成一個隨機數:random,并使用證書中的公鑰進行加密(非對稱算法),偽代碼如:RSA(SSL證書中的公鑰,random)->密文A
瀏覽器生成一個握手信息,如:"toby", 并使用確定的HASH算法生成一個hash值,偽代碼如:HASH("toby")->hash碼
使用random對toby握手信息進行加密(對稱算法),偽代碼如:encore(random,"toby")->密文B
把密文A,hash碼,密文B全部傳給網站
服務器接收到密文A、hash碼、密文B后,使用服務器端SSL證書中的密鑰對密文A進行解密,偽代碼如:RSA(SSL證書中的密鑰,密文A)->random
使用加密算法對密文B進行解密,偽代碼如decode(random,密文B)->握手信息
再用hash算法算出握手信息的hash值,偽代碼如HASH(握手信息)->hash碼
對比這個hash碼和傳過來的hash碼是否一致,如果一致,服務器端再生成一個握手信息比如"hello"對服務器端的一個握手信息進行加密,偽代碼如encode(random,"hello")->密文
對握手信息進行hash計算,偽代碼如hash("hello")->hash碼
把hash碼和密文傳給瀏覽器
客戶端接收到密文和hash碼
decode(random,密文)->握手信息
HASH(握手信息)->hash碼
對比hash碼,如果一致,隨機碼都互相驗證過,并且都各自存放好了,此時,兩邊都完成了HTTP交互,現在的結果是,客戶端和服務器都有一個random
接下來的請求就全部使用encode(random,明文)進行加密傳輸了,服務器端則使用decode(random,密文)->明文,此時,這個加密算法就是一個對稱加密算法了,這個解析出來的明文就會交給HTTP協(xié)議,所以我們應用拿到的是明文
線上充值原理
首先這里有三個名詞,一個是xx平臺就是我們要充值的平臺,還有一個是第三方支付平臺,這樣的平臺有很多,比如大家都知道的支付寶,財付通,網銀在線等等,還有一個是銀行,這個大家都懂
我一向是都是喜歡先粗暴地上流程圖,如下:
文字解讀:
首先,xx平臺需要和第三方平臺簽訂協(xié)議,這樣xx平臺就能得到一個在第三方平臺的賬戶,那么我們開始充值流程
1.用戶開始在xx平臺進行充值
2.用戶由xx平臺的在線充值界面跳轉到第三方支付平臺,這個時候需要帶上username、password、apikey以便第三方平臺知道我們來自哪個平臺,同時還要帶上一個唯一的id作為交易流水
3.一般有快速支付和網銀支付,這里拿網銀支付舉例,當點擊網銀支付的時候,跳轉到銀行的轉賬界面,這個時候要注意,這個接口是銀行和第三方支付平臺對接的,所以跳轉的時候還要帶上平臺的唯一標識
4.我們假設轉賬成功,那么這個時候,錢是轉到了第三方支付平臺,而不是xx平臺
5.第三方平臺需要為銀行提供一個接口,進行回調,告訴第三方支付平臺,流水號的處理結果
6.這個時候,將充值金額累加到xx平臺的賬戶中,但是這個只是虛擬現金流的增加,錢還在第三方支付平臺的銀行賬戶中
7.xx平臺需要為第三方平臺提供一個接口,處理回調,告訴xx平臺,流水號的處理結果
8.假設回調成功狀態(tài),xx平臺將在用戶的賬戶把錢增加,但是這個時候,也只是虛擬現金流的增加,此時錢還是在第三方支付平臺的賬戶
9.第三方支付平臺會在一個結算周期(一般是兩天到三天),他會自動地把這段時間之內交易成功的錢打到xx平臺上
所有第三方支付平臺的原理都是以上流程,所以,對于我們xx平臺而言,只需要做兩件事
頁面跳轉,把充值信息告訴第三方支付平臺
寫一個回調的接口,接收交易情況
黑帽WiKi_黑帽百科(m.790079.com),8年黑帽SEO優(yōu)化技術,黑帽seo快速排名,黑帽seo技術培訓學習,黑帽SEO快速排名程序、泛目錄、寄生蟲技術,贈送免費黑帽SEO視頻教程
（黑帽SEO技術,網站快速排名,蜘蛛池加速收錄,目錄程序定制）
掃一下添加微信：
