英語以外の言語でクライアント/サーバーシステムをプログラミングする方が安全ですか？
RESTフロント（JavaScript）とバックエンド（Java/Spring）の間で通信するシステムを開発しています。この質問がポップアップしました。
このシステムは、英語以外の言語で変数、URLなどに名前を付けることがより安全になりますか？
最も重要なプログラミング言語は英語であるため、ほとんどのプログラマーが少なくとも少しは知っている可能性が高いためです。私たちのものに別の言語で名前を付けると、攻撃者が何を意味し何をするのか理解するのが難しくなるため、ハッキングがより困難になる可能性があります。
「プログラミング」と「言語」を一緒に使用すると「言語」の他の意味に関する結果を見つけることができないため、Googleで結果を見つけることができませんでした。
技術的には少し、はい。だが：
- それは obscurityによるセキュリティ ですが、これは悪い考えです
- それはあなたの製品への信頼を高めません
- 何が何をしているのかを理解するのは非常に簡単で、少しの時間しかかかりません
- グーグル翻訳、あなたはただ無意味な名前を使うことができます、それはまだあまり役に立ちません
- メンテナンスが難しくなります
- 監査人が言語を理解できない可能性があるため、監査は非常に困難になります
すべてを考慮すると、おそらくそれだけの価値はありません。
それほど安全ではありません。リバースエンジニアは、anyの元の名前をそのままにしていないシステムで作業することを余儀なくされることが多いため（プロダクションソフトウェアでは、シンボル名が削除されることが多い）、対処に慣れています。コンピュータによって生成された名前で。 例は、ウィキペディアから取得され、よく見られる逆コンパイルされたCコードの種類のスニペットの例です：
struct T1 *ebx;
struct T1 {
int v0004;
int v0008;
int v000C;
};
ebx->v000C -= ebx->v0004 + ebx->v0008;
この種の表現での作業に慣れている人々は、無関係な名前が付けられた変数などの使用に騙されません。 これはコンパイルされたコードに固有ではありません、そしてCの使用は単なる例でした。一般にリバースエンジニアは、直感的でないコードを理解するために使用されます。 JavaScript、Java、Cのいずれを使用しているかは問題ではありません。API自体との通信しか分析していないかどうかは問題ではありません。リバースエンジニアは、ランダムまたは無関係な変数または関数名の使用に騙されることはありません。
本当にそうではありません-組み込み関数はすべて英語のままなので、変数が何を表すかを理解するのにそれほど多くの労力は必要ありません。それは誰かを少し遅くするかもしれませんが、人々がまだ至る所に単一の文字変数でコードをリバースエンジニアリングしたり、難読化ツールを介して実行されていたりすると、変数と関数に使用される言語を交換することは単に検索置換を行うことを意味します変数の使用目的を把握したら、十分に理解するまで繰り返します。
これはあいまいさによるセキュリティであり、専用の攻撃者を5分間遅らせます。
攻撃者を混乱させたい場合は、反対の名前や無関係の名前を付けても同じ効果があります。したがって、「ユーザーの作成」関数は「BakeCake」という名前にすることができます。これで、どれだけのセキュリティが得られるかを自分で答えることができます。実際、これはmore安全です。辞書を使用するだけでは無効にできないためです。
はい、最初は混乱しますが、稼働中のシステムを見ると、すぐにすべてが非常に明確になります。
システムは それ自体で安全 でなければなりません。ユーザー側のJavaScriptが値「open sesame」のパラメーターを渡すことに依存している場合、それは間違っています。
あなたにとってより便利な言語でプログラムを開発する必要があります（たとえば、コーダーの熟練度、コードベースとの一貫性、または使用している用語にさえ基づいて）。
他の回答はすでにそれが本当にセキュリティを提供しない方法を指摘しました。安全なプログラムを作成したい場合は、潜在的なハッカーがコードを簡単に読んで秘密の穴を学ぶことではなく、それをの人がそれを監査できるように読みやすくすることにもっと注意する必要があります。
Nonceと呼ばれる関数パラメーターがあり、リクエスト全体でそれが一意であることをどのように保証しているのかを示すコメントがリクエストで送信されない場合、それが間違いであると確信できます。実際、そのコードを読みやすくすると、そのパラメーターがドロップ/空になる可能性が低くなります（結局のところ すべてがなくても機能します ...）、またはそれが実際に発生する場合は、別のパラメーターを簡単に開発者は問題に気づきます。
（サードパーティもあなたにそれについてヒントを与えるかもしれません。おそらく、実際にそれを壊そうとしている人よりも、それをカジュアルに見ている人の方が多いでしょう。 ）
TL; DR：読み取り可能なコードを生成します。それに対処すべき人々のために。疑わしい場合は、ほとんどの人が知っているものを選んでください。
システムのメンテナンスが困難になることで、事態がさらに悪化する可能性もあります。
歴史に触発された極端な例を取り、フロントエンドとバックエンドの間で Navajo で通信します。 （もしそうでなければ）コードにパッチを当てる必要があるとき：
- 意味のないことを処理する（バグ/タイプミスに加えて、非直感的なコードの処理に時間がかかる）
- ナバホ語に堪能なプログラマーを雇う/維持する（契約者を見つけるのはおそらく不可能であり、非常に高価なスキルの組み合わせ）
また、クライアント側のJavaScriptのほとんどのインスタンスでは、クライアントのパフォーマンスを向上させるために（意味のある変数名などを使用して）開発されたスクリプトが「縮小」されます（ダウンロードするファイルサイズが小さい）。
この一部として、ほとんどの変数名は1文字に短縮され、可能な限り多くの空白が取り除かれます。これは、あなたが書くかもしれない他のどんなものと同じくらい読めなくなるでしょう。
また、chrome（たとえば）には、このような「人間が読めない」ファイルを「きれいに印刷」するメソッドがあるため、何が起こっているのかを簡単に理解できるようになります。オン。
要するに、クライアント側のコードの記述に使用する人間の言語は、実際には大きな違いはありません。
マスメディアを信じるなら、ハッカーの大多数はロシア、中国、北朝鮮なので、彼らはすでに非ネイティブで西洋のシステムをハックしなければならないという「ハンディキャップ」の下で活動している言語。したがって、映画のように信じられないほどあいまいなものを選択しない限り、Windtalkersそれらは何の違いもありません。しかし、あなたのための余分な努力は、バグを見つけて修正するための時間を短縮することを意味します。そのため、この戦略があなたのセキュリティを保証するweaker。
いくつかの回答では、これは「あいまいさによるセキュリティ」であり、実際にはセキュリティの形式ではないことが（正しく）指摘されています。攻撃者が忙しく攻撃している間、攻撃者が完全に注釈付きのソースコードをその前に置いていると想定するのが最も安全です。
リクエスト/トランザクション/セッションの前に知ることができるすべてを知っている場合、ソフトウェアは「安全」です[〜＃〜] and [〜＃〜]これは実際のセキュリティに影響を与えません製品の。
ソースコードは、不満を持つ従業員が解雇されて解雇されないためにのみ公開されていると見なす必要があります。あるいは、よく言われるように、「2人が秘密を守る唯一の方法は、そのうちの1人が亡くなった場合」です。したがって、あらゆる種類の難読化によって隠されている「特別な知識」は、生成されるとすぐに「一般的な知識」になったと見なす必要があります。
セキュリティは、本質的には、「何をするかを言い、何を言うかをすること」にすぎません。セキュリティ分析— Common Criteriaの下で行われるようなコード監査および正式な評価スキーム—アクションを実行するためのメカニズムが十分に文書化され、あるセキュア状態から別のセキュア状態へのすべての遷移がすべての要件の場合にのみ可能であることが必要です満足しています。あらゆる種類の難読化のリスクの1つは、巧妙なコーディングによってこれらの要件が不明瞭になることです。「密かに」「ユーザーの削除」または「ユーザーの名前の変更」またはその他の方法であるため、「create_user（）」が失敗する例を参照してください。このような名前の変更が脳でどれほど難しいかを示す実際の例として、画面に別の色で印刷されている色の名前を読み取る必要があるオンラインテストがあります。たとえば、青色のフォントで書かれた「RED」という単語は、「RED」の代わりに「BLUE」と言う人もいます。
それは無関係かもしれません。英語ではなくイタリア語（例：イタリア語）でコーディングしているが、ほとんどの顧客はイタリアにいるというシナリオを考えてみてください。当然、イタリア語を話すハッカーは、あなたを攻撃する動機/見返りが高いです。
このシナリオでは、別の言語でコーディングしても効果がないか、ハッキングが容易になります。