どうして JWT をセッションに使っちゃうわけ？ - co3k.org
備考 2018/09/21 22:15 追記 2018/09/20 12:10 に公開した「どうして JWT をセッションに使っちゃうわけ？」というタイトルが不適切だとご指摘をいただいています。 その意見はもっともだと思いますので、現在、適切となるようにタイトルを調整しています。 ご迷惑およびお騒がせをして大変申し訳ございません。 本文の表現についても改善の余地は大いにありそうですが、こちらは (すでにご意見を頂戴している関係で、) 主張が変わってしまわないように配慮しつつ慎重に調整させていただくかもしれません。 はあああ〜〜〜〜頼むからこちらも忙しいのでこんなエントリを書かせないでほしい (挨拶)。もしくは僕を暇にしてこういうエントリを書かせるためのプログラマーを募集しています (挨拶)。 JWT (JSON Web Token; RFC 7519) を充分なリスクの見積もりをせずセッシ
Chrome 43でUpgrade Insecure Requestsに対応してた - ASnoKaze blog
Upgrade Insecure Requests W3Cの仕様でUpgrade Insecure Requestsというものがある。 サブリソースのhttp://へのリクエストを自動でhttps://のものに変更する（下のデモサイトの例が分かりやすい。 指定方法としては以下の二通りである。 HTTPレスポンスヘッダで指定する Content-Security-Policy: upgrade-insecure-requests もしくはmetaタグで指定する <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> 試してみる デモサイトが公開されている https://googlechrome.github.io/samples/csp-upgrade-insecure-requests
Apacheのアクセス制御をちゃんと理解する。 - こせきの技術日記
Apacheの設定で Order deny,allowとか Satisfy anyとか、なんだか意味わからん人のために。僕はずっとわかってなかった。 基本 Apacheのアクセス制御には、 ホストによる制御 (Order,Allow,Deny) ユーザ認証による制御 (Auth*, Require) の2通りがある。 Satisfyは、2通りあるアクセス制御の両方を満たす必要があるかどうかを決定する。デフォルトはSatisfy all。Satisfy anyなら、どちらか片方満たせばよい。 Order http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#order Order deny,allowは、全てのホストからのアクセスを許可する。 Order allow,denyは、全てのホストからのアクセスを拒否する。 Order d
AWS で不正アクセスされて凄い額の請求が来ていた件 - yoya's diary
情けない話ですが、自分の大チョンボで AWS の個人アカウントが第三者にアクセスされた結果 190万円相当のリソースが使われ、最終的に AWS さんに免除を頂きました。反省込みで本件のまとめを書きます。 自分が馬鹿を幾つも重ねた結果であって、AWS 自体は怖くないというのが伝われば幸いです はじめにまとめ S3 実験してた時に SECRET KEY を見える場所に貼っていた事があり、第三者がそれでアクセスし大量の高性能インスタンスを全力で回す (恐らくBitCoin採掘) AWS さんから不正アクセスの連絡があり、急いで ACCESS KEY 無効＆パスワード変更、インスタンス全停止、イメージ削除、ネットワーク削除 免除の承認フェーズを進めて、クレジットカードの引き落とし前に完了して助かる AWS さんのサポート AWS さんは最大限サポートしてくれました 承認フェーズが進まない時もあまり
47NEWS（よんななニュース）
アメリカはタリバン復権を後押しし、アフガニスタンの民意もそれを支えた 民主化が失敗した理由は何か。これからどうなるのか【アフガン報告】６回続きの（３）
CSRF対策のトークンをワンタイムにしたら意図に反して脆弱になった実装例
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2011年1月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 橋口誠さんから今話題の書籍パーフェクトPHP (PERFECT SERIES 3)を献本いただきました。ありがとうございます。このエントリでは同書のCSRF対策の問題点について報告したいと思います*1。 本書では、CSRFの対策について以下のように説明されています（同書P338）。 CSRFへの対応方法は、「ワンタイムトークンによるチェックを用いる」「投稿・編集・削除などの操作の際にはパスワード認証をさせる」などがあります。一番確実な方法は両者を併用することですが、ユーザ利便性などの理由から簡略化する場合で
短縮URLは負債となる可能性が高いので作ることに恐ろしく躊躇する - キモブロ
なんていうか、存在すること自体がコストっていうのかな。一度短縮URLを始めたらそれは未来永劫維持されなければ今までに作り出したすべてのURLが無価値になってしまう。 それはなぜかというと、URLからハッシュ関数により一方的にハッシュを算出することが出来て、これはmp3とかmp4みたいに情報をロスさせることにより圧縮している。ロスしただけあって、ハッシュからURLへの復元はその変換したデータベースがないと出来ない。 これってすごいむちゃくちゃなことだと感じるはず。そのデータベースが失われたら今までの価値、文脈が失われる。たとえば著名な短縮URLサービスであるbitlyが消滅したとしたら、bitlyが使われた発言は何を言ってるのかわからなくなる。"そのbitlyが指し示していたコンテキスト"が失われた文章を君はどうやって理解するのかね。 つまり短縮URLを作り、それが誰かに一度でも使われてしま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
今さら聞けないSPAのCORS対策の話
深刻な脆弱性が見つかったInternet Explorer（IE6～11）を巡り全国各地の社内がコントでカオス : 市況かぶ全力２階建
安全なPHPアプリケーションの作り方2013
http://japan.internet.com/webtech/20130207/2.html
http://e0166nt.com/blog-entry-975.html