OAuth Danceとは
- 認可コードフロー、インプリシットフローではクライアント・認可サーバ間で何度も情報のやりとりが行われるが、その様子を指す
OAuth Danceの中で認可レスポンスが狙われる理由は3点
- 認可コード、アクセストークン、IDトークンなどの情報がURIの中に含まれている
- 認可サーバ、クライアント間の情報のやり取りの間にブラウザのリダイレクトを介している
- 認可サーバ・IDプロバイダによるリソースオーナー(エンドユーザー)の認証・同意処理が完了済み
上記のやりとりへの攻撃として5種類の攻撃がある
- CSRF
- リプレイスアタック
- コードインジェクション
- トークンインジェクション
- 認可コード横取り攻撃

第2章 CSRF

認可サーバーでは state に対して何の検証も行わない。state の検証を行うのはアプリであることに注意
state を使うことで CSRF を防ぐことができる
state により認証リクエストのセッションと認証レスポンスのセッションが同一であることを検証できる
OAuthは仕様でstateの利用は任意になっているため、ライブラリやフレームワークを利用する際は事前にstateの検証が正しく行われるかチェックが必要
セッションごとにstateを生成しなければならない
推測困難なランダムな文字列を state として使う
認可レスポンスのセッションと state の紐付けを確認する
state が含まれていない認可レスポンスはエラーで返す
OAuth 2.0 Security Best Current Practice
- https://tools.ietf.org/id/draft-ietf-oauth-security-topics-13.html

第3章リプレイス攻撃

第三者のIDトークンを攻撃者自身の管理下にあるアプリに適用
攻撃対象のフロー
- インプリシットフロー
- ハイブリットフロー
nonce - number used once
リプレイス攻撃を可能にしてしまう原因は、同じIDトークンを他のデバイスのアプリ上で利用できてしまうこと
IDトークンの検証完了後、nonce を無効化する

第4章認可コード横取り攻撃

