go-pear.pharにバックドアが仕込まれていた - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 半年以内にgo-pear.pharを使った人は必ずチェックしましょう。 2019/01/19 PEAR公式Twitterアカウントからツイート。 このアカウント全然活動してない。 https://twitter.com/pear/status/1086634389465956352 A security breach has been found on the https://t.co/dwKlscDEFf webserver, with a tainted go-pear.phar discovered. The PEAR websi
PHPの脆弱性 CVE-2018-17082 によるキャッシュ汚染についての注意喚起
エグゼクティブサマリ PHPの脆弱性CVE-2018-17082はXSSとして報告されているが、現実にはXSSとしての攻撃経路はない。一方、Apacheのmod_cacheによるキャッシュ機能を有効にしているサイトでは、キャッシュ汚染という攻撃を受ける可能性がある。 概要 PHPの現在サポート中のすべてのバージョンについて、XSS脆弱性CVE-2018-17082が修正されました。以下は対応バージョンであり、これより前のすべてのバージョンが影響を受けます。ただし、Apacheとの接続にApache2handlerを用いている場合に限ります。 PHP 5.6.38 PHP 7.0.32 PHP 7.1.22 PHP 7.2.10 PHP 5.5以前も対象であり、これらは脆弱性は修正されていません。 脆弱性を再現させてみる この脆弱性のPoCは、当問題のバグレポートにあります。 PHP ::
改ざんの標的となるCMS内のPHPファイル(2016-02-25) - JPCERT/CC Eyes
調査の結果、これらのPHPファイルが改ざんされたことにより、Webサイトからのレスポンス内に不正なコードが、閲覧者のアクセス毎に動的に挿入されていたことが判明しました。 改ざんされたPHPファイルによって不正なコードが挿入される仕組み 改ざんされたPHPファイルには、「//istart」および「//iend」というコメントに挟まれた、図 1のような不正なPHPコードが挿入されていました（不正なPHPコードが難読化されている場合も確認しています）。 この不正なPHPコードは、外部から取得したコードを挿入する機能を持っており、特定のURLから不正なコードを受け取り、特定の位置に挿入します。 図 1: 「//istart」および「//iend」に挟まれた不正なPHPコード 挿入される不正なコード Webサイトに閲覧者がアクセスすると、改ざんされたPHPファイル中の不正なPHPコードは、図 2のよ
PHPにおけるHTTPヘッダインジェクションはまだしぶとく生き残る
この記事はPHPアドベントカレンダー2015の3日目の記事です 。 MBSD寺田さんの記事「LWSとHTTPヘッダインジェクション」では、PHPのheader関数に関連して、PHP側のHTTPヘッダインジェクション対策を回避する手法と、それに対するPHP側の対応について書かれています。この記事では、寺田さんの記事を受けて、現在でもHTTPヘッダインジェクション攻撃が可能なPHP環境が残っているかを検証します。 HTTPヘッダインジェクションとは 以下の様なスクリプトがあるとします。 <?php header('Location: ' . $_GET['url']); オープンリダイレクタ脆弱性がありますが、それは気にしないとして、PHP5.1.1までのバージョンでは、以下の様な攻撃が可能でした。 http://example.jp/header.php?url=http://example
本当に PHP の DoS 脆弱性 (CVE-2015-4024) キツくない？ - はちゅにっき
hakaikosen.hateblo.jp 上記記事を「あら大変(棒読み)」とか思いながら読んでいたけれど、PHP の BTS の方を読んでみたら確かに原理から再現手順まで細かく記載されていて 「なんかこれまずそう」と思ったので、docker を使って検証してみることに。 PHP 入りの Docker コンテナは、Official のものを利用しました。registry.hub.docker.com 今回の脆弱性、POST しないページには関係ないのかな？と思ってましたが、よくよく見ると PHP さえ動くページであればなんでもいいらしい。 ということで以下のような PHP ファイルを用意し、ここにアクセス (攻撃) をします。 htdocs/index.php <!DOCTYPE html> <html> <head> <title>PHP Bugs #69364</title> </he
PHPのDoS脆弱性(CVE-2015-4024)キツくない？ - 出張おはき゛ろく
2015/05/14にリリースされたPHP 5.4.41/5.5.25/5.6.9で修正されたDoS脆弱性がある。 Fixed bug #69364 (PHP Multipart/form-data remote dos Vulnerability). (CVE-2015-4024) バグレポートに細かい話（原理から再現手順まで）が載ってて、要は細工したリクエストを送るだけで、しばらくCPUリソースを浪費するって話と読み取った。リクエストパラメータをパースする段階で起こるので、脆弱性のあるバージョンのPHPをHTTPサーバ経由で実行できる環境が全て影響を受けるんじゃないかなあ。 数年前に話題になったHashdosと、攻撃のお手軽さも影響も大差はない気がするんだけど、あんまり騒がれていない気がする。なんでなんだろう。 いやまぁHashdosはいろんな処理系に共通してたから話題になったんだろう
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
この記事はPHPアドベントカレンダー2014の22日目の記事です 。 2002年3月に公開されたIPAの人気コンテンツ「セキュアプログラミング講座」が2007年6月に大幅に更新されました。そして、その一節がPHPerたちを激しく刺激することになります。 (1) プログラミング言語の選択 1) 例えば、PHPを避ける 短時日で素早くサイトを立ち上げることのみに着目するのであれば、PHPは悪い処理系ではない。しかし、これまで多くの脆弱性を生んできた経緯があり、改善が進んでいるとはいえまだ十分堅固とは言えない。 セキュアプログラミング講座（アーカイブ）より引用 「PHPを避ける」とまで言われてしまったわけで、当然ながらネット界隈では炎上を起こし、現在はもう少しマイルドな表現に変わっています(参照)。 本稿では、当時のPHPの状況を振り返る手段として、この後PHPのセキュリティ機能がどのように変化
正規表現によるバリデーションでは ^ と $ ではなく \A と \z を使おう
正規表現によるバリデーション等で、完全一致を示す目的で ^ と $ を用いる方法が一般的ですが、正しくは \A と \z を用いる必要があります。Rubyの場合 ^ と $ を使って完全一致のバリデーションを行うと脆弱性が入りやすいワナとなります。PerlやPHPの場合は、Ruby程ではありませんが不具合が生じるので \A と \z を使うようにしましょう。 はじめに 大垣さんのブログエントリ「PHPer向け、Ruby/Railsの落とし穴」には、Rubyの落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、Ruby on Rails Security Guideからの引用として紹介されています。以下の正規表現は、XSS対策として、httpスキームあるいはhttpsスキームのURLのみを許可する正規表現のつもりです。 /^https?:\/\/[^\n]+$/
PHPとセキュリティの解説書12種類を読んでSQLエスケープの解説状況を調べてみた
この投稿はPHP Advent Calendar 2013の13日目の記事です。昨日は@tanakahisateruのPHPが糞言語なのはどう考えても参照をポインタだと思っているお前らが悪いでした。 現在twitterのタイムラインで、史上空前のSQLのエスケープブームが起こっています。 オレオレSQLセキュリティ教育は論理的に破綻している | yohgaki's blog 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ エスケープとプレースホルダをめぐる議論 - Togetterまとめ SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論 - Togetterまとめ IPAの「安全なSQLの呼び出し方」が安全になっていた | yohgak
CGI版PHPに対する魔法少女アパッチマギカ攻撃を観測しました
昨夜に、魔法少女アパッチ☆マギカ攻撃を観測しました。魔法少女アパッチ☆マギカとは、PoCのソースコードに Apache Magica by Kingcope とコメントされていることに由来しています（というか、私がそう訳しましたw）。 これは10月29日にPoCが発表されたPHP-CGI攻撃(CVE-2012-1823)の変種です。従来のPHP-CGI攻撃は、CGI版PHPが動作する環境で、PHPスクリプト（中身はなんでもよい）に対する攻撃でしたが、魔法少女アパッチマギカの方は、/cgi-bin/に置かれたPHP処理系（php-cgiなど）に直接攻撃するものです。 CGI版PHPを設置する方法は複数ありますが、よく使われる方法としてApacheのリダイレクトによりPHPスクリプトをPHP処理系に実行させる方法があります。この場合、/cgi-bin/php-cgiなどとしてPHP処理系を公開
安全なPHPアプリケーションの作り方2013
PHPカンファレンス2013における徳丸のプレゼン資料です。後から、参考文献などを加筆しました。Read less
PHPのdisplay_errorsが有効だとカジュアルにXSS脆弱性が入り込む
先に、「CVE-2008-5814を巡る冒険」にて、CVE-2008-5814脆弱性があるとdisplay_errorsがOnの環境下でXSS脆弱性となる場合があることを説明しました。しかし、display_errorsがOnの環境下ではCVE-2008-5814脆弱性がなくても、XSS脆弱性となる場合がしばしばあります。 これは、display_errorsによるエラーメッセージ表示がHTMLエスケープされていないことが原因です。簡単なサンプルを以下に示します。 <?php ini_set('display_errors', 1); // display_errorsを有効にする $a = array(); // 配列の生成 $index = $_GET['x']; // 配列のインデックスを得る $b = $a[$index]; // 配列の要素にアクセス このスクリプトに、x=<sc
ブラインドSQLインジェクションのスクリプトをPHPで書いたよ #phpadvent2012
この記事はPHP Advent Calendar 2012の20日目です。昨日はTakayuki Miwaさんの「ComposerとHerokuではじめる！PHPクラウド生活」でした。 以前、「『よくわかるPHPの教科書』のSQLインジェクション脆弱性」というタイトルで、同書のSQLインジェクション脆弱性について説明しましたが、SQLインジェクション脆弱性のあるSQL文がDELETE FROMだったので、先のエントリでは、脆弱性の悪用方法としてはデータ（ミニブログの記事）の削除を説明しました。簡単に「全ての記事を削除できる」ので重大な脆弱性ではありますが、個人情報などが漏洩する例ではありませんでした。 このエントリでは、ブラインドSQLインジェクションという技法により、DELETE FROM文の脆弱性から、個人情報を得る手法を説明します。 脆弱性のおさらい ここで、脆弱性のおさらいをしまし
セッションアダプション脆弱性がないセッション管理が必要な理由
(Last Updated On: 2018年8月18日)徳丸さんから「ブログ読みました。サンプルも動かしました。問題は分かるのですが、セッションアダプションがないPHPだと、何が改善されるのかが分かりません。教えて下さい 」とあったのでツイッターで返信するには少し長いのでこちらに書きます。まだ直していない脆弱性を詳しく解説するのはあまりよくないのですが、今なら影響を受けるアプリはほぼないと思うので構わないでしょう。 まず前提として、Webサーバと同様にJavascriptからもクッキーが設定できます。Javascriptインジェクションに脆弱なコードがサイトに1つでもあると、サイト上のセッションアダプション脆弱性をもつアプリへの攻撃が可能になります。この攻撃を緩和する対策もありますが、それはそれ、これはこれなので省略します。 セッションアダプションに脆弱なセッション管理機構で困る代表的な
セキュリティ情報:PHP5.4.8、PHP5.3.18以前にhashdos脆弱性
チェック用スクリプト hashdosの状態を確認するためのスクリプトを作成してみましたので、Webサイトのチェックにご活用下さい。 このスクリプトを任意のファイル名（PHPスクリプトとして実行できる拡張子）でチェック対象Webサーバーに保存して下さい。Webブラウザを用いて、このスクリプトを実行すると、結果が表示されます。JavaScriptを有効にして下さい。チェック終了後はスクリプトを削除して下さい。 <?php if (@$_GET['mode'] === 'check') { header('Content-Type: text/plain'); echo (int)count($_POST); exit; } $max_input_vars = ini_get('max_input_vars'); $postnumber = (int)$max_input_vars + 10;
有名フレームワークのCSRF対策方法を調べたまとめ - webネタ
ZendFramework 流れ 表示時 : token生成→hiddenセット + セッションにセット 送信時 : 送られてきたtokenをセッションにあるものと同じかでチェック token生成方法 ランダム値 + salt + 固定値 + ランダム値 md5( mt_rand(1,1000000) . $this->getSalt() . $this->getName() . mt_rand(1,1000000) ); まとめ ランダム値をセッションにいれて、送られてきたものとチェック。 Symfony 流れ 表示時 : token生成→hiddenセット 送信時 : 送られてきたtokenを、再度生成したtokenと比較して同じかチェック token生成方法 salt + 固定値 + セッションID sha1($this->secret.$intention.$this->getSe
徳丸本に載っていないWebアプリケーションセキュリティ
2. 本日お話しする内容 • キャッシュからの情報漏洩に注意 • クリックジャッキング入門 • Ajaxセキュリティ入門 • ドリランド カード増殖祭りはこうしておこった…かも? Copyright © 2012 HASH Consulting Corp. 2 3. 徳丸浩の自己紹介 • 経歴 – 1985年 京セラ株式会社入社 – 1995年 京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍 – 2008年 KCCS退職、HASHコンサルティング株式会社設立 • 経験したこと – 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当 – その後、企業向けパッケージソフトの企画・開発・事業化を担当 – 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当 Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿など を開始 –
PHPのescapeshellcmdを巡る冒険
以前、ブログ記事「PHPのescapeshellcmdの危険性」にて、escapeshellcmd関数の「余計なお世話」によって危険性が生まれていることを指摘しましたが、その後大垣さんによって修正案が提示され、結局「それはマニュアルの間違い」ということで決着が着いたようです。ところが、この議論とは別のところで、escapeshellcmdはPHP5.4.0で挙動が少し変わっていることが分かりました。 経緯 2011/1/1 徳丸が「PHPのescapeshellcmdの危険性」を書いて、クォート文字がペアになっている場合にエスケープしないという仕様が余計なお世話であり、危険性が生じていることを指摘 2011/1/7 大垣さんがブログエントリ「phpのescapeshellcmdの余計なお世話を無くすパッチ」にて修正案を提示 2011/10/23 廣川さんが、大垣さんのパッチ案を少し修正して
5分でできるPHPセキュリティ対策 - ぼくはまちちゃん！
こんにちはこんにちは！！ Webプログラミングしてますか！ よく「PHPはセキュリティがダメ」とか言われてるよね。 でもそれって、べつにPHPが悪いんじゃなくて、 たぶん、セキュリティとかが、まだよくわからない人が多いだけなんじゃないかな。 がんばって勉強しようと思っても、なんだか難しい理屈が並んでいたりするしね…。 なので今日は、セキュリティ対策について、 「これだけやっとけば、わりと安全になるよ」ってことを、初心者むけに、大雑把に書いてみます！ 理屈がわからなくても、最初はコピペでも、 なにもやらないより、やったほうがきっとマシになる！ 1. XSS対策 動的なものを表示するとき、全部エスケープすればokです！ (NG) あなたの名前は <?= $name ?> ですね！ ↓ (OK) あなたの名前は <?= htmlspecialchars($name, ENT_QUOTES) ?>
PHP5.3.7のcrypt関数のバグはこうして生まれた
昨日のブログエントリ「PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439)」にて、crypt関数の重大な脆弱性について報告しました。脆弱性の出方が近年まれに見るほどのものだったので、twitterやブクマなどを見ても、「どうしてこうなった」という疑問を多数目にしました。 そこで、このエントリでは、この脆弱性がどのように混入したのかを追ってみたいと思います。 PHPのレポジトリのログや公開されているソースの状況から、PHP5.3.7RC4までこのバグはなく、PHP5.3.7RC5でこのバグが混入した模様です。RC5はPHP5.3.7最後のRelease Candidateですから、まさに正式リリースの直前でバグが入ったことになります。 バグの入る直前のソースは、ここの関数php_md5_crypt_rから参照することができます。以下に、おおまかな流れを図示します。まずはバ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
