The SaaS CTO Security Checklist
Security shouldn’t feel like a chore. This is a basic checklist that any SaaS CTO (and anyone else) can use to harden their security. Select your startup stage and use these rules to improve your security. This list is far from exhaustive, incomplete by nature since the security you need depends on your assets. Feel free to contribute directly on GitHub!
PHPのJSON HashDosに関する注意喚起
4年前にHashDos（Hash Collision Attack）に関する効率的な攻撃方法が28C3にて公開され、PHPを含む主要言語がこの攻撃の影響を受けるため対策を実施しました。しかし、PHP以外の言語が、ハッシュが衝突するデータを予測困難にする対策をとったのに対して、PHPは、GET/POST/COOKIE等の入力データの個数を制限するという対症療法を実施したため、PHPにはHashDosに対する攻撃経路がまだ残っているということは、一部の技術者には知られていました。例えば、以下の様なつぶやきにも見ることができます。 だって、 hashdos 脆弱性の時、 Python とかの言語が、外部入力をハッシュに入れるときに衝突を狙えないように対策したのに、phpだけPOST処理で対策したからね？ json を受け取るような口もってるphpアプリのほとんどがhashdos残ってるんじゃない
sshのポートをデフォルトの22/tcpから変えるべきか論争に、終止符を打ちました - ろば電子が詰まつてゐる
また間が開きましたが、すみだセキュリティ勉強会2015#2を開催しました。発表していただいた@inaz2さん、@yasulibさん、ありがとうございました。当日の発表資料は上記の勉強会ブログからリンクしています。 今回の私の発表は、「攻撃を『隠す』・攻撃から『隠れる』」。ポートスキャンをするとsshが100個現れる「ssh分身の術」がメイン(?)です。 当初は、パケットヘッダやプロトコルのすき間にメッセージを隠したり、ファイルを隠すなども考えていたのですが……。あまりに盛りだくさんになりそうだったので、「ポートスキャンをいかに隠れて実行するか・ポートスキャンからどうやって隠れるか」と、ポートスキャンとnmapに絞って発表しました。 発表資料 私の発表資料は以下です。 (PDF)攻撃を「隠す」、攻撃から「隠れる」 発表ノート付きなのでPDFです。以下、落穂ひろいなど。 スキャンするポート数と
glibc の脆弱性 CVE-2015-0235（通称：GHOST）についてまとめてみた - piyolog
2015年1月27日(現地時間) Qualysはglibc(GNU C Library)に脆弱性を発見し、情報を公開しました。ここでは関連情報をまとめます。(暫定まとめなので精度低め、網羅性無しです。。) (1) 脆弱性関連情報 Qualysが公開した脆弱性情報 The GHOST Vulnerability Qualys Security Advisory CVE-2015-0235 注意喚起 IPA (注意) libc の脆弱性対策について(CVE-2015-0235) 脆弱性の概要 glibcの__nss_hostname_digits_dots() にヒープバッファオーバーフローの脆弱性。 当該関数はglibcのgethostbyname()とgethostbyname2()から呼ばれている。 アプリケーションによっては、DoS、またはリモートから任意のコードが実行可能となる可能性
自堕落な技術者の日記 : 様々なサーバーのPOODLE SSLv3脆弱性(CVE-2014-3566)対策のまとめ(更新3) - livedoor Blog（ブログ）
基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通 もくじ 1. はじめに 2. SSLv3を無効化できる場合のサーバー対策 2.1. Apache HTTPD Server + mod_ssl 2.2. Apache HTTPD Server + mod_nss 2.3. nginx 2.4. lighttpd 2.5. Microsoft IIS 2.6. (訂正)Apache Tomcat (Java JSSE) 2.7. Node.js 2.8. IBM HTTP Server 2.9. Amazon Web Services 2.10. その他のサーバー 2.11. SSLv3 を無効化するリスク 2.12. OpenLDAP 3. 諸般の事情で SSLv3 を有効にせざるを得ない場
先程から騒ぎになっているbashの脆弱性について – 上田ブログ
確認しました（苦笑） （追記: envを抜いてましたが、それだとCシェル系で確認できないので加えました） ueda@remote:~$ env x='() { :;}; echo vulnerable' bash -c 'echo this is a test' vulnerable this is a test 最初のワンライナーでなにがおこってるかというと、xの値であるはずの「() { :;}; echo vulnerable」の、echo vulnerableの部分がなぜか実行されています。 bashの文法ではシングルクォートで囲んだ中のものは何がどう書いてあっても単なる文字列であって、evalとかshとかに突っ込まない限り実行されるわけはないので、これは実装ミスかと。（と、書いたのですが環境変数に関数を仕込めるという仕様があるという話を初めて聞いて愕然と・・・。いま慌てて調べてます
事務局ブログ：「Covert Redirect」についての John Bradley 氏の解説 - 訂正版
先ほどの翻訳記事の原文への @miyagawa 氏からの指摘を受けて John Bradley 氏が新たな記事「OAuth 2 and Fragment encoding.」を書かれているので、翻訳します。 おぅ、わいや、John や。 昨日はカリフォルニアで開催されてるID厨の祭典「Internet Identity Workshop」ちぅイベントで、IETF OAuth WG のメンバーが Open Redirector の問題について話し合ったで。 数年前 JavaScript クライアントを想定してレスポンスの fragment encoding を採用する際、わいらはその選択についてそらぁ連日朝まで語り合ったもんや。 レスポンスの fragment encoding を採用した理由はいくつかある: JavaScript クライアントが token を取得するために、一度 serv
Covert Redirect Vulnerability with OAuth 2
tl;dr Covert Redirect Vulnerability is a real, if not new, threat when combined with Implicit Grant Flow (not Code flow) This Covert Redirect Vulnerability in OAuth 2 is an interesting one. There’s a couple of defending arguments that this isn’t a flaw in OAuth itself. While I agree that it isn’t a flaw in the protocol, I think the threat is a real one, combined with a) a loose validation on redir
パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
6月9日（日） に放映された「ほこ×たて」の「たて」の裏側について
2013/06/11 コース：元祖こってり 「元祖こってり」記事はネットエージェント旧ブログ[netagent-blog.jp]に掲載されていた記事であり、現在ネットエージェントに在籍していないライターの記事も含みます。 6月9日（日） に放映された「ほこ×たて」の「たて」の裏側について 2013年6月9日に放映されました、フジテレビ「ほこ×たて」に関しまして、反響が大きいようですので撮影の裏側をご紹介いたします。 まず、番組コーナー内の冒頭にご紹介いただきました弊社製品「防人」については、弊社がどのような会社なのかを簡単に紹介するということでお見せしましたが、防人はメールによる標的型攻撃を防ぐための製品ですので、その後の対決には一切使用していません。 実際の対決に際して防御側に求められたのは、サービスパックや修正プログラムの全く当てられていないパソコン上で、脆弱性が確実に存在しているサー
Same-Origin Policy とは何なのか。 - 葉っぱ日記
ちょっと凝ったWebアプリケーションを作成していたり、あるいはWebのセキュリティに関わっている人ならば「Same-Origin Policy」(SOP)という言葉を一度は聞いたことがあると思います。日本語では「同一生成元ポリシー」あるいは「同一生成源ポリシー」などと訳されることもありますが、個人的には「オリジン」は固有の概念を表す語なので下手に訳さず「同一オリジンポリシー」と書いておくのが好きです。 さて、この「オリジン」とは何なのかという話ですが、これは「RFC 6454 - The Web Origin Concept」で定められており、端的に言うと「スキーム、ホスト、ポート」の組み合わせをオリジンと定め、それらが同じものは同一のオリジンとして同じ保護範囲のリソースとして取り扱うということです。 例えば、http://example.jp/fooとhttp://example.jp:
ブログパーツやソーシャルボタンの類でアクセスログが残るのは当然だけどトラッキングされるのは当たり前にはなっていない - 最速転職研究会
わたくしは立場上、実装がダメなことにはとやかく言いますがポリシーについてはとやかく言わないことをポリシーとしており、また個人的にも所属組織的にも付き合いがある企業様を痛烈に批判するというのはブーメランとか槍とか鉄砲玉とかソーシャルメディアガイドラインとか飛んできたりしてリスキーではあるのですが、どう見てもアウトだろこれ、と考えるに至りまして筆を取らせていただく次第です。 これ http://d.hatena.ne.jp/kanose/20120306/hbmbutton http://blog.dtpwiki.jp/dtp/2011/09/post-9367.html どう見てもアウトだろ。理由は単純で、そういう目的で設置されたボタンではないし、はてなブックマークボタンが設置されているサイトは、はてなの管理してないサイトなのではてなの裁量でやってはいけないからです。いつから「はてな」は「は
クロスドメインでcookie書き込む方法 +クロスブラウザで - webネタ
あるサイトから別ドメインのクッキーを書き込む。こういうクッキーは、サードパーティクッキーと呼ばれる。FirefoxとChromeはデフォルトでサードパーティクッキーが書き込めるようになっているが、IEとSafariが問題になる。IEはコンパクトポリシーというものを設定すればいけるが、Safariは出来ない。Safariはデフォルトで”知らないとサイトや広告のみCookieをブロック”となっている。でも、GoogleAdsenseとかは書き込めている。なので調べた。 目的 localhostにアクセスしたときsample.comのクッキーを書き込みたい。 もちろんクロスブラウザで。 (sample.comはhosts書き換えやるといい) ポリシーの設定 (P3P) (以下IE対策用) webサイトで個人情報などを取り扱う場合、ブラウザで設定されたポリシー設定とアクセスしているサイトのポリシー
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
サードパーティCookieの歴史と現状 Part1 前提知識の共有 - 最速転職研究会
Web開発者のためのサードパーティCookieやらトラッキングやらの問題点について三回ぐらいに分けて書きます。 この文章は個人的に書いていますので、おい、お前のところのサービスがサードパーティCookieに依存してるじゃねーかというツッコミがあるかもしれないが、そういうことを気にしているといつまで経っても公開できないという問題が出てしまうので、そんなことはお構いなしに書く。ちなみに例外なく自社サービスに対してもサードパーティCookieに依存するな死ねと言っている。これはWebプログラマー観点で、自分がサービス開発に関わる上で知っておかねばならないだろう知識として十数年間だらだらとWebを見ていて自然に知っていたものと、あるいは興味を持って率先して調べたものが含まれている。ググッて直ぐに分かる程度の用語の定義的なことは書かない。あくまでWebサイト制作者側からの観点なので、ブラウザ開発関係
それ Unicode で
UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。
文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2010年9月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPカンファレンス2010にて「文字コードに起因する脆弱性とその対策」というタイトルで喋らせていただきました。プレゼンテーション資料をPDF形式とslideshare.netで公開しています。 文字コードのセキュリティというと、ややこしいイメージが強くて、スピーカーの前夜祭でも「聴衆の半分は置いてきぼりになるかもね」みたいな話をしていたのですが、意外にも「分かりやすかった」等の好意的な反応をtwitter等でいただき、驚くと共に喜んでいます。土曜にPHPカンファレンスに来られるような方は意識が高いというの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
超絶技巧CSRF / Shibuya.XSS techtalk #7
AWSのセキュリティについて
20130622 JAWS-UG大阪 AWSの共有責任モデル〜クラウドってセキュリティ大丈夫なの？と聞かれたら〜
