【付費(fèi)】前端密碼傳輸，支付請(qǐng)求等等類對(duì)安全性比較高的數(shù)據(jù)傳輸安全問題？

1. 前端不會(huì)放敏感信息，如果說敏感信息，應(yīng)該是cookie了,敏感信息都放在服務(wù)端的session，但是session_id由前端傳入,一般基于cookie傳輸，也有基于url傳輸?shù)?。說下登錄場景的密碼傳輸問題，一般都是明文傳輸?shù)椒?wù)器，大站可能會(huì)有jsmd5這種庫，這樣在網(wǎng)絡(luò)上傳輸?shù)囊呀?jīng)是md5密文。
2. https可以防止中間人攻擊，保證瀏覽器到服務(wù)器這條鏈路是可信任的傳輸。除非你手動(dòng)信任了中間人證書，我想沒什么人這么傻，服務(wù)器開啟ssl即可。加密成本最小，應(yīng)用不用更改。

https可以保證傳輸安全，數(shù)據(jù)從瀏覽器到達(dá)服務(wù)器的路上任何人不能竊取。

http與https 的安全區(qū)別簡單點(diǎn)來說就是， 你在路由器上， http你可以看到發(fā)出去的明文報(bào)文和接收到的明文報(bào)文。所以https是必須的，
啟用https之后， 在需要安全校驗(yàn)的地方，加入手機(jī)驗(yàn)證碼，回答問題，支付密碼等，身份驗(yàn)證，防止賬號(hào)被盜用。

瀏覽器安全控件是保證從鍵盤傳輸?shù)綖g覽器頁面安全的，但是一般安全空間體驗(yàn)極差，跨平臺(tái)不完善，手機(jī)端不支持等問題，不建議使用

作為一個(gè)前端小白，我之前碰到這個(gè)問題為了加密post這種傳輸?shù)臄?shù)據(jù)，一般是把參數(shù)數(shù)據(jù)的按照約定格式排序然后加上時(shí)間戳，在加上一個(gè)約定的key再使用別的加密方式加密例如md5這種方式加密，生成一個(gè)key若是與后臺(tái)生成的一致則可以成功請(qǐng)求，大概思路是這樣的，但我想說靠前端加密就是個(gè)笑話呀╮(╯▽╰)╭

先說 HTTPS， HTTPS在 TCP 和 HTTP 協(xié)議之間添加了一層用來加密（加密原理就不說了），上層不用考慮具體下層的實(shí)現(xiàn)，服務(wù)器（發(fā)送頁面，AJax通信等）不用考慮底層的實(shí)現(xiàn)，也就是說你寫 PHP 的代碼，所有數(shù)據(jù)都是加密發(fā)送出去的，可以保證所有的數(shù)據(jù)不被竊聽不被篡改，所以你可以不用考慮任何與加密相關(guān)的事情就可以認(rèn)為通信是安全的。

這種安全僅僅是指防止鏈路上的竊聽和篡改，只是說服務(wù)器和客戶間的路由器無法篡改和解密兩臺(tái)機(jī)器間的通信數(shù)據(jù)，路由器做的只能是轉(zhuǎn)發(fā)。 HTTPS并不保證在服務(wù)器或是客戶的電腦上數(shù)據(jù)的安全。就是說，你電腦上的惡意軟件依舊可以竊聽和篡改數(shù)據(jù)。 一種可能需要我們注意的情況是，一個(gè)HTTPS 頁面，引用了一個(gè)非 HTTPS 的 JS（或者其他頁面）， 那么這個(gè) JS 就是不安全的，有可能被篡改并在客戶的瀏覽器里執(zhí)行，而這個(gè) JS 是可以訪問這個(gè)頁面所有的數(shù)據(jù)的，此時(shí)如果有敏感數(shù)據(jù)被這個(gè) JS 讀取并發(fā)送出去也是可能做到的。

