ホームページを本格運用するなら コアサーバー × 独自ドメイン セット契約で ドメイン更新費が永久無料!
PHPデベロッパチームは5月8日(米国時間)、PHPの最新版となる「PHP 5.4.3」および「PHP 5.3.13」を公開した。どちらもPHPのCGIモードにあった重大な脆弱性が修正されており、すべてのユーザに対してアップグレードを推奨している。 PHP 5.4.3、PHP 5.3.13はともに同じ脆弱性に対処したバージョン。この脆弱性は、アメリカのセキュリティ研究センターCERTが3日(米国時間)に発表した問題で、DoS攻撃を受けたりWebサーバ権限でコードを実行される危険性があった。 PHP GroupではURLの末尾(index.php?)に「-s」をつけてアクセスし、ソースコードが表示された場合には、これらの攻撃を受ける可能性があるという。実はこの脆弱性については、3日に公開された「PHP 5.4.2」および「PHP 5.3.12」で対処したと発表したが、その後、6日に修正が不十
【対策されました】WebARENA SuiteX で WordPress3.2 以上を使いたい等の理由で PHP 5.3 を使ってる人は今すぐ脆弱性対策しましょう 2012 年 5 月 7 日 以下の内容は 2012年5月7日に緊急でアップしたものです。現在は SuiteX 側で同様の対策が実施されておりますのでユーザ側で対策する必要はありません。追記 2に示したリンク先をご確認下さい。 朝起きたら徳丸浩の日記にCGI版PHPにリモートからスクリプト実行を許す脆弱性(CVE-2012-1823)という記事がアップされておりました。 CGI環境でPHPを動作させているサイトには、リモートからスクリプト実行を許してしまう脆弱性があります。php.netから提供されている修正リリース(PHP 5.3.12 / PHP 5.4.2)は不完全なため、該当するサイトは至急回避策を導入することを推奨しま
CGI環境でPHPを動作させているサイトには、リモートからスクリプト実行を許してしまう脆弱性があります。php.netから提供されている修正リリース(PHP 5.3.12 / PHP 5.4.2)は不完全なため、該当するサイトは至急回避策を導入することを推奨します。 概要 CGIの仕様として、クエリ文字列に等号を含めない場合は、クエリ文字列がCGIスクリプトのコマンドライン引数として指定されます。 例えば、http://example.jp/test.cgi?foo+bar+bazという呼び出しに対しては、test.cgiは以下のコマンドラインで呼び出されます。 test.cgi foo bar baz この仕様を悪用して、CGI版のPHPにコマンドライン引数としてPHPのオプションを指定できます。例えば、http://example.jp/test.php?-s というリクエストは、-s
追記:より詳細の報告を公開しましたのでそちらを参照下さい CGI版PHPにリモートからスクリプト実行を許す脆弱性(CVE-2012-1823) 追記終わり。 昨日のメモでは、CVE-2012-1823の対処をFastCGIかmod_phpに移行するとしていたが、CGIのまま暫定対処する方法を以下に公開する。 PHPの設定が以下と想定する。 AddHandler application/x-httpd-php5 .php Action application/x-httpd-php5 /cgi-bin/php-cgi php-cgiを呼び出すラッパー(/cgi-bin/php-wrapper)を以下のように記述する。実行権限を付与すること。php-cgiにパラメータを渡さないところがポイント。 #!/bin/sh exec /usr/local/bin/php-cgi PHPの設定を以下のよ
追記:より詳細の報告を公開しましたのでそちらを参照下さい CGI版PHPにリモートからスクリプト実行を許す脆弱性(CVE-2012-1823) 追記終わり。 【概要】 PHP5.4.2で修正された脆弱性だが、直っていない。CGI版のみが影響を受ける。mod_phpやFastCGIによるPHP実行の場合影響なしとされる。 【影響】 ・PHPの実行時オプションが外部から指定されるその結果として以下の影響がある ・リモートのスクリプト実行(影響甚大) ・PHPソースの表示 【影響を受けるサイト】 ・PHPをCGIとして実行しているサイト(FastCGIは大丈夫らしい) 【回避策】 ・PHP本家の改修リリース(5.4.2など)は不十分な対策(PHP5.4.2でもリモートコード実行できることを確認済み) ・mod_rewriteによる回避策も不十分らしいが情報不足 ・FastCGIまたはmod_ph
5/3 17:45追記:t_komuraさんに指摘いただいた関数と、さらに僕が調べ直したものを含め、「ロケール設定に従う関数一覧」に25個ほど追加しました。かなり見落としがありましたね…。 PHPのロケール*1まわりについて調査したので、これをまとめてみます。 この記事は「ロケールの影響を受ける関数 - Sarabande.jp」を掘り下げたものです。masakielasticさん、ナイスな記事をありがとうございます。 PHPの文字列型と文字エンコーディング 他のモダンなLL言語と異なり、PHPは文字列の文字エンコーディングに関して何も仮定せず、単なるバイト列として管理しています。つまり、文字エンコーディングの取り扱いは各関数の実装に委ねられています。 下記の通り、これはマニュアルにも記述があるのですが、実に残念なことです。 残念ながら、PHP の各関数が文字列のエンコーディングを判断する
Rails 界隈で話題の Mass Assignment 脆弱性を CakePHP で防ぐ方法です。 Github に Mass Assignment 脆弱性が発見されて、Rails 界隈で話題になっています。この問題自体は目新しいものではなく、Rails 自体の問題というより、Rails アプリケーションの作り方の問題ということで、以前から作る側が注意を払う必要がありました。 この Mass Assignment 脆弱性は、Rails を手本に発展してきた CakePHP アプリケーションでも同様の問題が発生する可能性があります。知っている人には常識なのですが、まだ知らない人もいるかと思うので、CakePHPにおける対策方法を書いてみます。下記コードはCakePHP2系を想定していますが、考え方はCakePHP1系でも同じです。 Mass Assignment 脆弱性 CakePHP に
こんにちはこんにちは!! Webプログラミングしてますか! よく「PHPはセキュリティがダメ」とか言われてるよね。 でもそれって、べつにPHPが悪いんじゃなくて、 たぶん、セキュリティとかが、まだよくわからない人が多いだけなんじゃないかな。 がんばって勉強しようと思っても、なんだか難しい理屈が並んでいたりするしね…。 なので今日は、セキュリティ対策について、 「これだけやっとけば、わりと安全になるよ」ってことを、初心者むけに、大雑把に書いてみます! 理屈がわからなくても、最初はコピペでも、 なにもやらないより、やったほうがきっとマシになる! 1. XSS対策 動的なものを表示するとき、全部エスケープすればokです! (NG) あなたの名前は <?= $name ?> ですね! ↓ (OK) あなたの名前は <?= htmlspecialchars($name, ENT_QUOTES) ?>
このエントリでは、Cookieを用いたhashdos攻撃の可能性について検討し、実証結果と対策について報告します。 はじめに既に当ブログで報告の通り、hashdosと呼ばれる攻撃手法が公表されています。HTTPリクエストのパラメータ名に対するハッシュ値を故意に同一にした(衝突させた)ものを多数(数万程度)送信することにより、Webサーバーを数分程度過負荷にできるというDoS攻撃手法です。 先の記事でも説明しているようにPOSTパラメータ(HTTPリクエストボディ)に多数のパラメータを仕込む攻撃が典型的ですが、POSTパラメータ以外のパラメータを用いた攻撃についても検討しておかないと、防御漏れの可能性が生じます。 そこで、POSTパラメータ以外を用いた攻撃方法について検討します。 POST以外に多数のパラメータを仕込めるかPOST以外に多数のパラメータを仕込む場所があるでしょうか。候補となる
PHPを初期設定のまま使うと、いろいろ問題が起こる可能性があります。今回は、問題の発生を未然に防ぐ設定法をいくつか紹介します。(編集部) 初期設定のままでは良くないところもある ここ数回はPHP実行時の設定について解説しています。実行時設定を変更する方法として、PHPの設定ファイル(以下php.iniファイル)に設定を記述する方法と、Apache HTTP Server(以下Apache)の設定ファイルにPHPの設定を記述する方法の2つがあり、前回はその使い分けについて解説しました。 サーバ全体で標準の設定値としたいものはphp.iniファイルに、バーチャルホストやURLごとに変更したいものはApacheの設定ファイルに記述する、という使い分けの指針も示しました。 今回は、php.iniで設定できる項目、つまりサーバ全体にかかわる設定項目の中でも、初期設定のままにしておくことがあまり適切で
setcookieでクッキーを削除できなくて困っています。 現在会員サービスを趣味で作っています。その中で、一度ログインしてから2週間はidとパスワードを入力する必要なくログインできる機能をsetcookie関数を使って作りました。 以下がログイン時にセッションにidを保存するスクリプトです。 //ログインボタンがクリックされた場合の処理 if (isset($_POST["login"])) { //ログインIDとパスワードが入力されているかチェックする if ($_POST["loginid"] === "" || $_POST["password"] === "") { $error_message = "ログインIDとパスワードを入力してください。"; //ログインIDとパスワードが入力されていたら処理する } else { //ログイン関数を呼び出し、trueが返ってきたらログイ
Symfony Advent Calender 2011 JP 18日目です。前回は @hidenorigoto さんでした。リダイレクト・インターセプションは 2.0.0 が出る前のどこかのタイミングでデフォルトでオフになって焦った記憶があります。投稿処理などをしたタイミングでプロファイラを見る機会が多いので、有効にしておくと便利ですよね。 さて、 18 日目となるこのエントリでは、セキュリティの観点から Symfony2 の機能について簡単に観ていくことにします(本当はしっかり見ていくつもりだったのですが、時間的制約から急遽簡単になりました!)。 ここでは Symfony Standard Edition v2.0.7 のインストール直後の構成、依存ライブラリを前提として解説します。また、 Web アプリケーションセキュリティに関する基本的な知識を持っていることを前提として説明します。
Last Updated on: 2018年8月13日PHP Advent Calender用のエントリです。 PHPのセッション管理は非常に簡単です。セッションをsession_start()で開始して$_SESSION配列を使うだけです。便利で簡単なセッションモジュールですがセッションアダプションに脆弱であるため、一般に言われてる「ログインする時にはsession_regenerate_id()を呼ぶ」コーディングではセッションアダプションに脆弱になってしまいます。 まずは危険性と対策を紹介します。 セッションアダプションの危険性 セッションアダプションとは外部などから設定されたセッションIDを受け入れ初期化する脆弱性です。一番分かりやすい例はTrans SIDを有効にして http://example.com/index.php?PHPSESSID=1234567890 とアクセスす
► 2020 (4) ► 9月 (1) ► 7月 (1) ► 6月 (1) ► 1月 (1) ► 2019 (3) ► 5月 (1) ► 3月 (1) ► 2月 (1) ► 2017 (4) ► 11月 (1) ► 9月 (1) ► 5月 (1) ► 4月 (1) ► 2016 (5) ► 11月 (1) ► 10月 (1) ► 9月 (1) ► 7月 (1) ► 3月 (1) ► 2015 (2) ► 10月 (1) ► 7月 (1) ► 2014 (1) ► 8月 (1) ► 2013 (2) ► 12月 (1) ► 8月 (1) ► 2012 (11) ► 12月 (2) ► 10月 (1) ► 6月 (2) ► 5月 (1) ► 4月 (3) ► 3月 (1) ► 1月 (1) ▼ 2011 (2) ► 10月 (1) ▼ 9月 (1) 9月10日PHPカンファレンス2011で講演
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く