タグ

ブックマーク / tumblr.tokumaru.org (7)

  • WordPressのプラグインCP Multi View Event CalendarにSQLインジェクション脆弱性

    海外の脆弱性投稿サイトにてWordPress CP Multi View Event Calendar 1.01にSQLインジェクション脆弱性が報告されています。当方で追試をしたところ、確かにSQLインジェクション脆弱性があり、データベース内の任意のデータが漏洩することが分かりました。 大変危険な脆弱性ですが、今のところ対策バージョンは出ていないため、当該プラグインの使用を停止するしかなさそうです。WAFによる防御は有効と考えられますが、WAFの性能次第です。 前述のように、現在はゼロデイ脆弱性の状態ですので、詳細情報の公表はさし控えます。

    WordPressのプラグインCP Multi View Event CalendarにSQLインジェクション脆弱性
  • PHP5.4.24、PHP5.5.8以降で、__autoloadのクラス名チェックが実装されることに

    また、is_a関数(元々はis_subclass_of関数)が、クラス未定義の場合に__autoloadを呼び出す仕様がそもそも余計なおせっかいと思いますが、仮に__autoloadを呼び出すのであれば、クラス名(識別子)としての妥当性を確認すべきでしょう。現状では、クラス名として「1」や「/var/data/evil」など(クラス名にできない文字列)を指定しても、そのまま__autoloadが呼び出されます。 このため、PHP利用者側で取れる対策としては、__autoload関数側でクラス名の妥当性チェックをするのがよいと思いますが、来は、PHP側で対策すべきと考えます。 PHPのis_a関数における任意のコードを実行される脆弱性(CVE-2011-3379)とは何だったかから引用 この箇所ですが、 PHP-5.4.24RC1およびPHP-5.5.8RC1以降で、上記クラス名の妥当性検

    PHP5.4.24、PHP5.5.8以降で、__autoloadのクラス名チェックが実装されることに
  • CookieにログインIDを保存してはいけない

    phpproのQ&A掲示板で下記の質問を読みました。 ログインの際に、クッキーにログイン情報を保存し、ログアウトの際には、フォームタグの中でPOSTでログアウトの為の値を飛ばし、値を受け取ったらクッキーの有効期限をマイナスにしてクッキー情報を消すというログアウト処理を作っています。 同一ページでのCookieでのログアウト処理より引用 クッキーにそのままログイン情報を保持するのはよくありませんね。質問を更に読むと、以下のソースがあります。 setcookie("logid",$row["f_customer_logid"],time()+60*60*24); setcookie("point",$row["f_customer_point"],time()+60*60*24);どうも、SQL呼び出しの結果からログインIDを取り出し、それをそのままCookieにセットすることで、ログイン状態

    CookieにログインIDを保存してはいけない
  • 書式文字列によるSQLインジェクション攻撃例

    以下のようなコードがあり、nameは画面入力なのでSQLインジェクションが起こるのでは? と作成者に確認したところ、"%s"してあるから大丈夫との返事をもらいました。 ネット調べるとmysql_real_escape_stringでエスケープしてから"%s"で変換すれば大丈夫といった内容は見つけたのですが、mysql_real_escape_stringなど不要との返事をもらいました。 なぜ?と聞くとそういうものだとしか回答がありません。 ひどいですね。これは質問者が正しく、sprintfの%sで受けただけでは、SQLインジェクション脆弱性となります。 しかし、どうしてこのような間違った知識が出てきたのかと考えるに、数値を%dで受ける場合と混乱したのではないかと憶測しました。数値の場合、書式%dで受けていれば、仮に攻撃コードが入力されたとしても、%dで整数に強制変換されるので、SQLインジ

    書式文字列によるSQLインジェクション攻撃例
  • PHP5.3.2以降ではfcloseで自動的にアンロックされない

    PHP家サイトでflockの説明を読んでいたら、以下の変更履歴に気がつきました。 5.3.2 ファイルのリソースハンドルを閉じたときにロックを自動的に解放する機能が削除されました。 ロックの解放は、常に手動で行わなければなりません。 http://php.net/manual/ja/function.flock.php ところがネットの解説を見ると、ロック開放はflock($fp, LOCK_UN); ではなく、fcloseでやれとしている解説が結構あります。 (4)fcloseの前にflock解除するな … fcloseの前にflock(ファイルポインタ, LOCK_UN) する人は実に多いのですが、これははっきりと間違いだと断言します @ITPHPの記事が突っ込みどころ満載 - 暴言満載 LOCK_UNは普通は使われない。ロック開放はfclose()関数でやるのが鉄則。 http

    PHP5.3.2以降ではfcloseで自動的にアンロックされない
  • なりすまし犯行予告に悪用可能なWebアプリケーション脆弱性

    なりすまし犯行予告が話題になっています。現在問題になっているものは、マルウェアが使われているようですが、それ以外に、無線LANの乗っ取りや、Webアプリケーションの脆弱性悪用などの手法があります。NHKの報道では、クロスサイトリクエストフォージェリ(CSRF)脆弱性が、過去に悪用された事例が紹介されています(ただしmixiの例と思われます)。 また、3つ目として、利用者からの投稿を受け付ける掲示板側にセキュリティー上の欠陥があった場合、利用者がウイルスに感染しなくても、書き込みをされるおそれがあります。 このうち、CSRF=クロスサイトリクエストフォージェリと呼ばれる攻撃手法では、利用者に攻撃者が用意したホームページのリンクをクリックさせただけで、別の掲示板に文章を投稿させることが可能だということです。 この場合、利用者はクリックしただけなので、文章を投稿したことにはほとんど気付かないとい

    なりすまし犯行予告に悪用可能なWebアプリケーション脆弱性
  • hostsファイルにループバックアドレスを指定することは危険か?

    Androidの広告よけにhostsファイルを書き換えるAdAwayというアプリ(ルート化必要)が紹介されています。それがきっかけとなり、hostsファイルを書き換えることの危険性、とくに他人が作ったhostsファイルをそのまま自端末に適用してしまうリスクがtwitterで話題になりました。 これはまったく正しいのですが、なかのきえた氏から、以下のようにlocalhostIPアドレスを記述することも問題と指摘がありました。 @shigecchi2007 @ks_desire localhost系を書くこともヤバイのです。WindowsでローカルのIISが回り込まれたりWinNTの頃から既知の問題なんです。やるならFirewall機能で適切にブロックする事が必要です。 9月 23, 2012これに対して、ko-zuさんから、ループバックやLAN内ホストでの脆弱性対策についてというブログ記事

    hostsファイルにループバックアドレスを指定することは危険か?
  • 1