サインインページはなぜ転送後のURLを指定してはダメなのか

サインインURLに定義したURLを入力すると、dana-na/〜形式のURLにリダイレクトされる。
https://ive3.tk-nets.jp/nozaki

https://ive3.tk-nets.jp/dana-na/auth/url_6/welcome.cgi

このurl_xの数字だが、どうもサインインポリシーで上から定義した順にdefault,0,1,…となっているらしい。つまりこの順番を入れ替えると、別のログインページに行ってしまうということなんだろうか?
と思いきや、

How to determine "url_X" ?

Try to access configured Sign-in URL. If you configure "*/sec" URL under sign-in URL page on admin UI.
If user enters "https:///sec" in their browser, IVE redirects to a unique URL, e.g "https:///dana-na/auth/url_1/welcome.cgi".
You can use "url_1" as url_X parameter. The meaning is "https:///dana-na/auth/url_1/login.cgi mapped to "*/sec" sign-in URL.

つまりURLを構成する順に番号が与えられるらしい…_| ̄|〇
確かにいくら入れ替えようが前のURLを消そうが、url_6のログインページはまったく変わらなかった。
まいった・・こうなるとリダイレクト後のURLを直接指定するとまずい理由が見当たらない…_| ̄|〇


ちなみに、例えば管理コンソールに入っているとき、https://ive3.tk-nets.jp/nozaki を入力しても再び管理コンソール画面に戻される。これはおそらく

ただし、個々のケースでは、ユーザーのマシン上にあるCookie が、当該ユーザーのアクセスしようとしているリソースに一致しない場合があります。ユーザーが1つのURL にサインインし、別のURL によって保護されているリソースにアクセスしようとする場合があります。この場合には、SA は、そのユーザーが直近にサインインした、サインインURL および対応するサインインページを表示します。
たとえば、ユーザーが、http://yourcompany.net/employees というサインインURL を使用して、SA にサインインするとします。次に、ユーザーは、
https://yourcompany.net/partners/dana/term/winlaunchterm.cgi?host=など、外部サーバー上のリンクを使用して、SA リソースへのアクセスを試みる場合があります。または、https://yourcompany.net/partners/,DanaInfo=.awxyBmszGr3xt1r5O3v.,SSO=U+ など、別のセッション中に作成したブックマークを開こうとする場合もあります。これらの場合、SA は、そのユーザーがアクセスしようとした外部リンクや保存されて
いるブックマークに関連付けられたサインインURL やページではなく、
http://yourcompany.net/employees サインインURL とページをユーザーに対して表示します。

クッキーが原因らしい。
だが、リダイレクト後のURL(https://ive3.tk-nets.jp/dana-na/auth/url_6/welcome.cgi)を指定すると、管理画面に戻されずにちゃんとログイン画面が表示され、ログインもできる。この場合さっきまでログインしていた管理者セッションは保持されており、ログインしっ放しの状態になっていた。

しかし一方で、リダイレクト後のURLを直接指定したほうが望みのURLに行けるケースもある。

Secure Access は、サインインポリシーをSign-in Policies ページに表示されている順に評価します。完全に一致するURL が見つかると、評価を中止して、適切なサインインページを管理者またはユーザーに提示します。たとえば、2 つの管理者サインインポリシーを、2つの異なるURL で定義することができます。

  • 最初のポリシーは、URL ∗/admin を使用して、デフォルトの管理者サインインページにマッピングします。
  • 2 番目のポリシーは、URL yourcompany.com/admin を使用して、カスタム管理者サインインページにマッピングします。

この順序でポリシーをSign-in Policies ページにリスト表示した場合、最初のURL が2 番目のURL を包んでいるため、Secure Access は2 番目のポリシーを評価および使用しません。
管理者がURL yourcompany.com/admin を使用してサインインした場合でも、Secure Access はデフォルトの管理者サインインページを表示します。しかし、ポリシーを逆の順序でリスト表示した場合は、URL yourcompany.com/admin を使用してSecure Access にアクセスする管理者には、カスタム管理者サインインページが表示されます。

こういうケースは滅多にないだろうが、バーチャルホストなどで複数ホストで運用している場合くらいか。こういう場合、2番目のURLを入力してるのにどうしてもいつものログインページしか出てこないといったトラブルを招きかねない。
しかし、Sign-in Policies ページに表示されている順に評価すると言っておきながら、リダイレクト後のURLを直接指定しても飛べてしまうのはいかがなものか。dana-na/auth/url_6/welcome.cgi などどこにも定義していないのだから。あ、あくまでリダイレクト元を評価するって意味か


ちなみに本来はwelcome.cgiに飛んでID/PASSを入力するとlogin.cgiに飛び、Roleでのホストチェッカーなりを受ける仕組みらしい。
これを悪用すると、こんな便利な技もできちゃうw

https://ive3.tk-nets.jp/dana-na/auth/url_admin/login.cgi?username=adminid&password=adminpass&realm=Admin Realms

あくまで社内アクセス限定かな
まあHTTPSでHTTPリクエストは暗号化されてるから安全は安全だろうけど
1-4. クエリストリングから情報が漏れる