HOME»情報処理安全確保支援士掲示板»令和5年 秋 午後 問1 設問4
投稿する

令和5年 秋 午後 問1 設問4 [1524]

 山田さん(No.1) 
IPAの模範解答が
「スクリプトから別ドメインのURLに対してCookieが送られない仕組み」
とありました。

例えば、
「非同期リクエストで別オリジンに対するリソース取得は許可されていなければ実行不可」
という回答だと論点がずれていますでしょうか?

図4の5行目で
「xhr.send();」
とありますが、この時点で問題の前提である攻撃者サイトからリクエストだと、そもそもクロスオリジンリクエストでだめなんじゃないだろうか?と思いました。
「https://□□□.co.jp/user/profile」がログイン後のページだと思われるので、cookieが送信されないとページ取得できないとは思うのですが、クロスオリジンリクエストの観点での回答だとダメなんだろうか?と疑問に思っています。
ただあまり自信はなく、何か誤解をしているのかもしれないと思って正しく理解したいための質問です。

どなたか教えていただければ幸いです。
よろしくお願いいたします。
2024.04.13 00:19
pixさん(No.2) 
SC ダイヤモンドマイスター
>クロスオリジンリクエストの観点での回答だとダメなんだろうか?
>と疑問に思っています。
設問4には「Webブラウザの仕組みによって攻撃は成功しない。この仕組みを
40字以内で答えよ。」とあります。
したがって、Webサーバの仕組み(機能)の観点で解答する必要があります。
クロスオリジンリクエストの許可はサーバ側の観点と考えられます。
2024.04.13 00:49
 山田さん(No.3) 
pixさん
ご回答まことにありがとうございます。

ご回答内容を「ブラウザ側の機能で回答すべき」という内容と認識したのですが、今回「Cookieが送られない」というのは、理由を考えると以下なのでは?と思いました。
<Cookieが送られない理由>==============
仮にもしクロスオリジンリクエストでCookieを送信する場合、以下①②が必要だけれども、当然②が行われないので、結果Cookieが送られない。
①スクリプト側で「xhr.withCredentials = true」とする
②サーバー側で「Access-Control-Allow-Credentials: true」ヘッダーを返す
=============================

かつ今回疑問に思った「クロスオリジンリクエストの観点での回答だとダメなんだろうか?」という点について、非同期のクロスオリジンリクエストが拒否される理由は以下なのでは?と思いました。
<クロスオリジンリクエストが失敗する理由>==========
クロスオリジンリクエストが成功するには以下が①②が必要だけれども、当然②が行われないので、結果失敗する。
①スクリプト側で「Origin: 攻撃者ドメイン」ヘッダーを付与する
②サーバー側で「Access-Control-Allow-Origin: 攻撃者ドメイン」ヘッダーを返す
===========================

仕組みとしては「Cookieの送信」についても、「クロスオリジンリクエストの成否」についても、ブラウザ側、サーバー側のCORS対応によるもので、「Cookieが送信されない」が正解なのであれば、「クロスオリジンリクエストが失敗する」というのも正解なのではないのだろうか?と思ったのですが、この考え方だと何か勘違いしていますでしょうか?

(※正直、ドキュメントを読んで得ただけの表面上の知識のため、上記記載内容に自信は全くないです・・・)
2024.04.13 02:23
pixさん(No.4) 
SC ダイヤモンドマイスター
>ご回答内容を「ブラウザ側の機能で回答すべき」という内容と認識したのですが、
>今回「Cookieが送られない」というのは、理由を考えると以下なのでは?と思いました。
設問は「仕組みを答えよ」です。
スレ主様は『理由』を答えてしまっています。
『理由』は設問で求められていません。

もし設問が「Cookieが送信されない『理由』を答えよ」ならば、
クロスオリジンリクエストを理由にしてもよいかと思われます。

IPAの記述解答は大きく3パターンに分類できます。
・『理由』を求めるもの:設問中に『理由』を答えよと明記される
・『目的』を求めるもの:設問中に『目的』を答えよと明記される
・その他を求めるもの:仕組み、「機能」、「場合」、「こと」などを求められる

IPAの問題を解くには国語力が必要と言われますが、このように設問の
意図を正確に理解することが非常に重要だからです。
2024.04.13 02:52
 山田さん(No.5) 
