note のやらかしのあのへんについて。 認証自作、 Rails 、 Devise - Diary パーフェクト Rails 著者が解説する devise の現代的なユーザー認証のモデル構成について - joker1007’s diary 認証サーバーの実装は本質的に難しいです。セキュリティが絡むものは「簡単な実装」などなく、プロアマ個人法人問わず、個人情報を守るという点で、同じ水準を要求されます。悪意あるハッカーは常にカモを探していて、もし認証が破られた場合、自分だけではなく大多数に迷惑が掛かります。初心者だから免責されるといったこともありません。全員が同じ土俵に立たされています。 とはいえ、認証基盤を作らないといろんなサービスが成立しません。そういうときにどうするか。 Firebase Authentication で、タイトルの件なんですが、 Firebase Authenticat
このページについての説明・注意など PHP は、Apache モジュールや、CGI、コマンドラインとして使用できるスクリプト言語です。このページでは、主に PHP における、Web アプリケーションのセキュリティ問題についてまとめています。 Web アプリケーションのセキュリティ問題としては、以下の問題についてよく取り挙げられていると思いますが、これらのセキュリティ問題について調べたことや、これら以外でも、PHP に関連しているセキュリティ問題について知っていることについてメモしておきます。 クロスサイトスクリプティング SQL インジェクション パス・トラバーサル(ディレクトリ・トラバーサル) セッションハイジャック コマンドインジェクション また、PHP マニュアル : セキュリティや、PHP Security Guide (PHP Security Consortium) には、PH
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
Webアプリケーション作った後のチェック表
愛宕山太郎坊 アニメーション制作進行支援ソフト 愛宕山太郎坊 ログイン 会社id ユーザー名 パスワード ユーザー名またはパスワードが正しくありません。 閉じる ログイン
ケータイの端末ID・ユーザIDの取得についてまとめてみました Tweet 2008/9/8 月曜日 matsui Posted in au, DoCoMo, PHP, SoftBank | 12 Comments » ケータイサイトでは、端末ID・ユーザIDを取得する、という処理をよく行うことがあります。 ログインの度に、ユーザ名とパスワードを入力するというのは、ケータイの操作性の面からも現実的ではないためです。 今回はそんな各種IDの取得方法について、PHPを使った場合を例にとりまとめてみました。 ※ここでは端末IDを「ケータイに振られた個体識別情報（製造番号など）」、ユーザIDを「契約に紐付くID」として解説しています。 ドコモ端末での取得方法 1. utnを使う ドコモ端末ではutn属性を使うことによって、フォームやリンクから個体識別情報を取得することができます。 対応機種は、iモー
携帯サイトの作り方
ここでは、携帯向けサイトの作り方を簡単に紹介します。 PC向けサイトを作ったことのある人を対象とさせていただきます。 まず、携帯版のファイルはPC版と完全に分けましょう。 共通のファイルで済まそうとするのはかなり無理があります。 PCと携帯の違い いくつかあるので順に説明します。 ファイルサイズの制限 これが一番大きなところでしょう。 後で詳しく説明しますが、携帯向けサイトでは1ページ当りのファイルサイズを 画像も含めて5Kbytes程に収めなければなりません。 5Kbytesでは足りない、と思われる方も多いと思いますが 試しに5Kbytesの文章を書いて携帯で表示させてみましょう。 携帯の小さい画面から見ればこれでもかなりの情報量だと感じるはずです。 スタイルシート関連 携帯向けサイトでは、一切のスタイルシートが使えません。 もともと、スタイルシートとは細かな装飾方法をアレンジするための
このツイートを見て、「アプリで再ログインを頻繁要求されるってユーザビリティ良くないな。」と思ったのですが、普段裏側の仕組みは意識していなかったりテックリードの方に任せきりだったりしていたので、これを機に調べてみました。 そもそもスマホアプリ の時代、もはやauthenticationですらないと思うのよね。（何を言ってるかわからねえだろうと思うが。） — Hiromitsu Takagi (@HiromitsuTakagi) 2019年7月8日 この記事は「アプリでログインしっぱなしは、どのように実現されるの？」という疑問と調べた結果を共有するために書いていきます。 間違いや「もっとこんな仕組みが使われてるよ！」等のツッコミがあれば、どしどし貰えると助かります！ 疑問1. アクセストークンという仕組みとは？ 「なぜアクセストークンという概念が必要なのか？」 モバイルアプリでユーザー認証をし
SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜 - Qiita
SPAのログイン認証のベストプラクティスがわからなかったのでわりと網羅的に研究してみた〜JWT or Session どっち？〜JavaScriptRailsJWT認証React SPAのログイン周りについて、「これがベストプラクティスだ！」という情報があまり見当たらないので、様々な可能性を模索してみました。 いろいろな状況が想定され、今回記載する内容に考慮の漏れや不備などがありましたら是非コメントでご指摘いただきたいです！特に「おすすめ度：○」と記載しているものに対しての批判をどしどしお待ちしております！ この記事でおすすめしているものであっても、ご自身の責任で十分な検討・検証の上で選択されてください。 前提 想定しているAPIは、 ログイン外のAPIにはPOST/PUT/DELETEのものがなく、GETのみ GETのAPIにはDBを更新するなどの操作がない とし、そのためログイン外では
第1回 まずは「クッキー」を理解すべし
Webアプリケーションのぜい弱性がなかなかなくならない。メディアなどでも盛んに取り上げられているにもかかわらず，である。特に，セッション管理がからむアプリケーションのぜい弱性には，気付かないことが多い。具体的には「クロスサイト・リクエスト・フォージェリ」（CSRF），「セッション・フィクセーション」などである。これらはクロスサイト・スクリプティング，SQLインジェクションといった比較的メジャーなぜい弱性に比べて認知度が低く，対策も進んでいない。 原因の一つは，アプリケーションの開発者が原因を正しく理解していないこと。CSRFやセッション・フィクセーションについて言えば，セッション管理に使うクッキー（cookie）の動作を理解していないと対策が難しい。ところが最近の開発環境では，セッション管理の仕組みが隠ぺいされているため，必ずしもこの知識は要求されない。こうした開発者は容易にはぜい弱性に気
最近購入したPHP×携帯サイト 実践アプリケーション集を読んでいて妙な感じがしたので、この感覚はなんだろうと思っていたら、その理由に気づいた。本書に出てくるアプリケーションは、PHPのセッション管理機構を使っていないのだ。そんな馬鹿なと思ったが、目次にも索引にも「セッション」や「session」という語は出てこない。サンプルプログラムのCD-ROM上で session を検索しても出てこないので、セッションはどこでも使っていないのだろう。 そうは言っても、本書にはブログやSNSなど認証が必要なアプリケーションも登場する。本書で採用している認証方式はこうだ。 携帯電話の個体識別番号を用いた、いわゆる「かんたんログイン」のみを使う 認証状態をセッション管理機構で維持しない。全てのページで毎回認証する そのため、「iモードID」など、ユーザに確認せずに自動的に送信されるIDを用いる つまり、全て
入社4年目にもなってtech.kayac初登場のせいです。 ブログ書けプレッシャーにとうとう屈する時がきました。 これで夢にkyo_agoが出てうなされなくてすみます。(彼はtech.kayacの尻たたき担当でした) 先々月「ぼくらの甲子園!熱闘編」というゲームをモバゲー内にてリリースしました。 これは去年リリースした「ぼくらの甲子園!」の続編です。 モバゲーユーザの方、是非遊んでみてください。 今回はこの「ぼくらの甲子園!熱闘編」がどういうインフラ構成になってるか紹介したいと思います。 注) 題名に「カヤック流」とはつけましたが、カヤックでは多様性を善としている風潮があり、 ゲームによってインフラの構成が違うどころか、利用しているプログラミング言語すら違います。 なので全てのゲームがこのような構成になってるわけではありません。 前提 今回のインフラ構成を決めるに至って考慮した点は「ラクに
実は厄介、ケータイWebのセッション管理
実は厄介、ケータイWebのセッション管理：再考・ケータイWebのセキュリティ（3）（1/3 ページ） “特殊だ”と形容されることの多い日本の携帯電話向けWebサイト。そこには、さまざまな思い込みや性善説の上しか成り立たないセキュリティが横行しています。本連載は、ケータイWebの特殊性をていねいに解説し、正しいケータイWebセキュリティのあるべき姿を考えます（編集部） 「Cookieを使えない端末」でセッションを管理する方法は？ 第2回「間違いだらけの『かんたんログイン』実装法」ですが、多くの方に読んでいただきありがとうございました。 今回は、前回に引き続き架空のSNSサイト「グダグダSNS」のケータイ対応を題材として、ケータイWebのセッション管理の問題点について説明します。携帯電話向けWebアプリケーション（ケータイWeb）のセッション管理は、かんたんログインよりも対策が難しく、厄介な問
なぜ我々はsession.cookieを変更しなければならなかったのか - BASEプロダクトチームブログ
はじめに こんにちは。バックエンドエンジニアの小笠原です。 今回は、2022年2月18日から2022年3月4日にかけて発生していたこちらの障害に対し私達開発チームが実施した、session.cookieで定義しているCookieのkey名を変更するという影響範囲の大きい対応について、実施に至るまでの経緯や対応過程についてご紹介したいと思います。 ショップオーナー向けに掲載していたお知らせの内容 背景 全ては iOS14.5から端末識別子の取得に同意が必要になったことから始まった ことの発端は、iOS14.5以降からIDFA（端末ごとに持つ固有識別子）の取得に端末所有者の許可が必要になったことでした。 この変更は、端末所有者側から見ると情報の活用範囲を自身で管理できることでよりプライバシーに配慮されるようになった良い変更と言えるでしょう。 一方で、広告出稿側から見た場合は拒否をしたユーザーの
おはようございます、ritou です。 qiita.com これの初日です。 なんの話か 皆さんは今まで、こんな記事を目にしたことがありませんか？ Cookie vs JWT 認証に JWT を利用するのってどうなの？ JWT をセッション管理に使うべきではない！ リンク貼るのは省略しますが、年に何度か見かける記事です。 個人的にこの話題の原点は最近 IDaaS(Identity as a Service) として注目を集めている Auth0 が Cookie vs Token とか言う比較記事を書いたことだと思っていますが、今探したところ記事は削除されたのか最近の記事にリダイレクトされてるようなのでもうよくわからん。 なのでそれはおいといて、この話題を扱う記事は クライアントでのセッション管理 : HTTP Cookie vs WebStorage(LocalStorage / Sess
Web アプリケーションとは切っても切れないセッション機構。DB ベースでセッション管理を行なって得られた知見と、それを元に考察した結果をまとめてみます。 セッションデータの特性 DB で管理される他のデータに比べ、セッションデータはかなり特殊です。主な特徴は次のような感じ。 データが増加するのが速い 定期的な削除が必要 頻繁に更新される リクエスト毎に読みに行く必要がある このデータを読めないとアプリケーション全体にアクセスできない アクセス頻度が高いということです。あと、1つ目の特徴からセッションデータについては意識的に管理してやる必要があります。 現在の環境 アプリケーションの領域が少し特殊で、セッションデータがやたらたまります(ユーザ数何百万のサービスとかそういうのではないです)。 RDBMS MySQL 4.0.22 ストレージエンジン InnoDB レコード数 6千万 テータサ
Ywcafe.net
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Healthy Weight Loss Best Penny Stocks Cheap Air Tickets Credit Card Application Top Smart Phones Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy|Do Not Sell or Share My Personal Information
IPA-安全なウェブサイトの作り方2021年改訂第7版.pdf
JWT認証、便利やん？ - ブログ
どうして JWT をセッションに使っちゃうわけ？ - co3k.org に対して思うことを書く。 (ステートレスな) JWT をセッションに使うことは、セッション ID を用いる伝統的なセッション機構に比べて、あらゆるセキュリティ上のリスクを負うことになります。 と大口叩いておいて、それに続く理由がほとんどお粗末な運用によるものなのはどうなのか。最後に、 でもそこまでしてステートレスに JWT を使わなくてはいけないか？ とまで行っていますが、JWT認証のメリットはその実装のシンプルさとステートレスなことにあります。現実的には実際はDB参照とか必要になったりするんですが、ほとんど改ざん検証だけで済むのは魅力的です。トレードオフでリアルタイムでユーザー無効化ができないことくらいですかね。ライブラリなんて使う必要ないほどシンプルだし、トレードオフさえ許容できればむしろ、なぜこれ以上に複雑な認証
"JWT=ステートレス"から一歩踏み出すための考え方
おはようございます、ritouです。 この話に乗っかっていきます。 3行で ログアウト時にJWTを無効化できない実装は今後脆弱性診断で「OWASP Top 10 2021違反」と指摘されるようになりそう(今も個別にされてるかもしれないけど) JWTは単純なフォーマットなので、ステートレスなセッション管理においてログアウトしたときに文字列自体を無効化できない件は独自エンコード方式(一般的にフレームワークのCookieストアと呼ばれているもの)でも起こり得る 「セッションID vs JWTで内包」 以外にも 「セッションIDをJWTに内包」もあり得る。既存の機能を残しつつ「JWTで武装」する選択肢も考えてみてはどうか。 ステートレスなセッション管理でログアウトの際に文字列自体を無効化できない問題 これは前から言われていますし、駆け出し何とか勢のQiita記事に書かれるぐらいには一般的です。 2
■ クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。 クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。 前提 ログインしていないWeb閲覧者に対するCSRF攻撃（掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為）はここでは対象と しない。 ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追
PHPで安全なセッション管理を実現する方法
_ 残り容量が数十Mバイトになっていた PCがなんかくそ遅いなーと思ってふと空きディスク容量をみたら、残り数十Mバイトまで減っていた。Folder Size for Windowsで各ディレクトリ単位のディスク使用量をながめてみたところ、 Thunderbirdでimapでアクセスしているアカウントのデータフォルダに、なぜか1GバイトオーバーのINBOXファイルがあった。なにこれ？ 削除したけど別に動作には支障はなし。 puttyのlogが無限に追記されたよ……。数Gバイト。 昔ダウンロードしたCD/DVD-ROMのisoイメージファイルが、そこかしこに消されず残ってたよ。10Gバイトオーバー。 あと、細かいテンポラリディレクトリの中身とか消したら、30Gバイトくらい空いた。そこまでやって久しぶりにデフラグを起動したら、表示が真っ赤（ほとんど全部断片化されている）だったので、最適化実行中。
はてなブックマークのブックマーク数が多い順に記事を紹介する「はてなブックマーク数ランキング」。2024年2月のトップ50です*1。 順位 タイトル 1位 マンションリフォーム虎の巻 2位 死ぬほど嫌でした｜佐藤秀峰 3位 「面倒なことはChatGPTにやらせよう」の全プロンプトを実行した配信のリンクを整理しました｜カレーちゃん 4位 管理職必読 順番に読むと理解が深まる「マネジメントの名著」11冊 | 日経BOOKプラス 5位 メルカリで値段の「¥マーク」を小さくしたら購入率が伸びた理由、ペイディがサービス名を「カタカナ表記」にする理由など、プロダクトのマーケ施策まとめ30(2023)｜アプリマーケティング研究所 6位 7年適当に自炊してきて調味料について思ったことを書く 7位 ウクライナ軍に入隊したアジャイルコーチが、さまざまなメソッドを駆使して中隊長としてのリーダーシップを実現した話（
携帯端末の個体識別情報(uid)取得方法
携帯サイトでユーザー認証をする方法はいくつかあります。 一番簡単なのは、ユーザ名とパスワードを使う方法です。 しかし、毎回入力するのはユーザにとっては面倒ですよね。 PCサイトならばクッキーを使ってこれらの情報を保存しておけるので 毎回入力する必要はありません。 しかし携帯サイトではクッキーが使えない(一部機種によって可能らしい)ので 別の手法を取ることを考えなくてはいけません。 そこで出てくるのが、携帯端末の個体識別情報(uid)を使うというやり方です。 携帯電話は電話番号と同じように、その端末を識別するIDのようなものを持っています。 これを利用すれば、アクセスしてきたのがどのユーザなのかを判別することが可能になるというわけです。 キャリアによって取得方法や制限などがあるので、以下に紹介します。 なお、個体識別情報はキャリアによって様々な言い方があるようですが ここでは便宜上「端末ID
Webアプリ開発で必ずぶち当たる課題、Webアプリ特有の技術、アーキテクチャについて考えてみる。 古くから続く課題を知れば、次世代Webフレームワークがどのように解決しようとして、何を提示しようとしているか分かりやすくなるだろう。 ＃以下、セキュリティ関係などを除く。 Webアプリは、Ajaxが登場するまで、UIがブラウザで制限されているため、それほど難しい機能を実装できなかった歴史があった。 古くはPer/PHP、そしてJavaに至るまで、Webアプリはステートレスだったから、殆どの機能は閲覧機能とマスタメンテナンス機能にすぎなかった。 なぜなら、Webアプリでは、6時間以上もかかるようなバッチ処理を実装したとしても非現実的だから。 しかし、以前から知られているアーキテクチャ上の課題はあるし、Ajaxの出現によって更にその課題が複雑になった現状もある。 Webアプリを作る時はいつも、下記
やぁ、みんな，元気？とくまるひろしです。今日はSession Fixation攻撃の方法をこっそり教えちゃうよ。 いつもは防御側で漢字の名前でやってるんだけど，きょうは攻撃側ということで，名乗りもひらがなに変えたんだ。だってさ，今度デブサミでご一緒するはせがわようすけさんとか，はまちちゃんとか，ひらがなの人たちの方が格好良さそうじゃないか。 では始めよう。 このエントリは、http://blog.tokumaru.org/2009/01/introduction-to-session-fixation-attack.html に移転しました。恐れ入りますが、続きは、そちらをご覧ください。
ユーザーをログアウトから守れ！―シーケンス図から読み解くログイン状態維持【Webアプリ編】 | DevelopersIO
認証というのは面倒なもので、利用者に余計な手間を掛けさせてアクティブ率を下げたくないと日夜工夫を凝らす我々にとっては、やり玉に上がりやすいテーマであると思います。要するに、ユーザーをログアウトさせたくないわけです。さて、どうしましょう？ 生魚おじさん、都元です。今月の魚はアジです！アジを食べましょう。 さて、認証というのは面倒なもので、利用者に余計な手間を掛けさせてアクティブ率を下げたくないと日夜工夫を凝らす我々にとっては、やり玉に上がりやすいテーマであると思います。要するに、ユーザーをログアウトさせたくないわけです。 例えば Facebook や Twitter のページはいつ訪問しても自分のアカウントでログイン状態になっています。 最後にログインしたのはいつでしたっけ？ 覚えていませんよね？ これがおそらく皆さんの理想です。 セッションによるログイン ログインには通常、Cookie を
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 サービス上では複数リクエストをまたがって状態を保持するために、
2007年11月29日07:15 カテゴリ書評/画評/品評 Immortal Session の恐怖 さすがの私も、今夜半の祭りにはmaitter。 私のtwitterが荒らされていたのだ。 荒らし発言は消してしまったが、にぽたんがlogを残してくれている。 nipotumblr - Dan the cracked man 一部で言われているように、本当にパスワードが抜かれたかどうかまでは解らない。が、状況としてはnowaがベータテスト段階で持っていたCSRF脆弱性をついた荒らしにそっくりだった。 にぽたん無料案内所 - こんにちはこんにちは！！ この時も、私のnowaのメッセージに荒らしが入った。パスワードを変更しても暫く荒らしが続いていた点も似ている。 ここでの問題は、 bulkneets@twitter曰く(直接リンクは避けます) 問題は本人が気付いてもパスワード変えてもセッション残
Firebase AuthなどJavaScriptでAPIセッション用のトークンを得ることについて - Qiita
ちょっとでもセキュリティに自信がないなら、 Firebase Authentication を検討しよう （※ こちらの参照記事の内容自体に不備があるとか甘いとか指摘するものではないんですが、勝手に枕として使わせてもらいます） 上記記事は、Firebase Authenticationが提供するJavaScript APIを使ってJWTのトークンを取得し、自前のサーバにHTTPのヘッダで送りつけて検証をさせることで、認証の仕組みをセキュアかつかんたんに実現しよう、という内容です。 このようにJavaScriptのAPIでトークンを発行して自前バックエンドのAPI認証につかう方法はAuth0のSDKなどでも行われていますので、IDaaSをつかってSPAを開発する場合には一般的なのかもしれません。 話は変わりますが、SPAの開発に携わっている方は「localStorageにはセッション用のトー
富士通のMDA資料
SDAS（エスダス）（注1）は、開発期間短縮を実現し、お客様のビジネスのスピードアップに貢献する為の総合システム開発体系です。 新しい「SDAS」は、「短期間・高品質」のシステム開発を実現するとともに、「オープン性・国際標準」「ライフサイクル全般でのシステム最適化」「エンジニアリングとマネジメントを両輪とするプロジェクト遂行」を特長としています。 これにより、システム開発期間を従来と比べ、概ね半減することが可能となり、ITの観点から、お客様のマーケットの動きを先取りしたビジネス展開を支援していくことで、競争優位確保に貢献します。 システム開発を「要件定義」「設計」「構築」「テスティング」の4フェーズに分け、それぞれのフェーズを最短化する開発手法、標準技術に基づくツール群およびテンプレートを適用することで、トータルの期間短縮を実現します。 注1 SDAS： System Developmen
追記: 翔泳社さんからDjangoの書籍を出版するのでぜひ読んでみてください。 実践Django Pythonによる本格Webアプリケーション開発 作者:芝田 将翔泳社Amazon この資料は DjangoCongress JP 2018で話した「Djangoにおける認証処理実装パターン」 の解説記事になります。 2019/04/08 追記: GithubのコードはPython3.7 Django2.2にupdateしています) 何年か前に Djangoのユーザー認証まとめ という記事を書きました。今でもコンスタントに100PV/dayくらいアクセスのある記事なのですが内容が古く、実装時にハマりやすい注意点にもあまり触れることができておらず、おすすめできる資料ではありません。今回はDjangoCongress JPにて発表の機会をいただけたのですが、この機会に認証処理についてまとめ直すと同
技術/HTTP/REST設計思想の "Stateless" との付き合い方 - Glamenv-Septzen.net
id: 1350 所有者: msakamoto-sf 作成日: 2015-02-11 21:34:52 カテゴリ: HTTP プログラミング [ Prev ] [ Next ] [ 技術 ] RESTfulなAPIやWebアプリケーションを開発する際に、一つの疑問が生じる。 RESTでは「ステートレス」を重視して、サーバサイドでのセッション管理ではなく、クライアント側で認証情報や状態を保持して、サーバに都度送る方式を唱えている。これはHTTPで実装するなら、Cookieを使ったセッション管理ではなく、BasicやDigest認証など、HTTP認証を使うことになる。 しかし現実問題として、モダンなWebサイトでBasic/Digest認証を扱うことはなく、サーバサイドのCookieを使ったセッション管理を使うことになる。 RESTにおいて、ステートレスという特性と、現実のセッション管理をどう
今日 @mad_p さんからRT来てたこのツイートに関して、ちょっと調べたのでまとめときます。 Security Issue in Ruby on Rails Could Expose Cookies http://t.co/JlsXVEn4rZ — Ruby on Rails News (@RubyonRailsNews) September 25, 2013 前提条件 Railsではデフォルトでsessionをcookieにのみ保存して、DBなりmemcacheなりのserver-side storageには何も保存しません。 これがCookieStoreとか呼ばれてるやつです。 この場合のsession cookieは、Railsのsession object (Hash object) をMarshal.dumpしてそれに署名を付けたtokenです。 rails 4では署名付ける代
JWTとは JSON Web Tokenの略。ジョットと読むらしい。 ざっくりいうとJsonに電子署名を加え、URL-Safeな文字列にしたTokenのこと 正確にいうと、電子署名を使用する方式はJWS（JSON Web Signature）と呼ばれ、別途暗号化を使用するJWE（JSON Web Encryption）も存在する。よく見かける説明はJWS方式のほう。 JWS方式の場合、電子署名であり暗号化ではないため、中身を見ることは可能。但し改ざんはできない、という仕組み。 実際のユースケースで言うと、サーバ側で認証情報が入ったJsonを加工（電子署名を加える等）し、JWTにしたのち、それを認証Tokenとしてクライアントに渡す。クライアントはそのTokenを認証Tokenとして使用する。 仕組みについては調べればたくさん出てくるのでそちらを参照したほうが良いかと思います。 この記事では
おはようございます。ritou です。 5月下旬ぐらいにチーム内勉強会としてJSON Web Token(JWT)についてわいわいやりました。 その際に作成した資料に簡単な説明を添えつつ紹介します。 このブログではJWTについて色々と記事を書いてきましたが、その範囲を超えるものではありません。 ちょっとだけ長いですが、ちょっとだけです。お付き合いください。それでは始めましょう。 JSON Web Token boot camp 2020 今回の勉強会では、JWTについて概要、仕様紹介という基本的なところから、業務で使っていくにあたって気をつけるべき点といったあたりまでカバーできると良いなと思っています。 JSON Web Token 概要 まずは概要から紹介していきます。 JSON Web Tokenの定義とはということで、RFC7519のAbstractの文章を引用します。 JSON W
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
_書籍「PHP×携帯サイト デベロッパーズバイブル」の脆弱性 「PHP×携帯サイト デベロッパーズバイブル」という携帯サイト開発のノウハウを解説した書籍が今月初頭に発売され、話題になっている。Amazonの「インターネット・Web開発」カテゴリで1位ということで、たいしたものだ。私も発売前から予約して購入した。 私がこの書籍を購入した動機は大きく二つある。一つは、携帯サイトの最新の開発ノウハウをまとめた書籍に対する期待をしていたということ。もう一つは、セキュリティに対する記述がどの程度あるのかを見てみたいというものだった。 このうち、前者については、期待は叶えられた。非常に盛りだくさんのテーマが手際よくまとめられていて、かつ読みやすい。あまり原理・理屈のことは書いていないが、開発現場では、コピペの情報源として重宝されることだろう。 しかし、問題はセキュリティについての記述である。 本社のサ
HTTP Cookies
このウェブサイトは販売用です！ studyinghttp.net は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、studyinghttp.netが全てとなります。あなたがお探しの内容が見つかることを願っています！
※ご注意 他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。 また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。 「第2回 顧客データがすべて盗まれる」は、クロスサイトスクリプティング（XSS）と同様に実際のプログラミングを行うプログラマの責任であるという対策で、最も危険と思われるSQL InjectionとOS Command Injectionについて紹介した。今回は、プログラミング以前の設計段階で潜り込むセキュリティホール――見落としがちなセッション管理の脆弱性について説明していく。 We
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ちょっとでもセキュリティに自信がないなら、 Firebase Authentication を検討しよう
PHP と Web アプリケーションのセキュリティについてのメモ
ke-tai.org < Blog Archive > ケータイの端末ID・ユーザIDの取得についてまとめてみました
アプリで「ログインしっぱなし」はどのように実現されているか？ - Qiita
携帯電話向けWebアプリのセッション管理はどうなっているか - ockeghem's blog
カヤック流ソーシャルアプリの作り方 インフラ編 - KAYAC Engineers' Blog
Webアプリケーションのセッション管理にJWT導入を検討する際の考え方 - r-weblife
データベースを用いたセッションデータ管理について - LukeSilvia’s diary
高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法
はてなブックマーク開発ブログ
Webアプリのセッション管理はデスクトップアプリのメモリ管理と同じ - プログラマの思索
とくまるひろしのSession Fixation攻撃入門 - ockeghem's blog
マイクロサービス時代のセッション管理 - Retty Tech Blog
Immortal Session の恐怖 : 404 Blog Not Found
Django における認証処理実装パターン - c-bata web
Rails SessionにCookieStore使った時の問題点 - OAuth.jp
JWT・Cookieそれぞれの認証方式のメリデメ比較 - Qiita
2020年版 チーム内勉強会資料その1 : JSON Web Token - r-weblife
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
徳丸浩の日記 - 書籍「PHP×携帯サイト デベロッパーズバイブル」の脆弱性
＠IT：Webアプリケーション: 第3回 気を付けたい貧弱なセッション管理