オレオレ証明書をopensslで作る（詳細版） - ろば電子が詰まつてゐる
前回のopensslでRSA暗号と遊ぶでRSA暗号や秘密鍵について中身を色々といじってみた。続いて今回は、Apacheで使うオレオレ証明書を作ってみる。 細かいことはいいから、オレオレ証明書を作るコマンドだけ知りたい お急ぎの方は、以下3つだけやれば良い。これで10年間(3650日)有効なオレオレ証明書ができあがる。 $ openssl genrsa 2048 > server.key $ openssl req -new -key server.key > server.csr $ openssl x509 -days 3650 -req -signkey server.key < server.csr > server.crtできあがったserver.crtとserver.keyを、例えば/etc/httpd/conf/ 配下のssl.crt/ と ssl.key/ ディレクトリに設置
HTTPS通信時のURLは暗号化されるか - うまいぼうぶろぐ
2018/06 追記 古い記事ですがちょこちょこアクセスいただいているので更新。 最近は常時SSL、IPv4枯渇、CDN導入などの理由でSNIが良く使われるようになってきていますが この場合、ホスト名(URL全体ではない)は平文で送信されます。 client 側でキャプチャしたパケット curl -k https://sni.example.com/hogehoge $ sudo ngrep -d en3 -q -W byline port 443 and host 192.0.2.1 interface: en3 (192.168.6.0/255.255.255.0) filter: (ip or ip6) and ( port 443 and host 192.0.2.1 ) T 192.168.6.108:55460 -> 192.0.2.1:443 [AP] ...........
Webプラットフォームのセキュリティ
4. 事前学習を振り返る • HSTSを元に次のような問題点を考察した その技術では解決できない問題 端末時刻の改ざんによるHSTSの強制失効 その技術の導入により新たに生じる問題 HSTSを用いたユーザー追跡 (HSTS Supercookies) 実装の誤りに起因する問題 指定を誤るとHTTPS非対応のサブドメインがアクセス不能に 仕様上既定されていない振る舞い HSTSはWebSocket(ws:)にも適用されるのか？ CVE-2015-1244: Chrome でWebSocketにHSTSが適用されない HSTSはプライバシーモードにも引き継ぐのか？ またその逆は？ 7. 私の戦歴(参考) • 次のような仕様不備を脆弱性として指摘してきた ChromeのCSP違反レポートの送信先が<base>で制御できる https://crbug.com/431218 ChromeのHTML
Spring Security 4.0: WebSocket, Spring Data, テストサポート
Spring SecurityチームがSpring Security 4.0.0をリリースした。いくつかの新機能の他，デフォルトでのセキュリティも強化されている。WebSocket Security，Spring Data統合，テストサポートの改善，新たな(Apacheライセンスの)オープンソースプロジェクトとしてSpring Sessionの導入などが主要なテーマだ。Spring Sessionによって，カスタムバックエンドをプロジェクトのHttpSessionプロバイダとして簡単に開発できるようになり，任意の環境からのセッションへのアクセス，クラスタリングのサポートが可能になると同時に，プラグイン可能なセッションIDとWebSocketのサポートも提供される。 WebSocket Security Spring SecurityがSpringのWebSocketサポートと併用できるよう
HTTPS 化する Web をどう考えるか - Block Rockin’ Codes
Update 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。 2015/5/8: 構成を一部修正しました。 Intro 4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。 Deprecating Non-Secure HTTP | Mozilla Security Blog エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 本エントリも同じく CC BY-SA 3.0 とします。 Deprecating Non-Secure HTTP 原文: Deprecating Non-Secure HTTP 今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。 HTTPS が Web を前進させる手段である
HashiCorp社が出したVaultとはどういうものなのか - 理系学生日記
HashiCorp 社から、新たなソフトウェアである Vault by HashiCorp がリリースされました。 - HashiCorp Blog: Vault この Vault について、Getting Started を一通り実施した後に Docs の一部を確認してみたので、簡単にその内容をまとめてみます。 Vault とは何なのか Vault を一言で言うと、機密情報(Secret) を管理するツールです。 これだけ IT が広がっている現在、機密情報の範囲も広がり続けており、データベースにアクセスするためのユーザ/パスワードや、連携するシステムの API キー等、多岐に渡ります。こういった情報、おまえのところのシステムではどう管理してた？XML に生で書いてる、あるよねそういうの。jdbc.properties に直書き、うんうんわかるわかる。ちょっとがんばったら crypt で
ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について
ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について The sad state of sysadmin in the age of containers コンテナー時代のシステム管理者の惨状 システム管理は惨劇に見舞われている。現状は悲惨だ。 筆者は昔気質のシステム管理者に不満はない。システムの稼働を維持し、アップデートし、アップグレードする方法を知っている者達だ。 この憤りは、コンテナーと構築済みVMと、それらがもたらす、「信頼」や「アップグレード」の欠如による悲惨な惨劇に対するものだ。 例えば、Hadoopを見てみろ。誰もHadoopをスクラッチからビルドする方法を知っているようには見えないぞ。依存性とバージョンとビルドツールが悲惨なほどに絡まりあっている。 この手のイケてるツールの中で、古典的なmake
インターネットに接続しないWindowsXP機はサポートが切れても安全
菊池雅志 @MasashiKikuchi 〝サポート終了後はウイルス感染の危険が高まるなどサイバー攻撃に無防備に〟…なんだか危険を煽るけど、無駄金かけるよりインターネットから遮断して、自治体のLAN内で使う分には構わないのでは？/ 期限切れＸＰ、自治体５４％に２０万台（読） http://t.co/9tmuu5McfR 菊池雅志 @MasashiKikuchi そもそも「MSのサポートが切れるから危険」=「MSのサポートがあれば安全」という考え方が短絡。行政は、文書の作成と発行が多く、最新鋭のシステムに投資する必要はないし、利用者の〝慣れ〟の点でも無駄が多い。いたずらに危険を煽るのは、メディアとMSとメーカーの商売に過ぎない。
高木浩光＠自宅の日記 - Tポイントは何を改善しなかったか, Tポイント以外は何をやっていないか
■ Tポイントは何を改善しなかったか さて、昨年9月に、「Tポイントは本当は何をやっているのか」を書いてからもう9か月経った。その後、この件がどうなったかを確認しておく。 まず、問題となった「T会員規約」だが、10月1日に（毎年恒例の）改訂があったが、文言が少し直された程度で、問題とされていた肝心の部分は、何ら修正されなかった。 第4条 （個人情報について） 2. 当社が取得する会員の個人情報の項目 （1）「お客様登録申込書」の記載事項及びT-IDお申し込み時の登録事項（変更のお申し出の内容を含みます）氏名、性別、生年月日、住所、電話番号、電子メールアドレス等 （2）ポイントプログラム参加企業における利用の履歴 （3）T-ID及びＴカードの停止・退会状況その他第3条第2項に関する事項 （4）ポイントの付与又は使用等に関する情報 （5）クレジットカード番号 （6）その他の記述または個人別に付
感想： 体系的に学ぶ 安全なWebアプリケーションの作り方 - penultの日記
読んでます。 体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践 作者: 徳丸浩出版社/メーカー: SBクリエイティブ発売日: 2011/03/01メディア: 単行本購入: 119人 クリック: 4,283回この商品を含むブログ (146件) を見る まだ途中だけど、主にJava/Tomcatユーザとしての備忘メモ。ただし、セキュリティの専門家でも何でもないので間違いは大いにあると思われます。 HttpOnly 属性の指定（p.103） Tomcat では、Tomcat7以降（Servlet 3.0以降）なら単純に web.xml か web-fragment.xml に <session-config> <cookie-config> <http-only>true</http-only> </cookie-config> </session-confi
高木浩光＠自宅の日記 - ASPとかJSPとかPHPとかERBとか、逆だったらよかったのに
■ プログラミング解説書籍の脆弱性をどうするか 印刷されて流通する書籍に脆弱性がある、つまり掲載されているサンプルコードにズバリ脆弱性があるとか、脆弱性を産みやすいコーディングスタイルを身につけさせている解説があり、それが脆弱なプログラマを生産し続ける根源になっている問題は、「なんとかしないといけないねえ」と以前から言われてきた。 ソフトウェア製品の脆弱性は、指摘があればパッチが提供されたり修正版に差し替えられたりするが、書籍の脆弱性はどうか。正誤表が差し込まれるとか、回収する措置がとられるかというと、それは望めそうにない。言論には言論で対抗すればよいということになるだろうか。 久しぶりにいくつかの書籍について調べてみた。先月園田さんの日記などで比較的評判良く紹介されていた2冊を読んだ。 山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, 2004年6月 GIJOE, PHP
「Java 7 Update 11でも脆弱性は残っているから引き続きJava無効化を」という話について
「Java SE 7 Update 11 でもバグが修正されていない」という専門家の意見が書いてあるロイター通信の記事（Oracle updates Java, security expert says it still has bugs）をTwitterで紹介しましたが、「やはり修正されていない」「修正されたのは２つの脆弱性の内の一つだけ」というニュース記事が複数出てきました。 これらのニュース記事には、「Java 7 Update 11でも脆弱性は残っているから、Java(Java appletを起動するためのブラウザ上のJavaプラグイン)をひきつづき無効化せよ」という内容のCERTの意見が掲載されています（無効化手順はこちら）。 しかし、日本語の記事が曖昧で、少し情報源のページを読んでみると、単に「片方が修正されていないから危険」というわけではない、ちょっとややこしい話のようだった
なぜあなたがウェブサイトをHTTPS化するとサイトが遅くなってユーザーが逃げていくのか - 射撃しつつ前転 改
完全に釣りタイトルですけど中身は真面目に書くよ。 近年、ウェブサイトのHTTPS化が流行のようになっている。私の知る限り、Googleの各種サービスやTwitter、Facebookなどが完全にHTTPSで通信を行うようになっている。HTTPS、つまりSSLによる通信の暗号化によって、ユーザにこれまでよりも安全なウェブサイトを提供できる。 しかし、あなたが作っているサイトをふと思いつきでHTTPS化してしまうと、たぶん、これまでよりもサイトが遅くなる。ここでは、HTTPSで通信する場合の問題を解説する。 なぜ遅くなるのか HTTPで通信する場合、クライアントがサーバへと接続するためにはTCP/IPの3ウェイハンドシェイクという手順が必要になる。めんどくさいのでここでは詳しくは説明しないが、要するにクライアントがリクエストを投げる前にパケットを１往復させないといけないのである。パケットの往復
単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる
In some of the feedback I have gotten on the openID Connect spec, the statement is made that Connect is too complicated. That OAuth 2.0 is all you need to do authentication. Many point to Identity Pro… 英語読みたくないという人のために簡単に解説すると… OAuth 2.0 の implicit flow を使って「認証」をしようとすると、とっても大きな穴が開きます。 カット＆ペーストアタックが可能だからです。 OAuth 認証？は、図１のような流れになります。 図１ OAuth 認証？の流れ 一見、問題なさそうに見えます。しかし、それはすべてのサイトが「良いサイト」ならばです。 Site_A
開発者のための正しいCSRF対策
著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで本稿ではウェブアプリケーション開発者にとっての本当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日本政府のパーソナルデータ取り扱い方針を巡り、ヤフージャパンが過激な主張をして炎上(山本一郎) - 個人 - Yahoo!ニュース
http://www.matsuaz.com/matsumotojs/2012/01/10/1326123359251.html