この投稿は投稿者により削除されました。(2024.04.13 03:28)
2024.04.13 03:28
 山田さん(No.6) 
pixさん
ご回答まことにありがとうございます。

私の言葉づかいが適切ではなかったかもしれません・・・。
前回の私の投稿の「理由」という単語は「仕組み」と置き換えても意味が通ると思うのですが、文末に・・・
「仕組みとしては「Cookieの送信」についても、「クロスオリジンリクエストの成否」についても・・・」
・・・と記載しました通り、
「Cookieが送信されない」のも「クロスオリジンリクエストが失敗する」のも同様にSOPとCORSの仕組みで起こるのではないでしょうか?
2024.04.13 03:28
One Of 合格者さん(No.7) 
>クロスオリジンリクエストの観点での回答だとダメなんだろうか?

別解は無い
IPAの解答例が全て
IPAの解答例を導くにはどのような思考を辿ればよいのか

合格最優先であれば近道はこれらです。
2024.04.13 09:48
 山田さん(No.8) 
One Of 合格者さん
ご回答まことにありがとうございます。

求めていることはまさにご記載いただいた以下になります。
>IPAの解答例を導くにはどのような思考を辿ればよいのか

今回の設問4について、現在の私の思考では、以下①②が両方同じ仕組みに基づくものに思えています。
①「Cookieが送信されない」
②「クロスオリジンリクエストが失敗する」

そこでIPAの解答例①を導くための思考の途上で、同じ仕組みに思える①②が頭に浮かんだ際に②を排除する根拠が欲しいのです。
(そうでないと、ご記載いただいた「IPAの解答例を導くにはどのような思考を辿ればよいのか」という点がクリアにならないからです。)

※ちなみに別解がないのは理解しておりまして、「②も正解でしょ!」といった子供じみた主張をしたいのではありません。
以下のどちらかをはっきりさせたい意図での質問になります。
・私が何かを誤解をしている
・理解自体は間違っておらず、設問の解答例だけでは今回の疑問に白黒つけられない系の設問である

そのため、もしどなたかから「②は○○だからダメなんだよ、仕組みを誤解しているよ」と指摘があれば「あぁ、そうだったのか!」となります。
また仮にどなたかが「②も確かに仕組み的は同じだけど、なんで①なんだろうね?」と誰にもわからないようであれば、「あまり良い問題ではないのかな?認識自体は間違ってないならよいか」となります。

もし、何かアドバイスありましたら教えていただけると幸いです。
よろしくお願いいたします。
2024.04.13 12:35
pixさん(No.9) 
SC ダイヤモンドマイスター
>今回の設問4について、現在の私の思考では、以下①②が両方同じ仕組みに基づくものに
>思えています。
>①「Cookieが送信されない」
>②「クロスオリジンリクエストが失敗する」
度々すいません。WebブラウザがCookieを送信しないのは、ドメインが
違うからという単純な理由だと思います。
クロスオリジンリクエストはサーバ側の機能です。
なぜクロスオリジンリクエストにそこまでこだわるのでしょうか。
大変恐縮ですが、スレ主様は単純にドメインが違えばWebブラウザから
Cookieが送信されないという事実を知らないだけであるように思えます。
クロスオリジンリクエストという言葉のみ知っているため、無理やりそれに
結び付けようとしているように見えております。
2024.04.13 13:36
むぐむぐさん(No.10) 
考え方が逆ではないでしょうか?
ブラウザは異なるドメインにCookieを送信しません。
そこを安全に別のドメインなどに対してもCookieを送信できるようにする機能がCORSなので、送れない理由には出てきません。
2024.04.13 13:45
pixさん(No.11) 
SC ダイヤモンドマイスター
>そのため、もしどなたかから「②は○○だからダメなんだよ、仕組みを誤解しているよ」と
>指摘があれば「あぁ、そうだったのか!」となります。
>また仮にどなたかが「②も確かに仕組み的は同じだけど、なんで①なんだろうね?」と
>誰にもわからないようであれば、「あまり良い問題ではないのかな?認識自体は
>間違ってないならよいか」となります。
苦言を呈す形になり大変恐縮ですが、IPAの正答以外の解答について、間違っている
ことを指摘するのは非常に労力がかかるものです。
質問される方は単純に疑問を挙げているつもりかもしれませんが、
解答する方にとっては間違っている理由を調べて、検証するのは想像以上に
大変なものです。
この掲示板にはセキュリティについて詳しい方が多数いますが、そのようなレベルの
方であっても、簡単には回答できないと思われたほうがよろしいです。
その上、解決したとしても得るものは少ないです。

