OAuth徹底入門の読書感想文 -10章-
OAuth徹底入門を読んだので感想と概要を書いていきます
9章については先日書きました
今回は10章についてです
10章 よく狙われるOAuthトークンの脆弱性
Bearerトークンとは
OAuth2.0ではBearerトークンをセキュリティを担保する仕組みとして使う
Bearerトークンはトークンの所有者が誰であれ、そのトークンをリソースへのアクセスのために使用することができる
(ちなみにBearerとは持参者とかいった意味)
OAuthのBearerトークンに関した脅威には以下のものがある
- トークンの偽造 (Token Forgery)
- トークンのリプレイ (Token Replay)
- 攻撃者がトークンの有効期限がきれてしばらく経ってから再利用しようとしてくる場合がある。リソース・サーバーはその際エラーを返さなければならない
- トークンの流用 (Token Redirect)
- 攻撃者はあるリソース・サーバーで生成されたトークンを別のリソース・サーバーへ送信する場合がある
- トークンからの漏洩 (Token Disclosure)
- トークンはシステムに関する機密情報を含んでいることがある、攻撃者に情報を見られてしまう場合がある
Bearerトークンをどのように保護するか
- 安全ではないチャネル場で送らせない
- クライアント側ではトークンのもつスコープを必要最低限に絞っておく
- 認可サーバーではアクセストークンをハッシュ値でもつ、トークンの有効期限を短くする
- 保護対象リソースではトークンをログに残さない、なんでもできるような特別なアクセストークンを使用しない
感想
ついにBearerの意味がわかった (調べろって話なんだが、、)
トークン自体はただ保護対象リソースに提示されるものなので、７、８、９章で説明されてたクライアントや認可サーバーや保護対象リソースがどのようにトークンを守るかという話とかぶる部分は多かった
OAuth徹底入門の読書感想文 -9章-
OAuth徹底入門を読んだので感想と概要を書いていきます
8章については先日書きました
今回は9章についてです
9章 よく狙われる認可サーバーの脆弱性
認可サーバーはOAuthの構成要素の中でも最も複雑
ユーザーとのやりとりを行うWebサイトと、マシンとのやりとりを行うAPIの両方を提供しており、以下に述べるような一般的なセキュリティがまず求められる
- サーバーのログを安全にする (クレデンシャルなどをログに出さない)
- TLSを有効な証明書と共に使う
- 適切なアカウントのアクセス制御をする
また、OAuthにおける認可サーバーとしては以下のことに気をつける必要があります
セッションの乗っ取り
問題
認可コードによる付与 (Authorization Code Grant)を行なっている認可サーバーの場合、認可サーバーは生成した認可コードをURIのリクエスト・パラメータに含め、リダイレクトを使ってそれをクライアントへ運ぶようにする
この際、認可コードはブラウザを経由してクライアントへ運ばれるため、ブラウザ履歴に残ってしまう
もし共用のパソコンで作業をしていた場合、たとえ自分は作業が終わった段階でログアウトしても後からきた悪意あるユーザーが自分のID、パスワードでログインし、履歴に残っていた認可コードを使って認可サーバーへ注入したとすると、最初に認可コードを取得したリソース所有者のリソースにアクセスできるようになってしまう
対策
OAuthの仕様ではこうした自体を防ぐため、一度認可コードがトークンとの交換に使用されたらその場で認可コードを削除するようにしている
そうすることで、認可コードは認可サーバーに一度しか受け入れられなくなる
リダイレクトURIの不正操作
問題
OAuthではredirect_uriの検証方法については完全に認可サーバーに一任されている
認可サーバーは一般的に3つの検証アルゴリズム (完全一致、サブディレクトリの許可、サブドメインの許可)のどれかを使ってredirect_uriの検証を行う
サブディレクトリやサブドメインを許可していると、もし攻撃者がクライアント・サーバー内に悪意あるページを作成できた場合、redirect_uriを操作して認可コードやアクセストークンを持ったままユーザーを攻撃者の悪意あるページにリダイレクトすることができてしまう
対策
とてもシンプルだが、認可サーバーが利用すべき唯一の安全なredirect_uriの検証方法は完全一致である
オープン・リダイレクトによる脆弱性
問題
オープン・リダイレクトとは未検証のリンクへリダイレクトしてしまうことで悪意あるページにユーザーを遷移させてしまう脆弱性
たとえば、攻撃者が新しいクライアントを認可サーバーへ登録し、redirect_uriを以下のような特殊なものにしておく
https://hogehoge/fugafuga/authorize?response_type=code?client_id=attcker-client-id&scope=WRONG_SCOPE&redirect_uri=https://attacker.com
攻撃者はこのような不正な認証を行うリクエストのURIを作成しておくことで、正当なクライアントを攻撃者のサーバーにリダイレクトすることができる
対策
リクエストの処理でエラーが起こった際はリダイレクトするのではなく、400 Bad Requestを返すことでオープン・リダイレクトによる脆弱性をなくすことができる
感想
ちょっと難しかった
攻撃者、攻撃者のサーバー、攻撃者のクライアント、ユーザー、クライアント、認可サーバーなど登場する役が多いのでちょっと自分の頭の中でも整理しきれてない感じはする
ただやらなきゃいけないことはシンプルで明白なので実装時には心がけていこう
OAuth徹底入門の読書感想文 -8章-
OAuth徹底入門を読んだので感想と概要を書いていきます
7章については先日書きました
8章 よく狙われる保護対象リソースの脆弱性
この章ではどのようにリソース・サーバーを保護し、OAuthの保護対象リソースを対象とした攻撃からどのように守るかについて説明されています
保護対象リソースの脆弱性とは
最も明白なものはアクセストークンの漏洩
そのほかにもエンドポイントへのXSSなどがある
XSSへの対策
エンドポイントへのXSSを防ぐには
- ユーザーの入力を直接レスポンスに含むなど、信頼できないレスポンスを返す場合は全てサニタイズする
- URLエンコードする
- 正しいContent-Typeを返すことでJavascriptの実行を防ぐ
- ブラウザの提供する保護の仕組みを利用する
トークンのリプレイ攻撃への対策
アクセストークンが漏洩した場合、有効期限を短く設定しておけば被害を最小限にすることができる
また、OAuthでは様々な通信にTLSが使用されていることが前提とされている
HTTPの仕組みの一つであるHSTSを使用することで、HTTPSでの通信を使用することをサーバー側から指定することができる
感想
保護対象リソースはOAuthにおける役割も割とシンプルなので、セキュリティ面でもやることは少ない (レスポンスでXSSに気をつける、通信はTLSを使用するなど)と思った
ただ保護対象リソースに脆弱性があるとOAuthで頑張ってセキュアにしてもなんの意味もなくなっちゃうから重要だよな、、
Railsのコロンが2個並ぶやつ :: ←これ
短めです
Railsを読んでた時に、クラスを呼び出す際にコロン2つから始まる呼び出し方をみました
こんなやつ↓
::Foo::Bar
これってFoo::Barって書くのと何が違うんだろうと思って調べました
Foo::Barと書くと、ファイルのある階層の中でFoo::Barを探しますが、::Foo::Barとかくとパスのトップから見に行き、1番上にあるものを呼び出すそうです
OAuth徹底入門の読書感想文 -7章-
OAuth徹底入門を読んだので感想と概要を書いていきます
6章については先日書きました
7章 よく狙われるクライアントの脆弱性
この章ではOAuthクライアントを実装する際に注意するべき、狙われやすいポイントについて説明されています
クライアントに対するCSRF攻撃
CSRFについては以前記事を書きました
OAuthにおけるCSRFでは、攻撃者はあらかじめ認可サーバーから認可コードを取得し、偽造する
攻撃者は被害者を騙して、攻撃者が偽造した認可コードを被害者のクライアントが使用するように仕向ける
これにより、攻撃者の認可情報とクライアント・アプリケーションが結びついてしまう
対策としては推測できないstateパラメータを生成し、認可サーバーを呼び出す最初の手順でこれを渡す
クライアントはリダイレクトされた際にstateパラメータをチェックし、最初に送ったものと変わっていないか確認する
そうすることで、攻撃者の認可コードを使ったり、被害者のクライアントに注入したりすることを防ぐことができる
クライアント・クレデンシャルの不当な取得
ネイティブ・アプリなどのデバイスにインストールして使われるものは、内部にクレデンシャルを隠していてもデコンパイルされてクライアント・クレデンシャルが漏洩し、誰でもクライアントとして認可サーバーに認証されてしまう恐れがある
動的クライアント登録 (Dynamic Client Registration)を呼ばれる機能を使うと、OAuthのトークンのリクエストを行なった際にクライアント・シークレットが発行され、ネイティブ・アプリケーション中に最初からクレデンシャルが埋め込まれている状態を防ぐことができる
リダイレクトURIの登録
クライアントが認可サーバーにredirect_uriを登録する際にはできるだけ完全なURIを登録するべきである
下に良い例と悪い例を示す
// 良い例 https://foobar.com/oauth/oauthprovider/callback // 悪い例 https://foobar.com/
悪い例のようにドメインのみ登録したり、パスの一部しか登録しないと、容易にトークンの乗っ取りが可能になってしまう
もちろん認可サーバーもURIの完全一致のみ検証方法として用いるべきではあるが、サブディレクトリを許可するような設定になっていてもトークンが乗っ取られないように、リダイレクトURIは正しく記載しておく必要がある
認可コードの不正な取得
認可コードによる付与方式を狙った攻撃として多いのがHTTPリファラーを利用したもの
HTTPリファラーとはHTTPヘッダーのフィールドで、あるページから別のページに遷移する際にブラウザによって、どのURIから来たかという情報が記録されるもの
認可サーバーがリダイレクトURIにサブディレクトリを許可している場合、攻撃者はリダイレクト先にHTTPリファラーを有効にしたリンクを置いておきユーザーにクリックさせる
HTTPリファラーにはパラメータも一緒に参照できるため、認可コードが攻撃者から丸見えになってしまう
やっぱりリダイレクトURIは正しく登録しておく必要がある
感想
いろんな攻撃手法があるが、きちんとOAuthのやり方に則っていれば少なくともこの章で書いてあった攻撃は防げそうだと感じた
stateパラメータを使う、クライアントにあったフローを選ぶ、リダイレクトURIは完全に指定する、簡単だけど強力なセキュリティ
VS Code Meetup #2 - Live Share編に参加してきた！
以前参加したVS Code Meetupの2回目が1/23にMicrosoftのオフィスで開催されたので参加してきました！
1回目の様子は下の記事で書きました
VS CodeはGithubのossの中でで一番contributorの多いリポジトリだそうです
今回はLive Share編ということで、VS Codeの機能の１つであるLive ShareをメイントピックにしたMeetupでした
Live Shareとは
Live Shareは１つのソースコードを複数人で同時に編集できるVisual Studio Familyの機能です
以下にあげるようなことができます
具体的な用途としては
などが可能です
VS Codeのドキュメントは基本的に英語だけのことが多いそうですが、Live Shareは日本語サイトあります！
Live Shareを実際に使ってみる
Live shareを使うにはマーケットで公開されてる拡張を入れればOKです
オススメされていたLive Share Extension Packの中身は以下の4つです
- Live Share
- Live Share Audio
- VSCode同士で音声共有ができる！
- Live Share Chat
- VSCode同士でチャット共有ができる！
- Peacock
- 複数window開いている場合、windowごとに枠をカラーリングできる便利な機能
会場では実際に大阪会場と東京会場でLive Shareを使って共同編集していました
東京: VS Code on Mac、大阪: VS Code on windowsと場所、OS、エディタが全部違う状況で同時にデバッグしてます
大阪側で仕込んだブレイクポイントを、東京でステップ実行してたりしてすごい、、
macにpower shellが共有することが出来る！ (意味があるかは謎)
terminalの共有も可能ですが権限渡しちゃうと本当になんでもできるのでこれは注意が必要そう
もちろんread onlyにすることも出来ます
最大30人と共有可能、ただ会場にいただれも30人以上接続した時に何が起こるかはわからないとのことです、、w
あんまり人と一緒に開発しない人も使える! (?)
また、LTではLive Shareは1人でも使える！と発表している方もいました
どういうことかというと、例えば自宅のデスクトップPCで作業している途中で外出した場合、VS Codeさえ入っていれば手持ちのノートPCで続きから作業できるぞ！ということだそうです
僕は家でもノートPCで作業してるんでこの恩恵には預かれないですけどこれは意外と便利そう！？
感想
Live Shareまだ使ったことないんですがチームで開発する上では結構使い所多そうだなって気がしました
そのためにも会社にガンガンVS Codeを布教しなければ、、w
Rubyのobjectとselfの違い
先日、railsで継承元のclassで定義されているmethodを継承先のclassで使おうとしたらエラーになりました
class parentClass
def hoge
return 'hoge'
end
end
class ChildClass < ParentClass
def fuga
object.hoge
end
end
これはエラーになります
正しく動かすには以下の書き方をする必要があります
class parentClass
def hoge
return 'hoge'
end
end
class ChildClass < ParentClass
def fuga
self.hoge
end
end
objectをselfに変えると継承元のmethodが使えるようになります
参考
詳しいスコープの違いはリンクを参照してください
