當前位置:首頁 » 網頁前端 » 前端代碼加密
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

前端代碼加密

發布時間: 2022-02-01 00:56:22

❶ URL請求對參數前端JS加密,後台JAVA解密

數字的話可以使用 Base62 演算法,不過這只是表面的轉換,因為演算法是寫在Js里的,稍加分析就能知道怎麼去翻轉。
如果要有效加密的話,可以使用js調用RSA演算法進行加密,這樣js中只會暴露公鑰,可以實現安全的加密。
網上多得很。

❷ 求助前端JS都是用什麼加密的

寫過js混淆器,談一些淺顯的個人看法。個人認為,js的不可讀化處理分為三個方面:壓縮(compression)、混淆(obfuscation)和加密(encryption)。(不可讀化處理,這是我自己發明的術語,一切會增加代碼不可讀性的代碼轉換,都可以這么叫,「增加代碼不可讀性」可能是代碼轉換的結果或者目的).1.壓縮這一操作的目的,是讓最終代碼傳輸量(不代表代碼量,也不代表文件體積)盡可能小。壓縮js的工具,常見的有:YUICompressor、UglifyJS、GoogleClosureCompiler等。通常在代碼壓縮的過程中,只改變代碼的語法,代碼的語義和控制流不會有太大改變。常見做法是把局部變數縮短化,把一些運算進行等價替換等。代碼壓縮對於代碼保護有一些幫助,但由於語義和控制流基本沒變,起不了太大作用。在壓縮層面上,代碼不可讀只是一種附帶傷害,不是最終目的。2.混淆這一操作的目的,是讓代碼盡可能地不可讀,主要用作代碼保護。讓代碼不可讀,增加分析的難度,這是唯一目的。混淆過後文件體積變大一倍也沒關系,代碼量變多也沒關系,運算慢50%也沒關系。常見的做法有:分離常量、打亂控制流、增加無義代碼、檢查運行環境如果不對就罷工,等等。在混淆層面上,代碼不可讀是最終目的。值得一提的是,GoogleClosureCompiler的AdvanceLevelCompression會壓縮類和對象的成員,其壓縮結果很難分析,也可以認為是一種混淆,但兼容性不太好。廣告時間:我寫的js混淆器,中文名叫「看起來很厲害的JS編譯器」,英文名叫做TheImpressiveJS.Segment.Compiler,看起來很厲害的JS編譯器。3.加密說實話我很難對加密做一個定義,因為加密在Web界有太多歧義了。有加密就有解密,意味著加密操作可逆,密文可以明文化。就這樣看來,在Web界,可以稱之為加密的東西包括:HTTPS傳輸、JavaScript實現對稱加密或者不對稱加密等等。這樣看來,不可逆的代碼壓縮和混淆就不能列入加密這個范疇了。非要找一個可以稱之為加密,又經常被人誤解為壓縮和混淆的東西,DeanEdwards的DeanPacker/Unpacker可以拿來做個例子。比如我們把varnum=1;alert(num);輸入DeanPacker,pack一下,得到這么一串東西,是不是看著非常像被壓縮和混淆過的代碼?把上面那串意義不明物拿來unpack一下,得到了原文。實際上DeanPacker只是對源碼進行了一個字元串變換,沒有深入到代碼語法層面,你可以拿"Helloworld,你好師姐"來試試。用OnlineJavaScriptbeautifier能輕松把這串東西還原為「Helloworld,你好師姐」。可以看出,代碼加密意味著:將代碼明文進行可逆的變換(加密),生成密文;將密文進行逆變換(解密),可以還原明文;最終運行環境運行的是解密代碼。結語實際上大家對壓縮、混淆、加密這三個概念還是挺不清晰的,我在這里說一些個人見解,希望有幫助。在現實項目中,我是多種手段結合的:對於不需要做代碼保護的項目,比如個人博客,做代碼壓縮,加快載入速度,這就夠了。對於需要做一些代碼保護,防止抄襲的項目,可以在源碼中加入一些開發者的信息和防護代碼,然後混淆和壓縮。很不幸的是,我這方面總是做得不太好,防君子防不了小人啊哈哈。對於需要嚴格加密的項目,可以用混淆、壓縮、加密、簽名檢查等多種手段,這我就不清楚了,等大嬸來補充。

❸ 如何利用js加密html/css代碼

這是不可能的,不管怎麼加密,最終都要以明碼的形式才能被瀏覽器解析和渲染,所以只能騙騙小白,而想盜取你的網站源碼的人肯定都是專業人士,這種手段對他們而言可是不值一提。
換個角度想想看,各個銀行的網銀網頁,以及支付寶、財付通等等這些重要的直接與錢打交道的網站,他們的前端網頁為什麼不加密啊?是技術不行么?

❹ Web前端密碼加密是否有意義

