OpenSSLの脆弱性で想定されるリスク - めもおきば
JVNやJPCERT/CCの記事があまりにもさらっと書かれていて、具体的なリスクが想像しづらいと思うので説明します。 今北産業 (今ニュース見て来たから三行で教えて欲しいという人向けのまとめ) インターネット上の「暗号化」に使われているOpenSSLというソフトウェアが2年間壊れていました。 このソフトウェアは便利なので、FacebookだとかYouTubeだとか、あちこちのウェブサイトで使っていました。 他の人の入力したIDとかパスワードとかクレカ番号とかを、悪い人が見ることができてしまいます。(実際に漏れてる例) 他にも色々漏れてますが、とりあえずエンジニア以外の人が覚えておくべきはここまででOKです。もう少し分かりやすい情報が以下にあります。 OpenSSL の脆弱性に対する、ウェブサイト利用者（一般ユーザ）の対応について まだ直っていないウェブサイトもあれば、元々壊れていないウェブ
なぜRubyと違い、PHPの正規表現で^$の利用は致命的な問題ではないのか？
(Last Updated On: 2018年8月13日)Rubyデフォルトの正規表現では^は行の先頭、$は改行を含む行末にマッチします。PHPのPCREとmbregexでは^はデータの先頭、$は改行を含む行末にマッチします。 この仕様の違いはデータのバリデーションに大きく影響します。 参考： PHPer向け、Ruby/Railsの落とし穴 の続きの解説になります。こちらのエントリもどうぞ。 なぜ^と$が行の先頭と行の末尾にマッチするのか？ そもそも正規表現はテキスト検索を行うステートマシーンとして設計されました。通常テキストには改行があります。特定の行に一致するかどうかテストするように設計するのが自然です。この為、正規表現の^と$は行の先頭と末尾にマッチするように設計されたと考えられます。 正規表現をバリデーションに利用することは可能です。しかし、そもそもは正規表現に一致する「テキスト」
Heart Bleedを読んだ - The first cry of Atom
int dtls1_process_heartbeat(SSL *s) { unsigned char *p = &s->s3->rrec.data[0], *pl; unsigned short hbtype; unsigned int payload; unsigned int padding = 16; /* Use minimum padding */ heartbeatという機能の詳しいことは調べられていないけれどどうやらクライアントーサーバ型の機能を提供するものらしい。 つまり何らかのリクエストを受け取ってレスポンスを返すようなサービスを提供するものらしい。dtls1_process_heartbeatで大事なのは ポインタpだ。これはリクエストデータを受け取って格納している。このリクエストデータは構造体になっていて、以下のように記述されている。 typedef struct
CVE-2014-0160 OpenSSL Heartbleed 脆弱性まとめ - めもおきば
必要な情報は http://heartbleed.com/ にまとまっているのですが、英語だし長いしって人のために手短にまとめておきます。 どうすればいいのか OpenSSL 1.0.1〜1.0.1fを使っていなければセーフ あてはまる場合には、一刻も早くバージョンアップして、サーバごと再起動(わかるひとはサービス単位でもOK、ただしreloadではだめなことも) SSL証明書でサーバを公開しているなら、秘密鍵から作り直して証明書を再発行し、過去の証明書を失効させる(末尾に関連リンクあり)。 サーバを公開していない場合も、外部へのSSL通信があれば影響を受けるので、詳しく精査する。 PFS(perfect forward secrecy)を利用していない場合、過去の通信内容も復号される可能性があるため、詳しく精査する。 漏洩する情報の具体例は、OpenSSLの脆弱性で想定されるリスクとして
OpenSSLに脆弱性、クライアントやサーバにメモリ露呈の恐れ
オープンソースのSSL／TLS実装ライブラリ「OpenSSL」に64Kバイトのメモリが露呈されてしまう脆弱性が発覚し、この問題を修正した「OpenSSL 1.0.1g」が4月7日に公開された。 OpenSSLのセキュリティ情報によると、脆弱性はTLS Heartbeat拡張の処理における境界チェックの不備に起因する。悪用された場合、最大64Kバイトのメモリが接続されたクライアントやサーバに露呈される恐れがある。 この脆弱性は、OpenSSL 1.0.1fと1.0.2-beta1を含む1.0.1および1.0.2-betaリリースに存在しており、1.0.1gで修正された。直ちにアップグレードできない場合のために、「OPENSSL_NO_HEARTBEATS」のフラグを有効にして再コンパイルする方法も紹介している。 この問題についてOpenSSLを使ったサービスを提供しているセキュリティ企業のC
QiitaにXSS脆弱性 - Qiita
Qiitaに発生していた脆弱性について ※ エイプリルフールネタっぽいけど実際に発生していました。 ※ 現在この脆弱性は修正済みです。 問題のあった記事 問題のMarkdown おいしいクッキーを食べたい人はここをクリック！ **[おいしいクッキーを食べたい人はここをクリック！](data:text/html;base64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpPC9zY3JpcHQ+)** ブラウザ別の挙動 Chrome 33.0 データURIスキームの先で document.cookie を参照することは出来なかった。 Firefox 28.0 データURIスキームの先で document.cookie を参照することが 出来た 。 Internet Explorer とかその他もろもろ 編集リクエストに任せるぜ！ 考察 結局これってやばいの？
ANAの不正ログイン事件について徳丸さんに聞いてみた
高橋: こんにちは、高橋です。先月に引き続き徳丸さんをお招きして、今度はANAの不正ログイン事件についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: 徳丸です。よろしくお願いします。 高橋: まず、事件の概要を説明します。「ANAマイレージクラブ」のWebサイトに不正ログインがあり、顧客9人のマイレージ、総計112万マイルがiTunesギフトコードに勝手に交換されていたとするものです。当初顧客の通報で発覚した点はJALの場合と同じですね（参考）。 徳丸: で、私はなにをしゃべればいいのですかね。お招きいただいたので出てきましたが、パスワードがJALは数字6桁、ANAは4桁ですが、それ以外はあまり変わらないのですよね。 高橋: JAL、ANAと事件が続きましたが、攻撃手口は見えてきていないのでしょうか? 徳丸: 公式発表も報道もあまり情報がないので確定的なことは言えないのですが、
Composer のセキュリティ上の問題が直ったので PHP な方は今すぐ更新を - co3k.org
Composer の以下の問題が 2 月半ばあたりから話題になっていました。 Limit Replace / Provides to packages required by name in root package or any dep · Issue #2690 · composer/composer https://github.com/composer/composer/issues/2690 一言で言うと、 条件によってはユーザの意図しないパッケージがインストールされてしまう という問題です。悪意のあるパッケージをインストールしたことに気づかれなければ、攻撃者の思い通りのコードを実行させることができてしまいます。 ざっくり説明すると、 Composer には fork したパッケージや、リネームしたパッケージ から 、元のパッケージを置き換えることのできる機能が存在する (本エン
SSL暗号を無効化する仕組み – BREACH, CRIME, etc
(Last Updated On: 2018年8月4日)CRIMEやBREACHといったSSL暗号を無効化する攻撃を知っている方は多いと思います。しかし、その仕組みや攻撃方法は広くは理解されていないようです。Webシステムに関わる方であれば、BREACH攻撃の原理と対策を理解しておいて損はありません。BREACHや類似の攻撃は全く難しくありません。直ぐに理解できると思います。原理は簡単です！ CRIMEとBREACH攻撃 CRIMEもBREACHも暗号を解読せずに暗号コンテンツを解読する攻撃です。暗号を直接解読するのではなく、圧縮後のサイズ変化を利用したサイドチャネル攻撃を行います。サイドチャネル攻撃とは攻撃対象のセキュリティ対策（CRIME、BREACHの場合は暗号）などを直接攻撃するのではなく、動作を観察して攻撃する手法です。前回のエントリで紹介したタイミング攻撃では、コンピューターの
hata's LABlog: CSRF対策 with JavaScript
JavaScript を使った CSRF 対策の方法として、以前 Kazuho@Cybozu Labs で紹介されました。 CSRF 対策 w. JavaScript CSSXSS に対して脆弱でない CSRF 対策とはどのようなものか、という議論が続いているようですが、JavaScript を用いてよいのであれば、簡単な対策手法が存在すると思います。 ここでさらに一歩進めて、既存の FORM 要素に onsubmit 属性、および hiddenフィールドを直接追加せずに、JavaScript ファイルを１つインクルードすることにより、既存アプリケーションの書き換えをさらに少なくする方法を紹介したいと思います。 以下の JavaScript ファイルをHTMLの最後でインクルードする方法です。 fight_csrf.js sessid_name = ""; scripts = docume
Kazuho@Cybozu Labs: CSRF 対策 w. JavaScript
« PERL5WEBDB | メイン | IIS のログを tail -f » 2006年04月11日 CSRF 対策 w. JavaScript CSSXSS に対して脆弱でない CSRF 対策とはどのようなものか、という議論が続いているようですが、JavaScript を用いてよいのであれば、簡単な対策手法が存在すると思います。 CSRF 対策では、フォームの hidden パラメタに、なんらかのトークンを埋め込むことで、第三者によるフォーム偽造を防止するのが一般的です。しかし、 CSSXSS を用いて、そのトークンを第三者が読み出せてしまうという点が、問題をややこしくしているように思えます注2。 しかし、 JavaScript を用いて良い環境では、単純な対策が存在すると思います。 HTML 内にあらかじめトークンを埋め込んでおくのではなく、フォーム送信時に、ブラウザ側でトークンを埋
CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある - co3k.org
CSRF 脆弱性対策には攻撃者の知り得ない秘密情報をリクエストに対して要求すればよく、そのような用途としてはセッション ID がお手軽でいいよねという時代があったかと思います。 いや、もちろん、 CSRF 対策の文脈だけで言えば今も昔も間違いというわけではありません。セッション ID が秘密情報であるのは Web アプリケーションにおいて当然の前提ですので、 CSRF 対策としてリクエストに求めるべきパラメータとしての条件はたしかに満たしています。 たとえば 『安全なウェブサイトの作り方』 改訂第6版では以下のように解説されています。 6-(i)-a. (中略) その「hidden パラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。 (中略) この秘密情報は、セッション管理に使用しているセッション ID を用いる方法の他、
ntpd の monlist 機能を使った DDoS 攻撃に関する注意喚起
各位 JPCERT-AT-2014-0001 JPCERT/CC 2014-01-15 <<< JPCERT/CC Alert 2014-01-15 >>> ntpd の monlist 機能を使った DDoS 攻撃に関する注意喚起 https://www.jpcert.or.jp/at/2014/at140001.html I. 概要 NTP Project が提供する ntpd の一部のバージョンには、NTP サーバの状態 を確認する機能 (monlist) が実装されており、同機能は遠隔からサービス運 用妨害 (DDoS) 攻撃に使用される可能性があります。 NTP は、通常 UDP を使用して通信するため、容易に送信元 IP アドレスを 詐称することができます。また、monlist 機能は、サーバへのリクエストに対 して大きなサイズのデータを送信元 IP アドレスへ返送するため、攻
PHP本体でタイミング攻撃を防御できるようになります
(Last Updated On: 2021年3月25日) PHP 5.6からタイミング攻撃に対する対策が導入されます。メジャーなアプリケーションはタイミング攻撃対策が導入されていますが、PHP 5.6から簡単に対策できるようになります。 タイミングセーフな文字列比較関数はhash_equalsとして実装されました。 http://php.net/manual/es/function.hash-equals.php タイミング攻撃とは タイミング攻撃とは、コンピュータが動作する時間の違いを測って攻撃する、サイドチャネル攻撃（副作用攻撃）と呼ばれる攻撃手法の１つです。HTTPSの圧縮の副作用を利用したサイドチャネル攻撃が有名です。 コンピュータの動作時間、温度、音、電子ノイズ、電力使用量など、アルゴリズム自体の脆弱性を攻撃するのではなく副産物を利用する攻撃方法でサイドチャネル攻撃の一種です。
二要素認証のメリット ～二要素認証について知っておくべき事～ - 2月 - 2014 - ソフォス プレス リリース、セキュリティニュース、ソフォスに関するニュース記事 - Sophos Press Office | Sophos News and Press Releases
※この記事は本社サイト 「Naked Security」掲載の記事を翻訳したものです※ by Chester Wisniewski on January 31, 2014 この記事に関する最新の更新情報は Naked Security 掲載記事をご確認ください。 本記事では、二要素認証とは何か、どのように機能し、どのような場面で使用するのかなど、二要素認証の重要な点を説明します。 パスワードのデータベースへの侵入、フィッシング攻撃、すべてのキーストロークを記録するマルウェア、近所の ATM や行きつけの店舗に取り付けられたクレジットカードスキミング機器などの事件は繰り返し発生しています。 かつては 8 文字のパスワードでも十分でしたが、今ではより堅牢で信頼性の高い認証方法が必要となっています。 二要素認証の概要 マルチファクタ認証 / 二段階認証とも呼ばれることのある二要素認証 (2FA)
数字6桁パスワードのハッシュ値の総当たり、PHPなら約0.25秒で終わるよ
JALの6桁数字パスワード問題から派生して、JALのサイトがパスワードリマインダとして「現在のパスワード」を教えてくれることから、JALサイトではパスワードを平文保存しているのではないかという疑惑が持ち上がっています。それに対して、「いやいや、従来の主流と思われるソルト付きMD5ハッシュでの保存しても、実用的な速度でハッシュ値から元パスワードを『解読』できるよ」と、JALを擁護（?）するエントリが現れました。 パスワード問合せシステムを作る (clojureのreducers) この記事では、最初Clojureによる単純な総当たりで36秒、Clojureのreducersによる並列化で11秒でハッシュ値から元パスワードが求められるよ、と説明されています。まことに痛快な記事ですので、未読の方には一読をお勧めします。 とはいうものの、100万件のMD5の総当たりが、逐次実行で36秒、並列化して
パスワード問合せシステムを作る (clojureのreducers) - Qiita
現在のパスワードを教えてくれるからといって、「平文で保存してる！くぁwせdrftgyふじこlp」と脊髄反射してはいけません。 JALの6桁数字パスワードがどう格納されているか? 古いシステムなのでMD5でハッシュ化していると想定しますが、もちろんsaltは付けているでしょう。 さて、そんなパスワード保管方式で、現在のパスワード問合せに応答するシステムを作ってみます。 パスワードを「567890」、saltを「hoge」として、データベースには"hoge$567890"のMD5値"4b364677946ccf79f841114e73ccaf4f"が格納されているとします。 総当りしてみましょう。 (ns six-length.core (:require [clojure.core.reducers :as r]) (:import [java.security MessageDigest
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
XML と PHP のイケナイ関係 (セキュリティ的な意味で) -Introduction of XXE attack and XML Bomb with PHP-
CSRF対策用トークンの値にセッションIDそのものを使ってもいい時代なんて、そもそも無かった
Flashと特定ブラウザの組み合わせでcross originでカスタムヘッダ付与が出来てしまう問題が未だに直っていない話