『エンジニアストーリー by Qiita』は、「エンジニアを最高に幸せにする」というQiitaのミッションに基づき、エンジニアの皆さまに役立つヒントを発信していくPodcast番組（無料・登録不要）です。毎回、日本で活躍するエンジニアの方々をゲストに迎え、キャリアやモチベーションに関するお話をしていただきます。
今回の記事では、Webセキュリティの第一人者であり、「徳丸本」と呼ばれ広くWeb従事者に支持されている「体系的に学ぶ 安全なWebアプリケーションの作り方」の著者である徳丸浩さんをゲストにお迎えした回について、配信の模様をご紹介します。
▼徳丸さんの前回配信を見てみる
今回のエピソードでは、セキュリティの面白さや、どう興味を持っていくと良いか、リテラシーを上げるためにはなどについてお話をお伺いしました。
是非ご覧ください！
プロフィール
Webセキュリティの第一人者、EGセキュアソリューションズ株式会社 取締役CTO
Qiita株式会社 プロダクトマネージャー
テーマ「Webセキュリティの面白さと本の執筆について」
清野：今回徳丸さんとお送りするテーマは「Webセキュリティの面白さと本の執筆について」です。今回はセキュリティについて深掘りしながらお伺いしていきます。
徳丸：分かりました。
清野：前回、徳丸さんから「セキュリティに面白さを感じてのめり込んでいった」というお話がありました。その一方で、僕自身もそうなんですけど、セキュリティにはとっつきにくさがあるなと思っていて。Webアプリとかって書けば動いて嬉しいみたいなのが分かりやすいと思うんですけど、セキュリティの場合は攻撃をまず学んでいくとか実際動かしてみるとか、面白さに気づくまで勉強しないといけない気がしています。
なので、これからセキュリティを勉強していく人たちに対してアドバイスというかがあれば、ぜひ最初にお伺いしてみたいなと思っています。
徳丸：実はそういう質問が多いんですが、私自身はあまり上手く答えられないことが多くてですね。と言いますのは、私にとってはセキュリティって面白いものなので「面白くないんですけどどうしたら良いですか」と言われても、「え、面白いけど」みたいなふうになっちゃうんです。ただそうも言っていられないので、やっぱり先ほど清野さんおっしゃったように攻撃から入るのは、手っ取り早いかなとは思いますね。
そして「こんなことができるのか」みたいな知的な驚きと言いますか、そういうのをモチベーションにするのが早いかなと思います。逆にそういうのがあまり面白くないと思うなら、無理にやらなくて良いんじゃないかとさえ思ってしまいますね。
ソフトウェアを書く人であれば安全にするのは責務としてあるんですけども、そうではなくセキュリティを仕事にするかどうかで言うと、ソフトウェアのセキュリティの、例えば攻撃とかを見てこれはすごいと思えないんだったら、また別の仕事で良いんじゃないかなと思ってしまいますね。
清野：なるほど。セキュリティには座学っぽさみたいなイメージはある気がしていて、物作りというより最初に勉強していくみたいな。
しかも現代においてのセキュリティって攻撃が結構様々に出てきていてその対策みたいな感じになっちゃっているので、本来のセキュリティは攻撃者側としてこういうことできるよねとか、前回のお話にあったようにハックしていく面白さと、プラスそこを上手く防御していくっていう守りのセキュリティのお話がある気がします。そのあたりは勉強を、手を動かしながらやっていくのが面白いのかなって感じましたね。
徳丸：私自身はあまりやってないんですが、今ですと「TryHackMe」とか「Hack The Box」とか、様々なサービスで攻撃を学ぶとかですね。あるいは攻撃を学びながらそのところまで学べるみたいなサイトもありますし、それからいわゆるやられサイトですね。脆弱性がもともといっぱい入っているアプリケーションやサービスで、そこを自分で攻撃してみるみたいなのが、古典的ですが良いんじゃないかなと思います。
実は私自身、「BadTodo」というのを発表してまして、皆さんに試していただけるようになっています。たぶん50個以上の脆弱性が入っています。それぞれパターンも違います。
清野：なるほど。徳丸さんの本自体も手を動かして学べるスタイルになっている気がしているので、触りながらやっていくのはすごく面白そうですね。ありがとうございます。
徳丸：そう思います。私の本の初版が2011年に出たんですが、その段階でそういう環境を添付したいということになりまして、当時初期の段階ではCD-ROMをつけたんですが、そこにVMware PlayerとかVMそのものとか、そういったものをつけて販売しておりまして、ちゃんと手を動かして勉強してねというメッセージでした。
清野：これもぜひお伺いしたいんですが、徳丸さん自身はセキュリティのキャッチアップとか勉強って、今どうやってやってらっしゃるんですか？
徳丸：ずっと特定のサイトを見てるとか、そういうのはあまりなくてですね。X（Twitter）とか、あと自分が気にしてるテーマっていうのがありまして、それで検索したりたまたま引っかかったら深く追いかけたり、そういうスタイルでやってます。
これも人におすすめできるかというとあまりできない気もしますが、インターネット中心ではありつつも、例えば様々なプログラミングの仕方、ウェブアプリケーションの作り方がどんどん進化／変化していますが、そういう中で「こういう脆弱性が入るんじゃないかな」という着想を得るわけですよ。そうすると、前からやってるんですけれど昔ですとPHP言語の入門書って今世の中にいっぱいありますが、それが出たら買ってきて、脆弱性がないか調べるんですよ。そうすると脆弱性が結構あると。
じゃあどういう人が書いてるかというと、単にプログラムのこと知らないライターが書くことは実はあまりなくて、例えばフリーの開発者や一応専門家なわけです。専門家が書いてもやっぱりセキュリティという面ではこういうレベルなんだなみたいなことが間接的に分かるわけですね。
あるいは最近はYouTube動画も見てまして、それはセキュリティのYouTube動画じゃなくて、日本とかアメリカのこうやって開発するんだよっていう動画を。見ているときに「これはちょっと違うんじゃないか」とかに気づいて、そこを深掘りして調べるとか、そういうことを自宅ではやっています。
清野：そうなんですね。様々な方が作っているところを見ながら攻撃者目線でハックというか、見つけていっているというような感じなんですね。
徳丸：そうですね。前回でも言いましたが、やっぱりもともとあるのは仮説なんです。新しい作り方になったらこういう脆弱性が生まれるんじゃないかと。こういうことがあり得るということで発表しても良いんですが、一歩進めて実際にこういうことをやっているのを見つけたいんですね、私としては。だからちょっといろいろ探し回っているというところですね。
清野：そうやって探し回っている中で、よく言われている常識化したセキュリティのテクニックや攻撃手法以外のところが新しく見つかることってあるんですか？
徳丸：ありますね。ただそれが常識でないかどうかっていうのは、それはもう常識でしょうみたいなこと言われちゃうかもしれませんけど。
清野：そうなんですね。そういうのを見つけるときってそれも調べていったりするんですか？
徳丸：そのテクニックが分かっているものだったら、それを当てはめるとこういう攻撃できそうだなとかって分かる気がするんですけど。完全に新しいっていうのは実はそんなに多くなくて。
清野：そうなんですね。
徳丸：過去から蓄積された攻撃手法の延長線にあるものが多いんですね。例えば、今となっては当たり前になりましたが「サーバーサイド・リクエスト・フォージェリ（SSRF）」という攻撃的脆弱性があります。これはサーバーなどからURL指定で外部のサイトなどに情報を取りに行く。その情報を取りに行くURLが外から指定できるする場合がありますが、そういう場合に例えば外ではなくて、データセンターやクラウド内部のサーバーにアクセスできちゃいます。
なのでそのアプリケーションをいわばプロキシとして経由して攻撃できる、通信できるとダメだよねというのがサーバーサイド・リクエスト・フォージェリです。ただこれは成り立ちとしては非常に古典的なディレクトリトラバーサルっていう攻撃と似ています。ディレクトリトラバーサルの場合はそのファイルのパスを指定できる場合に起こるんですが、パスをURLに置き換えるとSSRF、サーバーサイド・リクエスト・フォージェリになるんですね。
ですから、その古典的な脆弱性を学んでただ丸暗記するんじゃなくて、咀嚼し発展することで新しい脆弱性に気づける。サーバーサイド・リクエスト・フォージェリは私が築いたわけじゃないですけども、そういう延長で考えるっていうのは有効だと思います。
セキュリティのジレンマ
清野：なるほど。ありがとうございます。ちょっと気になったんですけれど、セキュリティを発展させていくためにハックをしていくと、逆に新しい攻撃手法が見つかっていっちゃうじゃないですか。
そうすると攻撃者もそれを知ることになるので、今まで気づかれてなかったから特に攻撃されてなかったサービスとかが新しい攻撃をされちゃうことがある気がしていて。セキュリティを発展させていくためにやっていると、結果的に攻撃手法も増えていくみたいなジレンマみたいなを感じることってありますか？
徳丸：ありますね。
清野：そうなんですね。
徳丸：ただ例えばこのサーバーに脆弱性があるって言うならそのサーバーの管理者に伝えれば済みますが、新しい手法に気がついたとなると世界中の開発者にそれを教えてあげるけど、攻撃者には教えないっていうことはできないわけですね。ですから、結論としては広く発表するしかないということであります。
第1回でiモードの話をしましたが、当時簡単ログインといってiモードのサイトでパスワードレスで認証できるものがありました。これはドコモが出している正式な認証サービスではなくて、各サイトが独自にiモードの仕組みを使って認証がパスワードレスでできるという仕組みがあったんです。かなり前の話なんですが、実はそれが攻撃できてしまうということに私気づいたんですね。
清野：徳丸さんが気づいたんですか？
徳丸：はい、私が気づきました。ところがドコモ側で対策できればドコモに伝えて対策をお願いすれば済むんですが、対策できないことに気づいたんですよ。
清野：そこも気づいたんですね。
徳丸：ですから、相当悩んだんですが、発表するしかないということで発表しました。一部で「なんで徳丸はゼロデイの脆弱性を発表したんだ」みたいなことを言う人もいたようですが、ちゃんと分かっている人から見れば各サイトで対策するしかないので発表するしかないということになりました。特にそれで非難されたり訴えられたりはなかったんですが、結構ドキドキしますよね。
清野：なるほど、ありがとうございます。今もゼロデイ的なものの発表って結構されることはあると思っていて、そこら辺ってなんでなんだろうなみたいなのは結構気になっていました。
徳丸：やはりいずれは攻撃側も気づくわけでして、そうすると本当のゼロデイになっちゃう。先に発表することで、攻撃者も気づくけども対策側も同時に対策できるということで発表するしかないかなと思いますね。
清野：そうですね。後から気づくよりかは同時に気づいて、なんとかして攻撃者が攻撃してくる前に守るみたいな。そのスタンスが大事ってことですね。
徳丸：はい。
清野：ありがとうございます。
徳丸：今みたいな話じゃないんですけど、私のXのメッセージに「これこれのサイトに脆弱性見つけたんですけどどうしたら良いですか？」みたいな相談がたまに来ます。年に何回か来るんですけど「それはもうサイトに連絡するしかないんじゃない？」みたいな感じですね。あるいはIPA通して届出するかですね。それに返すしかないんですけどね。
清野：確かに。見つけちゃったら見つけちゃったでそれをどう伝えていくか、みんなすごく悩む気がします。
徳丸：そうですね。私はもうサイトの脆弱性ってあんまり探してなくて、それ見つけても届出とかすれば良いんでしょうけれど、それよりも例えばオープンソースのソフトウェアで脆弱性を探す方が良いというかあまりドキドキしなくて済むというかですね。
清野：そうですよね。下手になんとなくIssueとか書いちゃうと逆に危ないとかある気がする。
徳丸：本当にそうで、サイトの場合気をつけないと自分自身が法律違反を犯してしまう。特に不正アクセス禁止がありますね。自分自身が犯罪者になってしまいます。現にだいぶ昔ですけど逮捕されちゃった人とかいますので。
そういう意味でもWebサイトの脆弱性を探すのはやめたほうが良いというか。バグバウンティといって「報奨金出します」ってやってるところは割と安全なんですが、そうでないところはちょっと気をつけたほうが良いと思いますね。
清野：ありがとうございます。結構ここらへんは慣れない部分な気がするので、とても参考になります。ありがとうございます。
セキュリティのトレンド
清野：攻撃の定石はいろいろと出てきてるという話はある気がしているんですけど、セキュリティのトレンドみたいなのって今ってあるんですか？目下いろいろ生まれてきてるとか、考えないといけない議題になってるものとか。
徳丸：Webのセキュリティという点で言いますと、攻撃側がどんどん先を行くという話は実はあまりなくてですね。作り方が変わっていくと。新しい作り方にこういう脆弱性が考えられるよねみたいな話が多いんです。
ですから今時も珍しくはないですが、例えばシングルページアプリケーションというのが出てきて、表示系は全部JavaScriptでやりますよと。サーバー側にはもうAPIしかないというふうになったときに、実は基本は変わってないんですが、やはりシングルページアプリケーション、SPAならではの脆弱性の入り方があります。
あるいは従来はちゃんと作る側は気をつけていたところが、作り方がちょっと変わったためにそこがチェックされないようになってしまうとかはあり得ますね。
清野：なるほど。最近だとそのWeb系、特にWeb系だけでもないと思うんですけど、生成系AIから始まるAI新時代というか、AIで生み出すところがシステムの一部にどんどん組み込まれていく時代になってきていると思うんですけれど、そのあたりのセキュリティについての話もあるんですか？
徳丸：ありますね。例えばCopilotみたいなもので英語や日本語で簡単な指示をすればソースコードを書いてくれるのはどんどん使われはじめていますが、そのコードが絶対安全なのかというと実はそうではないですね。これは「Black Hat」という米国のセキュリティイベントで発表されてもいますが、例えばCopilotで生成されたコードにSQLインジェクションが入るとかです。
CopilotではなくてChatGPTですが、これは脆弱性が入るんじゃないかと思って「こういうプログラムを作ってください」と指示したら、ちゃんと脆弱性が入るとかですね。
清野：そうなんですね。
徳丸：あと著作権大丈夫なのかとかですね。秘密情報漏洩しないかとかそういう話もあるんですが、一方で質という問題もあります。今の生成AIは時々嘘をつきますがプログラムについてもそうで、これが単なるバグでですね。ちゃんと動かないのはテストで分かるんですけど、脆弱性となると普通の正常系のテストでは気がつかずに、そのままプロダクトになってしまうというのはあり得ますね。
清野：なるほど。今のお話だと、攻撃や問題は見えている状態な気がしていて、そこに対して、ソフトエンジニアとかプロダクトを作っている人間としてどういう守りを作っていくと良いのかもあるんですか？
徳丸：これは生成AIを使うからということではなくて、鵜呑みにしないということが大事ですね。自分が書いてもきちんとセキュリティのチェックはしなければいけないのと同じことがAIで作ったコードでもあるということであって変わるということではないと思うんですが、任せっきりはだめよということだと思います。銀の弾丸というか、魔法のツール的にもそれを信じ込んで使っていくみたいなところはまずやめていこうね、というところが大事みたいな感じですかね。
清野：そうですね。
徳丸：これは実は今に始まったことではなくて、例えばGitHubとか、それこそQiitaとかですね。そのコード例が上がっているとそれをコピペして使っちゃう。著作権上の問題がありますが、それも多くの人はあまり気にしないですね。公開されているんだから良いでしょうみたいな感じで使っちゃいます。でも実はバグがあるとか、脆弱性があるとか。
さっき話したこれこれする処理という話をしましたけど、その内容でGoogle検索とかで見つけたサイトに脆弱性があったときにコメントで教えてあげることがあるんですが、反応がないこともありますね。ちょっと残念な気持ちでありますが。これは多分そういうコードを実はAIが学習してしまっている可能性があるわけですね。
清野：逆にってことですね。
徳丸：AIが完全に何もないところからコードを書くというのは今は多分あまりできてなくて、過去に誰かが書いたコードを学習した積み重ねがベースになっていることが多いと思います。そうすると中には脆弱性があるサンプルもあるわけですね。そういうものを学んでしまうことは現状あるように思います。
清野：次の未来のためにのアクションで言うと、自分自身がみんなが生み出しているコードをそれぞれがちゃんと担保していく意識とかは大事そうってことですね。
徳丸：そうですね。近未来に起こりそう／起こるかもしれないこととして、今のAIは既存のコードを学習してそれを元に生成されていると思いますが、仮に全部AIで作れば良いじゃんとなってみんながそういうコードを発表をしないとなると、一体何を学習するんだろうとか。あるいは特に最先端のプログラム言語とかは元ネタが最初はないですから、セキュリティのリテラシーを上げるためには最初は誰かがインターネット上などに公開しないといけません。その辺のサイクルが今後変化しないかなというのは、個人的には興味があるんですよね。
清野：確かにそうですね。かつ、そこが変わってくるとエンジニアたちが気にしないといけないこととかも変わってくる気がするので、確かにそこは見えないけど考えていかないといけないですね。
徳丸：考えてどうにかなる問題でもないんですが、ウォッチはしていかないといけないと思いますね。
リテラシーを上げるためには
清野：ありがとうございます。やっぱりセキュリティって一人が意識を高めてても、組織とかそれぞれのコミュニティの中で全体のセキュリティのリテラシーを上げていくのとはまた別の話な気がしていて、業界全体のリテラシーを上げていくためにやっていったほうが良いこととか、小さな組織やチーム単位でそういうのを進めるときにやっていったほうが良いこととかってありますか？
徳丸：これは私の本業でもあり、セキュリティの本を書くとか様々な発信をすることの主要な動機でもあるんですが、20年とかやってきてて希望もあれば諦めみたいなのもあります。なんやかんや言ってあまり難しいことは伝わらないなという、諦めみたいなのがありますね。
ちょっと専門的な話になりますが、SKLインジェクションとかクロスサイトスクリプティングの対策として、エスケープ処理をやれということになっていたんです。例えばSKLでしたらシングルクォートがあったらそれを重ねなさいとかですね。小なり記号はアンパサンドとLTセミコロンに変換しなさいとか。これ簡単なように見えていろいろ組み合わせでやっていくと結構複雑になる場合がありまして、複雑になるとやっぱり人間間違えるんですよ。
昔は「これはもうあるルールで決まっていることだから、学習さえすればみんな分かるはずだ。それを私は伝えたい」と思っていたんですが、ある時期から「これは分からない人は多分一生分からないな」と。それはその人がサボってるとかではなくて、人間誰しも得意不得意がある、走るのが速い人もいれば遅い人もいると。それと似たようなことで、じゃあもうエスケープとかもうしなくて良いようにできたら良いなと思っていたら、実際そうなってきてるんですね。
今時もうエスケープ処理しなきゃいけないなんて局面はほとんどないわけですね。ですから難しいやつはダメってことです。実践するのに難解なものはもう、これはもうみんな分からないんだから難解でない方法を用意するしかないというふうに思ってますね。
あとやはり気持ちってすごく大事だと思うんですね。やっぱり人間はなんやかんや言って感情で動きますから「脆弱性があるとこんな怖いことが起こるんだよ」っていうのはちゃんと感じてもらわないと困るわけです。それは恐怖のどん底に陥れて変な壺みたいなのを売るとかではなくて、正しく心配してもらうために、甘く見てちゃダメだよっていうのを感情にも訴えることが大切で、そうするとモチベーションも湧いてくると思います。
清野：なるほど、ありがとうございます。まとめると、そもそもセキュリティの難しいところは考えなくても安全な世界観を作っていこうねという話と、どっちかっというと知識よりも情に訴えていくのも大事だよねという意識形成をしていくのが大事って感じですね。ありがとうございます。
徳丸さん今日はありがとうございました。まだまだお話ししたりないので、次回も徳丸さんとお送りします。
さいごに
「エンジニアストーリー by Qiita」は、近年高まるエンジニア向けPodcastのニーズに応え、エンジニアのキャリア形成に有益な情報を発信しています。興味のあるテーマを見つけて配信を聞いてみましょう！