OWASP Nagoya Chapter Meeting 1st に参加してきた話
よりによって普段セキュリティなどまったく気にしない私が、よりによってセキュリティの世界的コミュニティ OWASP の名古屋チャプター、よりによって設立後初の勉強会に、よりによって参加してきた話。
先日の Xamarin 勉強会の懇親会でお世話になったまるちゃんさんが宣伝していたり、前々から connpass で見ていたりして知ってはいましたが、直前まで参加するかどうかは悩んでいました。
でも、何事もやらなきゃはじまらないな、と思い立ち参加してきました。
私のセキュリティレベル
前の Xamarin の記事を読んでいただければわかると思いますが、ソフトウェアエンジニアやっていながらこういった問題に関しては全くの無知です。
CVE？とか監視してないし、 Java のアップデートとかセキュリティに特に重要になってくると思いますが、何か月前から放置してるし。
Xamarin の場合は、 Mono とか .NET とか前提知識があったので何とかついていけましたが、セキュリティに関しては本当にわからないことだらけ。というか何を勉強すればよいのかもわからない。
でも、せっかくの OWASP Nagoya Chapter 設立後初の勉強会だし、きっかけ作りとして行ってみてもいいかなと思って行ってみることにしました。
とりあえず前日の夜から CTF を少しやってみたんですけど、 SQL インジェクションできずに諦めて寝ました。朝6時に。
迎えた当日
会場は、名古屋駅からほど近い愛知大学名古屋キャンパスの 8 階の教室。
あの 109 シネマズの目の前にある大学で、設備がもはやオフィス並み。エスカレータはおろかエレベータまでついてる。というか 8 階まであるって、とんでもない大学ですね…
名古屋駅側から地上を歩いていくと、誘導係の方が数人。ちょっと陰になったところに入り口がありましたが、わかりやすい説明のもと迷わず行くことができました。
実は 100 人規模の勉強会だけあって、教室は超満員。ひろい講義室にプロジェクタの画面 3 つとでっかい BOSE のスピーカー。
大学の講義を聴くような感覚ですが、なかなか面白そうな雰囲気で勉強会がはじまりました。
勉強会スタート
OWASP Nagoya Chapter Leader 坂梨 さん
まず初めに、 OWASP Nagoya Chapter の Chapter Leader を務めていらっしゃる、坂梨さんから OWASP についての簡単な説明がありました。
OWASP とは
OWASP - Open Web Application Security Project は、 セキュアなソフトウェア開発を促進する技術、プロセスに関する情報を普及・啓発するオープンコミュニティ 。もっと詳しいことを話されてましたが、早すぎてメモれず…。
コミュニティ内でのノウハウを集めたドキュメントや、ツールなどが無料で使えるというものらしいです。
世界各地に チャプター というローカルな活動拠点があり、その数 276 チャプターが現在あるそう。
さらに、 OWASP Project というプロジェクトがいくつもあり、代表的な
- OWASP TOP 10
- OWASP Zend Attack Proxy (ZAP)
をはじめ全部で 93 もあるそう。活発ですね。
OWASP Nagoya の使命
日本には OWASP Japan をはじめ、全部で 10 のチャプターがあり、 OWASP Nagoya はその 記念すべき 10 番目。
世界中で議論されているセキュリティ情報を名古屋から広め、名古屋から世界に向けて新たな情報を発信していくことが OWASP Nagoya Chapter の使命だそうです。
Nagoya といえど名古屋に限らず、東海地区を中心に活動していくんだそうです。確かにこの辺りにセキュリティ関連の団体ってなかなかないですよねー、って思ったんですけど、
- 名古屋情報セキュリティ勉強会
- ISACA 名古屋支部
- CISSP 東海コミュニティ
と、案外セキュリティに関する団体はあるみたいで、連携を取りながら活動をしていきたいそう。
OWASP Kansai Chapter とのテレビ通話
OWASP Kansai も同日に勉強会が開催されていたそうで、ビデオ通話で会場を繋げました。
どこかのカフェなのか、おしゃれな丸テーブルが並び 4, 5 人グループになって座っているような形で、なかなか気楽なムードでした。
あちらも 100 人越えの規模で、熱気はどちらも劣らず。コミュニティってすごいなぁと思いました。
ただ、サブ画面でビールサーバからビールを注ぐ映像が淡々と流れていて、めっちゃラフな勉強会だな！？と驚いたりしたんですが、後々聞いてみたら大阪はいつもあんな感じらしいです。さすが大阪…。
感想とか
connpass で OWASP を初めて見たとき、セキュリティに関してだからすごく高度で、ちょっとおかたい雰囲気なのかなと早とちりしていたのですが、実際に来てみるとそうでもなくて、とても楽しそう。
肩の力が抜けたというか、何の変哲もないただの紹介のお話だったのに、どこか面白かった。
こういう空気もいいなぁ、と思いました。
OWASP Nagoya Chapter Leader 岡田さん
株式会社 アスタリスク・リサーチ 代表取締役。 OWASP Japan Chapter Leader でもあるすごい人。
2012 年 3 月に OWASP Japan ができる前、 OWASP Tokyo なるものがあり、そこで OWASP Developer Guide を翻訳したりしていたらしいです。もはや大御所ですね…。
スペアリブ美味しそう。
OWASP Japan への思い
OWASP Tokyo ができる少し前、1年ほどかけていろんなサイトのセキュリティに関しての対策を、サイトの設立者のもとまで足を運んてヒアリングして回ったことがあるそう。
その結果、パスワードをグループで使いまわすシステムだとか、 HTTPS に対応していなかったりだとか、システムを停止させたくないのでアップデートをしないだとか、そうしたセキュリティへのおざなりな姿勢が浮き彫りになったそうです。
もっと気軽にセキュリティに対して興味を持ってもらえる環境を作っていきたいと思っていた矢先、 OWASP Tokyo が設立からわずか 3 ヶ月で解散してしまいます (もともと企業絡みだったため) 。
そこで、日本全国に門戸を開こうと、 OWASP Japan Chapter を設立 (再設) されたそうです。
現在では全国に 9 つのローカル Chapter が存在していますが、 OWASP Japan ではそうした Chapter がない場所でも積極的に活動を行っていく方針だそうです。
聴いていて、心にグッとくる内容でした。
OWASP について
坂梨さんが説明されていましたが、もっと詳しく説明をされました。
Who is OWASP
「OWASP が～～と言っているから」とネット上に書き込んでいる人がいるみたいだそうですが、コミュニティの名前であって、人の名前ではない。
OWASP のメンバー
米国にいる中心メンバー数人以外は、全員ボランティア。
ボランティアだからこそ、プライスレスに活動ができることも多々あるそう。スポンサーがついてくれるということでしょうか？
OWASP’s DNA
OWASP のモットーは、「 やってから謝る 」こと。
いつかの APSEC というカンファレンスで Facebook の CIO がこんな発言をしたそうで。
最善のセキュリティを尽くせないのであれば、ほかのことをやれ
たとえば Facebook のユーザの 1/3 は、端末が SHA-1 ハッシュ化しか対応しておらず、高度な暗号技術を利用できない状態にあるのですが、それをセキュリティを重視するからといって切り捨ててしまうのはおかしい。
つまりセキュリティ管理者は、そうした 最善のセキュリティを尽くせないユーザ に対応するため、 プランB を考えなければならない。
たとえ先進国では最善の策を講じるとしても、ほかの地域では強制的に対応することはせず、ほかの認証や技術によってそれを補う形でセキュリティを担保する。
こうしたときに重要になってくるのは、 いろんなやり方を否定しない ことであり、発言したり実行したりした後から「この問題は考えていませんでした」というパターンも当然ありうるそう。
だから、 やってから謝る 。なんだかこのあたりは終始考えさせられる内容でした。
OWASP の活動
OWASP Japan だけでも Chapter Leader はたくさんいるし、世界ではもっとたくさんいるそう。 Leader がたくさんいるということは、他のメンバーもたくさんいるわけで。
世界中で様々な議論がされ、その成果物が無料でネット上にアップされているそう。ちょっとわからないことがあれば OWASP で検索すればなんでも出てくる、というレベルで。
基本的に英語で書かれている (英語で議論された) ものですが、日本のメンバーによって翻訳されているものがいくつもあるので、 (チートシート、 IoT プロジェクトのドキュメントなど) どんどん活用していってほしいそうです。
さらに今回のような勉強会で集まれば、同じ興味を持った仲間の顔が見れるからいいね、とおっしゃっていました。やっぱこうして集まるといいですね。
- 出版社/メーカー: 西東社
- 発売日: 2014/02/07
- メディア: Kindle版
- この商品を含むブログを見る
セキュリティへの 3 つの視点と、シフトレフト
このセクションの冒頭前後、異常な腹痛に襲われてしまい席を外していたので、当時の TL と戻ってきてからの話でちょっとだけ推測して書きます。間違ってたら容赦なくご指摘ください。
Shift Left とは
セキュリティを考えるうえでまず思い立つものといえば、一般的に 何が盗まれたか、何が壊されたか 。しかし、セキュリティはそんなに甘くはない。
顧客のクレジットカード番号が漏洩した、という問題について、それはなぜ起きたのかを考える必要がある。これは、どうして漏れたのか、すなわち どんな準備が不足したから問題が起こったのか という、問題が起こる前のことを考えるということ。
さらに言えば、 なぜ不足してしまったのか という根本的なことも考えていく必要がある。
そうした、時系列にして前に々にと考えていく (一般的に時系列は左から右に進むため、その逆である 左に進む ) ことを シフトレフト というらしい。
そして、シフトレフトを考えるうえで重要な 3 つの視点について解説してくださった(この部分が一番わからない、完全なる予想)
Attack Surface
単純に、 どこから攻められるか 。アプリケーションで言えばどの画面から攻められるか、システム的に考えればどの機能から攻め込まれるか。
日本語で言えば 攻撃面 。穴が露出していればそこから入ってきてしまうということですね。きっと。
攻撃側はそうした 攻撃面の調査 、それを踏まえた 脆弱性の発見 を売買するエコシステムを成立させていて、一度見つけられてもすぐには利用されない。いつかどこかでその情報を買った人が、自分が作ったウイルスに組み込んで使う、ということが一般的だそう。
(ここら辺から復帰)
つまり根本的には、脆弱性の情報が売られないため、攻撃面 (弱い面) を見つけられないということが重要だそうです。
攻撃面を意識すれば、おのずと脆弱性は防がれ、攻撃されない、という根本的解決につながる。これがシフトレフト的視点。
OWASP には Attack Surface と脆弱性、それによって盗まれる可能性のあるデータが関連付けられて掲示されているみたいです。気になったときには調べてみたい。
IoT Attack Surface Areas - OWASP
コンポーネント
昨今では、エンジニアが製作するシステムのうち、 OSS の割合がほとんどを占めていて、実際にエンジニアが作成しているシステムはほんの一部になっている。
つまり、自分で書いたプログラムやシステム以外の場所に脆弱性がある可能性が非常に高く、実際にそれらを知らずに使うことが多いそうです。
天才がプログラムを書けば 10000 行につき 2,3 個のエラーで済むものの、普通のプログラマが書けば 1000 行に 1 個の割合でエラーが含まれるそうで、そう考えると OSS に脆弱性がある可能性ってものすごく高いんですね。
自分ですべての責任を持っているプログラムを出荷しているプログラマって、本当に少ないそう。
使うコンポーネントはしっかりと選ぼう、ということでした。
例として挙げられていたのは、とある超有名な OSS のソースの中に、 パスワードが入力されていなければ ××× にする というロジックが含まれているのを見たことがあるらしい。つまり、パスワードがばれているようなもの。
恐ろしいことに、これが脆弱性として報告されていない (正規のプログラムとみなされている) んだそうです。
こうした問題を許せるようなプロダクトであればいいのですが、そうでないプロダクトの場合は言語道断でしょうし、しっかりと調べたうえで使わなければいけないさそうですね。
プロセス
名古屋では有名なかんばん方式、これはプログラムには当てはまらない。なぜなら、プログラミング自体が設計に値するから。
けれど、プログラムを作るにも設計は必要。スケジュールとか納期とかそういったものだけではなく、セキュリティに対しても重要だそうです。
OWASP TOP 10 や OWASP Proactive Controls のようなドキュメントには、 どうすれば脆弱性が止まるか というベストプラクティスが書かれている。日常生活で言えば、手洗いやうがいにあたるらしい。そう考えると、たしかに簡単な予防を続けることで、大きな事故にならなくて済むということは、よくありますね。
システムを作る初期の段階から、運用を見据えて設計していき、脆弱性を潰していく。常に前段階でユニットテストを行い、盤石なシステムを築いていくということが大事。
OWASP で公開されている Open SAMM を使うと、プロジェクトの成熟度を定量的に測ることができ、どこに力を入れているのか、そしてどこが弱いのかを視覚的に表せるため、おすすめだそう。
まとめ
岡田さんの SHIFT LEFT やセキュリティへの熱い思いがとても伝わってきました。
OWASP Nagoya で初めてだからなのかとても概念的な話が多かったのですが、 OWASP がどういう方向性で、セキュリティを考えるとはどういうことかという、とても基礎的なものが学べたと思います。
学校でも仕事でも、これまで具体的な技術とか攻撃の方法だけとか、いわゆる 即戦力 になる知識しか得てこなかったのですが、ちょっと視点を変えるだけでセキュリティに対してこんなにも熱くなれるんだという、 経験力 を見ることができて、幸せです。
なかなかこういう機会、私は持ち合わせていないので新鮮…。
OWASP Japan Advisory Board 徳丸さん
徳丸浩のWebセキュリティ教室（日経BP Next ICT選書）
- 作者: 徳丸浩
- 出版社/メーカー: 日経BP社
- 発売日: 2015/11/10
- メディア: Kindle版
- この商品を含むブログを見る
とてもすごい人だそうです。お名前だけは伺っております。
先のお二方とは違い、格段にレベルの高い実践的なお話をしていただきました。
脆弱性とは
脆弱性、と一言で言っても多種多様。たとえば、
簡単に言えば、そうした脆弱性というのは 悪用されるバグ のことであって、 バグを減らせばセキュリティ向上がある程度見込める のだそう。
- 悪用可能なバグ
- バッファオーバーフロー
- SQL インジェクション
- クロスサイトスクリプティング
- 悪用可能な設定不備
- デフォルトのパスワードが使われる、など
国際的な分類
脆弱性の情報を国際的な基準で分類する仕組みがある。
- CVE
- CWE
- Common Weakness Enumeration
- 汎用的な脆弱瀬瑛を識別する
- 体系化されている
信頼境界とは
Java セキュアコーディングスタンダードの例を解説されていました。
分類番号 IDS00-J は、もともと「境界を越えたデータを信頼しない、無害化しなければならない」という意味のコードだったそう。
ここでいう境界とは 信頼境界 と呼ばれるもので、システムの外側との境目、つまりシステム設計時に不明な領域との境目ことらしい。つまり外側の領域は、簡単に言えばユーザからの入力やディスク環境。
解説ではデータベースのやり取りにおいて、信頼境界外から受け取ったデータをデータベースと連携して利用するときは、必ず無害なデータに変換しなければならない(フィルタにかける)としているそう。
この説明を聞いて、誰もが システムの外側 (ユーザからの入力など) を自身が実装しているシステムの信頼境界で無害化し利用する必要がある と解釈するだろう、と徳丸さんは言う。
そんなこと本当にできるの？と徳丸さんは続ける。
実際、無害かどうかはそれを解釈する側の実装や仕様による。つまりデータベース側の実装によって無害かどうかの基準が変わってくるということだ。このことは Java セキュアコーディングスタンダードも把握して書かれているようで、 解析器側に無害化アルゴリズムが存在しているのであればそれを使うのが望ましい と解説されているそうだ。
多くのデータベース (またはそのやり取りを担保するフレームワーク) には、 プレースホルダ という無害化する実装がある。 SQL を穴あきの状態にしておき、そこにデータを埋め込む作業をデータベース側が行うというものだ。 ※動的プレースホルダについては割愛
もはや、 システムの信頼境界を考えるのは無意味だったのだ 。というか、データベース側の信頼境界をそのまま流用しているような気がする (私たちのコード自体が信頼境界外)。
この話のオチは、 Java セキュアコーディングスタンダードの IDS00-J につけられたタイトルが「 SQLインジェクションを防ぐ 」になったこと。解説にももはや信頼境界などという言葉は出てこないそう。
でも、徳丸さんはこれもセキュリティの進化の結果だと捉えているそうだ。こうしてセキュリティは進化していくんだなぁ…？ (わかってない)
信頼されるデータとは
IPA が公開している「安全なウェブサイトの作り方」にも、信頼境界という言葉は出てこないけれど、概念自体は登場するそう。
というか、自分たちにとって信頼が必要なデータは何かを考えることが大事だそうだ。
例えば、
といったものは、プログラムが動いていくうえで信頼されていなければならない。こうしたものを、いわゆる信頼境界の外側、 外部から入力できないようにする ということが重要。
どうしてもこれらを外から指定しなければならないとき (掲示板で HTML の装飾タグを使いたいとか) は、フィルタを使って無害化を行う。
- ログイン済みユーザ名 (認証)
- 管理者が入力できるようにした SQL (認可)
- HTML タグを制限 (フィルタリング)
- 外部からのファイル名 (basename)
上記のように、信頼するしかないデータ、信頼できなければ無害化すれば良いデータ、はじめの方に出てきた信頼しなくても良いデータ (プレースホルダに入れる場合など) と、データの意味を理解してセキュリティ対策を行う必要がある。なるほど深い。
よくわかるPHPの教科書
たにぐちまこと著、『よくわかるPHPの教科書』という本を参考に、セキュリティ攻撃の実践を行ってくださいました。
さて、皆さんお待ちかねの時間ですね。誰だ祭りだなんて言ったのは。
SQL インジェクション攻撃
セキュリティ攻撃の代表格とも言える、 SQL インジェクション。サーバサイドプログラミングに多少の実装差異や漏れがあると、悪用されてしまう。
たとえば $id に 「 88-1 」という文字列が入っていたとする。
UESR_NUMBER = sprintf('%d', $id)とするとUSER_NUMBER = 88と解釈されるUESR_NUMBER = $idとするとUSER_NUMBER = 88-1となりUSER_NUMBER = 87と解釈される
と、ほんの些細な実装差異によって、本来意図した挙動を示さなくなります。
この脆弱性を利用して、簡単な掲示板サイトで SQL インジェクション攻撃を実演されました。記事を削除するときにユーザ ID を偽装し、いともたやすく他人の投稿を消すことができてしまいました。
このようにエスケープ処理を施さず SQL 文に入力文字列を直接連結してしまうのは大いに危険だと言います。
応用的な SQL インジェクション攻撃として、 ブラインド SQL インジェクション も紹介されました。これは、 SQL が副問い合わせに対応していることを悪用し、 ANY(SELECT USER_NUMBER FROM T_USER) などと入力して攻撃を行うことだそう。これが恐ろしいのは、たった一つのデータではなくすべてのデータがヒットしてしまうということ。
実演として、たった20行足らずのプログラムで実際にデータベースの中身をすべてかっさらっていかれました。ユーザ名とパスワードのハッシュ値が駄々洩れの状態に。
世間にはこうした SQL インジェクションを行いやすくする、通称 SQL 注入工具というものが出回っているそうで、中にはセキュリティ企業が販売しているものもあるそう。誰でも簡単に行えるようになっているみたいです。
ますます SQL インジェクションが恐ろしいものだということがわかってきました。ちゃんとプレースホルダを使おう、文字コードを指定して文字化け攻撃を食らわないようにしよう、ということでした。
CSRF 攻撃
日本でもこの手口を用いて、なりすまし犯行予告事件が起きました。
細工されたサイト…具体的には iframe が埋め込まれたサイトを用意して、その中に action 属性に爆撃先サイトを指定した form タグを配置します。 iframe の高さを 0 にしておけば、見た目はわかりません。
そうすると、それを開いたブラウザが iframe の中身を解釈し、そこにある任意のコードを実行してしまいます。実行するのは閲覧者のブラウザですので、完全になりすましができてしまいます。
このような攻撃への対策としては、セッション毎にハッシュ値とトークンを比較して認証を行うことで、不正に CGI へコマンドを送っても処理しないようにする、という対策が有効だそうです。
XSS (クロスサイトスクリプティング)
ブラウザで見ているドメイン (オリジン) 上の他のサイトで任意の javascript を実行できる、という脆弱性を活かした攻撃。
ウイルスではないとされているそうですが、ワームには分類されるそう。
少し前までは (学校で習ったような内容としては) 、プログラム文字列が掲示板に登録されてしまいそれが潜在的にブラウザに残り、別のサイトを閲覧中に発動してしまう、ということが多かったそうですが、最近はもっと手口が多くなっているそう。
今回紹介されていたのは、掲示板におけるアイコンファイルの細工。アップロード時に画像ファイルかどうか判別するためにファイル名の下 3 桁をチェックしていましたが、ピリオドまではチェックしていないため、拡張子なしのファイルがアップロードできてしまいました。
サーバ設定によっては拡張子なしのファイルを text/html とみなして実行することができるそうで (規定では OFF になっているけど) 、アイコンとして表示しているにもかかわらずブラウザ上では通常のサイトと同じ状態で解釈し、 javascript を実行してしまいます。
ブラウザ上で実行されるだけでなく、二重拡張子を使うなどしてサーバ上で実行可能なプログラムがアップロードされると、サーバサイドがそもそも危険にさらされることになります。とくに実演では webshell というブラウザからサーバ上で UNIX コマンドを実行できるという チートな プログラムをアップロードし、サーバを完全に乗っ取っていました。本当に怖い。
感想など
実演や時折笑いを交えながらわかりやすく解説され、セキュリティの重要性や危険性が身に染みてわかりました。
数々の脆弱性は局所的な対策の積み重ねで食い止めることができる、と最後におっしゃっていたのですが、私のようにセキュリティに疎いとその重大さに気づいていないから、おざなりな姿勢になってしまうのかなと思いました。
中途半端な憶測や推測をせず、しっかりと地道に対策すれば、セキュアなシステムは実現できる。改めて実感しました。
OWASP Nagoya Chapter Leader 村井さん
勉強会の最後に、 OWASP Nagoya のこれからの活動について紹介してくださいました。
OWASP Nagoya Local Chapter Meeting / OWASP Day
スクール形式の勉強会や、外部講師を招待しての講演、 OWASP で公開しているドキュメントの紹介など、 至って真面目な イベントのようです。とはいえ今回のムードからしてそこまでお堅くはなさそう。
直近では、 11月に OWASP Nagoya Local Chapter Meeting #2 が開催されるそう。行かなくちゃ！
OWASP Nagoya Hands-On
ハンズオン形式でのセミナー、 OWASP で公開しているツールの紹介など、 至って真面目な イベントのようです。座学だけではわからないことも、ここでしっかりと理解できそう。
直近では、 2018年 3月に OWASP Nagoya Hands-On #1 が開催されるそう。行かなくちゃ！
OWASP Night in Nagoya
- 出版社/メーカー: 西東社
- 発売日: 2014/02/07
- メディア: Kindle版
- この商品を含むブログを見る
セミナーや、 LT で行う カジュアルな イベントのようです。わいわいと盛り上がりながら、セキュリティへの意欲を高めていくのだそう。
直近では、 2018年 1月に新年会も兼ねた OWASP Night in Nagoya #1 が開催されるそう。行かなくちゃ！
OWASP World Tour 2017 Tokyo / Nagoya Satellite
一般募集だと思った？残念、来場特典でした！
2017 OWASP World Tour Tokyo - OWASP
9月 30日に行われる OWASP World Tour 2017 の東京講演を名古屋で視聴できるサテライトイベント。今回の勉強会のまさにその場で connpass に公開していただき、真っ先に応募することができました。
会場は今回と同じ愛知大学で最大 40人 のところ、公開直後すぐ満席状態になってしまいました。私はとりあえず確保できました。
OWASP の Wiki を見ると会場変更されるかも？定員増えるかも？と示唆されているので、応募すればもしかしたら優先的に確保してもらえるかも。行かなくちゃ！！
懇親会に参加してみて
勉強会終了後、懇親会も行ってきました。
まともに飲み会も懇親会も行ったことがない中この規模に終始圧倒されていましたが、いろいろな話ができて面白かったです。
隣に座っていた某すごい方が岡田さんと対等 (?) に話をされていたのがとてもうらやましい。というか、自分の力不足さにとても失望した。もっと頑張らなければ、と改めて自覚しました。
おわりに
今回の勉強会は、初めは軽い気持ちで参加したけれど、振り返ってみると参加してよかったなぁと感じます。
セキュリティに対する関心を持てましたし、これからプログラムを作っていくうえでどれだけセキュリティが重要かを再確認できた気がします。
信頼境界のくだりは最近自分でも考えていたテーマで、ユーザをどこまで信用するか、どこで信用度チェックをするのか、という問いにひとまず結論がついたように思えます。たぶんすべてではないのですが。
自分の中で多くのきっかけができました。本当にありがとうございました。
最後になりましたが、長々と最後までお読みいただきありがとうございました。そして、お疲れ様でした。