HTTP 所有報(bào)文都是明文發(fā)送，兩臺(tái)電腦間的所有數(shù)據(jù)都可以被中間的路由看到，并且可以隨意的修改，因此他是不安全的。涉及到密碼的傳輸，如果是僅僅是密碼驗(yàn)證的話可以使用簡單的方式做到比較安全。 具體做法是，首先選一個(gè)hash函數(shù)，比如sha1。 服務(wù)器生成一個(gè)隨機(jī)數(shù)n1(隨機(jī)字符串)，客戶端也生產(chǎn)一個(gè)隨機(jī)數(shù)n2,相互發(fā)送給對(duì)方。 然后，客戶端求得sha1("密碼"+"n1"+"n2") 之后發(fā)送給服務(wù)器，服務(wù)器使用相同的算法計(jì)算這個(gè)值，如果相同則驗(yàn)證成功。(當(dāng)然，服務(wù)器上一般不明文保存密碼，但是這個(gè)沒有關(guān)系)。 生成隨機(jī)數(shù)的目的是防止重放攻擊。

如果服務(wù)器，客戶端和中間的惡意路由（或者其他監(jiān)聽者）一開始知道的信息都一樣，那么無論服務(wù)器和客戶端怎么通信都不會(huì)獲知額外的惡意路由不知道的信息，此時(shí)，怎么通信都是不安全的。 加密就是使用“壞人”不知道的一些信息，利用這一部分信息來加密。 HTTPS就是事先服務(wù)器生成一對(duì)公鑰，“壞人”無法獲知私鑰的信息（“壞人”知道的信息少），用戶在電腦上保存并且絕對(duì)信任這個(gè)公鑰而實(shí)現(xiàn)的加密。如果“壞人”事先獲知了服務(wù)器的私鑰，或是用戶電腦信任了“壞人”已知私鑰的公鑰，那么HTTPS也是不安全的。所以，如 @奔跑的香蕉 所說的那樣，有服務(wù)器生成公鑰發(fā)送給瀏覽器也是可以完成對(duì)敏感數(shù)據(jù)加密的。

其實(shí)在前后端交互過程中，你主要防御的是數(shù)據(jù)傳輸過程中防止有人中途截包解密的問題，如果你是說從瀏覽器開始防御基本不可能的，直接F12看的清清楚楚的。
而https你可以理解為它會(huì)為你自動(dòng)加密，當(dāng)然實(shí)際上肯定沒有這么簡單
http下面的加密你可以看一下非對(duì)稱加密。

前后臺(tái)都還可以，前后臺(tái)都能看懂和修改大部分的開源代碼，也在安全公司待過。
https已經(jīng)相對(duì)安全，數(shù)據(jù)已經(jīng)加密，可以防止中間人，密碼在上傳之前再進(jìn)行hash一下，sha256或者md5。

前端菜鳥, 分享個(gè)經(jīng)驗(yàn), 不一定是最好的, 意在拋磚引玉

可以用jsencrypt, 搜索下非對(duì)稱加密這個(gè)關(guān)鍵詞了解下概念先.
大概說明:

1. 服務(wù)端生成公鑰和私鑰
2. 公鑰明文給前端,
3. 前端再用這個(gè)公鑰給密碼加密, 發(fā)送到服務(wù)端
4. 服務(wù)端用之前生成的私鑰解密
5. 因?yàn)橹挥?strong>服務(wù)端有私鑰, 所以只有服務(wù)端能比對(duì)加密結(jié)果是否一致.

我單位是用這個(gè)做登陸的加密, 實(shí)施也很簡單.
https://github.com/travist/js...

密碼加密后再post請(qǐng)求

我說說我的見解呀，我是一個(gè)后端來著，我前端懂一點(diǎn)點(diǎn)，就是前端加密我覺得是沒必要的，比如傳輸數(shù)據(jù)，你用js加密的，就好像把鑰匙掛在門口一樣。沒必要，https是一個(gè)必然的趨勢，我覺得沒有一個(gè)網(wǎng)站是絕對(duì)安全的，只要能夠防住98%的入侵，就相當(dāng)不錯(cuò)了。目前來說就是證書比較安全實(shí)用吧。。。