HTML5のLocal Storageを使ってはいけない（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Randall Degges - Please Stop Using Local Storage 原文公開日: 2018/01/26 著者: Randall Degges 日本語タイトルは内容に即したものにしました。 画像は元記事からの引用です。 初版公開: 2019/10/19 追記更新: 2024/04/05 -- リンク情報を記事末尾に移動しました 本気で申し上げます。local storageを使わないでください。 local storageにセッション情報を保存する開発者がこれほど多い理由について、私にはさっぱり見当がつきません。しかしどんな理由であれ、その手法は地上から消えてなくなってもらう必要がありますが、明らかに手に負えなくなりつつあります。 私は毎日のように、重要なユーザー情報をlocal storageに保存す
SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜 - Qiita
SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜JavaScriptRailsJWT認証React SPAのログイン周りについて、「これがベストプラクティスだ！」という情報があまり見当たらないので、様々な可能性を模索してみました。 いろいろな状況が想定され、今回記載する内容に考慮の漏れや不備などがありましたら是非コメントでご指摘いただきたいです！特に「おすすめ度：○」と記載しているものに対しての批判をどしどしお待ちしております！ この記事でおすすめしているものであっても、ご自身の責任で十分な検討・検証の上で選択されてください。 前提 想定しているAPIは、 ログイン外のAPIにはPOST/PUT/DELETEのものがなく、GETのみ GETのAPIにはDBを更新するなどの操作がない とし、そのためログイン外では
マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その
なぜ我々はsession.cookieを変更しなければならなかったのか - BASEプロダクトチームブログ
はじめに こんにちは。バックエンドエンジニアの小笠原です。 今回は、2022年2月18日から2022年3月4日にかけて発生していたこちらの障害に対し私達開発チームが実施した、session.cookieで定義しているCookieのkey名を変更するという影響範囲の大きい対応について、実施に至るまでの経緯や対応過程についてご紹介したいと思います。 ショップオーナー向けに掲載していたお知らせの内容 背景 全ては iOS14.5から端末識別子の取得に同意が必要になったことから始まった ことの発端は、iOS14.5以降からIDFA（端末ごとに持つ固有識別子）の取得に端末所有者の許可が必要になったことでした。 この変更は、端末所有者側から見ると情報の活用範囲を自身で管理できることでよりプライバシーに配慮されるようになった良い変更と言えるでしょう。 一方で、広告出稿側から見た場合は拒否をしたユーザーの
AWS Application Composerで始める、 サーバーレスなデータ基盤構築 / 20240406-jawsug-hokuriku-shinkansen
systemd serviceから呼ぶシェルではsudoではなくsetprivを使う - 赤帽エンジニアブログ
Red Hatの森若です。 自分でsystemdのservice unitを作るときに、起動用のいくつかのコマンドを記述したシェルスクリプトを呼ぶ事は(理想的ではないですが)あるかと思います。 今回はこの場合に、sudoを利用するとまずい理由を説明して、かわりにsetprivを使うほうがよいという話です。 例題用のservice 実行してみる 別のcgroupだと何がまずいのか? 対策はsetprivコマンド 例題用のservice sudoによるまずい動作を確認するためのできるだけ単純な例として、hoge.service を用意します。 /opt/hoge/hoge.sh #!/bin/bash sudo -u moriwaka sleep 5000 /etc/systemd/system/hoge.service [Unit] Description=hoge [Service] Ty
"JWT=ステートレス"から一歩踏み出すための考え方
おはようございます、ritouです。 この話に乗っかっていきます。 3行で ログアウト時にJWTを無効化できない実装は今後脆弱性診断で「OWASP Top 10 2021違反」と指摘されるようになりそう(今も個別にされてるかもしれないけど) JWTは単純なフォーマットなので、ステートレスなセッション管理においてログアウトしたときに文字列自体を無効化できない件は独自エンコード方式(一般的にフレームワークのCookieストアと呼ばれているもの)でも起こり得る 「セッションID vs JWTで内包」 以外にも 「セッションIDをJWTに内包」もあり得る。既存の機能を残しつつ「JWTで武装」する選択肢も考えてみてはどうか。 ステートレスなセッション管理でログアウトの際に文字列自体を無効化できない問題 これは前から言われていますし、駆け出し何とか勢のQiita記事に書かれるぐらいには一般的です。 2
SPA+SSR+APIで構成したWebアプリケーションのセッション管理 - Pepabo Tech Portal
カラーミーショップ サービス基盤チームのkymmtです。この記事では、サーバサイドレンダリングするシングルページアプリケーションとAPIサーバからなるWebアプリケーションのセッション管理方法について紹介します。 アプリケーションの構成 構成の概要 今回は例としてEC事業部で提供するカラーミーリピートをとりあげます。構成としては、Railsで作られたAPIサーバ1と、Vue.jsで作られたシングルページアプリケーション(SPA)からなります。また、SPAはExpressが動くフロントエンドサーバでサーバサイドレンダリング(SSR)します。APIサーバはSPAかフロントエンドサーバだけが呼び出します。各ロールはサブドメインが異なります。 APIサーバでセッションIDを持つCookieを発行し、Redisを用いてセッション管理します。また、APIサーバへのセッションが有効なリクエストはフロント
この記事はRetty Advent Calendar 2019 21日目の記事です。エンジニアの 神@pikatenor がお送りします。11日目の記事に書かれた「弊社エンジニアの神（注・人名であり実名です）」とは私のことです。 qiita.com さて世はまさにマイクロサービス大航海時代、大規模化した組織・肥大化したコードベースのメンテナンスを継続的に行っていくべく、アプリケーションを機能別に分割する同手法が注目を集めていることは皆さんもご存知でしょう。 マイクロサービスアーキテクチャ特有の設計課題はいくつかありますが、今回は認証情報のような、サービス間でグローバルに共有されるセッション情報の管理のパターンについて調べたことをまとめてみたいと思います。 背景 HTTP は本質的にステートレスなプロトコルですが、実際の Web サービス上では複数リクエストをまたがって状態を保持するために、
ふと気になって調べたことの備忘メモです ✍ （2022/11/3追記）ご指摘頂いた内容を踏まえて加筆修正をおこないました なぜ調べたか Webアプリケーションの開発に携わっていると CSRF という脆弱性への対処を求められますが、多くの場合利用しているフレームワークが設定追加だけで対応してくれたり、既に前任者によって適切な処置がされていたりなど、実務上で目を向ける機会はその重要性と比較して少ないのでないかと思います また、Webブラウザの実装やHTTP周辺の関連仕様の変化から陳腐化している情報も多く、現代において全体感と具体的な対処法を理解するには少しばかりハードルが高いように感じていました ですので、自身の現時点での認識を明文化して残しておくことにしました なお、私はWebセキュリティの専門家でなく、一介の開発者のため、誤りが多分に含まれる可能性があります ご指摘を頂ければ修正したいと思
サマリ PHPサーバーサイドプログラミングパーフェクトマスターには、PHP入門書としては珍しくクロスサイト・リクエストフォージェリ(CSRF)対策についての説明があるが、その方法には問題がある。アルゴリズムとして問題があることに加えて、実装上の問題があり、そのままコピペして用いると脆弱性となる。 はじめに 古庄親方の以下のツイートを見て驚きました。 CSRF用のトークンの作成 ＄token = password_hash(mt_rand(), PASSWORD_DEFAULT); ってのを書籍で見た………もンのすンげぇなぁ(苦笑 書籍名でググって調べる……評判が悪いので、まぁ、納得っちゃぁ納得。 — がる (@gallu) July 17, 2019 CSRFトークンの生成に、password_hash関数を使うですと? 親方に書籍名を教えていただき、購入したのが、この記事で紹介する「PH
PHPで学ぶ Session の基本と応用 / web-app-session-101-2024
PHPカンファレンス関西2024 の登壇資料です。 Cookie を使った Session 管理について解説しています。
AWS Systems Manager セッションマネージャーでSSH・SCPできるようになりました | DevelopersIO
AWS Systems Manager セッションマネージャーに待望の機能（のひとつ）がやってきました！ Session Manager launches tunneling support for SSH and SCP サーバーにSSHしたり、ローカル・リモート間での SCP 越しのファイルの送受信も可能になりました。 更には SSH セッション越しにポート転送もできます。 ということで、さっそく試してみましょう！ リモートの準備 SSM エージェントをインストール SSH先サーバーに 2.3.672.0 以上の SSM エージェントがインストールされている必要があります。 古いエージェントがインストールされている場合、アップデートしてください。 Manually Install SSM Agent on Amazon EC2 Linux Instances - AWS Systems
PHPerKaigi 2021 の登壇資料です。 Cookie を使った Session 管理について解説しています。
プログラミング学習環境のMonaca Educationで、セガの人気パズルゲームである「ぷよぷよ」を使ってプログラミング学習できる教材「ぷよぷよプログラミング」が登場しています。「ぷよぷよプログラミング」は無料で利用できるとのことなので、プログラミング初心者が早速チャレンジしてみました。 【公式】ぷよぷよeスポーツ×プログラミング http://puyo.sega.jp/program_2020/ 「ぷよぷよプログラミング」サポートページ | Monaca Education https://edu.monaca.io/puyo 「ぷよぷよプログラミング」に挑戦するには、Monaca Educationにサインインする必要があります。というわけで、まずはMonaca Educationのアカウント作成ページにアクセスして、メールアドレスとパスワードを入力し、「アカウント新規作成」をクリッ
ある日の我が家 娘（４歳）「パパ、セッションとかCookieってなあに？」 娘「サーバサイドの勉強してると出てくるやつ」 ワイ「おお、今日はその質問か」 ワイ「ええでええで〜、パパが教えたるで〜」 娘「わ〜い！」 ワイ「ワ〜イ！」 例えば月曜日 ワイ「例えば、月曜日の朝は仕事する気にならへんからTwitterを見るやろ？」 娘「うん！」 ワイ「せやからTwitterのホーム画面を見るために」 ワイ「ブラウザのアドレスバーにhttps://twitter.com/homeって打ち込むんや」 ワイ「まぁ実際にはブックマークから行くんやけど、まぁ同じことや」 ワイ「つまりブラウザ君を通して、サーバ君に」 「ワイのTwitterのホーム画面のHTMLをくれや〜」 ワイ「ってことを伝える訳や」 娘「うんうん」 ワイ「でもな？」 ワイ「それもCookieを使ってセッション管理をせんと実現できひんことや
ある日，HTML5のLocal Storageを使ってはいけない がバズっていた． この記事でテーマになっていることの１つに「Local StorageにJWTを保存してはいけない」というものがある． しかし，いろいろ考えた結果「そうでもないんじゃないか」という仮定に至ったのでここに残しておく． 先の記事では，「Local StorageにJWTを保存してはいけない」の根拠として「XSSが発生した時，攻撃者がLocal Storageに保存したJWTを盗むことが出来てしまう」といったセキュリティ上の懸念事項が挙げられていた． これに対し，クッキーを用いたセッションベースの認証では，セッションIDをクッキーに保存する．クッキーにHttpOnlyフラグをつけておけば，JavaScriptからはアクセスできず，XSSが発生しても攻撃者はセッションIDを読み取ることが出来ない． 一見すると，これは
待望！Amazon ECSのコンテナにログインできるAmazon ECS Execを試してみた - SMARTCAMP Engineer Blog
スマートキャンプ、エンジニアの入山です。 前回のブログにも書きましたが、弊社では昨年末から既存のEC2からECS/Fargateへのインフラ移行作業を実施しています。 EC2からECSへ移行する上では、特に運用面が大きく変わります。利便性やメンバーへの教育コストを考慮すると、今までEC2でやっていた運用をECSでどう上手く代替するかが力の入れ所だと思います。 一ヶ月前に弊社インターンの関口が書いた以下の記事も、既存運用の置き換えやデバッグ時の利便性向上を目的とした手段の１つで、この記事を執筆した時点ではECS/Fargate上のコンテナに対するAWS公式のログイン手段はありませんでした。 tech.smartcamp.co.jp 弊社のECS移行も稼働直前の佳境を迎えている最中ですが、この度Amazon ECS Execがリリースされ、待ち望んでいたECS/Fargate上のコンテナに対す
[アップデート] 実行中のコンテナに乗り込んでコマンドを実行できる「ECS Exec」が公開されました | DevelopersIO
もう、コンテナ調査のためにEC2に乗り込む必要は無い！ もう、Fargateだからコンテナの状況が見れないと悩むこともない！ ECS開発者待望の機能がリリースされました！ みなさん、こんにちは！ AWS事業本部の青柳＠福岡オフィスです。 Amazon Elastic Container Service (ECS) において、実行中のコンテナに乗り込んでコマンドを実行できる機能「ECS Exec」が公開されました。 Amazon ECS now allows you to execute commands in a container running on Amazon EC2 or AWS Fargate どんなものなのか、早速使ってみたいと思います。 これまでの方法 デバッグやトラブルシューティングを行うために、実行中のコンテナに乗り込んでコマンドを実行したいという時があると思います。
![[アップデート] 実行中のコンテナに乗り込んでコマンドを実行できる「ECS Exec」が公開されました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/f10e4b6d55aa4fe987e9584f7b2febd50e43f158/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Famazon-elastic-container-service.png)
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Microservices における認証と認可の設計パターン
sessionとcookieが多分わかる資料
マイクロサービス時代のセッション管理 - Retty Tech Blog
CSRF(Cross-Site Request Forgery)攻撃について
PHPサーバーサイドプログラミングパーフェクトマスターのCSRF対策に脆弱性
PHPで学ぶ Session の基本と応用 / web-app-session-101
無料でぷよぷよを通してプログラミング学習できる「ぷよぷよプログラミング」が登場したので体験してみた
4歳娘「パパ、セッションとCookieってなあに？」 - Qiita
おーい磯野ー，Local StorageにJWT保存しようぜ！