またIPAの試験はIPAの解答が正答になります。それ以外の認識があっているような
ことはありません。
IPAの解答を信じられないというのは、この試験を理解するにあたり、非常に
大きなマイナスとなります。

ただ単純に自分の考えがIPAの正答と食い違っているのであれば、
・IPAの正答が正しい理由
・自身の回答が誤っている理由
を調べた上で、その真偽を質問していただくの方が望ましいです。
2024.04.13 13:58
 山田さん(No.12) 
pixさん
もぐもぐさん

ご回答まことにありがとうございます。

>pixさん:WebブラウザがCookieを送信しないのは、ドメインが違うからという単純な理由だと思います。
>:Cookieが送信されないという事実を知らないだけであるように思えます。
>もぐもぐさん:ブラウザは異なるドメインにCookieを送信しません。

今回の設問4に関して、xhrのGETリクエスト先のドメインとCookieのドメインはともに"http://□□□.co.jp"で同一ではないでしょうか?
(もしpixさんともぐもぐさんが、例えばサイトAのCookieをサイトBに送らないといった基本的なことを指しているのであれば、それは認識しているつもりでして・・・)

私の技術的な認識が間違っているかもしれないのですが、今回設問4の攻撃者サイトからだと「Cookieが送信されない」のはSOP(同一オリジンポリシ)により送信されないのではないでしょうか?

具体的いうと以下と考えていますが間違っていますでしょうか?
①被害者となるユーザーは本文にある"http://□□□.co.jp"へログイン状態の前提。よってCookieのドメインは"http://□□□.co.jp"と思われる。
②xhrのget送信先のドメインも"http://□□□.co.jp"
(上記①②によりドメインは一致。ただしCookieが送られるか送られないは以下③④に記載したSOPにひっかかるか引っかからないかが要因と思っています。)
③スクリプトがユーザーレビューページ内に存在するのであれば、”送信元ドメイン"と”送信先ドメイン”が同一の為、SOPにひっかからずCookieは送信され、攻撃者は攻撃を行うことができる
④スクリプトが攻撃者サイトだと”送信元ドメイン”と”送信先ドメイン”が異なりSOPに引っかかる(クロスオリジンリクエストとなる)ため、Cookieが送られない


>pixさん:なぜクロスオリジンリクエストにそこまでこだわるのでしょうか。
すみません・・・上記のような認識を持っており、こだわっているというよりも、「Cookieが送信されない」と「クロスオリジンリクエストが失敗する」が同じ仕組みにみえ、IPAの正答にたどり着くために、後者が私の誤解に基づき同じ仕組みに見えているのであれば、そこをクリアにしたいと思っているためです。

>pixさん:質問される方は単純に疑問を挙げているつもりかもしれませんが、解答する方にとっては間違っている理由を調べて、検証するのは想像以上に大変なものです。
申し訳ございません・・・解答いただく方がそこまでしていただいているとは認識できておりませんでした。
ご回答者様の知識で答えられる範囲でお答えいただいているものかと甘い認識でおりました。
もし、本件で様々なことをお調べいただいき、労力を割いてしまっているご状況でしたら、大変失礼いたしました。

>pixさん:その上、解決したとしても得るものは少ないです。
自信の理解が誤っていることを知ることができた場合、私にとっては得るものは大きく・・・
ただ、皆さんから回答でなければ、徹底的に追及するつもりは毛頭なく、前回の投稿で記載した通り「あまり良い問題ではないのかな?認識自体は間違ってないならよいか」となります。(もしくは「認識が正しいか間違っているかの確認もできなかったからグレーのままにしておこう」となります)

>pixさん:IPAの解答を信じられないというのは、この試験を理解するにあたり、非常に大きなマイナスとなります。
信じられないということはありません。今回のIPA解答は理解できています。
本質問は別解として「クロスオリジンリクエストが失敗する」が存在するのか、それともNGなのか(NGならできれば仕組みも含めて)知りたくての質問となります。

