セキュリティキャンプ2019 応募用紙晒し(トラックB開発と運用)
Capr1です．
セキュリティキャンプ2019トラックB(開発と運用トラック)に受かったので、後輩や今後参加する人たちの参考になればと思い自分の応募用紙を置いておきます．
ぜひ来年応募してみてください！
共通問題
問1
ブログや、Twitter、GitHub、Slideshare、Speaker Deckなど公開している活動や資料があれば、URL等を記載してください。
ブログ：https://caprinet.hatenablog.com/
Twitter：https://twitter.com/_Capr1_
Github：https://github.com/KazuyaMatsunaga
問2
セキュリティ・キャンプ地方大会などセキュリティに関するイベントに参加していれば、それを記入してください。
SECCON Beginners 2018東京：https://2018.seccon.jp/2018/09/seccon-beginners-2018-tokyo.html
問3
オープンソースなどの活動に参加していれば、どんな実績があるかを記入してください。
参加の形態は開発だけには限りません。
conbuという会場ネットワークを構築しインターネット接続を提供するコミュニティの活動に参加し、PHPカンファレンスの会場のネットワークの構築を行いました．そこでWLCの構築、会場で使うアクセスポイントのJOINや単体テスト、本番構成でのE2Eテストを行い、またCiscoというルーターのコンフィグを行いました．普段自分は趣味でSlackBotの開発やWebアプリケーションの開発を行っていましたが、こういったネットワークといった低レイヤの部分は触ったことがなかったので、非常に勉強になり、そしてここで学んだことはその後の研究室内のネットワークを構築するときにも活かされています．
問4
自分のスキルについて、得意としている、あるいは得意としたい技術領域について、
なぜその技術領域が好きなのか、その技術領域でどんな世界を作っていきたいのか、
『好きなだけ』語ってください。
自分は幅広い分野に興味があるのですが、特に自分は「サーバサイド」の分野を得意としたいと考えています．理由は二つあります．
１：
今やゲームにおいてオンラインプレイやアップデートというものが当たり前になってきたので、現代の様々なソーシャルゲームやコンシューマーゲームの裏側には今やサーバというものが必要不可欠になっています．そしてゲームにおいて特別なイベントが発生したり、アップデートが実装されると、普段よりもサーバへのアクセスが集中し、それだけサーバに負荷がかかります．そしてサーバに負荷がかかると、サーバがエラーを引き起こし、ゲームがプレイできなくなるといった問題が起こります．実際に最近「大乱闘スマッシュブラザーズSPECIAL」というゲームでアップデートが実装され、午前10時から更新データのダウンロードが開始されたにも関わらず、サーバへアクセスが集中し、メンテナンスに入ってしまい、結局午後3時までメンテナンスが続き更新データをダウンロードできずプレイできない状態が続いてしまったといった問題が発生しました．実際私や友達もそのせいでゲームをプレイできず、非常にもどかしい思いをして、阿鼻叫喚していました．
なので私はこういった事件を防ぐために、そしていつでもプレイしたいときにゲームをプレイできるようにするために「サーバサイド」という技術領域を極め、サーバへの負荷対策を考え、ゲーム・サービスのメンテナンス時間を０にしたいと考えています．
２：
今やクライアントやサーバサイドとの間で、アカウントへのログインやアイテム購入や課金などの際に、お金やアカウントの情報(メールアドレスやパスワード)といった機密情報がやり取りされるケースが多くなってきました．そしてこういった機密情報がやり取りされるサービスは攻撃者にとっては格好の攻撃対象となります．実際、2013年10月に米Yahoo!が過去にサイバー攻撃を受け、2016年12月の時点で合計で10億人分のユーザーの個人情報が盗まれてしまった事件が発生してしまいました．(https://www.itmedia.co.jp/enterprise/articles/1612/15/news078.html
)
また2018年3月にマイネットが運営する13タイトルのゲームサービスのサーバが不正アクセスを受け、サーバの起動・停止やデータ管理が可能な「特権ID」を盗まれ、その「特権ID」を利用し、データを削除するプログラムを実行し、また2回目の攻撃でVPNに不正アクセスをし、サーバ上のデータを実行するコマンドを実行し、複数のゲームのサーバをダウンさせ、長時間のメンテナンスを余儀なくされてしまいました．(https://www.itmedia.co.jp/business/articles/1803/26/news131.html
)
私は今後あらゆるサービスにおいてこのようなことが起こらないように、「サーバサイド」という技術領域を極め、サーバのセキュリティを支え、ユーザーの大事なアカウント情報やサーバを操作する為の「特権ID」といった機密情報を守り、サービスを止めないようにし、ユーザーに安心してサービスを使えるようにしたいと考えています．
問5
あなたが今まで作ってきたソフトウェアにはどのようなものがありますか？
また、それらはどんな言語やライブラリを使って作ったのか、
どこにこだわって作ったのか、たくさん自慢してください。
- 昼飯をランダムで決めてくれるココアSlackBot
どこかに出かける度にいちいちネットでお店を検索して昼飯を決めるのが面倒だったので、現在地、料理のジャンル、予算の三つの情報を入力すると、アニメ「ご注文はうさぎですか？」の登場キャラのココアが、その情報に基づいてお店を検索し、その中からランダムでお店のURL を投稿してくれるSlackBotを作りました．(作品URL：https://github.com/KazuyaMatsunaga/Cocoa_bot
)
最初はUserのコメントに反応して配列に格納された法政大学小金井キャンパス周辺の店名をランダムに一つ抽出し投稿するだけでしたが、それだと自分が大学にいる時でしか使えないため、ホットペッパーグルメのグルメサーチAPIを利用することで入力された現在地からお店を検索できるようにし、どこでも使えるようにしました．またそれだけだと、学生が経済的に行けないような高級なランチのお店や居酒屋のお店が検索結果として返ってきてしまうため、予算を入力することで、その予算の情報に基づいたお店を検索するようにし、学生が行かなさそうなお店が検索結果に含まれないようにしました．
例えば以下のような感じに Botとやり取りすると昼飯をランダムで決めてくれます．
(1)条件に合うお店が見つかった場合
User：@Bot ランチ食べたい
Bot：ご注文はランチですか？
@User 現在地を教えてね！
User：新宿
Bot：@User 新宿だね！料理のジャンルは何にしようか？
User：ラーメン
Bot：@User ラーメンだね！予算はどれくらいがいいかな？
下の中から好きなのを選んでね！(番号で答えてね)
1:～500円
2:501～1000円
3:1001～1500円
User：2
Bot：@User OK！ちょっと待っててね！
@User このお店はどうかな？
北海道らーめん 鷹の爪 新宿店
https://www.hotpepper.jp/strJ001189340/?vos=nhppalsa000016
User：@Bot ありがとう
Bot：@User うん！どういたしまして！
(2)条件に合うお店が見つからなかった場合
User：@Bot ランチ食べたい
Bot：ご注文はランチですか？
@User 現在地を教えてね！
User：吉祥寺
Bot：@User 吉祥寺だね！料理のジャンルは何にしようか？
User：イタリアン
Bot：@User イタリアンだね！予算はどれくらいがいいかな？
下の中から好きなのを選んでね！(番号で答えてね)
1:～500円
2:501～1000円
3:1001～1500円
User：2
Bot：@User OK！ちょっと待っててね！
@User いいお店が見つからなかった...ごめんね...
User：@Bot ありがとう
Bot：@User うん！どういたしまして！
言語はライブラリが豊富であり、他の言語と比較して書きやすく読みやすいPythonを使いました．またHerokuという無料で使えるレンタルサーバーを用いて、Botを常駐化させています．
またURL先の画像にもあるように、ただやり取りするだけでは寂しいので、ユーモアさを出すためにやり取りの最後に ココアが動いているGIF画像を投稿する処理を実装しています．しかし、ローカル環境で実行していた時には正常に動作していた画像を投稿するという機能がHerokuで実行した時に動作しなくなるという問題が発生しましたが、問題が発生した原因を考え解決方法を自分で考えたり調べたりすることによって、何とか解決することができました．
今後の展望として、条件に合うお店が見つからなかった場合に、お店が見つからないままやり取りが終わるのは不便だと感じているので、再度情報の入力を要求する処理を実装したいと考えています．
- 音楽との新しい出会い方を提供するスマホアプリ「Battari」
近年新しい音楽と出会いたいが曲数が多くて探せず、曲を探す時間がないことから発生する音楽的無気力という問題をGoogleMapやフリック機能を用いて音楽との新しい出会い方を提供することにより解決するスマホアプリを研究室のプロジェクトで他大学とチームを組んで開発しました．開発を行うチームは１０人程度のもので、開発を進めていく上でAndroid・iOSアプリのそれぞれにおけるGoogleMap上に曲を設置し、設置された曲を拾う機能の実装とフリック機能で曲を送信する機能の実装と曲を受信した際に通知する機能の実装とユーザーのプロフィール画面の実装と曲のデータを管理するためのサーバの実装の計９つの担当に分けて作業を行いました．私はAndroidアプリのGoogleMap上に曲を設置し、設置された曲を拾う機能の実装とSpotifyのAPIを用いて自分がフォローしているアーティストとそのアーティストの曲をリスト表示する機能の実装を担当し、実装はプログラミング言語KotlinとAndroidStudioにより行いました．KotlinもAndroidStudioの操作も初めてだったので苦労しましたが、エラーが発生したり実装の仕方がわからない所があれば自分で調べて解決したり、調べても解決できないことがあれば詳しい人に相談することで何とか解決することができました．
反省点として、開発当初はアプリのリリースを目標としていたため、他の人が読んでも理解できないような複雑なコードの書き方や枠組みにしてしまったことです．このせいで、Android開発初心者の人がコードを読んでも中々理解できず、開発の進みに遅れが生じてしまったことがありました．もし、私が今後このようなチーム開発をするなら、他の人や初心者が読んでも理解しやすいようなコードを書き、シンプルな枠組みを確立したいと考えています．
- 日報の日付を自動で投稿するSlackBot
前述の研究室のプロジェクトでの他大学とのチーム開発において、毎日日報をSlack上で書くことになり．誰かがSlackの日報チャンネルにその日の日付を投稿して、そこのスレッド上に各々日報を書くことになりました．しかし、このやり方だと日付を投稿する人への負担が大きくなってしまうという問題やその人が日付を投稿するのを忘れてしまうという恐れもありました．そこでこれらの問題を解決するために自分は日付を決まった時間に自動で投稿してくれるSlackBotを開発しました．サーバの管理の手間を省くため、Googleのサーバ上で実行されるGoogleAppsScriptで開発をしました．また日報の出し忘れを防止するために、日報の締め切りの時間が近づくと自動でリマインドしてくれる機能も実装しました．
(作品URL：https://github.com/KazuyaMatsunaga/DailyReportBot)
- ゲームポートフォリオサービス(開発中)
現在開発している自分がプレイしてきたゲームを管理したり記録できたりして、それらを公開できるWebサービスです．フロントエンドはVue.js、サーバサイドはGolang + Firebaseで実装しています．Amazon APIと連携してゲームを検索できるようにし、それをリストに追加できるようにしたいです．またTwitterと連携させてソーシャルログインを実装させ、「●●●さんは今△△△(ゲームタイトル)をプレイ中！！」「「●●●さんが△△△をクリアしました！！」」といった風にツイートできるようにさせたいです．
問6
あなたがこれまで利用したことがあるインターネットサービスの中で一番すごい！と思ったものについて、
技術的なのか、仕組み的なのか、ビジネス的なのか、
どんなところがすごいと思ったのかを説明してください。
私が一番すごいと思ったインターネットサービスはバンドリのスマートフォン向けゲームであるバンドリ！ガールズバンドパーティ！（ガルパ）です．もともとバンドリはアニメやコミックに加え、キャラを担当する声優陣が実際に楽曲を演奏するマルチメディアコンテンツでしたが、個人的にはアニメが開始した段階では力の入れ方の割にはあまり流行っていない印象でした．そんな状況で配信されたガルパはバンドリの楽曲に加え、キャラクターの声優による人気のアニソンカバーが収録されていることなどが要因だったのかセールスでも上位に入っています．さらに、アニメも最終回に向かうにつれて段々と良くなっていき、アニメとガルパの相乗効果でライブへの期待も高まってきました．もともと曲を知らなかったユーザーにゲームを通じて曲への興味を高めさせ、ゲームから他のメディアにも興味を持たせていくようなコンテンツの運営方法はすごく興味があり、このようにガルパはビジネス的にすごいサービスであると考えています．
問7
今年のセキュリティ・キャンプ全国大会で受講したいと思っている講義は何ですか？
そこで、どのようなことを学びたいですか？なぜそれを学びたいのですか？
講義を担当する講師に響くようにアピールしてください(複数可)。
私はセキュリティキャンプでは以下の講義を受講したいと考えています．理由は２点あります．１つ目は、私は自分で独学する際、本やインターネットを参考にし、勉強しますが人の記憶力には限界があり、忘れてしまうので実際に手を動かしメモを取るようにしています．そうすることで、インプットとアウトプットがしやすくなると思っています. そのことから、私はなるべく手を動かし学べる講義を中心に選びました．２つ目は、私はネットワークが好きで今まで研究室内のネットワークの構築を行ったり、PHPカンファレンスという技術系イベントの会場のネットワークの構築を行ってきました．しかしこういった活動の中ではプログラムを書く機会がなく、そこでプログラムを少しでも書けるようになれたらと趣味でSlackBotの開発やWebに関する本を読みつつWebアプリケーションの開発を行い、勉強していました．しかし、Webアプリケーションの開発の際に、Webサービスを開発したことがない全くの初心者からWebサービスを安全に個人で提供できるようになるにはどうしたらいいかわからず、中々公開できずにいました．なので, 今回のセキュリティキャンプに参加することで、Webサービスを安全に個人で提供できるようになるまでの道筋を勉強していくきっかけにし,今後も引き続きのWebの勉強をし続けたいと思い、今回はWebシステムやWebセキュリティ に関連する講義を中心に受講したいと思っています．
また講義名の下に参加理由を書きました．
[B1〜3]クラウド時代における大規模分散Webシステムの信頼性制御
この講義を通して「Webサービスの運営者・開発者がどのようにして24時間365日安全かつ快適に利用できるWebサービスを構築・運用しているのか」ということを学びたいです．それにより、「Webサービスを開発したことがない全くの初心者からWebサービスの開発者・運営者として人々に快適で安全なWebサービスを個人で提供できるようになるまでの道筋が掴めない」という最大の悩みを解決し、現在開発中の「自分がプレイしてきたゲームを管理したり記録できたりして、それらを公開できるWebサービス」を世の中に提供できるようになりたいです．この講義では事前に開発したクラウドネイティブなWebシステムを実際の運用現場の事例と最新の研究動向について議論し、高信頼なWebシステムに改良していきながら24時間365日安全かつ快適に利用できるWebサービスの構築・運用方法について学べる絶好の機会なので、Webサービスの開発者・運営者となるためにもこの講義を受講したいです．
[B4]認証の課題とID連携の実装
現在開発中の「自分がプレイしてきたゲームを管理したり記録できたりして、それらを公開できるWebサービス」では、Twitterと連携して現在自分がプレイしているゲームの情報を呟けるようにしたり、ソーシャルログインができたりするという展望があります．この講義を通して、「いかに安全にソーシャルログインなどといったID連携をWebアプリケーション上に実装するか」ということを学びたいです．それにより、もし自分がID連携を実装したWebサービスを公開した時に、安心してユーザーがSNSとのID連携機能を使えるようにしたいです．この講義では、実際にWebアプリケーション上にOpenID Connectを実装し、 OpenID ConnectといったID連携の実装のリスクやその対策について手を動かしながら学べる絶好の機会なので、安心してユーザーがSNSとのID連携機能を使えるようにするためにもこの講義を受講したいです．
[B5]体系的に学ぶモダンWebセキュリティ
自分でWebサービスを公開するためには、XSSやCSS Injectionなどといったブラウザ側のWebセキュリティの理解が必要不可欠です．この講義を通して、「いかにWebサービスのブラウザ側のセキュリティを高めるか」ということを学びたいです．それにより、もし自分が「自分がプレイしてきたゲームを管理したり記録できたりして、それらを公開できるWebサービス」を世の中に提供する時に、脆弱性を突かれ、そのWebサービスを利用している人のTwitterのIDやパスワード、メールアドレスといった個人情報が盗まれないような安全なWebサービスを提供できるようになりたいです．
[B6]つくって学ぶ、インターネットのアーキテクチャと運用
私は情報ネットワーク・セキュリティ研究室に所属していて、これまでネットワークについての洋書を読んだり、研究室内のルータを触ったり、PHPカンファレンスという技術系カンファレンスのネットワーク構築スタッフ(NOC)をやってきたりと、DHCPやNATといったネットワークの技術について色々と本を読んだり手を動かしたりして勉強してきました．この講義では実際にルータなどの設定を行って「ネットワークのネットワーク」であるインターネットの構築を行うとのことなので、自分がまだ扱ったことのないDNSやRPKIなどといった技術について実際に手を動かしながら学ぶことで、自分の中のネット―ワークの知見をさらに広げることができるのではないのかと考え、この講義を受講したいです．
私は情報ネットワーク・セキュリティ研究室に所属していて、 「ボットネット」に関する研究をしていこうと考えています．その研究の際、機械学習を用いることで、トラフィックの解析やボット検知に役立つのではないかと考えています．私は全く機械学習に触れたことがないのですが、今回機械学習について知ることで今後に活かせるのではと思っています．またこの講義はハンズオンということで、実際に手を動かして機械学習を学べるいい機会であり、この講義を受講したいです．
選択問題
以下の中から、2問以上を選んで回答してください。(今回は問１と問４を選択)
問1
「1000万人が利用するTwitterのようなタイムラインサービス」をあなたが開発することになったとしたら、
予算はあるとして、どんなアーキテクチャで設計しますか？
具体的に利用するミドルウェアやライブラリまで思い浮かぶ人はそこまで踏み込んで書いてください。
「1000万人が利用するTwitterのようなタイムラインサービス」のアーキテクチャについて、Webシステムの構成の観点から考えていきます．
まず、Webシステムの構成についてですが、そもそもWebシステムは主にWebサーバとWebアプリケーションサーバとDBサーバに分けられます．Webサーバはユーザーと直接やり取りを行うサーバであり、ユーザーがWebブラウザからリクエストした内容を受け付けて処理します．例えば単純な会社のHPなど、テキスト情報だけの静的なページであれば、そのままHTMLやCSS、画像を返します．一方でリクエストの内容が動的な処理の場合、WebサーバはWebアプリケーションサーバへ処理のリクエストを依頼し、返ってきた処理をデータとして同じくWebブラウザへ返します．Webサーバでは一つ一つのリクエストに対する処理量は小さい代わりに、受け付けるHTTPリクエストの数が非常に多くなる傾向があります．Webサイトの一つのページを表示するだけでもHTMLファイルだけでなく、CSSファイルやJavaScriptファイルなど様々な静的コンテンツが必要です．HTTPリクエストでは一回のリクエストで一つのファイルしか取得できないため、一つのWebページを表示するだけでも大量のHTTPリクエストが送られます．このことからWebサーバは一回のWebページの表示のために数多くのHTTPリクエストを処理しなければなりません．
WebアプリケーションサーバはWebサーバからの動的コンテンツへのリクエストをJavaやRuby、PHPなどで書かれたプログラムを実行して処理するサーバです．場合によってはDBサーバにアクセスしてデータを要求し、その結果を人が見やすいようにHTMLに整形したりします．単にHTTPリクエストで指定されたファイルをWebブラウザに返すだけのWebサーバと違い、Webアプリケーションサーバでは様々な処理が行われています．
DBサーバは主にデータの管理を行っているサーバで、Webサイトに必要なユーザーデータなどを保存しています．
今回開発するのは「1000万人が利用するTwitterのようなタイムラインサービス」ということで、このサービスは非常に利用者が多く、また画像やフォロー数などの情報といった扱うデータの量も多くなり、タイムラインの更新や取得、さらにツイートの投稿などといった様々な処理が要求されます．このことから以下のようなことが懸念されます．
- WeサーバへのHTTPリクエストの数が膨大になる
1000万人もの人たちが一度にTwitterのタイムラインのページを閲覧するとなると、タイムラインを見る人の数が多いほどWebサーバへのHTTPリクエストは多くなります．また前述したように一つのWebページを表示するだけでも大量のHTTPリクエストが送られるため、Webサーバへ送られるHTTPリクエストの数は膨大になります．
- Webアプリケーションサーバへの負荷が大きくなる
Twitterのようなタイムラインサービスでは画像やフォロー数などの情報といった扱うデータの量も多くなり、タイムラインの更新や取得、さらにツイートの投稿などといった様々な複雑で重い動的な処理が要求されます．また利用者数が「1000万人」と多いため、WebサーバからWebアプリケーションサーバへのリクエスト数も多くなります．このため、頻繁にWebアプリケーションサーバ側で様々なプログラムを動かしたり、DBサーバにアクセスしてデータを要求し、その結果を人が見やすいようにHTMLに整形してWebサーバに返す必要があるため、Webアプリケーションサーバへの負荷が大きくなります．
以上のような懸念点から考えると、「1000万人が利用するTwitterのようなタイムラインサービス」では、WebサーバとWebアプリケーションサーバ、DBサーバをそれぞれ異なるノード(コンピューター)に配置し、軽い処理で膨大な静的コンテンツへのHTTPリクエストはWebサーバに、リクエスト数が比較的少なく処理の重い動的コンテンツの処理をWebアプリケーションサーバに、データの管理や保存をDBサーバに、といったように役割を分担させることで、それぞれのコンピューターのもつリソースを各サーバへ最大限に振り分けることができます．また今回は予算はあるとのことなので、WebサーバとWebアプリケーションサーバが配置されたコンピューターを予算のある限り用意することで、もし大量にWebサーバやWebアプリケーションサーバへのリクエストがきても、安定してサービスを稼働させることができます．よって「1000万人が利用するTwitterのようなタイムラインサービス」ではこのようなアーキテクチャで設計するべきであると考えています．
問4
OpenIDやOAuthといった技術を使ったアプリケーションのメリットとデメリットについて回答してください。
なお、FacebookやTwitterなどのソーシャルログインを実装したことがある場合には、
その環境（ライブラリやフレームワーク、開発言語など）と開発してみて感じたことを自由に回答してください。
そもそもOAuthとはクライアントアプリが、Twitter ,FaceBookなどのユーザー情報やユーザーに紐付いたリソースを多く持っているSNSなどと連携して、SNS上の情報を第三者のアプリケーションで利用できるようにする仕組みです．
例えば、Twitter APIではユーザーの認証方式としてOAuthをサポートしています．このOAuthを使うとユーザーが自身のTwitter APIへのアクセス権限を第三者のアプリケーションに渡すことができ、これによりユーザーが第三者のアプリケーションに対してTwitter上のリソースにアクセスすることを許可できます．その結果、第三者のアプリケーションがユーザーの代わりにツイートの投稿などができるようになります．
つまり第三者のアプリケーションに対してWebサービスAPIへのアクセスを安全に許可し、何らかの機能を利用する権限を与える「認可」の機能を持つ仕組みで、それをオープンな標準プロトコルとしてまとめられたものがOAuthです．
ここでOAuthのメリットをBasic認証と比較して考察していきます．
まずBasic認証によるアプリケーションからのAPIアクセスの流れを説明します．まずユーザーがユーザーの認証情報(IDとパスワード)をアプリケーションに渡し、アプリケーションがAPIに対してユーザーの認証情報を付与したHTTPリクエストを送り、APIへのアクセスを許可します．
つまり、アプリケーションがBasic認証を使ってAPIにアクセスするにはユーザーの認証情報をHTTPリクエストに付加する必要があり、そのためにはユーザーが認証情報をアプリケーションに預けなければなりません．しかしこれには2つの問題点があります．
- アプリケーションが認証情報を平文で保持しなければならない
アプリケーションはユーザーから受け取った認証情報を、APIへのHTTPリクエストに付加する時のために平文で保持しなければならず、もしアプリケーション側で脆弱性が発生した場合、保持している認証情報が漏洩する恐れがあります．
- APIアクセスの範囲を設定できない
例えばアプリケーション側にTwitterのツイートを投稿するだけの権限を提供したくても、IDとパスワードを渡してしまっているため、機能の制限を課すことができません．これによりツイートの取得やダイレクトメッセージの送受信までもが可能となってしまい、アプリケーション側でユーザーのTwitter上の非公開情報を取得することが可能となってしまいます．
ここでTwitterにおけるOAuth認可のフローを説明します．
まずユーザーがアプリケーションにTwitterとの連携機能を使うことを要求します．その後アプリケーションはユーザーをTwitterの認可ページにリダイレクトさせます．そしてユーザーは認可ページで認証情報(TwitterのIDとパスワード)を入力し、アプリケーションによるTwitter APIアクセスを許可します．その後、Twitterがアプリケーションにアクセストークンをアプリケーションに提供します．そしてアプリケーションは、取得したアクセストークンを使って認証が必要なAPIの呼び出しを行い、ツイートの投稿といった処理を行います．
ここでBasic認証におけるアプリケーションからのAPIアクセスのフローとOAuth認可のフローを比較すると、OAuth認可における様々なメリットが考えられます．
- 認証情報をアプリケーションが保持しない
Basic認証と違い、OAuth認可ではユーザーがアプリケーションに認証情報を渡す必要がないため、もしアプリケーション側で脆弱性が発生したとしても、保持している認証情報が漏洩する恐れはありません．またアプリケーションにとってユーザーを識別するものはアクセストークンしかないため、セキュリティリスクは最小限に抑えられます．
- APIアクセスの範囲を確認できる
アプリケーションがTwitterのどのようなリソース・機能にアクセスしようとしているのかを、ユーザーが認可ページでの手続き時に確認できるため、もしその中にアプリケーション側でアクセスしてほしくないリソースがあった場合、ユーザーが認可を行わずにアプリケーション側でユーザーのTwitter上の取得されたくないリソースを取得することを防ぐことができます．
- APIアクセスの範囲を設定できる
Basic認証と違い、OAuth認可ではユーザーがアプリケーションに認証情報を渡さないため、アプリケーション側でAPIアクセスの範囲を設定し、機能の制限を課すことができます．これにより、例えばツイートの投稿の機能のみを与えて、ツイートの取得やダイレクトメッセージの送受信をできないようにし、アプリケーション側でユーザーのTwitter上の非公開情報を取得できないようにすることが可能となります．
このようにBasic認証におけるアプリケーションからのAPIアクセスのフローと比較すると、OAuth認可には様々なメリットがあると考えられます．
また次にOAuthのデメリットについて考察していきます．
先ほどのOAuth認可のフローにおいて、アプリケーションは最終的に認証が必要なAPIの呼び出しを行うためにアクセストークンをTwitterなどのサービスプロバイダから受け取りますが、仮にこのアプリケーションが悪意のあるものであったとします．この場合、OAuthには以下のようなデメリットが存在すると考えられます．
・アクセストークンを取得しているため、ユーザーになりすまして他の任意のOAuth認証(ソーシャルログイン)対応のアプリケーションにログインされたり、勝手にサービスプロバイダのAPIの呼び出しが行われる(トークン置き換え攻撃)
悪意のあるアプリケーションは他のImplicit Flowで実装されたブラウザを使って、他の任意のOAuth認証対応のアプリケーションにログインしようとします．悪意のあるアプリケーションに利用されるブラウザは他の任意のOAuth認証(ソーシャルログイン)対応のアプリケーションにログインする際に、認証サーバから攻撃者用のアクセストークンをもらいますが、このアクセストークンは渡さずに代わりに以前に必要なAPIの呼び出しを行うためにサービスプロバイダからもらったユーザーのアクセストークンを渡します．ここで他の任意のOAuth認証(ソーシャルログイン)対応のアプリケーションが渡されたトークンが本当は以前に利用したアプリケーション用のものだと認識する手段はなく、自分向けのものとして受け取ってしまいます．そしてそのアプリケーションはサービスプロバイダにアクセストークンを渡し、その結果攻撃者はユーザーになりすまして他の任意のOAuth認証(ソーシャルログイン)対応のアプリケーションにログインしてしまいます．
また手に入れたアクセストークンは他のImplicit Flowで実装されたブラウザでも利用できるため、ユーザーになりすまして勝手にサービスプロバイダのAPIの呼び出しが行われ、例えばTwitterの場合だと悪意のあるURLが貼られたツイートが勝手に投稿されてしまう恐れがあります．
このようにアクセストークンを悪意のアプリケーションに渡してしまうと、「トークン置き換え攻撃」により攻撃者がユーザーになりすまして別のアプリケーションにログインできたり、勝手にサービスプロバイダのAPIの呼び出されてしまうといったリスクがあるというデメリットがあると考えられます．
応募するにあたって参考にした本
「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか
- 作者: 小森裕介
- 出版社/メーカー: 技術評論社
- 発売日: 2010/04/10
- メディア: 大型本
- 購入: 57人 クリック: 1,242回
- この商品を含むブログ (35件) を見る
- 作者: 竹迫良範,和田卓人,おにたま,中島聡,角田直行,はまちや2,上谷隆宏,青木俊介,大塚知洋,生尾剛士,大和田純,永安悟史,馬場俊彰,久保達彦,白土慧,じゅんいち☆かとう,太田昌吾,小野修司,ミック,嶋田裕二,個々一番,みやけん,清水亮,WEB+DB PRESS編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2011/06/24
- メディア: 大型本
- 購入: 20人 クリック: 434回
- この商品を含むブログ (22件) を見る
Golangのgorutineとchannelについて
Go言語の醍醐味であるgoroutineやchannelについて、自分なりの理解の確認のために書いていこうと思う．
goroutineについて
goroutineとは「Goのランタイムに管理される軽量なスレッド」である．
go f(x , y)
みたいに関数の前にgoキーワードをつけて呼び出せば簡単にgoroutineを作れる．
要するにgoroutineとは「並行に動作している関数」のことでしょう．
Go言語の特徴として挙げられる機能の1つに、「*1並行処理を書くのが簡単」というものは恐らくここから来ている．
channelについて
channelとは「goroutineとgoroutineの間でデータの受け渡しをするGo特有のデータ構造」...らしいです．
すいません、正直channelについてはあまり実感として理解していません...．
調べていくうちに参考になりそうなサイトが見つかったので、実際にサイトを見ながら手を動かしていって理解を深めていこうかと思います．
参考資料↓
*1:ちなみに並行処理とは同時にいくつかの質の異なることを扱うことであり、並列処理とは同時にいくつかの質の同じことを行うことらしいです．
Golang公式チュートリアル「A Tour of Go」を一周してきた感想
お久しぶりです．Capr1です．
Go言語を勉強しようと思い、Golang公式チュートリアル「A Tour of Go」を一周してきたので、その感想を(なんか書きたくなったので)書いていこうかと思う．（唐突）
「A Tour of Go」を一周してきて
全体の流れとしては、前半ではGo言語の基本的な文法を演習問題を解いていきながら学んでいき、後半ではgoroutineやchannelといったGo言語の醍醐味といった部分について触れていくといった感じでした．
そしてこの演習問題、後半に進むほど正直かなり難しくなっていきます．
最初の方はすんなり解けたのですが、後半になるにつれ、中々解けず、ネットで解き方を調べたり、解説や模範解答を見てウンウンとうなりながら理解していき、なんとか最後までやり遂げることができました．(結局の最後のWebCrawlerのやつはよくわからなかった...)
演習問題を解いていくにあたって(たしか)参考にしたサイト↓
やっていきたいこと
自分はゲームが好きで、今まで、そして現在もゲームをかなりプレイしているので、自分がプレイしてきたゲームを管理できるWebアプリケーションを作りたいと考えています．
また研究室の先輩に「GoのWebフレームワークで、軽いやつならgin、フルスタックなやつならrevelがオススメだよ〜」とのアドバイスを受けたので、サーバー構築の際にginやrevelといったGoのWebフレームワークも使いこなせたらいいなと思っています．
あとは簡単なSlackBotとかLINEbotとかも良さそう．
https://github.com/gin-gonic/gin
Goで何か作ったら、また記事を書こうと思います．
以上です．それではまた会う日まで ﾉｼ
SECCON Beginners 2018東京に行ってきたお話
もう３週間前のことだけど、SECCON Beginners 2018東京というCTF初心者向けのイベントに参加してきました．
自分が所属している研究室の先輩に「こういうイベントあるけど、興味あったら参加してみなよ」的なことを言われ、元々ハッキングといったセキュリティの攻撃側の技術には興味があったのでとりあえず行ってみようかなー的な感じで応募したら、まさかの当選で、その時は嬉しさと期待で胸が一杯だった．
がその一方で、ガチ初心者の僕が今回のイベントのレベルについていけるのかという不安もあった．が、周りの人も僕と同じように、CTFやるの初めてという人も多かったし、今回のイベントではCTFの演習の前にCTFのCryptoとpwnについての講義が行われたのだが、その講義の中で運営をしている人が丁寧に解説してくれたり、分からないことがあったらすぐに教えてくれたおかげで、初心者の僕でもついていけた．
最初の講義ではCryptoについての講義だった．この講義では、暗号全般の話、公開鍵暗号に使われている数学の知識だったりの解説が中心だった．数学が好きだったので、実際にペンと紙で素因数分解を行ったり、逆元を求めたり、鍵や暗号文、平文を求めたりするのは楽しかった．また講義の最後ではpythonの暗号処理ライブラリを紹介していて、こんなライブラリもあるのかとpython初学者の僕にとっては勉強になった．
次の講義はpwnについての講義だった．なおpwnについての講義はBeginners史上初の開催だったらしい．この講義の内容はpwnとは何かの解説、BufferOverflowについての解説、またそれをついた攻撃を仮想環境を用いて実際にやってみようというものだった．演習ではアセンブリ言語が多く出てきたり、慣れないLinuxの操作や攻撃用のコードを書くところなどで色々苦戦したが、解説を聞いたり分からないところを運営の人に聞くなどして何とか講義についていった．実際に攻撃用のコードを書いてリモートのシェルコードを実行できたりするとハッカーの気分になれて、講義の内容自体は難しかったがとても楽しかった．
そして講義が終わった後はCTFの演習が行われた．演習が始まってからは初めてということもあってか、何がなんだか分からず色々テンパッてしまった．が落ち着いてからは色々ググりながら問題を解いていった．結果的にはCryptoの問題は４問中２問、Miscは１問解けて、pwnは一問も解けなかった．
ちなみにスコアは300、順位は62位(121人中)だった．
今振り返ってみると、pwnの一番簡単な問題を解けなかったのと、SimpleRSAはもう少し時間があれば解けたから、そこらへんが悔しかった．実際演習の後で行われた懇親会で、運営の人と話す機会があったのだが、pwnはアセンブリの知識がないと難しい的なことを言っていたので、まあしょうがないのかなーとは思っている．次は解けるようにしたい．
CTFの演習を通して、確かにCTFは難しいけど、解けた時の喜びはとても大きいものだと感じた．(実際問題が解けた時は心の中で(よっしゃー(ﾟ∀ﾟ))的な感じでガッツポーズしてました笑)
イベントの後、CTFについて色々調べてみたらこんなCTFの紹介サイトを見つけた．
このサイトの記事の中でCrypto、暗号に関する参考文献や問題を見つけたので、これから取り組んでいきたい．
あとWebにも興味があるから、もしWebのCTFが開催されるなら行ってみようかなーと思っている．
以上SECCON Beginners 2018東京に行ってきたお話でした．運営の方々、お世話になりました．
このブログについて
本ブログ「Capriの日々」は都内の某私立大学に通う情報系大学生Capr1(カプリ)の技術的な活動や記録を綴っていくブログだ．（たまに関係ないことも書くかも笑）
また自分はこういった文章を書く経験が浅く、本もほとんど読まないため、所々で間違った言葉の使い方や稚拙な文章が見られるところもあるかもしれないが、そこのところはご了承願いたい．
