令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
Dev Containerを使ってみよう
Dev Containerを使ってみよう Dev Containerを使う上で知っておくと良さげな情報のまとめ記事です 前にRemote SSHでDev Containerの環境を構築する記事を書いたので、今回はDev Container全般の情報をまとめてみました tl;dr Dev Containerを使うと開発環境をコンテナで構築できるよ(ランタイムとかツール類含めて！) docker composeだとアプリケーションを動作させる環境は作れるけどDev Containerは開発環境ごと構築できて便利 Dev Containerを使うにはdockerとDev Containerを利用できるエディタが必要 Dev Container内でdocker composeを利用できるから、Dev Container用のコンテナ+ミドルウェアコンテナを用意すればアプリケーションを開発できる環境が
BSTRはwchar_tへのポインタではありません - syghの新フラグメント置き場
COMの文字列にはBSTRというデータ型が使われています。 BSTRが定義されているWindows SDKのヘッダーを見てみましょう。 // <wtypes.h> in Windows SDK 8.1 #ifndef _PREFAST_ typedef /* [wire_marshal] */ OLECHAR *BSTR; #else // _PREFAST_ typedef _Null_terminated_ OLECHAR *BSTR; #endif OLECHARはもともとCOMの前身であるOLE (Object Linking and Embedding) で使われていた文字型の名残で、当時はANSI MBCSのcharでしたが、現在はWCHARすなわちwchar_tと等価です。Windows上ではsizeof(wchar_t) == 2であり、UTF-16エンコーディングのUni
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
