令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
SPAセキュリティ入門～PHP Conference Japan 2021
こちらのスライドは以下のサイトにて閲覧いただけます。 https://www.docswell.com/s/ockeghem/ZM6VNK-phpconf2021-spa-security シングルページアプリケーション(SPA)において、セッションIDやトークンの格納場所はCookieあるいはlocalStorageのいずれが良いのかなど、セキュリティ上の課題がネット上で議論されていますが、残念ながら間違った前提に基づくものが多いようです。このトークでは、SPAのセキュリティを構成する基礎技術を説明した後、著名なフレームワークな状況とエンジニアの技術理解の現状を踏まえ、SPAセキュリティの現実的な方法について説明します。 動画はこちら https://www.youtube.com/watch?v=pc57hw6haXkRead less
実例に学ぶXSS脆弱性の発見と修正方法/line_dm 16 20160916 how to find and fix xss
LINE Developer Meetup in Fukuoka #16 http://connpass.com/event/38413/
Electronのwebview要素ではallowpopups属性をつけてはいけない - 葉っぱ日記
Electronを使ってブラウザのようなアプリケーションを作る場合には webviewタグが使用される。例えば、アプリケーション内にexample.jpのサイトを表示するには以下のようにHTMLに記述する。 <webview src="http://example.jp/"></webview> ここで、webviewタグにallowpopups属性を付与すると、example.jpサイト内のコードからwindow.open等を使って新たにウィンドウを開くことができるようになる。このとき、example.jpに悪意があり以下のようなコードが含まれているとする。 if( typeof require === "undefined" ) window.open( 'http://example.jp/', '', 'nodeIntegration=1'); else require( "chi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
