PHPのリリース日とサポート期限 - Qiita
PHP 7.0 は2018年12月3日に公式のセキュリティサポートが終了し、その前の2018年9月13日に 7.0 系最終リリースとなるはずだった 7.0.32 が公開された。しかし、セキュリティサポート終了後の2018年12月6日に 7.0.33 が公開された。 PHP 5.6 の公式のセキュリティサポートは当初2017年8月28日まで 4 だったが、5系最後のリリースであることを理由に 5 2016年始めに2018年末まで延期された。6 2018年12月6日にリリースされた 5.6.39 が最終リリースになるはずだったが、セキュリティサポート終了後の2019年1月10日に 5.6.40 がリリースされた。 7 PHP 5.5 は2016年7月10日に公式のセキュリティサポートが終了し、その前の2016年6月23日に 5.5 系最終リリースとなるはずだった 5.5.37 が公開された。し
PHPサーバーサイドプログラミングパーフェクトマスターのCSRF対策に脆弱性
サマリ PHPサーバーサイドプログラミングパーフェクトマスターには、PHP入門書としては珍しくクロスサイト・リクエストフォージェリ(CSRF)対策についての説明があるが、その方法には問題がある。アルゴリズムとして問題があることに加えて、実装上の問題があり、そのままコピペして用いると脆弱性となる。 はじめに 古庄親方の以下のツイートを見て驚きました。 CSRF用のトークンの作成 ＄token = password_hash(mt_rand(), PASSWORD_DEFAULT); ってのを書籍で見た………もンのすンげぇなぁ(苦笑 書籍名でググって調べる……評判が悪いので、まぁ、納得っちゃぁ納得。 — がる (@gallu) July 17, 2019 CSRFトークンの生成に、password_hash関数を使うですと? 親方に書籍名を教えていただき、購入したのが、この記事で紹介する「PH
2018年のパスワードハッシュ - Qiita
数年前であれば仕方なかったところですが、2018年の今となっては、パスワードハッシュの手動計算はもはや"悪"です。 まずログイン認証と称してmd5とかsha1とか書いてあるソースはゴミなので投げ捨てましょう。 hashやcryptは上記に比べればずっとマシですが、使い方によっては簡単に脆弱になりえます。 あと『パスワードを暗号化する』って表現してるところも見なくていいです。 PHPには、ハッシュに関わる諸々の落とし穴を一発で解消してくれるpassword_hashという超絶便利関数があるので、これを使います。 というか、これ以外を使ってはいけません。 以下はフレームワークを使わずに実装する際の例示です。 フレームワークを使っている場合は当然その流儀に従っておきましょう。 ハッシュの実装 データベース ユーザ情報を保存するテーブルを作成します。 パスワードカラムの文字数は、システム上のパスワ
PHPにおけるシンボリックリンクを使ったデプロイの危険性について（「realpath_cache」和訳）
2016/10/31 PHPにおけるシンボリックリンクを使ったデプロイの危険性について（「realpath_cache」和訳） PHP サーバーサイド この文書は@julienPauliさんによる記事「realpath_cache」の日本語翻訳です。元々は@gilbiteさんがKLab社内向けに翻訳したものでしたが、日本語では見たことがない指摘を含んでおり今でも有用だと考えたため、@julienPauliさんの了解を取った上で@hnwが修正・追記して公開するものです。 はじめに PHP に realpath_cache_get(), realpath_cache_size() という関数があることをご存じでしょうか？ また、php.ini に realpath_cache から始まる設定項目があることは？ realpath cache は知っておきたい極めて重要な概念です。 特に、コードの
PHP「expose_php = off」の設定
不動産専門ホームページ制作会社で働くエンジニアのブログです。日々、業務の中で得られた知識や技術、時々はプライベートなネタも投稿していきます。 menu 本日は、お客さんが借りられているサーバのPHP設定を1か所変更しました。 php.ini に 「expose_php」という項目があると思います。 こちら、 有効になっていると、 HTTPヘッダーにPHPのバージョンを出してしまいます。 こんな感じで↓ ※レスポンスヘッダー「WEB Developer」というアドオンを使って確認しています。 HTTPヘッダにPHPのバージョンを出しっぱなしというのも気持ちが悪いので、 ここは隠してやることに。 と言っても、 「expose_php = off」と設定してやるだけです。 設定後、このようになっていればOKです↓ expose_phpを有効に設定しておくと、 インストールしているPHPのバージョ
WordPress 4.7.1 の権限昇格脆弱性について検証した
エグゼクティブサマリ WordPress 4.7と4.7.1のREST APIに、認証を回避してコンテンツを書き換えられる脆弱性が存在する。攻撃は極めて容易で、その影響は任意コンテンツの書き換えであるため、重大な結果を及ぼす。対策はWordPressの最新版にバージョンアップすることである。 本稿では、脆弱性混入の原因について報告する。 はじめに WordPress本体に久しぶりに重大な脆弱性が見つかったと発表されました。 こんな風に書くと、WordPressの脆弱性なんてしょっちゅう見つかっているという意見もありそうですが、能動的かつ認証なしに、侵入できる脆弱性はここ数年出ていないように思います。そういうクラスのものが久しぶりに見つかったということですね。 WordPress、更新版で深刻な脆弱性を修正 安全確保のため情報公開を先送り Make WordPress Core Conten
文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2010年9月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPカンファレンス2010にて「文字コードに起因する脆弱性とその対策」というタイトルで喋らせていただきました。プレゼンテーション資料をPDF形式とslideshare.netで公開しています。 文字コードのセキュリティというと、ややこしいイメージが強くて、スピーカーの前夜祭でも「聴衆の半分は置いてきぼりになるかもね」みたいな話をしていたのですが、意外にも「分かりやすかった」等の好意的な反応をtwitter等でいただき、驚くと共に喜んでいます。土曜にPHPカンファレンスに来られるような方は意識が高いというの
少なくとも RedHat が2020年まではサポートしてくれるはず (#2660285) | PHP 5.3.29リリース、これでPHP 5.3系のサポートは終了へ | スラド
PHPの開発元は 5.3系のサポートを打ち切るという事ですが 少なくとも RedHat 社が2020年までは保守してくれる筈です なぜなら、Red Hat の RHEL6 (Red Hat Enterprise Linux 6) には PHP 5.3が含まれていて RHEL6のサポート期間は（少なくとも）2020年11月30日まであるからです http://ja.wikipedia.org/wiki/Red_Hat_Enterprise_Linux [wikipedia.org] ですので、RHEL6のrpmパッケージ版phpを使っている人は、2020年までサポートが受けられます また自前でPHPをビルドして使っている場合でも、とりあえずRHEL6 のセキュリティアップデートを定期的にチェックして PHP関連のパッケージが更新された場合は パッケージのソースコード(*.src.rpmファイ
RHEL/CentOS 6のPHP5.3.3 は安全か？ - Qiita
RHEL6/CentOS6 のサポート期限は、2020年11月30日までです。早めに OS リプレイスの計画を立てましょう この記事は RHEL/CentOS 7のPHP5.4.16 は安全か？ の RHEL/CentOS 6 版です。 よく、 CentOS6.x にバンドルされている PHP5.3.3 を使用していると、 「まだ PHP5.3 なんて使ってるの？？ セキュリティに対する意識あんの？？」 って言われます。 確かに、PHP5.3.3 は2010年にリリースされたとても古いバージョンですし、5.3 系は2014年8月14日にリリースされた 5.3.29を最後に公式のサポートを終了しています。 でも、 CentOS6.x の PHP は、リリース当初の2011年から、 5.3.3 のままです。2015年12月現在でも、 5.3.3 のままです。これには理由があります。 CentO
67. PHPファイルの応答ヘッダーに含まれるPHPバージョンを隠蔽する
ヘッダー情報からサーバーで使用しているPHPバージョンを特定されてしまい、そのバージョンのセキュリティーホールを狙った攻撃を受けてしまう可能性があります。今回は、ヘッダー情報からPHP・Apacheのバージョンを特定させない方法を紹介します。 対策がされていないサーバーへHTTPリクエストを送信し、実際にヘッダー情報を取得すると・・・ [root@localhost ~]$ telnet localhost 80 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. GET /test.php HTTP/1.0 HTTP/1.1 200 OK Date: Fri, 26 Jan 2007 12:00:00 GMT Server: Apache/2.0.59
PHPのunserialize関数に外部由来の値を処理させると脆弱性の原因になる
既にいくつかの記事で指摘がありますが、PHPのunserialize関数に外部由来の値を処理させると脆弱性の原因になります。 しかし、ブログ記事等を見ていると、外部由来の値をunserialize関数に処理させているケースが多くあります。 ユースケースの一例としては、「複数の値をクッキーにセットする方法」として用いる場合です。 PHP クッキーに複数の値を一括登録する方法という記事では、以下の方法で複数の値をクッキーにセットしています。 $status = array( "height" => 167, "weight" => 50, "sight" => 1.2 ); setcookie("status", serialize($status)); クッキーの受け取り側は以下のコードです。 print_r(unserialize($_COOKIE['status'])); 出力結果は以下
GHOST脆弱性を用いてPHPをクラッシュできることを確認した
GHOST脆弱性について、コード実行の影響を受けるソフトウェアとしてEximが知られていますが、PHPにもgethostbynameという関数があり、libcのgethostbyname関数をパラメータ未チェックのまま呼んでいます。そこで、PHPのgethostbynameを用いることでPHPをクラッシュできる場合があるのではないかと考えました。 試行錯誤的に調べた結果、以下のスクリプトでPHPをクラッシュできることを確認しています。CentOS6(32bit/64bitとも)、Ubuntu12.04LTS(32bit/64bitとも)のパッケージとして導入したPHPにて確認しましたが、phpallで確認した限りPHP 4.0.2以降のすべてのバージョンのPHPで再現するようです。なぜかPHP 4.0.0と4.0.1では再現しませんでした。 <?php gethostbyname(str_
PHPの脆弱性への攻撃名称と対策メモ - Qiita
自分用メモ。ごちゃごちゃすると忘れるので、なるべくシンプルにまとめたい。 誤り、不備などあれば、随時追加修正します（ご指摘ありがとうございます）。 クロスサイトスクリプティング（cross site scripting、XSS） 概要 訪問者に目的のサイトとは別の罠サイトを踏ませて不正な処理を実行させる行為。 原因 フォームから受け取った値を、エスケープせずに画面に出力するために発生 （偽のフォームを作成する手法も有るので、JavaScriptの対策だけでは不足） HTMLの実体参照を用い、& を & に、< を < に、> を > に、" を " に、それぞれ置換する。 PHPではhtmlspecialchars関数を用いれば、一括で対策できる （ただしENT_QUOTESを設定しないとシングルクォーテーションはエスケープされない）
安全なAPI過信症候群の処方箋 – execv/SQLite3編
(Last Updated On: 2018年8月13日)またプリペアードクエリなど、安全とされるAPI万能と考えている方に会ったのでエントリを書きました。広く病気として治療すべき、と思いエントリを書きます。安全なAPI過信症候群と名付けました。 安全なAPI過信症候群（同類にプリペアードクエリ過信症候群など）：「安全」とされるAPIを使えば安全と、盲目的に信用し考慮すべきリスクを考えない症候群。ITエンジニアが発症し最も重要なセキュリティ対策である入力バリデーションを「必要ない、できない、セキュリティ対策ではない」エスケープは「必要ない、有害である」とする場合、かなり重度の場合が多い。 このブログでは既に何度もプリペアードクエリクエリは不完全である、と指摘しています。プリペアードクエリを使っていれば安全と盲目的に信じている方向けの基礎知識を紹介します。コマンド実行APIのexecvと最も
10. PHPのイースターエッグを見つけ出そう
PHPを長年使っている方には結構有名なことですが、PHPを使用しているページ に特殊なクエリを渡すと、面白い画像やPHPのクレジットを見ることができます。 PHP Logo http://php.net/?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 Zend Logo http://php.net/?=PHPE9568F35-D428-11d2-A769-00AA001ACF42 PHP Credits http://php.net/?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000 PHP Logo http://php.net/?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 画像は上記以外にも何種類か存在しており、またバージョンによって表示される ものが違うようです。それらの画像を
PHPのescapeshellcmdを巡る冒険
以前、ブログ記事「PHPのescapeshellcmdの危険性」にて、escapeshellcmd関数の「余計なお世話」によって危険性が生まれていることを指摘しましたが、その後大垣さんによって修正案が提示され、結局「それはマニュアルの間違い」ということで決着が着いたようです。ところが、この議論とは別のところで、escapeshellcmdはPHP5.4.0で挙動が少し変わっていることが分かりました。 経緯 2011/1/1 徳丸が「PHPのescapeshellcmdの危険性」を書いて、クォート文字がペアになっている場合にエスケープしないという仕様が余計なお世話であり、危険性が生じていることを指摘 2011/1/7 大垣さんがブログエントリ「phpのescapeshellcmdの余計なお世話を無くすパッチ」にて修正案を提示 2011/10/23 廣川さんが、大垣さんのパッチ案を少し修正して
よくわかるPHPの教科書 PHP5.5対応版のクロスサイト・スクリプティング
たにぐちまことさんの よくわかるPHPの教科書がこのたび改版されて、よくわかるPHPの教科書 【PHP5.5対応版】として出版されました。旧版はmysql関数を使ってSQL呼び出ししていましたが、mysql関数がPHP5.5にて非推奨となったための緊急対処的な内容となっているようです。つまり、従来mysql関数を呼び出していた箇所をmysqliの呼び出しに変更したというのが、主な変更点のようで、これ以外はあまり変更点は見あたりません。 既に、Amazonでは、熱烈な読者の方からの詳細のレビューが届いています。 神本御降臨！ 言わずと知れたPHPプログラミング書籍のロングセラー。 2010年9月に発売された前作の改訂版。 PHPのバージョンも最新の5.5に対応、内容は前作と殆ど同じ。 少し前に前作を購入した方も本書を購入した方がいいでしょう。 【中略】 それにしても、帯の「３万人に読まれた定
書籍「気づけばプロ並みPHP」にリモートスクリプト実行の脆弱性
書籍「気づけばプロ並みPHP」のサンプルスクリプトにリモートスクリプト実行の脆弱性があるので報告します。 はじめに Yahoo!知恵袋の質問を読んでいたら、以下の質問がありました。 気づけばプロ並みPHP （著）谷藤賢一 （発行）リックテレコムP１１２の画像をアップロードする機能でエラーがでます。 http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q11119835496 より引用 質問に対しては回答が既についてクローズされていましたが、引用されているソースを見て任意のファイルを任意のファイル名で、Web公開ディレクトリにアップロードできることに気づきました（下記）。 <?php // 略 $pro_gazou=$_FILES['gazou']; // 略 if($pro_gazou['size']>0) { if ($pro_
basic認証時にパスワードを取得する方法がPHPにあるらしい - やきにくとくにきや
PHP技術者認定・上級模擬問題 をやっていて知ったのだが、$_SERVER['PHP_AUTH_PW']なるグローバル変数で取得できるらしい。 やってみた index.php <?php echo "認証に成功しました<br>"; echo "ID:".$_SERVER['PHP_AUTH_USER']."<br>"; echo "パス:".$_SERVER['PHP_AUTH_PW']; ?> .htpasswd kunikiya:GZnkccJy7Ynbo .htaccess AuthUserFile .htpasswd AuthName "Please enter your ID and password" AuthType Basic require valid-user 表示結果 認証に成功しました ID:kunikiya パス:pass 昔はセキュリティのためユーザー名は取得で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHP+Apacheでウェブサーバを運用する場合のセキュリティのベストプラクティスを教えてください。…