読者です 読者をやめる 読者になる 読者になる

DIGITAL COFFEE-デジタルコーヒー

どうでもいいことを呟くどうでもいいブログ

Mastodon(マストドン)ってなんだ?

どーも、PlugOutです。

 

mastodon.social

先日からいろんなメディアで話題になっている「Mastodonマストドン)」、僕も触ってみました。

Twitterとほぼ同じような機能を持っているSNSで、名前は違えどツイートやRT、Favができます。

Twitterと違う点としては、これは分散型であるということ。

簡単に言えばMMORPGのサーバー選択と同じで、どこのサーバーで利用するのか選ぶ必要があります。

ただしサーバーが違ってもやり取りは可能なようです。

そしてオープンソースなので、自分でサーバーを立てることも可能。

要は、1つのサーバーが落ちてもそのサーバーに属している人たちが利用できなくなるだけということですね。

 

んー……。

 

エンジニアとしては凄く画期的な機能だなと思うけれど。

利用者としては、やはりTwitterでいいじゃん感は否めないだろうな。

Twitterが無くなるならこっちを使い始める人も多そうだけれど、まだ敷居は高そうだしな。

ちょっと今後の動きに注目ではありますねー。

 

wsup.social

ちなみに僕のアカウントはこれです。

もしよかったらフォローしてくださいね!

ではでは!

 

Double Submit CookieでのCSRF対策について

どーも、PlugOutです。

今回は久々にエンジニア的な技術ネタを。

 

RESTFULなWebアプリケーションにおいて、どうCSRFクロスサイトリクエストフォージェリ)の対策を行うかということについて。

クロスサイトリクエストフォージェリ - Wikipedia

 

まずCSRFとは、あるサービスにおいてログイン中のユーザーを対象して仕掛ける脆弱性攻撃のことです。

例としてはあるSNSにログイン中のユーザーがいて、そのユーザーはcookieにセッション情報を保持しています。(今後、このユーザーを被害者と呼びます)

攻撃者は悪意のあるページを用意しておき、被害者がこのページを見た瞬間にSNSへの投稿を行わせるような悪意のあるコードを実行するように仕掛けておきます。

(例えば、ajaxでPOSTを実行させるようなJavaScriptコードです)

すると、SNS側では通常のPOSTと攻撃のPOSTが見分けられないので変な投稿が受け付けられてしまうというものです。

 

今までのWebアプリケーションの場合は、POSTする前のページにトークンを用意しておきこれを照合することによってこれを回避してきました。

(攻撃者はこのトークンを予測できない)

 

しかしRESTFULなアプリケーションにおいては、POSTとGETが独立して動くためにこの手段を使うことができません。

そこで使われるのが「Double Submit Cookie」という手法です。

これはGET時にCookieに専用のトークン情報を仕込んでおき、これをJavaScriptサイドに読み込ませてそれをヘッダに入れさせるというもの。

API側ではこのヘッダの値とcookieの値をチェックして、一致した場合のみ正当なリクエストと判断させます。

ここで肝となるのが、CookieにはHttpOnlyの設定を行わないということ。

こうしておけば、JavaScript上からサーバーが付与したCookieの情報を読み取ることができます。

 

ではどうしてこれがCSRFの防御策になるかというと、攻撃者が用意するページは攻撃対象のドメインとは異なるためにCookieを読み込むことができないからです。

 

angularでは簡単にこの「Double Submit Cookie」を実現できる「CookieXSRFStrategy」というものが用意されています。

angular.io

 

……と、まぁいろんな海外サイトを巡って情報を仕入れました。

日本語の解説サイトがほぼ0だったので、自分用のメモがてらまとめただけですが、もし役に立ったら幸いです。

ではでは!