密碼在前端加密完全沒有意義,對密碼系統的安全性不會有任何提高,反而會引發不必要的麻煩。首先,做前端開發的人需要知道,前端系統的控制權是完全在用戶手裡的,也就是說,前端做什麼事情,用戶有完全的控制權。假設如同 @陳軒所說,前端做過了md5,後台就不用做了,這個做法會有什麼後果?如果某一天,這個系統的資料庫泄露了,黑客就直接拿到了每個用戶的密碼md5值,但此時,由於黑客知道密碼是在前端進行哈希的,所以他不需要爆破出該md5對應的原文是什麼,而是直接修改客戶端向伺服器發出的請求,把密碼欄位換成資料庫中MD5就可以了,由於與資料庫中記錄一致,直接就會登錄成功。這跟直接存儲明文密碼沒有任何區別!!!所以不管前端是不是加密了密碼,後台使用安全的哈希演算法對內容再次轉換是非常有必要的。(MD5可不行,要用bcrypt,我之前回答過一個類似的:隨著顯卡性能的高速發展,目前的快速Hash演算法是否已經變得不夠安全了?)這個回答還有一個人贊同,希望大家別被錯誤答案誤導了。另外一個答案 @林鴻所說,在非安全HTTP連接上,可以防止原始密碼被竊聽。但問題在於由於你的登錄系統接受的哈希過的密碼,而不是原文,竊聽者根本不需要原始密碼,只要通過哈希結果就可以偽造請求登錄系統。這樣做只能防止被竊聽到原文的密碼被攻擊者用在社會學攻擊上,而不能改善該網站的安全性。所以不管前端是不是加密了密碼,使用HTTPS安全連接進行登錄都是非常有必要的。以上我說的兩點,合起來看就是:不管前端是否加密了密碼,都不能以此為假設,讓後端設計的安全等級下降,否則就會有嚴重的安全問題。實際上,前端進行密碼加密,可以看做幫助用戶多進行了一次原文的轉換,不管用了什麼加密演算法,算出來的結果都是密碼原文,你該如何保護用戶的原始密碼,就該如何保護此處的加密結果,因為對你的登錄系統來說,它們都是密碼原文。以上這些,說明了密碼加密是沒有什麼意義的,接下來,我要說明前端加密會帶來什麼問題。有些人會認為前端進行了加密,可以降低後台的安全性需求,這種錯誤的觀念會造成系統的安全漏洞。實際上,你不能對前端做任何的假設,所有跟安全相關的技術,都必須應用在後台上。前端進行加密會造成頁面需要js腳本才能運行,那麼假設你的系統需要兼容不能運行js的客戶端,就必須再設計一個使用原文的登錄介面。由於前端是不是加密,所有安全機制都必須照常應用,所以為系統增加這樣的復雜性是完全沒必要的,即使傳輸明文密碼,只要正確使用了HTTPS連接和伺服器端安全的哈希演算法,密碼系統都可以是很安全的。

❺ 在網頁前後端傳json的時候,一般用加密么比如我從前端傳一個id跟一個value給後端怎麼處理呢

格式:{id: value}詳細加密代碼參照網路經驗:https://jingyan..com/article/6f2f55a114b012b5b93e6cc4.html

❻ 前端加密傳遞信息時,有什麼好的方法

試試鐵馬加密軟體,可以試用,並提供針對性的加密服務。
鐵馬加密16年加密經驗,能為企業提供針對性的文件加密解決方案,防止圖紙、文件、源代碼,資料庫等等商業秘密非法外泄。具有後台自動運行、不影響工作、無需員工配合等特性。
加密場景包括內部流通、外發、員工出差、伺服器存儲等。

❼ html前端幾種加密方

可以直接的啊。。。

❽ web前端的數據如何加密

前端數據一般都需要在後台使用的所以必須要用可逆的加密方式 現在比較流行的就是非對稱的加密方式比如RSA 具體方法是生成兩個秘鑰 公鑰 私鑰 前端使用js(可以網路下載)把數據利用公鑰進行加密 加密結果傳給後端 後端利用私鑰解密方法對數據進行解密

❾ 如何在前端調用js對密碼進行加密

加密和解密原則上都應該在後台完成才合乎常理,如果在前端加密,就好比在眾目睽睽之下化妝易容,然後聲稱自己是另一個人一樣,沒意義啊。
如果一定要在前端加密,可以這樣:
<input type="submit" name="submit" value="注冊" onclick="var pwd=document.getElementsByName('password')[0];pwd.value=md5(pwd.value);"/>

❿ Web前端密碼加密是否有意義

在前端對密碼做一次MD5,看起來是防止明文傳輸了,事實上只有一種情況下它可以提高用戶的安全性,那就是用戶在別的網站上也用和你的網站一樣的密碼。並且在任何情況下都提高不了你自己網站的安全性。前面說的傳輸過程、內存里、日誌里……這些地方沒有明文密碼,其實都只能保護用戶本身的利益,對於自身服務的安全性是沒有提高的。因為,既然傳輸過程不是加密的,那麼包隨便發,至於發一個abc123,還是發一個,對你的程序沒有任何的區別,這時候你的程序都是小綿羊。這個過程可以看做,你的用戶都用了32位字元串的密碼,如是而已。從事實意義上講,在所有網站上用同樣密碼的用戶非常多,所以可以勉勉強強的說,這是有一丁丁點的意義的。但即使在前端做了簽名,因為hash暴露了,也還是很容易被撞庫。但是,對安全性沒有提高,就不做了嗎?當然要做,因為要應付審計。