>pixさん:ただ単純に自分の考えがIPAの正答と食い違っているのであれば、
>・IPAの正答が正しい理由
>・自身の回答が誤っている>理由
>を調べた上で、その真偽を質問していただくの方が望ましいです。
IPAの正答が正しい理由は理解できております。
自身の解答が別解として存在しそうかどうか、調べているはいるものの、確信に至れないため、識者の方にお伺いできればと思って質問させていただいた次第です。
2024.04.13 15:00
 山田さん(No.13) 
この投稿は投稿者により削除されました。(2024.04.13 15:18)
2024.04.13 15:18
 山田さん(No.14) 
すみません、補足です。

>もぐもぐさん:そこを安全に別のドメインなどに対してもCookieを送信できるようにする機能がCORSなので、送れない理由には出てきません。
CORSはSOPの制限に対し、ブラウザ、サーバー両側でヘッダを付与することで柔軟性を持たせるための仕組みと認識しております。
そのため送れない理由は(正確に表現すると)SOPに引っかかり、CORSで許可もしていないからという認識です。(許可すれば送れる)
もし、認識が異なる場合、教えていただければ幸いです。

>pixさん:クロスオリジンリクエストはサーバ側の機能です。
クロスオリジンリクエストはブラウザの送信元と送信先オリジンが異なるリクエストと認識しており、サーバー側の機能とは認識していないのですが、どういったご認識でサーバー側の機能とご判断されているのでしょうか?

※もしご回答いただける場合、あくまで既にお持ちの知識内でのご回答で全く問題ございません。
2024.04.13 15:19
むぐむぐさん(No.15) 
>そのため送れない理由は(正確に表現すると)SOPに引っかかり、CORSで許可もしていないからという認識です。(許可すれば送れる)

お話の内容から理解されているとおもいますが、送れない理由はSOPのみでCORSは送る方法の話なので送れない理由を説明する際は冗長という認識です。

>非同期リクエストで別オリジンに対するリソース取得は許可されていなければ実行不可

最初に戻ってこの回答ですが、まず最初に起きる出来事(失敗の原因)としては、サーバへprofileページへのリクエスト送信、サーバ側でcookieがないのでセッションエラーになることではないでしょうか?

これが最初の原因で、これに対して回答する必要があるとすると模範解答になるのだと思います。
この際、「非同期リクエストで別オリジンに対するリソース取得は許可されていなければ実行不可」は回答としてずれていないでしょうか?

同一オリジンポリシーですが、cookieを送れない原因はこちらで正しいと思います。
回答の具体性で、同一オリジンポリシーによって起きる現象として、cookieを送信されないまで書くと正当になる気がします。
問題の流れもXSSによるcookieの流出で、cookieに着目た問と問題文になっていますしね。
回答の粒度感は難しいですよね。私も悩みながら勉強していました。
2024.04.13 16:46
 山田さん(No.16) 
むぐむぐさん

ご回答まことにありがとうございます。
技術的な観点のご回答頂けて大変ありがたいです!

>お話の内容から理解されているとおもいますが、送れない理由はSOPのみでCORSは送る方法の話なので送れない理由を説明する際は冗長という認識です。
>最初に戻ってこの回答ですが、まず最初に起きる出来事(失敗の原因)としては、サーバへprofileページへのリクエスト送信、サーバ側でcookieがないのでセッションエラーになることではないでしょうか?

ひょっとしたら、ようやく理解できたかもしれません・・・
私は以下と考えておりました。
①「クロスオリジンリクエストでかつ単純リクエストでない場合」はプリフライトリクエストが行われ、サーバー側からCORSの「Access-Control-Allow-Origin: 攻撃者ドメイン」といったヘッダが返ってこない限り、本来のリクエストは送信されない
②そのためCookie送信以前に、CORSに許可されていないクロスオリジンリクエストとして弾かれるのでははないだろうか・・・?

しかし、今回のケースだとxhrのリクエストは「クロスオリジンリクエスト」の中でも「単純リクエスト」に該当し、プリフライトリクエストは飛ばず、本来のリクエストは送信され「Cookieでセッションエラー」になるということ???とようやくつながりました。

そして、今回私が単純リクエストでないと誤認していたのは以下が原因とも気づけました。
図4の「4: xhr.responseType = "document"」  
この一行について、誤った脳内変換がされていてなぜか「ContentTypeヘッダーに"document"が指定された」と完全に誤認して思い込んでおり、「これ、単純リクエストに該当しなくなるからプリフライトリクエストとぶよな・・・?」と思い込んでしまっておりました。(そこから上記疑問へと発展していった経緯でした・・・)