同じデバイスにインストールされた「同じカスタムスキームを持つアプリ」に認可コードを奪われる。結果、アクセストークンを取得される
対象は、OAuth, OIDC
攻撃対象は、認可コードフロー、ハイブリッドフロー(response_typeにcodeを含むもの)
攻撃を可能にしているポイントが同じカスタムスキームであること
PKCE
- code_verifier
  - 長さ43文字、最大128文字までの間の[A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" / からなるランダム文字列
- code_challenge
  - code_verifierに対して code_challenge_method の計算をほどこして算出された値
- code_challenge_method
  - plain
    - code_challenge = code_verifier
  - S256
    - code_challenge = BASE64URL-ENCODE( SHA256 (ASCII( code_verifier ) ) )
認可サーバで、code_verifierの検証が行われる

第5章トークンインジェクション

第三者の有効なアクセストークンを攻撃者自身の管理下にあるアプリに適用
攻撃対象は、OAuth、OIDC
OAuthには対策がない(独自対応しているサービスはある)
at_hash <- access token hash?
- IDトークンに含まれるクレームの１つ
IDトークンには2つの役割がある
- 認証アサーションとしての役割
- デタッチ署名としての役割
認証レスポンスのアクセストークンの情報を、ペイロードに含めることで、アクセストークンの署名としても機能する
ペイロードには「IDトークンの署名と同じハッシュアルゴリズムでアクセストークンのハッシュ値を算出し、その左半分をBase64URLエンコードした文字列」を at_hashの値に入れる
取得したアクセストークンに対して、上記で算出したat_hashの値とIDトークンのペイロードに埋め込まれたat_hashの値を比較することで入れ替えに気づくことができる
インプリシットグラントは使わず、認可コード + PKCE
フラグメントはリダイレクト時にその情報がサーバに送られないため、漏洩のリスクが下がる
コラム: トークンはどこからもれるのか？が面白い p.66

第6章コードインジェクション

第三者の未使用の認可コードを攻撃者自身の管理下にあるアプリに適用
攻撃対象は、OAuth、OIDC
PKCE・nonce・c_hash(code hash?)による対策が書かれている
OAuthの仕様では認可コードは有効期限が短く、一度しか利用できないため、利用されていない許可コードを取得した上で、短い有効期限内に攻撃を完了する必要がある
コードインジェクションを防ぐために、アプリは「」セッションとcode_verifierの紐付け」を管理し、認可サーバは「code_challengeと認可コード(code)の紐付け」を管理する必要がある
コードインジェクションを防ぐために、アプリはセッションとnonceの紐付けを管理し、IDプロバイダはnonceと認可コード(code)の紐付けを管理する必要がある
c_hashが利用できるのは、response_typeの値にid_tokenとcodeの両方が含まれるハイブリッドフロー
c_hashは、「IDトークンの署名と同じハッシュアルゴリズムで認可コードのハッシュ値を算出市、その左半分をBase64URLエンコードした文字列」
- 認証レスポンスで取得した認可コードに対して、上記と同じ演算を行い、同じく認証レスポンスで取得したIDトークンのc_hashの値を比較することで認可コードの入れ替えに気づくことができる

第7章全体整理

認可フローやクライアントの種別に応じて、攻撃の種別や対策方法がまとめられている
ハイブリットフローでのパラメータ共有について p.106

2021-05-09

『OAuth、OAuth認証、OpenID Connectの違いを整理して理解できる本』を読んだ

Book

目的

前作に続いて、OAuthとOpenID Connectの違いを理解したくてこの本を読みました。

techbookfest.org

感想

こちらも前作に続き分かりやすく解説されていて、かつサクッと読めます！

タイトルにもあるように、OAuth、OAuth認証、OpenID Connectの違いが整理して書かれているため、OAuthと比べてどこがどう違うのか上手く説明してくれています。

第2章でOAuthの復習の章を設けられていますが、個人的には前作の『雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本』を理解した後にすぐ読んだほうがより理解がしやすいのかなと思います。

techbookfest.org

あと、個人的にコラムは絶対読み飛ばさないほうが良いです！

OAuthの脆弱性やアプリのログインに脆弱性があった場合にどうやって攻撃されるのかが説明されているので、読み物としても面白いですし、実際にこうやって攻撃されるのかとOAuth認証やOIDCへの理解も深まると思うので。

読書ノート

OAuth認証
- アプリはプロフィールAPIで得たユーザー識別子の情報などを利用して、ユーザーの認証が可能になる
- OAuth認証、アプリのログイン実装の脆弱性についてのコラムが面白い - p29
- Facebookではなりすましログインへの対策に /debug_tokenエンドポイントという独自エンドポイントを用意している
OpenID Connect(OIDC)
- OAuthに IDトークン・UserInfoエンドポイントを加えたものを言う
- IDトークンはユーザーの認証に利用
- UserInfoエンドポイントはユーザーのプロフィール情報を得るために利用
- OAuthとOIDCのロール関連用語に違いがある - p36
OIDCのフローは3つ
- 認可コードフロー
- インプリシットフロー
- ハイブリッドフロー
  - インプリシットフローと認可コードフローのハイブリッドなフロー
  - パブリッククライアントとコンフィデンシャルクライアントの両方で構成されているクライアントに利用する
    - JavaScriptアプリ・ネイティブアプリ + バックエンドサーバー
OIDCでは scopeの値は仕様で決まっている
OAuthとOIDCの一番のち外はフローにおいて、IDトークンの発行が行われること
デタッチ署名とは、署名の対象と署名が分離した形式の署名のこと

2021-05-09

『雰囲気でOAuth2.0 を使っているエンジニアが OAuth2.0を整理して、手を動かしながら学べる本』を読んだ

Book

目的

OAuth2.0への理解を整理したい思い読みました。

techbookfest.org

感想

タイトルにもあるように雰囲気でOAuth2.0を使っている人やとりあえずOAuth2.0って何？って人にすごくおすすめです！

分かりやすいし、安い！

1~5章は、OAuth2.0とは何か？から始まり、OAuthの各グラントタイプごとにクライアントがどのような流れでトークンを受け取るか分かりやすく説明されています。

本自体は100ページ程度ですが、OAuth2.0の説明自体は60ページほどで1時間弱あればゆっくり読んでも読み終わるので、すごく良くまとまっているなと思いました！

個人的に、パブリッククライアント向けのグラントタイプとして推奨されている、「認可コードグラント+ PKCE」は知らなかったので勉強になりました！

6章は、実際にGoogleのPhoto Library APIを用いてOAuth2.0を手を動かしながら学べます。

1~5章で学んだ内容を実際に手を動かして復習できるので、理解も深まりやすいです。

OAuth2.0の説明を読んでよく分からなければ、まず6章の内容に従い手を動かしてから読むと良いかも知れません。

読書メモ

認可エンドポイントとトークンエンドポイントは、認可サーバが提供するURI
リダイレクトエンドポイントはクライアントが提供するURI
トークンエンドポイントではBasic認証によって、クライアントのアイデンティティが確認される
Basic認証としてAuthorization ヘッダーに設定されるのは、クライアントID とクライアントシークレット
- これらは認可サーバーにクライアントを事前登録する際に発行される
OAuthのグラントタイプ
- 認可コードグラント
- インプリシットグラント
  - 非推奨
- クライアントクレデンシャルグラント
- リソースオーナーパスワードクレデンシャルグラント
リソースオーナーパスワードクレデンシャルグラントを利用できるのは、リソースサーバーおよび認可サーバーとクライアントの提供元が同じ組織である場合
- クライアントタイプがコンフィデンシャル、パブリックの両方で利用可
PKCE は「Proof Key for Code Exchange」の略で「ピクシー」と読む

2021-04-19

2021年4月12日 ~ 18日振り返り

振り返り

先週の振り返りです。

仕事

Play2.6 Migration

先々週から引き続きPlay 2.6 Migration作業を行っていました。

ほぼほぼMigration Guideの項目は対応し終わっていましたが、以下の対応を行っていました。

deprecatedになったメソッドの修正
warningが出ているコードの修正
Unitテストの修正
各プロジェクトのビルド・テストがCI上でALL Greenになるように修正

ほぼ一人で作業(ときどき同僚に相談乗ってもらった)だったので、なかなか根気のいる作業でしたが、無事完了できました！

あとは、検証環境で動作確認・数週間運用後に本番リリースを行う予定です。

AWS Lambda ランタイムのアップデート作業

会社の部内のプロジェクトでいくつかで使われているサービスがあり、それをだいぶ前に保守作業を移譲されて自分が担当しています。

今回、AWS Lambdaのnode.js10.xが2021年7月30日から「サポート終了フェーズ 1 」が開始されるとのことで、対応しておいたほうが良いということで着手しました。

(あれ、自分が読んだときは2021年5月末までだったけど変更された？)

docs.aws.amazon.com

Lambdaのランタイムのアップデート自体は結構すぐ対応できたのですが、ランタイムとは関係ない部分で一部エラーが発生しているのに気が付き、修正作業を行いました。

結構前に書かれたコードなのでライブラリのバージョンも上げたり、もっというとコード自体を書き直したりしたいところですが、機能が追加されたりするサービスではなく基本的に安定して稼働しているサービスなので着手できていないのが現状です。

ここらへんも保守・運用しやすいように細かいアップデートをしていきたいところです。

プライベート

ブロクにも書きましたが、4/16 (金) にAWS DevOps Engineer - Professionalに合格できました！

blog.ryskit.com

これであとはSpecialtyの資格をどんどん取っていくだけですが、ひとまずAWS以外のことも学びたいので資格勉強はGW明けまでお休みです。

今月の自分の課題図書にした「Akka実践バイブル」をあまり読み進められてなかったのでここらへんでスピード上げて読み進めていきます。

読書

2021-04-17

AWS DevOps Engineer - Professionalに合格した

AWS 資格 AWS Certified

2021年4月16日(金)にAWS DevOps Engineer - Professional(DOP)の試験に合格しました！

f:id:ryskit:20210416223019p:plain

学習期間

学習期間は2週間で、1週間は試験範囲に出るAWSサービスのドキュメント等を読みさらっと流して、最後の1週間で模擬試験など受けて集中的に学習しました。

学習内容

まずはDOPの試験ガイドを読んで、出題範囲のAWSサービスのドキュメントを読みました。

AWS公式 DevOps Engineerの試験ガイド

ドキュメントにある程度目を通したら、Udemyで販売されているTutorials Dojoの模擬テストを一通り受けました。

www.udemy.com

模擬テストを受けるとだいたいの出題されるAWSサービスの範囲が分かるのと、解説を読めばこのAWSサービスで何を解決できるのか、詳細を把握できるかと思います。

模擬試験1回目は理解が深まってない状態で受けるのでスコアは悪かったんですが、そこは気にせず2、3回同じ模擬試験を受けて自分はどこを間違ったのかを把握したのが良かったのかなと思います。

間違った問題は正解の解説だけでなく、間違った選択肢の解説もちゃんと読んでおくと、自分のAWSサービスへの理解と実際のAWSサービスの挙動のズレを正せると思います。

また、解説にはAWSサービスのドキュメントリンクがだいたい記載されているので、それらはすべて隅々まで目を通すのが良いと思います。

余談

以前にAWS Security - Specialtyの試験を受験したときに勉強したAWSサービスががDOPの出題範囲と少し被っていたのがすごくラッキーでした。

領域別に試験があるとはいえ、重要なAWSサービスはいろんな試験に出題されるため、何回もドキュメントを読むことになるので理解が深まりやすいのが良いところです。

試験当日

試験日はいつもどおり7:30に起きて早めに試験会場の近くのスタバでコーヒーでも飲みながら、自分でまとめたAWSサービスの要点などを復習します。

試験前なので、水分を取りすぎてトイレに行きたくならないように気をつけました。笑

基本的にProfessionalの試験の問題文は長いし、日本語がかなり読みづらいので試験時間ギリギリまで使いました。

ちょっと不安だなと思った問題に対しては見直しフラグを立てて問題を解き進めて最後に見直すのが良いと思います。

1問1問時間掛けていると最後までたどり着けない可能性があるので、そこは気をつけたいところです。

次は？

社内にはAWS資格12冠を達成している人たちがゴロゴロいるのですが、それに追いつけるように2週間~1ヶ月に１つのペースでAWS試験を受けたいと思っています。

次は、AWS Database - Specialty(DBS)を受けようかなと考えています。

まだ6冠しか取得できていないので、あと最低5回も試験を受けないといけないのは憂鬱ですが頑張っていくぞ！

www.credly.com

話は変わりますが、6月にDBS関連の書籍が発売されるみたいです。発売されるまでには自力で勉強して合格していきたいところ！！

要点整理から攻略する『AWS認定データベース-専門知識』

それではまた！

2021-04-12

2021年4月5日 ~ 11日振り返り

振り返り

先週の振り返り。

仕事

先々週に引き続き、Playframework 2.6のMigration作業を行いました。

Play 2.6に移行したことでdeprecatedになったメソッドがいくつもあり、テストを実行するとwarnログが出力されてXXかYYに置き換えろと怒られるので、ひたすらそれらを修正する作業です。

ただ、素直に置き換えるとテストが動かなくなったりするので、今度はテストを修正するという作業を行ったり来たりしていました。

なかなか根気のいる作業だなとは思いますが、どういう仕組みでフレームワークが動いているかを改めて勉強する良い機会にもなりますし、自分たちのアプリケーションへの知見を深める良い機会にもなります。

マルチプロジェクトで構成されていて、テストが完全には通ってないので次のスプリントでも対応が必要そうです。

プライベート

4/16 に AWS DevOps Engineer - Professional の試験が控えているので、勉強しつつ面白そうな勉強会にオンラインで参加していました。

もう少し読書したりしたいですが、今は試験勉強に集中！

2021-04-05

2021年3月29日 ~ 4月4日振り返り

振り返り

先週の振り返り。

仕事

先週は、Play 2.6へのMigration作業を行いました。

機能開発ではなく改善タスクに多くの時間が割ける今、フレームワークのバージョンが古いものを上げていこうとチームで動いており、先々週あたりにPlay 2.4 から 2.5 に上げて問題がなかったので、2.6 にも上げてしまおうという流れです。

ただ、Play 2.5 から 2.6 へのMigrationに関して、Migration Guideを読んでもらうと分かるのですが変更点がかなり多いです。 www.playframework.com

play-jsonがライブラリとして切り出されたり、Akka Httpがサーバのデフォルトになったりと既存のコードに影響するものが多く、「コンパイルが通らないから通るように修正 → テストが通らない → 修正すると他でエラーが出る → 修正する」みたいなサイクルをぐるぐる回していました。

今のプロジェクトに入ってから機能追加や修正をやっていましたが、Play自体にあまり詳しいわけではありません。今回2.6へのMigration作業を通してPlayFramework周りの知識を深められればなと思って作業しているので、かなり楽しく作業を進めれています。

先週だけでは終わる量ではなかったので、次のスプリントでも作業することになりそうです。

Migration作業について

アプリケーションフレームワークのMigrationは、Migration Guideがある場合はそれらをチェックシートにして作業を１つ１つ進めるのが良かったです。

というのも、変更内容が多い場合にいくつも修正作業を同時に進めてしまうと、どれがどこまで進んだのか進捗管理が難しくなってしまいます。また、修正作業の抜け漏れも発生しやすい状態になってしまうからです。

また、Migration作業を進めるに当たり作業ログも逐次書いていくと良いと思います。

作業ログがあると時間が空いてしまった場合にも思い出しやすいですし、作業を誰かに引き継ぐ場合にもここまでこういう内容で進めたと共有しやすくなるからです。

プライベート

注文していたOura Ringが届いて、最近コンディションや睡眠の数値を改善する活動にハマっています。

睡眠時の何が悪いのかを具体的な指標で示してくれるので、改善するポイントが分かりやすいのが気に入っています。

Amazonで買うと5万以上しますが公式サイトで注文すると3万弱で買えるので、もし検討されている人は公式サイトで買うことをオススメします！

ouraring.com

やったこと

AWS DevOps Engineer資格勉強
アルゴリズム実技検定公式テキスト 6.3 幅優先探索と深さ優先探索まで

読書

入門監視

入門監視 ―モダンなモニタリングのためのデザインパターン

作者:Mike Julian
発売日: 2019/01/17
メディア: 単行本（ソフトカバー）

先週は「入門監視」を読みました。もっと早く読んでおけば監視の仕組みを作る際に参考になったのになと思いながら読んでました。

監視のアンチパターンやデザインパターン、良いアラートの仕組みなど、監視についてギュッと濃い内容でまとまっています。

あと、付録Cとしてsongmuさんが書かれた実践監視SaaSも非常に勉強になりました。

3章には「良いアラートの仕組みを作る6つの方法」について書かれているのですが、その１つに「アラートにメールを使うのを止める」というのがあります。

アラートの使い道は以下の3つに集約されると書かれています。

- すぐに応答かアクションが必要なアラート
    - SMSなどに送る
- 注意が必要だがすぐにアクションは必要ないアラート
    - 社内チャットに送る
- 履歴や診断のために保存しておくアラート
    - ログファイルに送る

お客様とチームで使っているDataDogのアラートがメールとSlackに送られており、特にメールの量が多すぎるので注意力が削られている原因にもなっているので改善の余地があるなと感じました。

監視アンチパターン
- ツール依存
- 役割としての監視
- チェックボックス監視
- 監視を支えにする
- 手動設定
監視デザインパターン
- 組み合わせ可能な監視
- ユーザ視点での監視
- 作るのではなく買う
- 継続的改善
良いアラートの仕組み
- アラートにメールを使うのを止める
- 手順書を書く
- 固定の閾値を決めることだけが方法ではない
- アラートを削除し、チューニングしよう
- メンテナンス期間を使おう
- まずは自動復旧を試そう

2021-03-31

2021年3月22日 ~ 28日振り返り

振り返り

先週の振り返りを書きます。

仕事

あるキャッシュを作成するLambdaの処理時間がほんの少しではあるが遅くなってきていました。

キャッシュのもとになる取得先のデータ件数が徐々にではあるが増えていてそれが原因です。

処理時間が遅くなって問題が顕在化しないうちに、このキャッシュを作る処理内容やアーキテクチャをどうするべきか検討するというPBIに着手しました。

PBIを着手するにあたって問題だと感じたのは、「問題がそもそも整理されていなかった」ことです。

というのも、PBIのタイトルには「Lambdaのリファクタリングの調査」というようなタイトルで、内容には「Aに変更したらどうか？」のような感じに記載されていて、そもそも問題は何か・なぜそれが問題なのか・Lambdaのリファクタリングで問題が解決するのか、といった着手するのに必要そうな情報が不足していると感じました。

PBIを作成する場合には、自分以外の人が着手することを念頭に置き、タイトルは完結で分かりやすく・内容はそのPBIの問題やなぜやるのか？ということを明確に記述した方が確実に効率が良いなと学びがありました。

問題の内容だったり、なぜやるのか？というのを書くのは時間が掛かることかもしれないですが、書くことでチーム全員が把握できるし、何度もPBI作成者に書いた内容の意図などをヒアリングすることも省けるかもしれないので、丁寧なPBI作成を心掛けたいと思います。

プライベート

以下の記事にも書きましたが、2021/3/26 (金) に「AWS Solution Architect - Professional」に合格しました！

blog.ryskit.com

正直、試験中は問題を解きつつも自信は持ててなかったので、再試験か。。。と落ち込み気味でしたが、試験を終了したら「合格」の文字が見えて思わず「っっしゃ！」と会場で声が出ちゃいました。笑

ひとまず、SAPの試験勉強は終わりましたが、今度は「AWS DevOps Engineer - Professional」取得目指して頑張ろうと思います。

あと、初めて生牡蠣食べて当たりました。笑めちゃめちゃ苦しいので、生牡蠣食べる前は覚悟した方が良いなと思いましたw

やったこと

アルゴリズム実技検定公式テキスト[エントリー~中級編]
- 5章基礎的なアルゴリズムまでの問題を解いてみました。

アルゴリズム実技検定公式テキスト[エントリー~中級編] (Compass Booksシリーズ)

作者:岩下真也,中村謙弘
発売日: 2021/02/27
メディア: 単行本（ソフトカバー）

2021-03-26

AWS Solution Architect Professionalに合格した

AWS 資格 AWS Certified

2021年3月26日(金)にAWS Solution Architect Professional(SAP)の試験を受験し合格しました！

AWS Solution Architect Professional受かったーー🎉🎉🎉🎉
試験中まともに解けた自信がなくて再受験とか思ってたけど受かって良かったー😆
— 木田亮介 (@_ryskit) March 26, 2021

次のDOPの試験に向けて自分がやったことを整理しようと思います。

学習期間

学習期間としては、1ヶ月(ダラダラ) + 1週間(超集中)というところです。

正直ダラダラ試験勉強するぐらいなら、好きなことやってた方が良いです。無駄な時間の使い方をしたなと思い反省していています。

超集中した1週間は毎日5~6時間ぐらいは勉強していました。内容については後述します。

普段は夜更し気味だったんですが、試験一週間前はさすがに生活リズムを取り戻さないといけなかったので、12:30 ~ 1:00 には眠りにつくように心がけてました。

好きだったフォートナイトも試験直前はさすがに我慢しました笑

学習内容

以下の模擬試験を分からなくても良いのでとにかく解きまくりました。

模擬試験が終わると、解説と参考情報が出てくるので、それを読みつつAWSの公式ドキュメントも隅々まで確認するというやり方をしていました。

とにかく公式ドキュメントやFAQに書いてることは問題として出されても良い状態にまで持っていくのが良かったと思います。

模擬試験をやっていると自分が不得意なAWSサービスが分かってくるので、あとは理解できてない部分をひたすらドキュメントを読んで確認します。

僕の場合はDirect ConnectやActive Directory、Route53などのサービスをあまり理解できてなかったのでよく勉強していました。

Direct Connectに関しては実際にさわる機会もあまりないのでよく分からなかったですが、佐々木拓郎さんがブログでまとめてくださっていたのでこれを読んで理解していました。非常に助かりました！

blog.takuros.net

試験当日

10時から試験開始だったので、7:30に起きて試験会場近くのスタバで勉強のときにまとめたメモを見て最終確認をしていました。

注文したのはラテのトールサイズで、朝起きてからあまり水分を飲まずに行きました。これが非常に良かった！

というのも、前回受けたAWS SCSの試験のときは、ラテのグランデサイズを注文して、試験の後半トイレ行きたいしか考えられなかったからです。笑

今回はそのようなこともなく最後まで集中力を保ちながら問題を解くことができました。

まとめ

超集中して短期間で勉強し、睡眠はたっぷり取って、試験当日は水分をあまり取らずに試験に臨む！これだけ！

次は、AWS DevOps Engineer - Professionalを頑張るぞ！

なぜ買ったのか？

感想

目的

感想

読書メモ

第1章 OAuth・OIDCのおさらい

第2章 CSRF

第3章 リプレイス攻撃

第4章 認可コード横取り攻撃

第5章 トークンインジェクション

第6章 コードインジェクション

第7章 全体整理

目的

感想

読書ノート

目的

感想

読書メモ

仕事

Play2.6 Migration

AWS Lambda ランタイムのアップデート作業

プライベート

読書

学習期間

学習内容

余談

試験当日

次は？

仕事

プライベート

仕事

Migration作業について

プライベート

やったこと

読書

入門 監視

仕事

プライベート

やったこと

学習期間

学習内容

試験当日

まとめ

第3章リプレイス攻撃

第4章認可コード横取り攻撃

第5章トークンインジェクション

第6章コードインジェクション

第7章全体整理

入門監視