令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
「APIエコノミー」に迫る“検知できない脆弱性攻撃”の脅威
コンテンツデリバリーネットワーク（CDN）サービスを基盤に、各種のクラウド型セキュリティサービスを手掛けるアカマイ・テクノロジーズでWebセキュリティの動向を追う中西一博氏が、非常に発見が難しくなっているWeb攻撃の実態と手口を暴き、その対策について解説する。 以前の連載：迷惑bot事件簿 アプリのマイクロサービス化とAPIの関係 世界中のWeb通信を中継しているAkamai Technologies （以下 Akamai）が取り扱う通信の8割以上は、すでにAPIの通信が占めている。 APIを利用するスマートフォンやブラウザアプリが普及の後押しをしているのは間違いないが、近年ではサーバ側のマイクロサービス化（あるシステムを小規模なシステムを組み合わせて開発する手法）の影響も大きい。 日本も同様だ。商用のWebアプリケーション開発者に話を聞くと「いま開発中のWebアプリやスマホアプリのサーバ
マイクロサービスでの認証認可 - Qiita
複数のクラウドサービスを利用している（マルチクラウド）など、単純には閉域網を構築できない環境でマイクロサービスアーキテクチャを採用する場合には、サービス間の認証認可が必要となる。この場合のサービス間の認証認可方式を決める参考となる、OSSやSaaS、Webサービスで採用方式ついて整理した。 Istio サービスメッシュの実装として有名なIstioではサービス間通信を以下のように制御できる。 Istioの認証認可では認証主体がService Identityというモデルで抽象化され、KubernatesやIstioで定義するService Accountに加えて、GCP/AWSのIAMアカウントやオンプレミスの既存IDなどをService Identityとして扱うことができる。 サービス間の認証 (Peer Authentication) は、各サービス (Pod) に設置するSideca
認証トークンをCookieに保存するのは卒業しよう - Qiita
Webアプリケーションの認証トークン（セッション）はCookieヘッダで送信するのが一般的だとは思いますが、 そろそろこのCookieに依存した方法は負の遺産ではないでしょうか？ 認証トークンの送信はRFC 7235で規定されているAuthorizationヘッダを使うと良いです。Basic認証とかDigest認証で使うやつですね。 実はBasicやDigestの他にRFC 6750でBearerというスキームが登録されています。単一の文字列を認証情報として送信するためのスキームで、トークンを送信するのにピッタリです。 参考: トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた その場合は、認証トークンはCookieではなくlocalStrage（またはsessionStorage）に保存することになると思います。
Kazuho@Cybozu Labs: Re: はてな認証 API
« はてな認証 API | メイン | Hash ≠ MAC » 2006年05月06日 Re: はてな認証 API naoya さんありがとうございます、ということで、「認証APIのメモについてのレス」への返答です。 2006/5/7 追記: 1) で述べた MD5 による api_sig の偽装が可能であることを確認しました。この偽装を用いた攻撃は、auth.json および auth.xml については、1) に述べたとおり成功しません。認証リンクについては、仕様として任意のパラメータをハンドリングできる必要があるので、攻撃が成立してします (攻撃者がパラメータを追加することができる)。 よって、認証リンクの署名機能は壊れている、と言わざるを得ないように思います。 3) パラメータ指定の手法について 先にこちらから。 パラメータ指定は先日サポートしました。http://auth.ha
Google Safe Browsing API - Google Code
注æ: ä¸é¨ã®ãã¼ã¸ã¯è±èªã§ã®ã¿ãå©ç¨ããã ãã¾ãã Safe Browsing API ã«ã¤ã㦠Safe Browsing API ã¯ãGoogle ãå®æçã«æ´æ°ãã¦ãããã£ãã·ã³ã°è©æ¬ºãã¼ã¸ããã«ã¦ã§ã¢ ãã¼ã¸ã®ãã©ãã¯ãªã¹ãã«å¯¾ãã¦ãã¯ã©ã¤ã¢ã³ã ã¢ããªã±ã¼ã·ã§ã³ã URL ã®ç¢ºèªãè¡ãå®é¨ç㪠API ã§ããã¯ã©ã¤ã¢ã³ã ã¢ããªã±ã¼ã
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.machu.jp/posts/20060507/p01/