恐らく皆さんがコミュニケーションをとっていただけたことで頭が整理され、上記誤解に気づくことができたのだろうと考えています。
誠にありがとうございます。

※もし、上記の気づいた点(今回のリクエストは単純リクエストである等)が間違ってなければ、これで腹落ちができるのですが、もし何か技術的な面でまだ認識が誤っている、つじつまが合っていなさそうな点が含まれているようであれば、突っ込んでいただけるとありがたいです・・・
2024.04.13 19:46
a1111さん(No.17) 
クロスオリジンリクエストが失敗するのはブラウザの仕組みではないから

単純な1文で説明がつきます。
2024.04.13 21:20
 山田さん(No.18) 
a1111さん

ご回答ありがとうございます。

>クロスオリジンリクエストが失敗するのはブラウザの仕組みではないから
>単純な1文で説明がつきます。
もし可能でしたらそのご主張の根拠を技術的な観点で教えていただけると助かります。
サーバー側だけの仕組みとお考えなのでしょうか?

よろしくお願いいたします。
2024.04.13 22:48
a1111さん(No.19) 
ブラウザの仕組みかどうかを確認するだけでよいです。
いろいろ調べれば、ブラウザの仕組みというのが「国語的に」適切でないということはわかるでしょう。

ポイントは「国語的に」ブラウザの仕組みかどうかであって、技術的にブラウザの仕組みかどうかを説明するということではないという点です。

IPAの文意通りというのはIPAの解釈する「ブラウザの仕組み」ということになります。

どこまで技術的に議論したところで、この一言にまとまりますし、本掲示板の範囲から逸脱していくと思いますよ

「わたしはこれもブラウザの仕組みだと思う」というのは自由に主張いただいて構わないのですが、IPAの解答に対して別解になりえますか?という質問は暇つぶしにはいいですが、試験的にはあまり意味はありません
2024.04.14 00:32
a1111さん(No.20) 
補足です。
結論として
質問者様が求めているものは何かと考えたところIPAの公式の「ブラウザの仕組み」の定義ということになるでしょう。

「間違いがあれば指摘してほしい」というご質問方法はあまりしないほうが良いかと
間違いがあれば指摘してほしいという言葉からはご自身が間違っている確率が高いのではないかという心理があると読み取りました。まずは、どの部分が間違っているかを明記したうえでご質問するのが良いと思います。

雑談ということであれば、このやりとりでもよいと思うのですが、設問をタイトルにしている以上、問題の文意(IPA解答)からそれていくスレッドはあまりよく思いません。
2024.04.14 01:03
 山田さん(No.21) 
a1111さん

ご回答ありがとうございます。

>いろいろ調べれば、ブラウザの仕組みというのが「国語的に」適切でないということはわかるでしょう。
>ポイントは「国語的に」ブラウザの仕組みかどうかであって、技術的にブラウザの仕組みかどうかを説明するということではないという点です
かなり独特な解釈をされているのですね。

>IPAの文意通りというのはIPAの解釈する「ブラウザの仕組み」ということになります。
>どこまで技術的に議論したところで、この一言にまとまりますし、本掲示板の範囲から逸脱していくと思いますよ
こちらも同様、かなり独特な解釈をされていますね。

>「わたしはこれもブラウザの仕組みだと思う」というのは自由に主張いただいて構わないのですが、
思う思わないの問題ではなく、技術的に判断できるものだと考えます。

>IPAの解答に対して別解になりえますか?という質問は暇つぶしにはいいですが、試験的にはあまり意味はありません
試験のことしか考えられず、本質的な技術的理解を求めることを暇つぶしと感じるレベルなのであれば、そのご意見でもよいと思います。

ご回答からa1111さんは技術的根拠をお示しすることが難しいのか個人の考えしか述べていないように思えます。
ありがとうございました。
2024.04.14 01:03
a1111さん(No.22) 
かなり知識が高い方と思いますので、実際の試験で同様の問題がでるときに
解答を書くという形で確認するのがよいかと。

問題に対する質問という形でされている以上、そのように解答が返ってくることに
お気を悪くされないよう。

ブラウザの仕組み上、クロスオリジンリクエストは拒否されますか?という質問に対してそんなに異を唱える方はいないと思います。

