a-b<cがあり、Javaセキュリティについて考えています.
2623 ワード
ソフトウェアエンジニアリングでは、どの開発言語を使用しても、セキュリティは非常に厄介で重要な問題です.セキュリティはソフトウェア開発分野の永遠のテーマの一つであり、インターネットの混雑と発展に伴って牽引された新技術の興起と革命(例えば近年火をつけたnode.js、python、goなど、マイクロソフトもオープンソース後の.net Core)に伴い、ソフトウェアエンジニアリングにおけるセキュリティがより際立って重要になった.
では、何が危険なのでしょうか.私の最初の反応はSQL注入攻撃などの注入攻撃です.1つの典型的なシーンはWEBアプリケーションの中で、ユーザーのログイン機能、ユーザーが入力したユーザー名のパスワードによって相応のデータを取得して、それではSQLの注入は運に応じて生まれて、ユーザー名を模擬して、パスワードは特殊な文字を加えて、悪意のあるスクリプトなどの手段を加えて、更に引き返すことができない結果をもたらします.例えば、通常のスクリプトは、
安全なJavaコードの作成方法について、Sun公式はガイドを提供し、興味のある学生はこの文章を参考にすることができます.
•静的フィールド•役割ドメインの縮小•共通メソッドとフィールド•保護パッケージ•equalsメソッド•オブジェクトを変更できない可能性がある場合•機密データを含む内部配列への参照を返さない•ユーザーが提供する配列を直接保存しない•シーケンス化•原生関数•機密情報のクリア
例えば、DoSはよく見られるサイバー攻撃で、「洪水攻撃」と戯れる人もいる.その慣用的な手法は、大量のマシンが要求を送信したり、ターゲットサイトのブロードバンドとリソースを消費したりして、ユーザーが正常にアクセスできなくなり、サーバのダウンタイムになるなどの手段です.
このような問題については,サーバレベルだけでは多少の欠点がある場合,Java,JVM,および関連するスレッドのセキュリティ,アプリケーションの欠陥など,プログラムレベルの攻撃を考慮して低コストのDoS攻撃を行う必要があるかもしれない.
面接では、セキュリティの問題を聞かれますが、多くのセキュリティの問題はコードのセキュリティと関係があります.Javaコードの実行手順をレビューします.
まずコンパイラがJAvaファイルは.classバイトコードファイルは、クラスローダが担当します.classファイルはJVMにロードされ、バイトコード検証によって検証され、Java解釈器によってマシンコードとして解釈されて実行されます.
クラスローダにロードする.classファイルがjava仮想マシンに移行する過程で、クラスローダは、ネイティブファイルシステムのクラスとネットワークシステムがインポートしたクラスを区別することでセキュリティを向上(ネットワーク上のアプリケーションがローカルのデータを変更することは許されません)、本機のクラスは先にロードされ、すべてのクラスがロードされると、実行ファイルのメモリ区分が固定され、バイトコード検証器は.classバイトコードファイルの検証を開始し、バイトコード検証器は信頼できるコンパイラによって生成されたクラスファイルを検査しません.その後、java解釈器材はクラスファイルを解釈はマシンコードとして実行します.
b<0でデータがオーバーフローした場合、どのくらいの問題が想像できますか?!一方,境界を越えた処理についてはJavaの下位層では良好な解決が示されているが,数値によるメモリ問題は侮れない.
もちろん、セキュリティの問題を考慮しすぎると、アプリケーションの冗長性や弱体化を招くことになります.これらは状況によって異なり、棺を覆うことはできません.
例えば、問題が発生する可能性のあるコードに対して、よく使われる手段try...catch(){...}では、問題が来ました.catchは何ですか.一般的には、ログ処理を行うためcatchをキャプチャする必要があります.ログには、コードの位置、メソッド名、エラーの原因など、機密情報さえ含まれています.もちろん、私の提案は、できるだけ内部識別の異常情報を使用し、クライアントに返される類似の異常メッセージができるだけ少ない自動的に返される異常メッセージを使用することです.
セキュリティ基準が特に高いシステムでは、機密情報が使用された後、検出されないように、すぐにメモリの破棄を明確にする必要があります.あるいはcore dumpが発生した場合、意外な露出を避ける.
開発およびテストフェーズ
1.できるだけ規範化コードは、『アリババ開発マニュアル』を参考にする.
2.できるだけ多くのコードレビューを行い、気まずいコードが発生しないようにする
3.コードcheck-inなどの段階で、hookメカニズムを利用して規則検査ツールを呼び出し、規範に合わないコードがOpenJDKコードライブラリに入ることを保証する
導入フェーズ
JDKの暗号化方法の路線図を参照できます
以上はすべて日常の开発のために総括して、ネット上の大神の文章を参考にして、少し整理して、勉强して使う権利があって、もちろん面接は不注意に感动することができて、后で整理する机会があります.
ご指摘を歓迎します.
では、何が危険なのでしょうか.私の最初の反応はSQL注入攻撃などの注入攻撃です.1つの典型的なシーンはWEBアプリケーションの中で、ユーザーのログイン機能、ユーザーが入力したユーザー名のパスワードによって相応のデータを取得して、それではSQLの注入は運に応じて生まれて、ユーザー名を模擬して、パスワードは特殊な文字を加えて、悪意のあるスクリプトなどの手段を加えて、更に引き返すことができない結果をもたらします.例えば、通常のスクリプトは、
select * from userInfo where username='input_Name' and password='input_Pwd or'のように、もしそうなら?select * from userInfo where username='input_Name' and password='input_Pwdte' or 1=1 or '' 安全なJavaコードの作成方法について、Sun公式はガイドを提供し、興味のある学生はこの文章を参考にすることができます.
•静的フィールド•役割ドメインの縮小•共通メソッドとフィールド•保護パッケージ•equalsメソッド•オブジェクトを変更できない可能性がある場合•機密データを含む内部配列への参照を返さない•ユーザーが提供する配列を直接保存しない•シーケンス化•原生関数•機密情報のクリア
例えば、DoSはよく見られるサイバー攻撃で、「洪水攻撃」と戯れる人もいる.その慣用的な手法は、大量のマシンが要求を送信したり、ターゲットサイトのブロードバンドとリソースを消費したりして、ユーザーが正常にアクセスできなくなり、サーバのダウンタイムになるなどの手段です.
このような問題については,サーバレベルだけでは多少の欠点がある場合,Java,JVM,および関連するスレッドのセキュリティ,アプリケーションの欠陥など,プログラムレベルの攻撃を考慮して低コストのDoS攻撃を行う必要があるかもしれない.
面接では、セキュリティの問題を聞かれますが、多くのセキュリティの問題はコードのセキュリティと関係があります.Javaコードの実行手順をレビューします.
まずコンパイラがJAvaファイルは.classバイトコードファイルは、クラスローダが担当します.classファイルはJVMにロードされ、バイトコード検証によって検証され、Java解釈器によってマシンコードとして解釈されて実行されます.
クラスローダにロードする.classファイルがjava仮想マシンに移行する過程で、クラスローダは、ネイティブファイルシステムのクラスとネットワークシステムがインポートしたクラスを区別することでセキュリティを向上(ネットワーク上のアプリケーションがローカルのデータを変更することは許されません)、本機のクラスは先にロードされ、すべてのクラスがロードされると、実行ファイルのメモリ区分が固定され、バイトコード検証器は.classバイトコードファイルの検証を開始し、バイトコード検証器は信頼できるコンパイラによって生成されたクラスファイルを検査しません.その後、java解釈器材はクラスファイルを解釈はマシンコードとして実行します.
a b c int if(a - b < c) { // … }この簡単そうに見えますが、問題のないコードは次の問題を引き起こします.b<0でデータがオーバーフローした場合、どのくらいの問題が想像できますか?!一方,境界を越えた処理についてはJavaの下位層では良好な解決が示されているが,数値によるメモリ問題は侮れない.
もちろん、セキュリティの問題を考慮しすぎると、アプリケーションの冗長性や弱体化を招くことになります.これらは状況によって異なり、棺を覆うことはできません.
例えば、問題が発生する可能性のあるコードに対して、よく使われる手段try...catch(){...}では、問題が来ました.catchは何ですか.一般的には、ログ処理を行うためcatchをキャプチャする必要があります.ログには、コードの位置、メソッド名、エラーの原因など、機密情報さえ含まれています.もちろん、私の提案は、できるだけ内部識別の異常情報を使用し、クライアントに返される類似の異常メッセージができるだけ少ない自動的に返される異常メッセージを使用することです.
セキュリティ基準が特に高いシステムでは、機密情報が使用された後、検出されないように、すぐにメモリの破棄を明確にする必要があります.あるいはcore dumpが発生した場合、意外な露出を避ける.
開発およびテストフェーズ
1.できるだけ規範化コードは、『アリババ開発マニュアル』を参考にする.
2.できるだけ多くのコードレビューを行い、気まずいコードが発生しないようにする
3.コードcheck-inなどの段階で、hookメカニズムを利用して規則検査ツールを呼び出し、規範に合わないコードがOpenJDKコードライブラリに入ることを保証する
導入フェーズ
JDKの暗号化方法の路線図を参照できます
以上はすべて日常の开発のために総括して、ネット上の大神の文章を参考にして、少し整理して、勉强して使う権利があって、もちろん面接は不注意に感动することができて、后で整理する机会があります.
ご指摘を歓迎します.