安全でない直接オブジェクト参照

直接オブジェクト参照は、開発者がファイル、ディレクトリ、データベースキーなどの内部実装オブジェクトへの参照を、攻撃者がこれらの参照を操作して不正なデータにアクセスできる検証メカニズムなしで公開した場合に発生する可能性があります。

簡単な図を使用して、この欠陥の脅威エージェント、攻撃ベクトル、セキュリティの弱点、技術的影響、およびビジネスへの影響を理解しましょう。

アプリは、アカウント情報にアクセスしているSQL呼び出しで未確認のデータを使用します。

String sqlquery = "SELECT * FROM useraccounts WHERE account = ?";
PreparedStatement st = connection.prepareStatement(sqlquery, ??);
st.setString( 1, request.getParameter("acct"));
ResultSet results = st.executeQuery( );

攻撃者は、ブラウザのクエリパラメータを変更して管理者を指すようにします。

http://webapp.com/app/accountInfo?acct=admin

ハンズオン

Step 1− Webgoatにログインし、アクセス制御の欠陥セクションに移動します。目標は、tomcat-users.xmlが配置されているパスに移動して、tomcat-users.xmlを取得することです。以下はシナリオのスナップショットです。

Step 2 −ファイルのパスは「現在のディレクトリは」フィールドに表示されます-C:\ Users \ userName $ \。extract \ webapps \ WebGoat \ lesson_plans \ enそして、tomcat-users.xmlファイルが下に保持されていることもわかっていますC:\ xampp \ tomcat \ conf

Step 3−現在のディレクトリから完全に移動し、C:\ Driveから移動する必要があります。Burp Suiteを使用してトラフィックを傍受することで、同じことを実行できます。

Step 4 −試行が成功すると、tomcat-users.xmlに「おめでとうございます。このレッスンは正常に完了しました」というメッセージが表示されます。

予防メカニズム

開発者は、開発フェーズ自体で安全でない直接オブジェクト参照を防ぐためのガイドとして、次のリソース/ポイントを使用できます。

  • 開発者は、間接的なオブジェクト参照に1つのユーザーまたはセッションのみを使用する必要があります。

  • 信頼できないソースからの直接オブジェクト参照を使用する前に、アクセスを確認することもお勧めします。