Webサービスにおけるログイン機能の仕様とセキュリティ観点 - Flatt Security Blog
はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上 @0x003f です。 本稿では、Webアプリケーション上で実装される「ログイン機能」の実装パターンをいくつか示し、その「仕様の中で起きうる脆弱性」とその対策について解説していきます。 「ログイン機能」はToB、ToC問わず多くのWebアプリケーションで実装されている機能で、XSSやSQL Injection、Session Fixationといったような典型的な脆弱性の観点については、なんらかの解説を見たことのある方も多いと思います。 しかし、「仕様の脆弱性」というのはあまり多く語られていない印象です。今回はそのようなタイプの脆弱性についての解説を行います。なお、IDaaSを用いずに自前でログイン機能を実装しているケースを複数パターン想定しています。 はじめに ログイン機能の仕様パターンとセキュリティ
最近知ったCloudflareで実はこんなこともできる集
Argo Tunnel Client(cloudflared)をngrokの代替として使う cloudflaredというArgo Tunnelクライアントを使えば、ngrokのようにローカルサーバを外部に公開することができる。 # localhost:8080 を公開する。実行後に表示されるURLを使ってどこからでもアクセスできる。 cloudflared tunnel --url http://localhost:8080 これだけならばわざわざ乗り換える理由にはならないが、ngrokでは有料でしか使えない機能も無料プランで使える。 カスタムドメインの割り当て SSOによる認証 TCPのプロキシ セキュアでDDNSのいらないVPNの構築 例えば個人で自宅にVPNの環境を作る場合、ルーターのVPN機能を使うか、VPNサーバを立ててDDNSでドメインを自宅のグローバルIPに紐付けるといったや
JWTの無効化実装例
こんばんは、ritou です。 今日は JWTの無効化の方法はいっぱいあるよ って話を書きます。 単体での無効化(jti, 文字列全体のハッシュ) これが最も一般的な JWT無効化の方法 と言えるかもしれません。 ちょっと前に話題になった「Stateless」なユースケースにおける無効化できないみたいな話に絡むところでしょう。 The "jti" (JWT ID) claim provides a unique identifier for the JWT. 例えば失効対象の jti のリストを管理することで無効化判定ができるでしょう。 有効期限を持つかどうかにより対象の jti をいつまで保持するか、などの細かい要件は変わります。 これ以外にも、JWTに含まれる claim を利用した検証 ってのは 無効化管理/判定 をしていると言いかえることもできます。 時刻での無効化(iat, ex
GCP の Application Default Credentials を使った認証 - ぽ靴な缶
公式ドキュメントで説明されているけど、同僚に何度か説明する機会があったり、作る必要のないサービスアカウントキーを目にすることも多いのでまとめておく。 認証情報が登場しないアプリケーションコード 例えば以下のコードで Secret Manager に保存したトークンを取得することができる。SecretManagerServiceClient にサービスアカウントキーを渡さずとも動作する。 const {SecretManagerServiceClient} = require('@google-cloud/secret-manager'); const client = new SecretManagerServiceClient(); (async () => { const [secret] = await client.accessSecretVersion({ name: 'proj
ユーザー アカウント、認証、パスワード管理に関する 13 のベスト プラクティス2021 年版 | Google Cloud 公式ブログ
※この投稿は米国時間 2021 年 5 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。 2021 年用に更新: この投稿には、Google のホワイトペーパー「パスワード管理のベスト プラクティス」のユーザー向けとシステム設計者向けの両方の最新情報を含む、更新されたベスト プラクティスが含まれています。 アカウント管理、認証、パスワード管理には十分な注意を払う必要があります。多くの場合、アカウント管理は開発者や製品マネージャーにとって最優先事項ではなく、盲点になりがちです。そのため、ユーザーが期待するデータ セキュリティやユーザー エクスペリエンスを提供できていないケースがよくあります。 幸い、Google Cloud には、ユーザー アカウント（ここでは、システムに対して認証を受けるすべてのユーザー、つまりお客様または内部ユーザー）の作成、安全な取り扱い、
CloudFront + S3 + CloudFront Functions で BASIC 認証をかける
はじめに CloudFront + S3 で静的な Web サイトをホスティングしている。 ステージング環境として同様のサイトを作ったが、超簡単なアクセス制限をかけるために BASIC 認証をかけたい。 こういったケースでは Lambda@Edge を使うのが主流のようだが、最近リリースされた CloudFront Functions を使ってやってみた。 手順 CloudFront Functions のサイドバーに Functions メニューがあるので、そこから以下の内容で Functions を登録する。 function handler(event) { var request = event.request; var headers = request.headers; // echo -n user:pass | base64 var authString = "Basic
セッションマネージャー越しにSSHアクセスすると何が嬉しいのか | DevelopersIO
セッションマネージャー越しにSSHアクセスする構成のメリットについて考えてみました。 なにそれ？ 公式ドキュメントでいうと以下内容のことです。 Step 8: (Optional) Enable SSH connections through Session Manager もう少し詳しく まず、クライアントはセッションマネージャーを使ってアクセスしたいインスタンスにアクセスします。 もう少しこの部分を具体的に説明すると、クライアントがアクセスしているのはインスタンスではなく、SSM(Systems Manager)のエンドポイントです。 そして、アクセス先インスタンス内のSSM Agentがポーリングアクセスしていて、こちらを通じてアクセスしています。 そして、この接続の先で、SSH接続し直しているイメージになります。これが今回扱う「セッションマネージャー越しにSSHアクセス」です。 わ
アプリケーションにおける権限設計の課題 - kenfdev’s blog
日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。 所々で「メリット」「デメリット」に関連する情報がありますが、そのときそのときには色々と感じることがあっても、いざ記事にまとめるときに思い出せないものが多々ありました。フィードバックや自分の経験を思い出しながら随時更新する予定です。 TL;DR（長すぎて読みたくない） 想定する読者や前提知識 この記事での権限とは 権限の種類 ACL(Access Control List) RBAC(Role-Based Access Control) ABAC(Attribute-Based Access Control) どの権限モデルを採用するべきか 権限を適用する場面 機能
認証の標準的な方法は分かった。では認可はどう管理するんだい？ #cmdevio
「認証は OIDC 等のデファクトに乗っておけ」 というのはわかりました。ではその次。認証した後です。 残念ながらアクセス制御の枠組みにはデファクトがありません。 自分で設計するしかないのです。 しかし、我々は漠然と車輪の再発明を続ければいいのでしょうか。アクセス制御にスタンダードが無いなら無いなりに、 どのようにアクセス制御機構を整備すればいいのか？その考え方を整理していきましょう。Read less
GCP からの HTTP リクエストをセキュアに認証する
はじめにGCP にはあらかじめ HTTP のエンドポイントを登録しておくと、そこに対して HTTP リクエストが送られてくるようなプロダクトがいくつか存在します。 Cloud Pub/SubCloud TasksCloud Schedulerどれも非同期系の処理を行うプロダクトであり、非同期処理を行う Worker を HTTP の Web サーバとして記述できるのが大きなメリットになっています。 しかしそれらの Web サーバはパプリックなエンドポイントとして用意することも多いことから、送られてきた HTTP リクエストが本当に GCP の特定のプロダクトから送られてきたものなのか？という「認証」をどうやるかが長らく問題になっていました。 既存のやり方としては Web サーバの実装方式によっていくつかありますが、 App Engine (1st gen) を使う場合: “login: a
登録されるとつらいユーザー名リスト - Qiita
Twitter, GitHub, Qiita などのように root/(username) でユーザーページをルーティングするところが増えてきている. このルーティングを採用し, help などのユーザー名を許可すると, root/help が奪われてしまう. そこで, 登録時に validate で, ある程度排除するのが習わしになっていると思うが, 急に root 直下に置きたいページが増えたときなどに取得されていると悲しいことになる. また, サブドメインを利用するサービスだと, api などをうっかり取られてしまうケースが後を絶たない. http://api.hatenablog.com/ みたいに取られることによる面白みもあるが, おおむねつらい. 実際, twitter では search アカウントが取られていて, TweetDeck では twitter.com/searc
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
