最近私はいくつかの意味のない機能を提供するウェブサイトにいました:
基本的にURLをフェッチし、そのコンテンツをダンプしました。 XML、txt、HTML、curl経由で到達可能な任意のパスを使用できます。
これはかなり危険だと私は思いましたが、私は正しいのですか?
手元にLinuxがなく、このサイトを見つけることができませんでしたが、ハッキングされたPHP私のWindowsマシンのページは次のURLをうまく利用しています。
file://D:/something/index.html
そしてそれを私に提示しました。これは基本的に、攻撃者がスクリプトが実行されているマシンをローミングすることを可能にしないのですか?このURLは
file:///etc/passwd
linuxで動作しますか?
他に明らかな問題はありますか?
POP3、LDAP、smbなどのスキームを介して他のリソースにアクセスしている誰かになりすましている?
これを書いているときに、HTTP [S]へのホワイトリストスキームとFTPでこれらの問題を解決できるかどうかを考えました。
私はまだこのページを介してサイトの訪問者になりすますことができますが、違法なコンテンツにアクセスしたり、おそらく検閲などを迂回したりする以外の問題については知りません。
入力が注意深くフィルタリングされていない場合、それはServer Side Request Forgery(SSRF)と呼ばれる脆弱性です。
共通の弱点列挙番号とそのページさえあります。 https://cwe.mitre.org/data/definitions/918.html
予期しないホストまたはポートにURLを提供することにより、攻撃者はサーバーがリクエストを送信しているように見せることができ、ファイアウォールなどのアクセス制御をバイパスして、攻撃者がURLに直接アクセスできないようにします。サーバーをプロキシとして使用して、内部ネットワークのホストのポートスキャンを実行したり、システム上のドキュメントにアクセスできる(file://を使用した)他のURLを使用したり、Gopher://やtftpなどの他のプロトコルを使用したりできます。 ://:リクエストの内容をより詳細に制御できます。
この脆弱性を悪用することにより、攻撃者は次のことが可能になります。
フィルタリングされていないcURLサポートは、cURLがHTTPおよびHTTPS以外の多くのURLスキーマをサポートするため、通常のSSRFの脆弱性よりもさらに悪いものです。 #curl-config --protocols
を実行して、サポートされているものを確認します。
file://
URLスキームを使用してローカルファイルにアクセスできます(curl file:///etc/passwd
はLinuxでも機能します)dict://
URLスキーマを使用して、任意のポートの任意のホストにリクエストを送信し、カスタムデータを送信することができます。 URL dict://Host:port/command
はサーバーをホストに接続させ、文字列command
を指定されたポートに送信します。ldap://
ftp://
scp://
smb://
telnet://
imap://
pop3://
smtp://
rtsp://
tftp://
まあ、彼らがこの機能をどのように実装したかに依存して、それは確かに非常に危険かもしれません。あなたが言及したリスクに加えて、非公開URLがシステムによって取得される可能性もあります。たとえば、 http://127.0.0.1 を取得すると、localhostが取得されます。
最近、管理パネルなどがHTTPを介して一般的にデプロイされ、ローカルサーバーにアクセスでき、他のランダムなIPにはアクセスできないため、これはリスクになる可能性があります。
もちろん、サイトがこれらの攻撃をすべて正しくフィルタリングしていることがわかるかもしれません。そうしないと、攻撃を試みないと明らかではありません(もちろん、管轄によっては法的に疑わしい可能性があります)。