ホームページ > 記事 > ウェブフロントエンド > Web フロントエンド JS コードは保護する必要がありますか? Web フロントエンド JS コードを保護する方法
Web フロントエンド JS コードは保護する必要がありますか?
これには、特定の状況の詳細な分析が必要です。
1. Web ページの画像カルーセルやマーキー効果などの単純な関数を作成する場合。それは保護を必要としません。
2. 豪華な特殊効果を慎重に設計し、苦労して実装した特殊効果コードを他人が自由に使用できないようにしたい場合は、この JS コードを保護する必要があります。
3. トランザクション ロジック、アカウントとパスワードの情報、個人のプライバシー、さらにはリモート サーバーやデータベースとの通信など、JS コードによって制御される重要な機能がページ上にある場合、関連する JS コードを次のようにする必要があります。 JS コードの盗難防止保護を行う必要があります。
そうしないと、ハッカーによって分析され、攻撃されるなど、重大な問題が発生する可能性があります。安全関連の問題は常に芽を摘み取る必要があり、成り行き任せにすべきではありません。それがあなたにとってまったく重要でない限り。
Web フロントエンド JS コードを保護するには?
1. パッケージ化と圧縮
パッケージ化と圧縮が JS コードの保護であると考える人もいます。確かに、梱包は少なくともある程度の保護を提供できると思われます。ただし、パッケージ化と圧縮の目的は、JS コードを保護することではなく、使用を容易にし、コード サイズを削減し、使用を容易にし、送信を容易にすることです。たとえば、モジュール型プログラミングでは、「script src」を使用して 1 つずつ参照すると、200 個の JS ファイルが生成される可能性があります。これは、エージェントにとっても、ネットワーク読み込みにとっても、一種の拷問です (ブラウザも同様です)。 x_x)怒ってください!
Webpacket や Gulp のパッケージ化と同様に、これらの複数の JS を 1 つのファイルに合成でき、コード圧縮を実現するためにキャリッジ リターン、ライン フィード、およびスペースを削除することもできます。また、長い変数名を統一スタイルに変更するなどの単純な難読化操作もいくつかあります。短い変数名など。そして、最終的にファイルが生成される。総コード量が減り、可読性も悪くなり、使いやすくなりました。同時に、これで JS コードの保護も実現できると考える人もいます。実際には、もちろんコードは保護されていません。読みやすさは変わりませんが、コードの量は増えていますが、少し忍耐強くコードを読めば、コードが依然として理解しやすいことがわかります。 、セキュリティはまったくありません。
2. 難読化と暗号化
フロントエンド JS コードを保護するには、難読化と暗号化を組み合わせる必要があります。
JS ソースコードを個別に暗号化することは不可能であり、ましてや JS のいわゆる不可逆暗号化は不可能です。コードがブラウザ側で実行される場合、ブラウザの JS エンジンによって認識されて実行される前に、コードが復号化されて元のコードに復元される必要があるためです。復号化後は、完全な元の JS コードが存在します。これは非常に安全ではなく、元の JS コードを表示する方法はたくさんあります。
JS コードの難読化は、多くの開発者によってローエンドの JS コード保護方法であると考えられており、JS ソース コードの暗号化よりも安全性が低いように思えます。実際、難読化には複数のレベルがあります。たとえば、比較的ローエンドの文字検索と文字列置換、疑似ゾンビ コードのランダムな挿入、文字列の 16 進化などです。最初に構文解析、字句解析を実行し、構文ツリーを再構築する高度なメソッドもあります。これは、JS エンジンを実装し、エンジン内でコードを処理するのと同じです。その後、高度な操作を実行できます。たとえば、新しい構文構造を構文ツリーに挿入したり、すべての文字列を抽出して暗号化したり、変数を定期的に再定義して意味をなくしたりできます。これにより、真のコードの再構築が可能になります。このようにして再構築された JS コードの安全性は質的に向上します。
JShaman JS 保護など、実際の難読化と暗号化を併用すると、 は実際の JS コードのセキュリティ保護を実現できます。 JS 暗号化は JS 難読化に統合され、JS 難読化は JS 暗号化に埋め込まれます。このように保護されたコードをクライアントの実行環境で逆復元しても、意味不明の関数、コード、文字列が大量に取得されてしまいます。特別な点は、コードが再構築されており、リバース エンジニアリングによって得られるものは、意味のない JS コード、大量のゾンビ コード、混乱した文字列、意味不明の変数などを分離して再構築したものであることです。元のコードと比較すると、読みやすさは雲泥の差です。 頑固な人は、「解読できない保護ソリューションはない」とも言うかもしれません。注意深く、注意深く、時間をかけて分析する限り、元のコードの意味を分析することはできます。
ただし、元のコードを読み取るのに 10 分しかかからないかもしれませんが、保護された JS コードから元の意味を読み取るには… 10 か月かかる場合があります。現時点では、JS コードが次のバージョンに更新されている可能性があります。
JSコード保護の目的は達成されましたね。
Web フロントエンド開発のアップロードアバター JS サンプル コードのアップロード
以上がWeb フロントエンド JS コードは保護する必要がありますか? Web フロントエンド JS コードを保護する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。