令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
JavaScriptのプロトタイプ汚染攻撃対策は難しい - Qiita
先日、私のプロジェクトで脆弱性関連のissueが投稿されたので対策を行いました。 指摘内容は主に「プロトタイプ汚染攻撃」でした。自分では対策を行っていたつもりだったのですが、様々な穴がありました。 プロトタイプ汚染攻撃可能な脆弱性は成功すると他の機能や脆弱性との組み合わせによって、任意のコード実行を可能にする危険度の高いものですが、XSSやCSRFに比べて、初学者が触れられる纏まった対策方法の情報が少ないと感じたので、ここに記そうと思います。 プロトタイプ汚染攻撃とは 日本語の情報としては Node.jsにおけるプロトタイプ汚染攻撃とは何か - ぼちぼち日記 が詳しいですが、まず、前提として、JavaScriptは「プロトタイプベースのオブジェクト指向」を採用しており、原則、すべてのプリミティブ型およびオブジェクトのインスタンスは「プロトタイプ」オブジェクトを参照しています1。 また、プロ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
