2011年11月29日のブックマーク (4件)

  • au の F001 に存在した EZ 番号詐称の脆弱性について - co3k.org

    このエントリでは、海老原が 11/11 に発見した、「F001 の PC サイトビューアを利用して EZ 番号の作業がおこなえる」という脆弱性について説明します。 この脆弱性を利用されると、たとえば、「かんたんログイン」などの機能を提供する勝手サイトにおいて、 au 端末を利用したユーザになりすまされてしまうといった被害が発生しえます。 問題の解決に向けてご協力いただいた 徳丸さんのブログエントリ にも詳しく触れられていますのでそちらもご一読ください。 おさらい 徳丸浩さんの以下のエントリで説明されているとおり、 au の 2011 年秋冬モデルの端末でおこなわれる(と宣言されている)変更が、「かんたんログイン」等の用途で使われている EZ 番号の詐称を許す可能性があるのではないかと多くの方々の間で懸念されていました。 IPアドレスについてはKDDI au: 技術情報 > IPアドレス

    mumincacao
    mumincacao 2011/11/29
    Apache さん『.』を『_』に変換してくれるけどろぐでは上書き前の UA を残してくれるですか!?(・ロ【みかん とはいえ UA が偽装されて無い前提の時点でちょっとあれな気もするし・・・
  • KDDIの新GWで「かんたんログイン」なりすましの危険性あり直ちに対策された

    au/KDDIの2011年秋冬モデル(現時点ではF001のみ)にてEZwebとPCサイトビューア(以下PCSV)のゲートウェイが統合されたことに伴い、かんたんログインを実装しているサイトに対して、F001のPCSVからJavaScriptを用いた「なりすまし」攻撃ができる状態でした。この問題をKDDIに通報したところ、直ちに対策が取られ、現在は安全な状態です。以下、詳しく報告します。 目次概要 経緯 何が問題か 経緯説明(1)基的なチェックは対処済みだった 経緯説明(2)ハイフンをアンダースコアに変えるトリックは対策済み 経緯説明(3)海老原氏が発見したトリックとは 経緯説明(4)KDDIに連絡→翌日に対処 実証例 外部からJavaScriptを実行できる条件 影響を受けるサイトの条件 影響 対策 今回の問題は、端末あるいはau設備の脆弱性なのか まとめ 概要以前、「EZwebの2011

    KDDIの新GWで「かんたんログイン」なりすましの危険性あり直ちに対策された
    mumincacao
    mumincacao 2011/11/29
    勝手に PHP だけの問題と見てるひと居るけど Apache の CGI 経由で Perl, Python, Ruby 試してみたけど全部引っかかるにう・・・ (・x【みかん
  • 第44回 セキュリティ対策が確実に実施されない2つの理由 | gihyo.jp

    セキュリティ対策は言語やアプリケーションを問わず非常に重要です。しかし、取るべきセキュリティ対策が確実に実施されないケースが広く見受けられます。 最近の例では次のような物があります。 WordPress Meenews 5.1 Cross Site Scripting WordPress Enable-Latex Remote File Inclusion Dolibarr 3.1.0 RC Cross Site Scripting / SQL Injection 上のURLの脆弱性も対策が簡単なものが多いですが、対策が簡単なSQLインジェクションの脆弱性も数多く見つかっています。 CMS Balitbang 3.x SQL Injection AdaptCMS 2.x SQL Injection Icomex CMS SQL Injection なぜ簡単な対策で防げる脆弱性でもセキュリテ

    第44回 セキュリティ対策が確実に実施されない2つの理由 | gihyo.jp
    mumincacao
    mumincacao 2011/11/29
    『入力値の妥当性ちぇっく』と『出力時のえすけーぷ』は別物なのになんで重複処理扱いされるのかなぁ? 多重のせきゅりてぃ対策ってなに指してるのかさっぱり・・・ (´・ω【みかん
  • 静的プリペアドステートメントが「原理的に安全」な理由 - がるの健忘録

    ものっそ大雑把に説明をしていきます。 「わかりやすさ」中心なので、「現在(ここほんの40〜50年くらい)の素晴らしい技術(アルゴリズム考え方アーキテクチャその他)」には大分と背を向けている可能性がありますのでご注意ください B-p 真面目にSQLのパースあたりとかを知りたかったら、是非具体的なソースコードを読んでみてくださいませ。 さて。 ざっくりと解説をするために、SQL文を非常に「簡単に」してみます。あちこち漏れてますが、その辺は適宜脳内補完をお願いいたします。 とりあえず、SQLには「以下の機能がある」と仮定します。 ・読み書きどっち? SELECTなのかINSERTなのかUPDATEなのか ・対象テーブル どのテーブルに対する操作要求なのか ・対象カラムとか値とか SELECTならナニを読みたいのか? insertとupdateならどこにナニを書きたいのか? ・レコードに対する制限

    静的プリペアドステートメントが「原理的に安全」な理由 - がるの健忘録
    mumincacao
    mumincacao 2011/11/29
    そいえば『こんな SQL になるから SQL Injection されちゃうね』はよく見かけるけど『DB の中の人がこう読んじゃうから』はみんなわかってる前提になってること多いのかなぁ?(・x【みかん