㈠ 前端是否需要對密碼進行加密傳輸 && HTTPS
最近學習node，寫demo登陸和注冊功能的時候因為要考慮後台的加密和安全所以也想了下前端的，前端傳輸密碼的時候是否應該加密之後再傳輸呢
看了一些網站的登陸，csdn、等是明文傳輸，但騰訊、網路這些一線大站是經過前端加密的，看了些大佬的文章，順便自己搬個凳子記個筆記
前端的加密本身不能對網站的安全性有任何提高功能，所有的關於網站的安全技術都應該放在後台，但是這也不是完全沒有意義，可以增加攻擊成本，盡可能降低攻擊帶來的損失，畢竟丟了密文比丟了明文要強，而且犯罪分子技術參差不齊，簡單的加密能夠攔截很大一部分菜鳥，至於高手。。。
最後看到比較統一的是隱秘信息傳輸應該使用https
這篇文章只是想弄懂流程和原理，不會去糾結具體的術語
HTTP協議以明文方式發送內容，不提供任何方式的數據加密，處在同一網路中的其它用戶可以通過網路抓包來竊取和篡改數據包的內容，甚至運營商或者wifi提供者，有可能會篡改http報文，添加廣告等信息以達到盈利的目的
可以通過和SSL(Secure Socket Layer，安全套接層)組合使用來為瀏覽器和伺服器之間的通信加密。在這條加密線路上進行通信的http被稱為HTTPS（HTTP Secure，超文本傳輸安全協議）。
SSL證書（Secure socket layer），就是遵守SSL協議，由受信任的數字證書頒發機構CA頒發，主要用來提供對用戶瀏覽器和伺服器的認證，對傳送的數據進行加密和隱藏，確保數據在傳送中不被改變保證數據的完整性，加密方式為「非對稱加密」和「對稱加密」。
1、用戶連接到你的Web站點，該Web站點受伺服器證書所保護
2、你的伺服器進行響應，並自動傳送你網站的數字證書給用戶，（瀏覽器內置一個受信任的機構列表和這些機構的證書）用戶的瀏覽器查看該證書是否存在於瀏覽器的受信任機構列表中，並且通過伺服器證書中的信息與當前正在訪問的網站（域名等）是否一致來鑒別你的網站，鑒別沒成功會提醒用戶是否繼續該訪問
3、鑒別成功後，用戶的瀏覽器產生一把唯一的會話鑰匙，用以跟網站之間所有的通訊過程進行加密，會話密鑰是隨機生成，每次都會有不一樣的結果，
4、使用者的瀏覽器以網站的公鑰對交談鑰匙碼進行加密，以便只有讓你的網站得以閱讀此交談鑰匙碼
1、使用HTTPS協議可認證用戶和伺服器，確保數據發送到正確的客戶機和伺服器；
2、HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，要比http協議安全，可防止數據在傳輸過程中不被竊取、改變，確保數據的完整性。
3、HTTPS是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。
4、谷歌曾在2014年8月份調整搜索引擎演算法，並稱「比起同等HTTP網站，採用HTTPS加密的網站在搜索結果中的排名將會更高」。
1、HTTPS協議握手階段比較費時，會使頁面的載入時間延長近50%
2、HTTPS連接緩存不如HTTP高效，會增加數據開銷和功耗，甚至已有的安全措施也會因此而受到影響；
3、SSL證書需要錢，功能越強大的證書費用越高
4、SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名
5、HTTPS協議的加密范圍也比較有限，在黑客攻擊、拒絕服務攻擊、伺服器劫持等方面幾乎起不到什麼作用。最關鍵的，SSL證書的信用鏈體系並不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行。
知乎各位大佬的回答 https://www.hu.com/question/25539382
HTTP與HTTPS的區別 https://www.cnblogs.com/wqhwe/p/5407468.html
㈡ web前端用戶的密碼提交時應當怎樣加密
密碼在前端加密完全沒有意義，對密碼系統的安全性不會有任何提高，反而會引發不必要的麻煩。首先，做前端開發的人需要知道，前端系統的控制權是完全在用戶手裡的，也就是說，前端做什麼事情，用戶有完全的控制權。假設如同 @陳軒所說，前端做過了md5，後台就不用做了，這個做法會有什麼後果？如果某一天，這個系統的資料庫泄露了，黑客就直接拿到了每個用戶的密碼md5值，但此時，由於黑客知道密碼是在前端進行哈希的，所以他不需要爆破出該md5對應的原文是什麼，而是直接修改客戶端向伺服器發出的請求，把密碼欄位換成資料庫中MD5就可以了，由於與資料庫中記錄一致，直接就會登錄成功。這跟直接存儲明文密碼沒有任何區別！！！所以不管前端是不是加密了密碼，後台使用安全的哈希演算法對內容再次轉換是非常有必要的。（MD5可不行，要用bcrypt，我之前回答過一個類似的：隨著顯卡性能的高速發展，目前的快速Hash演算法是否已經變得不夠安全了？）這個回答還有一個人贊同，希望大家別被錯誤答案誤導了。另外一個答案 @林鴻所說，在非安全HTTP連接上，可以防止原始密碼被竊聽。但問題在於由於你的登錄系統接受的哈希過的密碼，而不是原文，竊聽者根本不需要原始密碼，只要通過哈希結果就可以偽造請求登錄系統。這樣做只能防止被竊聽到原文的密碼被攻擊者用在社會學攻擊上，而不能改善該網站的安全性。所以不管前端是不是加密了密碼，使用HTTPS安全連接進行登錄都是非常有必要的。以上我說的兩點，合起來看就是：不管前端是否加密了密碼，都不能以此為假設，讓後端設計的安全等級下降，否則就會有嚴重的安全問題。實際上，前端進行密碼加密，可以看做幫助用戶多進行了一次原文的轉換，不管用了什麼加密演算法，算出來的結果都是密碼原文，你該如何保護用戶的原始密碼，就該如何保護此處的加密結果，因為對你的登錄系統來說，它們都是密碼原文。以上這些，說明了密碼加密是沒有什麼意義的，接下來，我要說明前端加密會帶來什麼問題。有些人會認為前端進行了加密，可以降低後台的安全性需求，這種錯誤的觀念會造成系統的安全漏洞。實際上，你不能對前端做任何的假設，所有跟安全相關的技術，都必須應用在後台上。前端進行加密會造成頁面需要js腳本才能運行，那麼假設你的系統需要兼容不能運行js的客戶端，就必須再設計一個使用原文的登錄介面。由於前端是不是加密，所有安全機制都必須照常應用，所以為系統增加這樣的復雜性是完全沒必要的，即使傳輸明文密碼，只要正確使用了HTTPS連接和伺服器端安全的哈希演算法，密碼系統都可以是很安全的。
㈢ Web前端密碼加密是否有意義
沒有意義
密碼前端的加密根本沒有意義，密碼系統的安全性沒有提高，但會造成不必要的麻煩。
首先，前端開發人員需要知道前端系統的控制完全掌握在用戶手中，也就是說前端所做的事情和用戶擁有完全的控制。據稱，前端做了MD5，後台不必做，這種方法會有什麼後果？如果有一天，系統資料庫泄露，黑客直接獲得每個用戶的密碼的MD5值，但這一次，因為黑客知道密碼的哈希的前面，所以他不需要鼓風的MD5對應什麼是原創，而是直接修改發送到伺服器的客戶端請求的在它的資料庫密碼欄位MD5，符合資料庫中的記錄，你可以直接登錄。這與直接存儲明文密碼沒有區別！！！所以不管前端密碼是否加密，後台使用哈希演算法的安全內容轉換都是必要的。（MD5不能使用BCrypt的，我以前回答類似：用圖形表現，當前快速發展的快速哈希演算法已成為不安全嗎？）有一個人同意這個答案，我希望你不要被錯誤的答案誤導。對方的回答，Linh說，是為了防止原始密碼被利用在一個不安全的HTTP連接。但問題是，因為你的登錄系統接受密碼代替原來的，竊聽者根本不需要原始密碼，只要哈希結果可以偽造請求登錄系統。這樣做只會防止攻擊者在社交攻擊時使用原始密碼，而不會提高網站的安全性。所以不管前面密碼是不是加密的，使用HTTPS安全連接登錄都是很有必要的。
㈣ HTTPS通信時,Web伺服器收到加密後的「對稱加密用的密鑰」,使用什麼對其進行解
https其實是有兩部分組成：http + SSL / TLS，也就是在http上又加了一層處理加密信息的模塊。服務端和客戶端的信息傳輸都會通過TLS進行加密，所以傳輸的數據都是加密後的數據。具體是如何進行加密，解密，驗證的，且看下圖
㈤ web文件上傳能否對文件加密
您可以對用超級加密3000將文件加密後再上傳。
㈥ web滲透測試之攻破登錄頁面
當我們在做滲透測試時，無論廠商項目還是src眾測項目，都會遇到給一堆登錄系統的URL，然後讓我們自己去測，能不能進去全看天的狀況，本文將講一下怎麼突破這種封閉的web系統，從而進行更深層次的滲透 ，學完後你會發現，其實你就是系統管理員。
如果能直接繞過登錄系統界面，後面的就比較好做了，目前常見的登錄系統繞過方法有：
大部分情況下，系統登錄頁面都不存在xss，目錄遍歷，SQL注入等漏洞，這時候最常用的方法就是爆破和猜解登錄口令，密碼猜解最關鍵的就是字典要高效准確
https:// down.52pojie.cn/Tools/N etwork_Analyzer/Burp_Suite_Pro_v1.7.31_Loader_Keygen.zip
2.准確的用戶名，密碼字典是高效破解的重中之重 ，一般都是指定幾個常見用戶名 ，嘗試 top500，top1000進行爆破 字典不必要太大，最重要的是針對性要強 ，下面是top1000：
鏈接: https:// pan..com/s/1-XztuB 8YTfpT5aUBVbmbzA 密碼: 56pb
3.如果還是不能猜解成功，就要根據目標信息用字典生成器構造針對性的字典來猜解了，推 薦幾個比較好的字典生成工具
pydictor：
LandGrey/pydictor
crunch:
crunch - wordlist generator
Cewl:
digininja/CeWL
Cupp:
Mebus/cupp
因為管理員許可權較高，通常我都會先進行管理員口令的猜解，總結了一些常見的管理員用戶名字典
<u>鏈接:</u> <u> https:// pan..com/s/1sOD1-u whnStaw_LfMOf-sQ </u><u>密碼: 3yqe</u>
用此用戶名字典，再加上弱口令top1000，同時爆破系統管理員用戶名密碼
鏈接: https:// pan..com/s/1-XztuB 8YTfpT5aUBVbmbzA 密碼: 56pb
常見的普通用戶用戶名是姓名拼音，總結了普通用戶字典
TOP3000姓名
<u>鏈接:</u> <u> https:// pan..com/s/1qN9kCF tymP4ugvu3FFkKbA </u><u>密碼: hkzp</u>
TOP10w姓名
https:// github.com/rootphantome r/Blasting_dictionary/blob/master/top10W.txt
通常可以選擇幾個弱口令密碼，比如：123456，123abc，111111，然後配合top10w來猜解登陸口令，一些初始化的默認密碼也很簡單，如果能找到配合top10w通常也能爆出登錄口令
現在的業務系統口令傳輸到後端前都會進行加密處理 ，web常見的加密方式有 md5 加密、sha1 加密、RSA 加密，在此基礎上總結了兩種破解方式：
1.利用burpsuite的payload processing功能，把字典按照加密方式先加密再發包
2.用字典生成工具生成加密好的字典，然後burp直接載入加密字典
這里推薦的字典生成工具是pydictor，encode功能內置了多種加密演算法，調用handler工具直接加密自己的明文字典
如果登錄系統設置了IP地址白名單，我們可以通過下面的幾個http頭欄位偽造IP地址，用burp抓包後將下面的某個http頭欄位加入數據包發送到伺服器
<pre class="prettyprint hljs css" style="padding: 0.5em; font-family: Menlo, Monaco, Consolas, "Courier New", monospace; color: rgb(68, 68, 68); border-radius: 4px; display: block; margin: 0px 0px 1.5em; font-size: 14px; line-height: 1.5em; word-break: break-all; overflow-wrap: break-word; white-space: pre; background-color: rgb(246, 246, 246); border: none; overflow-x: auto;">Client-Ip: 127.0.0.1
X-Client-IP: 127.0.0.1
X-Real-IP: 127.0.0.1
True-Client-IP: 127.0.0.1
X-Originating-IP: 127.0.0.1
X-Forwarded-For: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Remote-Addr: 127.0.0.1
X-Forwarded-Host: 127.0.0.1</pre>
如果在系統登陸界面加上了驗證碼，那麼上面的方法基本上就都失效了，那有什麼方法可以繞過驗證呢
1.圖形驗證碼不刷新
在一段時間內只要不刷新頁面，無論登錄失敗多少次都不刷新驗證碼，這個時候就可以使用同一個驗證碼根據上面的方式進行暴力破解
2.驗證碼失效
不管在驗證碼表單輸入什麼樣的數據，都會判斷通過，但這種情況很少見
3.圖形驗證碼可被識別，抓包直接可以獲得驗證碼
很多網站的驗證碼都可以在請求數據包中找到，或者隱藏在request的cookie中，response的源碼中，可以利用burpsuite的macros來匹配response中的相應數據，具體的爆破方法參見下文：
burpsuite爆破密碼（含驗證碼） - CSDN博客
4.圖形驗證碼參數直接繞過
對於request數據: user=admin&pass=1234&vcode=brln，有兩種繞過方法：
一是驗證碼空值繞過，改成 user=admin&pass=1234&vcode=；
一是直接刪除驗證碼參數，改成 user=admin&pass=1234。
5.萬能驗證碼
滲透測試的過程中，有時候會出現這種情況，系統存在一個萬能驗證碼，如0000、9999，只要輸入萬能驗證碼，就可以無視驗證碼進行暴力破解。
6. 驗證碼可被識別
有些圖形驗證碼加入的像素線條過於簡單，使用圖形驗證碼識別工具可以識別出每次更換的驗證碼，在平常的漏洞挖掘過程中，如果我們發現登錄的驗證碼非常簡單且易於識別，那我們就可以嘗試使用自動化工具來進行登錄破解了，如 PKAV 的 HTTP Fuzzer
7.使用機器學習演算法識別驗證碼
主要是對特定網站的圖形驗證碼訓練識別模型，達到一定的准確率就可以調用進行模擬提交圖形驗證碼的值了。可參考以下三篇文章進行學習：
使用KNN演算法識別驗證碼:
http:// nlao.github.io/2016/0 9/22/%E9%AA%8C%E8%AF%81%E7%A0%81%E7%A0%B4%E8%A7%A3%E6%8A%80%E6%9C%AF%E5%9B%9B%E9%83%A8%E6%9B%B2%E4%B9%8B%E4%BD%BF%E7%94%A8K%E8%BF%91%E9%82%BB%E7%AE%97%E6%B3%95/
卷積神經網路識別驗證碼
http:// nlao.github.io/2016/0 9/23/%E9%AA%8C%E8%AF%81%E7%A0%81%E7%A0%B4%E8%A7%A3%E6%8A%80%E6%9C%AF%E5%9B%9B%E9%83%A8%E6%9B%B2%E4%B9%8B%E4%BD%BF%E7%94%A8%E5%8D%B7%E7%A7%AF%E7%A5%9E%E7%BB%8F%E7%BD%91%E7%BB%9C/
使用 TensorFlow 訓練驗證碼
http:// nlao.github.io/2017/0 4/10/%E4%BD%BF%E7%94%A8TensorFlow%E8%AE%AD%E7%BB%83Weibo-cn%E9%AA%8C%E8%AF%81%E7%A0%81/
對於網站要求輸入手機號，接收手機簡訊並校驗簡訊驗證碼是否正確進行登錄的系統，突破的主要思路有：
1.簡訊驗證碼生命期限內可暴力枚舉
在驗證碼還未過期的時間段內，可枚舉全部的純四位數字、六位數字等較簡單的簡訊驗證碼；
2. 簡訊驗證碼在數據包中返回
和圖形驗證碼一樣，在response中可以直接獲取到簡訊驗證碼。
3. 修改請求數據包參數或 Cookie 值繞過
比如有 post 數據包：mobile=12435437658&userid=123456, Cookie中有：codetype=1
在特定步驟，修改 mobile=自己的手機號，自己手機就可以收到別人的驗證碼，後面再用別人的手機號和接收到的驗證碼登錄；
修改 Cookie 中可疑的參數和值，進行繞過，比如上面修改 codetype=0；
4. 修改返回包繞過
提交錯誤的簡訊驗證碼，返回包中有： status=false，在Burpsuite中修改為 status=true，即可繞過前端判斷，成功進入系統。具體還要結合實際的場景，靈活操作。
web系統登陸頁面看似銅牆鐵壁，但其實只要梳理一遍思路，右鍵看過每一行網站源碼，弄懂每個參數的意義，查看每一個js文件，就會發現其實自己就是系統管理員，只是我把密碼忘了，現在我要用上面的方式進入。
㈦ 確保Web安全的HTTPS
很多人說「不用HTTPS就是裸奔」
HTTP的不足：
通信使用明文（不加密），內容可能會被竊聽(wireshark/fiddler)
不驗證通信方的身份，因此有可能遭遇偽裝
無法證明報文的完整性，所以有可能已遭篡改
TCP/IP 是可能被竊聽的網路
1.通訊的加密：
SSL(Secure Socket Layer,安全套接層）或TLS(Transport Layer Security,安全層傳輸協議)
有興趣深入SSL/TLS: https://www.jianshu.com/p/3e5f01360827
用 SSL 建立安全通信線路之後，就可以在這條線路上進行 HTTP通信了。與 SSL 組合使用的 HTTP 被稱為 HTTPS（HTTP Secure，超文本傳輸安全協議）或 HTTP over SSL。
2.內容的加密：
為了做到有效的內容加密，前提是要求客戶端和伺服器同時具備加密和解密機制。主要應用在 Web 服務中。有一點必須引起注意，由於該方式不同於 SSL 或 TLS 將整個通信線路加密處理，所以內容仍有被篡改的風險。
不驗證通訊方的身份就可能遭遇偽裝
無法確定請求發送至目標的 Web 伺服器是否是按真實意圖返回響應的那台伺服器。有可能是已偽裝的 Web 伺服器。
無法確定響應返回到的客戶端是否是按真實意圖接收響應的那個客戶端。有可能是已偽裝的客戶端。
無法確定正在通信的對方是否具備訪問許可權。因為某些Web 伺服器上保存著重要的信息，只想發給特定用戶通信的許可權。
無法判定請求是來自何方、出自誰手。
無法證明報文的完整性，可能已遭篡改
如何防篡改？
可以使用MD5和SHA-1等散列演算法，但這仍然無法百分百保證結果的正確，因為散列碼如果同時被修改的話，用戶還是無法意識到文件已經被修改。還是用HTTPS吧。
HTTP+ 加密 + 認證 + 完整性保護=HTTPS
HTTP是身披SSL外殼的HTTP
相互交換密鑰的公開密鑰加密技術 ：
共享密鑰加密的問題：
證明公開密鑰的正確性的證書：
也可以通過設置->高級->管理HTTPS證書來查看所有已經安裝的證書（chrome瀏覽器）
HTTPS的安全通信機制：
步驟 1： 客戶端通過發送 Client Hello 報文開始 SSL 通信。報文中包含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所使用的加密演算法及密鑰長度等）。
步驟 2： 伺服器可進行 SSL 通信時，會以 Server Hello 報文作為應答。和客戶端一樣，在報文中包含 SSL 版本以及加密組件。伺服器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。
步驟 3： 之後伺服器發送 Certificate 報文。報文中包含公開密鑰證書。
步驟 4： 最後伺服器發送 Server Hello Done 報文通知客戶端，最初階段的 SSL 握手協商部分結束。
步驟 5： SSL 第一次握手結束之後，客戶端以 Client Key Exchange 報文作為回應。報文中包含通信加密中使用的一種被稱為 Pre-mastersecret 的隨機密碼串。該報文已用步驟 3 中的公開密鑰進行加密。
步驟 6： 接著客戶端繼續發送 Change Cipher Spec 報文。該報文會提示伺服器，在此報文之後的通信會採用 Pre-master secret 密鑰加密。
步驟 7： 客戶端發送 Finished 報文。該報文包含連接至今全部報文的整體校驗值。這次握手協商是否能夠成功，要以伺服器是否能夠正確解密該報文作為判定標准。
步驟 8： 伺服器同樣發送 Change Cipher Spec 報文。
步驟 9： 伺服器同樣發送 Finished 報文。
步驟 10： 伺服器和客戶端的 Finished 報文交換完畢之後，SSL 連接就算建立完成。當然，通信會受到 SSL 的保護。從此處開始進行應用層協議的通信，即發送 HTTP 請求。
步驟 11： 應用層協議通信，即發送 HTTP 響應。
步驟 12： 最後由客戶端斷開連接。斷開連接時，發送 close_notify 報文。上圖做了一些省略，這步之後再發送 TCP FIN 報文來關閉與 TCP的通信。
問題：為何不完全使用非對稱加密演算法，而是使用非對稱加密演算法傳送密鑰，對稱加密演算法加密內容？（性能問題）
常見對稱加密演算法:AES/DES
常見非對稱加密演算法：RSA
對稱加密演算法和非對稱加密演算法速度對比：
https://blog.csdn.net/wowotuo/article/details/80295586
要進行 HTTPS 通信，證書是必不可少的。而使用的證書必須向認證機構（CA）購買。證書價格可能會根據不同的認證機構略有不同。通常，一年的授權需要數萬日元（現在一萬日元大約摺合 600人民幣）。
https不是只有信徒，google的霸道也引來了很多的反抗者~
1.chrome瀏覽器將非https站點默認標注為「不安全」的
2.SEO，不https就掐掉流量。。。
RSS 之父 Winer 炮轟 Google 反客為主強推 HTTPS：
https://www.oschina.net/news/97660/dave-winer-criticize-google
搭建一個https服務端：
https://www.jianshu.com/p/c59ea7d0230e
windows server上的一個簡單https例子(不想亂搞測試環境，就沒弄Linux)：