設問に対する回答という形で皆様解答されていると思いますので、一度整理いただき、
適切なタイトルでご質問・問題定義されるのがご質問者・回答者  双方よろしいかと思います。
2024.04.14 01:07
 山田さん(No.23) 
a1111さん

すみません、補足をご投稿いただいている合間に恐らく回答を記述していて、補足を投稿後に読みました。

>結論として質問者様が求めているものは何かと考えたところIPAの公式の「ブラウザの仕組み」の定義ということになるでしょう。

>「間違いがあれば指摘してほしい」というご質問方法はあまりしないほうが良いかと間違いがあれば指摘してほしいという言葉からはご自身が間違っている確率が高いのではないかという心理があると読み取りました。まずは、どの部分が間違っているかを明記したうえでご質問するのが良いと思います。

>雑談ということであれば、このやりとりでもよいと思うのですが、設問をタイトルにしている以上、問題の文意(IPA解答)からそれていくスレッドはあまりよく思いません。

恐縮ですが、私の質問について問題があるとお感じになるということであれば、管理人様へ報告されてはいかがでしょうか?
この掲示板の使用方法について個人の考えを示されても、違和感を感じます。
(私は設問に関して、本質的な理解を得ることで、IPA解答に辿りつく思考方法を身につけたいと思って設問しているつもりなのですが、掲示板の使用方法に違反しているかどうかは管理人様にご判断いただきたいです)
2024.04.14 01:08
a1111さん(No.24) 
違反しているとは思いません。
IPAの問題に対してご質問されているようでしたので、これ以上の回答がでてこないのではという懸念です。
下記についても私の文意に対しては異なった回答になっていると私は感じております。

>恐縮ですが、私の質問について問題があるとお感じになるということであれば、管理人>様へ報告されてはいかがでしょうか?
>この掲示板の使用方法について個人の考えを示されても、違和感を感じます。
>(私は設問に関して、本質的な理解を得ることで、IPA解答に辿りつく思考方法を身に>>つけたいと思って設問しているつもりなのですが、掲示板の使用方法に違反しているか>どうかは管理人様にご判断いただきたいです)

技術的な観点の回答でなく大変失礼いたしました。
2024.04.14 01:13
 山田さん(No.25) 
a1111さん

すみません、恐らく今度はNo22をご投稿いただいている合間に、私が補足(No20)に対するお返事(No23)を記述していてそれを投稿後にNo22を読みました。

これはNo22についてのお返事です。
>設問に対する回答という形で皆様解答されていると思いますので、一度整理いただき、適切なタイトルでご質問・問題定義されるのがご質問者・回答者  双方よろしいかと思います。

No19のご投稿、及びNo20(補足)のご投稿内容から、あまりよい意図を感じられず「管理人様へご報告いかがでしょうか?」とお伝えしてしまいましたが、大変失礼いたしました。
あくまで善意によるご忠告をいただいたのだと認識を改めました。
ありがとうございます。
2024.04.14 01:28
 山田さん(No.26) 
a1111さん

すみません、再度入れ違いで、これはNo24についてのお返事です。

>違反しているとは思いません。
>IPAの問題に対してご質問されているようでしたので、これ以上の回答がでてこないのではという懸念です。

ありがとうございます。
この点については、実はNo15までにご回答いただいた方とのコミュニケーションで頭が整理され、No16で自身の誤認していた点について気づいたことを記載し、もう着地かなと思っておりました。

ただその後、No17でa1111さんからご返信を頂けたので、私のNo16の記載に誤りがあったのだろうかと感じて、No18で技術的な観点でのご質問させていただいた次第でした。

ただ今思えば、私の質問の立て方や途中の返信が分かりづらかった点が恐らく原因の一つとしてあり、スレッドがNo16と長く続いてしまい、内容がぱっと把握しづらいスレッドになっていた点はあったのだろうと反省しております。

そのような中、No17でご返信いただけただけでもありがたく感じております。
この点含め、No23では失礼な記載をしてしまい申し訳ございませんでした。

恐らく、この長く細かいスレッドを読み込んで更にご返信いただく方はもういないのではないかと思ってておりまして、これで着地となるのではないかと考えております。

ありがとうございました。
2024.04.14 01:49
返信投稿用フォームスパム防止のためにスレッド作成日から30日経過したスレッドへの投稿はできません。
© 2014-2024 情報処理安全確保支援士ドットコム All Rights Reserved.

Pagetop