.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
0x00脆弱性の詳細
Shiroがパスを制御している場合、着信URLエンコードをデコードできなかったため、攻撃者はフィルターをバイパスし、フィルタリングされたパスにアクセスしました。
0x01脆弱性の影響
SHRIO 1.3.2
0x02環境構築
このバージョンにはShiro-Spring-Boot-Starterがまだないため、https://github.com/godzeo/shiro_1.2.4_sample/archive/archive/archaster.zip。次に、サンプル/web/pom.xmlファイルでJSTLのバージョンを1.2に指定する必要があります。
Idea Editorを介してWarパッケージにコンパイルし、TomcatのWebAppsディレクトリに入れて実行します。コンパイルされた戦争パッケージ：https://github.com/backlion/demo/blob/master/samples-web-1.2.4.war 
0x03脆弱性の再発
したがって、アカウントパスがフィルタリングされたパスに属していると判断できます。現時点では、burpを使用して切り捨ててから、認証許可をバイパスするパスにアクセスする前に、ディレクトリ名を追加/arbitraryディレクトリ名を追加します。 1.最初に、バックエンドホームページに直接アクセスしてから、直接ジャンプ302 
2.アクセスパスの前にディレクトリ名を追加/arbitraryディレクトリ名を追加すると、高すぎる
3にアクセスできます。ここでは、バックグラウンドのホームページソースコードと、バイパス後にアクセスしたページのコンテンツを表示できます。
0x04脆弱性分析
この脆弱性に関しては、オンラインで公開されている情報はほとんどありません。見つけることができる唯一の有用なものは、GithubのコミットレコードとCVEの説明情報です。
githubコミット情報：https://github.com/apache/shiro/commit/b15ab927709ca18ea4a02538be01919191919191919191919191919191919CVE.MITRE.ORG/CGI-BIN/CVENAME.CGI？ webutils.javaのgetContextPathメソッドにあります。
CVEは次のように説明されています。
1.3.2以前のApache Shiroは、攻撃者が意図したサーブレットフィルターをバイパスし、非ルートサーブレットコンテキストパスの使用を活用することによりアクセスできるようにします。
このCVEの説明とコミット情報に基づいて、非ルートコンテキストパスが発生したときにコンテキストパスを取得するときに脆弱性が引き起こされることがわかりますが、詳細情報はまだ不明です。
ContextPathに関連しているため、サンプルプロジェクトを展開するときは、ContextPathの下でそれらを展開する必要があり、ルートを使用できません。最初に、GetContextPath関数の入り口に247行にブレークポイントを設定し、アクセスするためにログインが必要な通常のリクエストを送信し、近くのコードの処理ロジックを調べます。
Curl -V 'http://192.168.1.9:8080/Samples-WEB-1.2.4/Account/Index.jsp' 
分解後、これがコンテキストパスであり、特別な動作がないことがわかります。私たちは返品に従い、フォローダウンし続けます。 ContextPathがわからない場合は、最初に自分でGoogleで検索することをお勧めします。
関数org.apache.shiro.web.util.webutils＃getPathWithInApplicationに従ってください。
私は関数org.apache.shiro.web.filter.mgt.pathmatchingfilterchainresolver＃getChainに従い続けました。 Requesturiが実際に取得されたことがわかります。ここで少しのステップでそれに従ってください。 103行近くのループの場合、一致するプロセスのためにrequesturiを取得するために使用され、一致する状況で対応する操作を実行することを見つけることは難しくありません。
ここで要求するのは、/account/**モードと一致するaccount/index.jspです。構成ファイル（shiro.ini）では、 /account /**ディレクトリにログイン後にユーザーがアクセスする必要があります。ここでの操作は、現在のユーザーがログインしているかどうか、または許可を得ているかどうかを確認することです。
ここでは、F9が直接リリースされ、302が実際にログインページにリダイレクトされていることがわかります。このようにして、アイデアは明確です。問題はContextPathです。これはRequesturiを生成するために使用され、Requesturiはこのリクエストに認証が必要かどうかを決定します。したがって、変形したコンテキストパスを構築して変形したrequesturiを生成するだけで、Apacheshiroの認証メカニズムをバイパスできます。
では、どのように構築する必要がありますか？コミットパッチコードによると、デコード操作と正規化操作が実行されていることがわかります。それは非通常の経路によって引き起こされなければなりません。間違ったコンテキストパスを取得するには、/x/./のようなパスを構築するだけであると推測されます。
再びそれを分解した後、ContextPathの価値が/x/./sample_web_warになっていることがわかります。計算されたrequesturiが何であるかを確認するには、それをフォローダウンしますか？正規化とデコード後、requesturiの値は/sample_web_war/account/index.jspです。
私が見たちょうど私が見た一致するパートに続き続けてください。表示されるrequesturiが /account /**モードと正常に一致しなくなることを確認するのは難しくありません。また、ログインがログインしているかどうかを確認する段階には入りません。このリクエストをリリースして、正常であるかどうかを確認します。
curl - path-as-is -v 'http://192.168.1.9:8080/x /.//samplys-web-1.2.4/account/index.jsp'
が表示される前にログインする必要があるページコンテンツを正常に返しました。これは主に、ContextPathとRequesturiの一貫性のない処理によるものです。
0x05参照
https://blog.csdn.net/qq_41832837/article/details/109064636#%E8%BF%9C%E7%A8%8B%E5%A5%89%E5%8 5％A8％E9％99％90％E5％88％B6％E7％BB％95％E8％BF％87％E6％BC％8F％E6％B4％9E％EF％BC％88CVE-2016-6802％EF％BC％89
http://ll29.cn/apache%20shiro/apache%20Shiro%E8%BF%9C%E7%A8%8B%E5%A %89%E5%85% A8％E9％99％90％E5％88％B6％E7％BB％95％E8％BF％87％E6％BC％8F％E6％B4％9E [CVE-2016-6802] .HTML
https://Lightless.me/archives/apache-shiro-analysis.html
https://github.com/godzeo/shiro_1.2.4_sample