令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
CSRF 対策はいまだに Token が必須なのか?
CSRF 対策は One Time Token を form なりに付与して、サーバ側でチェックすれば良い。 それをデフォルトでサポートしてるフレームワークなどもあるし、なくてもライブラリでいくらでも対応できる。 どうせ完全にステートレスなサービスはなかなかないので、サーバ側に redis や memcache を用意するのも別に大変じゃない。 なので、 CSRF 対策として Token を付与するのは、最も安全で推奨できる方式ではある。 っていうのを踏まえた上で、もう SameSite=Lax デフォルトだけど、今でも Token 必須なの？みたいなのがたびたび話に出るので、いい加減まとめる。 前提 この話は、スコープがどこなのかによって話が多少変わるので、そこを絞る。 今回は Passive ではなく Active に対策していく場合を考えるので、前提をこうする。 SameSite=l
Web Security 101: An Interactive Cross-Site Request Forgery (CSRF) Demo - victorzhou.com
Looking for an introduction to Cross-Site Request Forgery (CSRF)? This post will be a little different - instead of telling you what it is, I’m going to show you. Ready? Setting the Scene You’re a responsible, hardworking person. You’ve saved up your money over the years at Definitely Secure Bank®. The Definitely Secure Bank logo. You love Definitely Secure Bank - they’ve always been good to you,
新卒研修受講レポート～セキュリティ編～ - mixi engineer blog
こんにちは。2017年新卒エンジニアの追田と服部です。 本記事では、4月におこなわれた新卒エンジニア向けのセキュリティ研修の大まかな概要や感想を受講者の立場からお伝えしたいと思います。 講師はXFLAG事業本部 たんぽぽGの亀山さんです。 内容 研修は以下の3部構成で実施されました。 セキュリティの必要性や脆弱性とその対策についての説明 WebGoat(研修用やられサイト)を用いた実習 スマートフォンゲームのチート事情についての解説 1. セキュリティの必要性や脆弱性とその対策についての説明 まず、企業が情報セキュリティ上の過失によって個人情報漏洩などの事故を起こしてしまった場合、どのような影響が考えられるでしょうか。 その企業の信頼の低下やイメージダウンを招いてしまうことはもちろん、それに伴う業績悪化や対応費用によって数百億円規模の損失を計上してしまう場合もあります。 本研修では過去に発
デブサミ2017「インテリジェンスで挑むサイバー攻撃の最前線」講演メモ #devsumi - 元RX-7乗りの適当な日々
IIJの方による大量トラフィックにおける情報セキュリティ＋機械学習的な話を聞いてきたので、そのメモです。 穴吹 健一 氏 (株)インターネットイニシアティブ IIJの"J"は何なのか、穴吹氏もよく知らないとのこと... ビッグデータや機械学習を少々 サイバーセキュリティをめぐる攻防 サイバーセキュリティとは データ改善やサービス継続の妨害のような犯罪を阻止 最近はMSS(マネージドセキュリティサービス)提供の会社が増えてきた サイバー攻撃は他人事ではない 標的型メールによるマルウェア感染による個人情報流出 派遣社員によるデータ持ち出しによる個人情報流出 CSRF/トロイの木馬による遠隔操作による不正操作 などなど 攻撃主体と目的 国家 諜報活動や他国の政治への介入 ハクティビスト 政治的主張 犯罪組織 利益目的の情報窃取や脅迫 よくある攻撃手法 DDoS攻撃 古典的だがどの通信が攻撃か判別
最も割高なアンチパターン : 構造化されたデータを文字列関数で操作する「printfアンチパターン」について | POSTD
本記事では、私の知る最も割高なアンチパターンとなるプログラミングについて述べます。 それは、 構造化されたデータフォーマットを文字列関数を使って操作すること です。 以後これを” printfアンチパターン “と称します。 コスト 私がこれを”最も割高な”アンチパターンと呼ぶのは、根拠のない主張ではありません。 cve.miter.org のデータを使って 脆弱性をタイプ別にカウントし 、下記のように、上位を占める脆弱性のタイプ別リストを作りました。 rexec: 19268 DoS: 14849 xss: 9236 memory: 8212 sqlinj: 6230 privilege: 3321 dirtraversal: 2762 arith: 1260 csrf: 1117 私の方法に対する批判や良いご提案があれば遠慮なくどうぞ。 上位を見ると、XSSとSQLインジェクションの数が
安全な脆弱性の作り方 - 葉っぱ日記
この記事は 「脆弱性"&'<<>\ Advent Calendar 2016」16日目の記事です。具体的な脆弱性の話でなくてすみません。いろいろコードを書いていると、安全に脆弱性を発生させたくなるときがあります。って書くとさっぱり意味がわからないと思いますが、セキュリティの講義のための演習環境とかそういうやつです。 受講生自身の手でWebアプリケーションの脆弱性を探してもらうような演習では、検査対象となる脆弱性を含むWebアプリケーションを用意する必要があります。こういった「脆弱なWebアプリケーション」は例えば Broken Web Applications Project のようなものを代表にいくつかのものがありますが、これらはUIが英語であったり、あまりにもメジャーすぎて受講生も触っている可能性があったりと、場合によっては利用が難しいことがあります。特に、単一のWebサーバに対して複
Sign-in on the Web — Credential Management API and Best Practices
This is a recollection of my part of the talk at Chrome Dev Summit 2016 titled “Sign-in on the Web — Credential Management and Best Practices”. Check the video for my colleague Sabine Borsay taking the first half of the talk describing the unique challenges we face on the web when personalizing user’s experience through sign-ins. Unlike native apps, the web needs considerations for different attac
Node.jsのセキュリティ・チェックリスト | POSTD
(訳注：2016/1/5、いただいた翻訳フィードバックを元に記事を修正いたしました。) セキュリティ – 誰もが見て見ぬふりをする問題 。セキュリティが重要だということは、誰もが認識していると思いますが、真剣にとらえている人は少数だと思います。我々、RisingStackは、皆さんに正しいセキュリティチェックを行っていただきたいと考え、チェックリストを用意しました。皆さんのアプリケーションが何千人というユーザやお客様に使用される前にセキュリティチェックを行ってください。 ここに挙げたリストのほとんどは概略的なもので、Node.jsに限らず、全ての言語やフレームワークに適用することができます。ただし、いくつのツールは、Node.js固有のものとなりますので、ご了承ください。 Node.jsセキュリティ に関するブログ記事も投稿してありますので、こちらも是非読んでみてください。 構成管理 HT
XSSやCSRFリスクを軽減する、Entry Point Regulationとは - ASnoKaze blog
Entry Point Regulation とは 反射型XSS・XSSI・CSRFのリスクを軽減するユーザエージェント上の仕組みとして、W3CでEntry Point Regulationという仕様が策定中です。 Webアプリケーションの口(Entry Point)に幾つかの制限をかけることが出来ます。別オリジンからのリクエストの時に、クエリパラメータやHTTPリクエストボディ(POSTメソッド)が付いていればブロックする、と言った事がマニフェストで指示できるようになりそうです。 EPRにおけるリクエストカテゴリ 各エンドポイント(URL)はどのようなリクエストを受け付けることが可能か指定できます。その時に指定するリクエストは以下に分類されます navigational request：context frame typeは"top-level", "auxiliary", "neste
58. すごいリロード対策
まず、日本のサイトにある一般的な登録フォームの画面遷移は 入力画面→入力確認画面→完了画面 となっている場合が多いようです。ここでリロード問題となるのは完了画面でのDBへのINSERT処理やCSV書き出し処理、メール送信処理など「一度しか行わない処理」です。例えば完了画面へ遷移した際にブラウザのリロードボタンが押された場合、確認画面よりsubmitした情報が再度submitされて上記の一度しか行わない処理が二度行われてしまいます。そうならないよう、リロード対策はスクリプトで制御します。 まずは確認画面のスクリプト 確認画面でチケットを発行し、セッションに保存しておきます。同時に完了画面へチケットがPOSTされるよう、hiddenにセット。こうして完了画面へ遷移させます。それでは完了画面のスクリプトを見てみましょう。 このように、確認画面で発行されたチケットは一度使い切ってしまえば2度処理さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CSRF対策のやり方、そろそろアップデートしませんか / Update your knowledge of CSRF protection