改めて学ぶセッションベース認証[Goによる実例付き] - Qiita
アプリケーションにおけるユーザー認証は、セキュリティとユーザーエクスペリエンスの核となる部分です。 この記事では、セッションベース認証(この記事ではセッション認証とします)の基本を理解し、Go言語(Golang)のを使った具体的な実装方法を解説します。標準ライブラリのみ使用してシンプルに書いてあるのでGo言語を普段使わない人も理解しやすいかと思います。 セッション認証とは？ セッション認証は、ユーザーが一度ログインすると、その後の各リクエストでユーザーを識別する方法です。 通常、セッション認証では以下のステップが含まれます。 ユーザーはブラウザを通じてIDとパスワードを含むログインリクエストをサーバーに送信します。 サーバーは提供された認証情報を検証し、正しいと判断された場合にセッションを確立します。セッション情報はサーバー内とCookieに保存されます。今回はメモリに保存しますが、実際の
![改めて学ぶセッションベース認証[Goによる実例付き] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/722e1b2d2104f6211630869475e34c5242025825/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JUU2JTk0JUI5JUUzJTgyJTgxJUUzJTgxJUE2JUU1JUFEJUE2JUUzJTgxJUI2JUUzJTgyJUJCJUUzJTgzJTgzJUUzJTgyJUI3JUUzJTgzJUE3JUUzJTgzJUIzJUUzJTgzJTk5JUUzJTgzJUJDJUUzJTgyJUI5JUU4JUFBJThEJUU4JUE4JUJDJTVCR28lRTMlODElQUIlRTMlODIlODglRTMlODIlOEIlRTUlQUUlOUYlRTQlQkUlOEIlRTQlQkIlOTglRTMlODElOEQlNUQmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzNBM0MzQyZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPTFlYWM0NDVhMDljNDI0NmI1Y2EwZmQxMDQ3NDc3MDFl%26mark-x%3D120%26mark-y%3D96%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9OTcyJnR4dD0lNDBZYXNoeSZ0eHQtY29sb3I9JTIzM0EzQzNDJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9NTZlOWZiYjgyNWJlMjFiOGI5MjhjYWEzZTg3MzZjYzY%26blend-x%3D120%26blend-y%3D500%26blend-mode%3Dnormal%26s%3D83b7004f99b293efe6866765650ca82f)
golangでログイン機能を作る②(RedisでSessionとCookie)
【環境】 MacBook Air (M1, 2020) OS: MacOS Big Sur version11.6 Docker Desktop for Mac version4.5.0 golangでログイン機能を作る①(bcryptでパスワード暗号化)の続きです。 今回はSessionとCookieを使いログイン状態を維持させます。 Session情報の保存には、Redisというメモリ上で実行されるデータベースを使います。 ディレクトリ構成 go_blog ├── .air.toml ├── build │ ├── app │ │ ├── .env │ │ └── Dockerfile │ └── db │ │ ├── .env │ └── Dockerfile ├── cmd │ └── go_blog │ └── main.go ├── controller │ ├── home_
CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある - co3k.org
CSRF 脆弱性対策には攻撃者の知り得ない秘密情報をリクエストに対して要求すればよく、そのような用途としてはセッション ID がお手軽でいいよねという時代があったかと思います。 いや、もちろん、 CSRF 対策の文脈だけで言えば今も昔も間違いというわけではありません。セッション ID が秘密情報であるのは Web アプリケーションにおいて当然の前提ですので、 CSRF 対策としてリクエストに求めるべきパラメータとしての条件はたしかに満たしています。 たとえば 『安全なウェブサイトの作り方』 改訂第6版では以下のように解説されています。 6-(i)-a. (中略) その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。 (中略) この秘密情報は、セッション管理に使用しているセッション ID を用いる方法の他、
fuelphpでセッションidをurlパラメータで引き回す方法 - とりあえずphpとか
やりたいこと タイトルのとおりですが、http://example.com/?session_id=*** のようにurlでセッションidを引き回してセッションを使用したかった。 ガラケー(フューチャーフォン)時代はcookieが使えない端末が多かったのでこのようなやり方はよくやってました。 まぁ、今ならcookie非対応端末なんてほとんどないしそういう端末はサービス非対応としてしまっても問題なさそう、、、 まずは設定 fuel/core/config/session.phpを編集 // 33行目くらい cookie→file //'driver' => 'cookie', 'driver' => 'file', // 51行目くらい true→false //'encrypt_cookie' => true, 'encrypt_cookie' => false, // 72行目くらい s
FuelPHPでセキュアな設定をする
FuelPHPをお仕事で使う方も増えてきたと思います。 そんな中で気になるのはやはりセキュリティ。 ということで今日はFuelPHPでセキュアな状態にするための設定を書きます。 まず @kenji_sさんの下記のブログが非常に分かりやすく書かれています。 FuelPHP でのセキュリティ対策(1) FuelPHP でのセキュリティ対策(2) FuelPHP でのセキュリティ対策(3) 今日はこれ以外の下記の項目について書きます。 DBにセッションを保存 変更推奨のセッション情報 https時にCookieにsecure属性を付与 1.DBにセッションを保存 defaultはセッションをクッキーに保存しています。 これをDBに変える情報は公式ドキュメントにあります。 FuelPHP公式ドキュメント 1.7 DB以外にも File Memcached Redis などが選べます。 DBを使う際
FuelPHPでセッション共有時の注意点 - Qiita
TL;DR FuelPHPでセッション情報をMemcacheやRDBMSなどを使って複数ノードで共有する場合には、 app/config/crypt.php を複数ノードで同じ値となるように設定する必要がある。 背景 Webアプリを複数ノードで構成して、ロードバランサでセッション維持をしない場合には、どのノードにユーザの再アクセスがあってもセッションを維持するために、セッションストアとしてMemcacheやRDBMSなどを使うと思います。 例えば、以下のような構成。 このような構成を FuelPHP で行う場合の注意点を書いておきます。 図と、以降の説明では ElastiCache（Redis）を使っていますが、注意点についてはRDBMSだろうが普通のMemcacheだろうが同じです。 セッションストアの指定 FuelPHP では、セッションストアの指定を app/config/sessi
Node.js + Express + MongoDB でのセッション管理 - hogehoge
なんでMongoDBでセッション管理するのか Node.js + Express (Connect) で標準で提供されている MemoryStore でセッション管理を行うとメモリ上での管理になるため node が落ちるとセッションデータが消えることになりセッションの永続化ができませんし、動作確認もソースの確認も行っていませんが、production で起動した際に出力されるメッセージ（https://github.com/senchalabs/connect/blob/master/lib/middleware/session.js#L199）に Warning: connection.session() MemoryStore is not designed for a production environment, as it will leak memory, and will n
間違いだらけのHTTPセッション管理とその対策
(Last Updated On: 2018年10月12日)HTTPセッション管理はWebセキュリティの中核と言える機能です。Webセキュリティの中核であるHTTPセッション管理に設計上のバグがある事は少なくありません。今回のエントリはPHP Webアプリ開発者ではなく、主にWebフレームワーク側の開発者、つまりPHP本体の方に間違いがあるという話しです。Webアプリ開発者の回避策も紹介します。 まずセキュリティの基本として「入力のバリデーションを行い、正当な入力のみを受け入れる」があります。しかし、PHPに限らず多くのセッション管理機構は当たり前の「入力のバリデーションを行い、正当な入力のみを受け入れる」を行っていません。セッションIDの再生成（リセット）も不完全な物が多いと思います。 参考： 知らないと勘違いする「合成の誤謬」の罠 開発者は必修、SANS TOP 25の怪物的なセキュリ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPで学ぶ Session の基本と応用 / web-app-session-101