2018年12月30日日曜日

curlを使ってサーバーからファイルをダウンロードしようとしたらできなかった話

ネットワーク周りを調べ始めて一週間ほどたち、ローカルだけど自作ホームページを表示できたので、じゃやりたいことを本格的にするかと、curlを使ってサーバーからアップロードしたファイルをダウンロードしようとしたら違うものが保存された。
#失敗したもの
curl -X POST localhost/page/download > test.txt
サーバー側のログを見るとCan't verify CSRF token authenticityとでていて頭?である。
上のエラーメッセージで調べるとこちらのページに解決策があった。
要は、ブラウザが裏側で行っていたことをしてなかったのが、失敗の原因だった。 なので、そのページ通りにコマンドを実行したら無事できて、よかった(月並み)。
curl localhost/ --cokkie-jar cookie | grep csrf
curl localhost/page \
  -F "authenticty_token='上のgrepしたもの中のcsrf-tokenのcontentにある文字列を入れる'" --cookie cookie > test.txt

CSRFについて

CSRFはCross-Site Request Forgeries(クロスサイトリクエストフォージェリ)と呼ばれるWebアプリケーションの脆弱性の一つ。 Wikepediaを見ると「ぼくはまちちゃん」事件で利用されたそうだ。

いくつかサイトを調べているとサーバー側の不備が原因の脆弱性だそうだ。 ユーザー側の対策としては、使っていないときはログアウトする、怪しいURLにはアクセスしないがある。 (個人的にスマホで毎回ログイン/ログアウトしている人いるのかな?って。スマホに危機が迫っている。何者かに侵略されているぞ!)

リンク一覧

  1. IPA 3. CSRF (クロスサイト・リクエスト・フォージェリ)
  2. 大量の「はまちちゃん」を生み出したCSRFの脆弱性とは?
  3. 外部からPOSTできない?RailsのCSRF対策をまとめてみた

リンク最後のQiitaを読むと今回したいことはPOSTではなくGETリクエストを使用する方があっているのでは?と思ったので修正。(POSTにしていたのはなんていうか流れ、惰性、なんか変わったことをするにはPOSTみたいな思い込みですかね)

そういえばWebサービスにはRESTという設計モデルがあるって、どこかで聞いていた覚えがある。RESTに当てはめると今回の機能は取得(GET)にあたる機能だから、POSTはおかしい。別にサーバー内のデータを書き換える訳ではないし。 さらにいうと更新とか削除とかすべてPOSTで行っているので、PUT、DELETEに置き換えないと…。公開する前から修正するところだらけである。

さらにいうと、作っている間にみたサイトで、最近のWebサービスにはSSR(Server Side Rendering)を使ったAjaxで1ページだけで画面遷移を行うとかみて、Webの進歩の速さは速すぎると、毎度思う。(格好いいサイトは歓迎です!) SSRはWebページの不正コピーを防ぐため手段としても活用されているみたいでコンテンツを重要視しているサイトとかだと必須になるのかな?とか思ったり。

SSRなページを作るならVue.jsかなーって、思っていたり、Webページばかり作っていたら、オンラインゲームを作る余裕がないじゃんとか思ったり、そんな日々です。

とりあず、今回の件でRails使っていて良かったなぁと。セキュリティについてはさっぱりだから、フレームワーク側で対策してくれているのはありがたいです。

0 件のコメント:

コメントを投稿