理解してるつもりの SSL/TLS でも、もっと理解したら面白かった話 · けんごのお屋敷
apache や nginx の設定をしたことがあれば以下の様な行を見たことがある人も多いのではないでしょうか。(※ 下記は nginx の設定。apache の場合は SSLCipherSuite です。) ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5; これが暗号スイートを指定している箇所です。そしてこの部分、わけのわからない文字列の羅列なのですごく取っつきにくくて何を指定したらいいかわからないので、コピペしてしまう人も多いんじゃないでしょうか。かくいう私も数年前に趣味で TLS 対応の Web サービスを作った時はコピペで済ませていました。この暗号スイートは、以下のような OpenSSL のコマンドを使って対応している一覧を見ることができます。 $ openssl ciphers -v AES128-SH
金融機関の口座集約アプリの危険性について - プログラマでありたい
先日、銀行口座の口座集約のとあるiOSアプリの記事について、危険だよなぁと何気なく呟いたら中の人からリプを貰いました。Twitterで呟いているのですが、文字だけでは解りにくいのでまとめてみます。ただ、そのアプリ固有の問題ではなく、構造的な問題なのでアプリ名は開示しません。（安全なので安心ですという論調は、どうかと思いますが。。。） 口座集約アプリの構造 口座集約のアプリは、アカウント・アグリゲーション(Account aggregation)サービスと言われています。サービスの実体は、複数の銀行の口座情報とID,Passwordを預かり、代行でログインして結果のhtmlを解析（スクレイピング）して利用明細や残高を集約するものです。口座とID,Password情報、解析エンジンをどこに置くかで、クライアント型とサーバ型に分類されます。 サーバ型アプリケーション まずサーバ型アプリケーション
脆弱性の危険度(ざっくり) - めもおきば
まあCVSSの解説見ろよって話なんだけど、ありがちな脆弱性の危険度は個人的にはこんなイメージです。 総合的な危険度 ＝ 条件 × 影響 条件 脆弱性の攻撃に必要な前提条件が「狭い」のであればそれほど問題ないです。 一番ヤバイ: TCPやUDP、IPによりネットワークから送られた通信で攻撃が成立 Slammer(しかもハンドシェークが不要なUDPのため被害が拡大) Heartbleed Shellshock、GHOST(ただし一部のミドルウェア) だいぶヤバイ: 通信路に割り込まないとイケない(MITM) *1 アクティブに通信に割り込むかどうかで度合いが変わる POODLEとか FREAK そこそこヤバイ: ネットワーク経由での攻撃ができるが、認証後でないと成立しない ヤバイ: ログイン後の一般ユーザーで攻撃が成立 ちょっとヤバイ: 弱い設定をしている場合など限られた条件でのみ攻撃が成立
情報処理推進機構：情報セキュリティ：脆弱性対策：安全なウェブサイトの作り方
「安全なウェブサイトの作り方」は、IPAが届出(*1)を受けた脆弱性関連情報を基に、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、ウェブサイト開発者や運営者が適切なセキュリティを考慮したウェブサイトを作成するための資料です。 「安全なウェブサイトの作り方」改訂第7版の内容 第1章では、「ウェブアプリケーションのセキュリティ実装」として、SQLインジェクション 、OSコマンド・インジェクション やクロスサイト・スクリプティング 等11種類の脆弱性を取り上げ、それぞれの脆弱性で発生しうる脅威や特に注意が必要なウェブサイトの特徴等を解説し、脆弱性の原因そのものをなくす根本的な解決策、攻撃による影響の低減を期待できる対策を示しています。 第2章では、「ウェブサイトの安全性向上のための取り組み」として、ウェブサーバの運用に関する対策やウェブサイトにおけるパスワードの取扱いに関す
第３３４号コラム「今年はソフトウェア脆弱性の当たり年？」 | デジタル・フォレンジック研究会
第３３４号コラム：上原 哲太郎 理事 （立命館大学 情報理工学部 情報システム学科 教授） 題：「今年はソフトウェア脆弱性の当たり年？」 今年(2014年)は本当に驚くほど深刻かつ影響範囲の大きいソフトウェア脆弱性が次々報告されており、後年から「当たり年」として記憶されるような年になりそうです。まずはそれを振り返ってみましょう。 まず4月、広範に使われているSSL/TLSライブラリであるOpenSSLに深刻な脆弱性が見つかりました。これはSSLの仕様にあるHeartbeatという機能の実装の不具合に起因していまして、攻撃者はこの不具合を突いてOpenSSLが用いられている各種サーバのプロセス内のメモリの一部を読み取ることができます。このメモリ内には、直前の利用者のユーザ名やパスワード、HTTPS通信時のCookie、そしてサーバ側の秘密鍵が入っている可能性があります。この脆弱性はその攻撃の
2 段階認証は本当に安全なのか調べてみた | はったりエンジニアの備忘録
このブログを読んでいる人なら Google や AWS の 2 段階認証（マルチファクタ認証）を有効にしていると思います。もしパスワードが漏れてしまってもワンタイムパスワードを入力しないと認証されないので安心です。 有名どころのサービスでは使えるところが増えてきましたが、2 段階認証を有効にしていれば万全なのでしょうか。エンジニアである以上、その仕組みを理解したうえで自信を持って安全と言いたいところ。 というわけで、2 段階認証は本当に安全なのか仕様を紐解きながら調べてみました。 ワンタイムパスワードの仕様 ワンタイムパスワードを生成する仕様は HOTP と TOTP の 2 つがあり、RFC の仕様になっています（TOTP はドラフト段階）。 HOTP (HMAC-Based One-Time Password Algorithm) TOTP (Time-Based One-Time P
AWS で作るシステムのセキュリティ考 - 水深1024m
AWS アカウントを複数人で使ってシステムを作っていく時に、 セキュリティの面からやるべきことについて。 主に Web アプリケーションを想定した内容ですが、特に書いてあることは特殊ではないと思います。 各所の Blog にも記事書かれてますが思っていることをつらつらと書いてみます。 なんか変なこと言ってたらご指摘ください。 参考: AWSのセキュリティが気になるなら読んでおくべきAWSセキュリティのベストプラクティス - yoshidashingo はじめに (AWS アカウントと IAM ユーザ) 前提というか用語の話。 AWS アカウント アカウント作成時のメールアドレス、パスワードでログインして使うユーザ IAM ユーザ AWS アカウントから発行できる、ユーザ名とパスワードでログインして使うユーザ AWS アカウント周り AWS アカウント (ルートユーザ) で作業できないように
全InternetExplorerに影響あり 攻撃も確認されているゼロデイ脆弱性公表 パッチが提供されるまでは緩和策を取ろう
TOP Security 全InternetExplorerに影響あり 攻撃も確認されているゼロデイ脆弱性公表 パッチが提供されるまでは緩和策を取ろう 米国時間2014年4月26日（日本時間同27日）、マイクロソフトが自社のブラウザであるInternetExplorerの脆弱性を公表しました。 Microsoft Security Advisory 2963983 上記、マイクロソフトのアドバイザリーでは現在サポートされているすべてのInternetExplorer（Ver6、7、8、9、10、11）に影響があるとのこと。 一方、この脆弱性を発見したセキュリティベンダーFireEyeのブログでは、InternetExplorer9、10、11が攻撃の対象となるとしています。 New Zero-Day Exploit targeting Internet Explorer Versions
Y!J API が止まった日 - GlobalSign の Root 証明書切れから学んだこと - OAuth.jp
昨日あたりから、Yahoo! Wallet や YConnect といった、Yahoo! Japan の API にアクセスできなくなったって人、ちらほらいるかもしれませんね。 僕もちょっとそういうケース見かけました。 なんか Yahoo! Japan がポカしちゃったの？とか、まぁ昨日まで健康に動いてたシステムが突然 Yahoo! Japan の API にアクセスできなくなっちゃったんだし、そらそう思うのもムリはない。 が、今回のケース、Yahoo! は全く悪くない！ プライバシーフリークはどうかと思うがな！！ では早速、今回起こったことを、振り返ってみましょう。 Yahoo! API にアクセスできなくなった Yahoo! Japan は、yahoo.co.jp 以外にも、CDN 用や API 用など、用途ごとにいくつかのドメインを持ってます。 今回止まったのは、その中の API 用
己を知り、敵を知る――Nmapで見つめ直す自分の姿 ― ＠IT
この記事が公開されるころは、年始ということでバタバタとしていることだろう。「長期休暇後」「新年を迎えて」といったように節目となり、心機一転という心境にもなるのではないだろうか。 そんな気持ちもあって今回は、自身が管理しているネットワークに対してポートスキャンを行い、開放しているサービスの確認・把握をいま一度行ってみようと思う。 ※ご注意 オープンポートの確認とはいえ、自身の管理下にないネットワークに行った場合は、攻撃行為と判断される場合があり、最悪の場合、法的処置を取られる可能性もあります。このような調査を行う場合は、くれぐれも許可を取ったうえで、自身の管理下にあるネットワークやサーバに対してのみ行ってください。 また、本稿を利用した行為による問題に関しましては、筆者およびアイティメディア株式会社は一切責任を負いかねます。ご了承ください。 敵は外部から――その「外部」って何を差してますか？
なぜb-casは失敗してインターネットはうまくいくのか？ - アンカテ
前のエントリで書いたように、b-casは用途を広げた時に前提条件が変わってしまったために、小さな「あってはならないこと」が起きただけで、手当ての方法が無くなってしまいました。 では、これと同じような見方で、インターネットそのものに「あってはならないこと」が起きた時どうなるか、について書いてみたいと思います。「インターネットそのもの」と言っても、一般の人が目にする「インターネット」の中でセキュリティをしっかり守らなければいけないのは、オンラインショッピングの時に使われる「SSL」という通信方式です。 アドレスが「https://」で始まるサイトにアクセスすると、そのアドレスの横に鍵の形の「安心マーク」が表示されます。オンラインショッピングで決済の画面やクレジットカード番号を入れる画面では必ずそうなっていると思いますが、これが今「SSL」を使っているよ、「SSL」がうまく動いているよというお知
徳丸本に載っていないWebアプリケーションセキュリティ
2. 本日お話しする内容 • キャッシュからの情報漏洩に注意 • クリックジャッキング入門 • Ajaxセキュリティ入門 • ドリランド カード増殖祭りはこうしておこった…かも? Copyright © 2012 HASH Consulting Corp. 2 3. 徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿など を開始 –
スマホアプリとプライバシーの「越えてはいけない一線」 － ＠IT
スマートフォンアプリは果たしてどこまで、端末に関する情報を取得してもいいのだろうか。 位置情報と連動してお勧め店舗情報を表示したり、過去の検索履歴を基に商品を提案したりと、端末の情報やユーザーの行動履歴を活用するスマートフォンアプリが登場している。中には便利なものも多いが、一歩間違えれば、ユーザーのプライベートな情報が筒抜けになりかねない。結果として、スマートフォンを活用したビジネスやそれを支える広告市場までもが、否定的な目で見られ、発展を阻害される恐れもある。 この議論が起こったきっかけの1つは、ミログが公開していた「AppLog」と「app.tv」というアプリだ。AppLogはSDKの形で提供され、これを自前のアプリに組み込むと、Android端末にインストールされているアプリの情報やその起動回数を収集し、同社のアプリケーション分析サービスに送信するようになっていた。開発者にはインスト
reCAPTCHAの無茶振りとその理由 - しろもじメモランダム
CAPTCHA（いわゆる画像認証）の実装の一つにGoogleのreCAPTCHAというものがあるが、今日の昼にこんなものに引っかかった。 ウムラウト付きのcaptchaとか微妙に難易度高いなこれｗ URL 2011-09-30 11:53:27 via Janetter2 @mashabow 私はbiſhopを出されたことがありますｗ bishopで通りましたが 2011-09-30 11:56:53 via Tween to @mashabow どうやらreCAPTCHAは、a–zの26文字以外のアルファベットも出してくるらしい。面白そうだったので、更新ボタン（矢印が巴形になっているボタン）を押しまくって変なものが出てこないか探してみた。 reCAPTCHAの無茶振り・初級篇 thouſand。上のツイートにも出てきた ſ はいわゆる長いsで、現代風に表記すれば thousand。古い本
本当は怖いパスワードの話 ハッシュとソルト、ストレッチングを正しく理解する － ＠IT
PSN侵入の件から始めよう 今年のセキュリティの話題の中でも特に注目されたものとして、4月20日に起こったPSN侵入事件があります。5月1日にソニーが記者会見をネット中継したことから、ゴールデンウィーク中にもかかわらず多くの方がネット中継を視聴し、感想をTwitterに流しました。もちろん、筆者もその1人です。 このときの様子は、「セキュリティクラスタまとめのまとめ」を連載している山本洋介山さんが、Togetterでまとめています。 Togetterのまとめを読むと、漏えいしたパスワードがどのように保護されていたかが非常に注目されていることが分かります。Togetterのタイムラインで、14:48ごろにいったん「パスワードは平文保存されていた」と発表されると、「そんな馬鹿な」という、呆れたり、驚いたりのつぶやきが非常に多数流れます。 しかし、15:03ごろに「パスワードは暗号化されてなかっ
都道府県型JPドメインがCookieに及ぼす影響の調査
JPRSからのプレスリリース『JPRSが、地域に根ざした新たなドメイン名空間「都道府県型JPドメイン名」の新設を決定』や報道などで「都道府県型JPドメイン」というものが新設されることを知りました。 都道府県型JPドメインとは、現在活発に使われていない地域型ドメインを活性化する目的で、地域型ドメインの制約（ドメイン名が長い、一人・一団体あたり1つまで）を簡略化しようというもののようです。 しかし、現在の地域型ドメインは、ブラウザにとって処理がややこしいもので、IEなどは昔からまともに対応していません。このため、Cookie Monster Bugという脆弱性になっているという経緯があります。このルールをさらに複雑にすることになるということから、ブラウザセキュリティに関心の高い人たちが騒ぎ始めています。 そこで、高木浩光氏の日記「JPRSに対する都道府県型JPドメイン名新設に係る公開質問」の以
ORCA愉快日記(2010-03)
_ [Ubuntu] Ubuntu Server版とDesktop版の違いメモ 以前Ubuntu 8.04の違いについて調べたものをまとめたもの。少し情報が古くなっていますが、根本的なServer版とDesktop版の指向の違いは変わっていません。 追記 :Ubuntu 10.04などの最近の環境では、標準カーネル以外に、4GB以上のメモリを認識できるようPAE機能を有効にしたカーネル linux-image-generic-pae などのパッケージもリリースされています。 □ Ubuntu Server版とDesktop版の違い Ubuntuの主なエディションとして、Desktop版とServer版がある。 参照しているソフトウェアリポジトリは一緒のため、パッケージそのものは 同じものがインストールされるが、デフォルトでインストールされるパッケージの数や種類は異なる。 また、カーネルにつ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
共用サーバにおけるSymlink Attacksによる攻撃とその対策について - さくらインターネット創業日記
Node.js のセキュリティの話
暗号化と署名は対称じゃないよという話 - まちゅダイアリー (2008-03-02)