この記事はPHP Advent Calendar 2020の19日目です。18日目は@You-sakuさんのPHPでYoutubeのAPIを利用したいでした。 私は以前、PHPのすべてのバージョンを使う環境として、phpall、phpcgiall、modphpallを紹介してきました。これらは、PHPのすべてのバージョンをそれぞれコマンドライン、CGI、mod_phpの形式で動作させるものです。現在では、PHPのバージョンを切り替えて動作させる仕組みはphpenv、phpbrew等何種類もありますし、php-buildという、PHPをビルドするというそのものずばりの仕組みも広く使われています。しかし、短いPHPスクリプトをPHPの全バージョンで試すという私の使用法からは、phpall（およびその派生としてphpcgiall、modphpall）はメリットがあり、私は今もPHPのビルドを続け
この記事はPHP Advent Calendar 2019の5日目の記事です。 はじめに 私は6年前に、PHP Advent Calendar 2013として「PHPだってシェル経由でないコマンド呼び出し機能が欲しい」という記事を書きました。その中で、OSコマンドインジェクション対策の根本的かつ安全な対策は「シェルを経由しないコマンド呼び出し」であることを指摘した上で、末尾に以下のように書きました。 PHPコミッタのみなさま、PHP5.6の新機能として、シェルを経由しないコマンド呼び出しの機能を追加できませんか? 現実には当時からPCNTL関数にてシェルを経由しないコマンド呼び出しはできたのですが、当関数の使用が難しいことと、CLI版あるいはCGI版（FastCGIは可）のPHPでないとサポートされていないなどの制限があり、popenやproc_openなど使いやすいコマンド呼び出し関数に
サマリ PHPサーバーサイドプログラミングパーフェクトマスターには、PHP入門書としては珍しくクロスサイト・リクエストフォージェリ(CSRF)対策についての説明があるが、その方法には問題がある。アルゴリズムとして問題があることに加えて、実装上の問題があり、そのままコピペして用いると脆弱性となる。 はじめに 古庄親方の以下のツイートを見て驚きました。 CSRF用のトークンの作成 ＄token = password_hash(mt_rand(), PASSWORD_DEFAULT); ってのを書籍で見た………もンのすンげぇなぁ(苦笑 書籍名でググって調べる……評判が悪いので、まぁ、納得っちゃぁ納得。 — がる (@gallu) July 17, 2019 CSRFトークンの生成に、password_hash関数を使うですと? 親方に書籍名を教えていただき、購入したのが、この記事で紹介する「PH
宅ふぁいる便から平文パスワードが漏洩した件を受けて、あらためてパスワードの安全な保存方法が関心を集めています。現在のパスワード保存のベストプラクティスは、パスワード保存に特化したハッシュ関数（ソルトやストレッチングも用いる）であるbcryptやArgon2などを用いることです。PHPの場合は、PHP5.5以降で使用できるpassword_hash関数が非常に便利ですし、他の言語やアプリケーションフレームワークでも、それぞれ用意されているパスワード保護の機能を使うことはパスワード保護の第一選択肢となります。 なかでもbcryptは、PHPのpassword_hash関数のデフォルトアルゴリズムである他、他の言語でも安全なハッシュ保存機能として広く利用されていますが、パスワードが最大72文字で切り詰められるという実装上の特性があり、その点が気になる人もいるようです（この制限はDoS脆弱性回避が
SSRF(Server Side Request Forgery)という脆弱性ないし攻撃手法が最近注目されています。以下は、ここ3ヶ月にSSRFについて言及された記事です。 EC2上のAWS CLIで使われている169.254について SSRF脆弱性を利用したGCE/GKEインスタンスへの攻撃例 SSRFを利用したメール送信ドメインの乗っ取り 「CODE BLUE 2018」参加レポート（岩間編） この「空前のSSRFブーム」に便乗して、SSRFという攻撃手法および脆弱性について説明します。 SSRF攻撃とは SSRF攻撃とは、攻撃者から直接到達できないサーバーに対する攻撃手法の一種です。下図にSSRF攻撃の様子を示します。 攻撃者からは、公開サーバー（203.0.113.2）にはアクセスできますが、内部のサーバー（192.168.0.5）はファイアウォールで隔離されているため外部から直接
エグゼクティブサマリ 聖教新聞社が運営する通販サイト「SOKAオンラインストア」から2,481件のクレジットカード情報が漏洩した。リリースによると、漏洩に使われた手口は従来とは異なるもので、改正割賦販売法の実務上のガイドラインである「クレジットカード情報非保持化」では対策できないものであった。 はじめに 今年の9月4日に聖教新聞社の通販サイトSOKAオンラインストアからクレジットカード情報漏洩の可能性がリリースされました。以下は聖教新聞社から運営委託されているトランスコスモス株式会社のリリースです。 「ＳＯＫＡオンラインストア」の件 このたび、弊社が聖教新聞社様より運営を委託されている「ＳＯＫＡオンラインストア」において、クレジットカード情報を入力して商品をご注文いただいた一部のお客さまのクレジットカード情報が、第三者によって不正に取得された可能性があることが発覚い たしました。 http
エグゼクティブサマリ 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 ::
中島明日香氏の近著『サイバー攻撃 ネット世界の裏側で起きていること』を読んだので紹介したい。本書は、一見すると入門者向けの初歩的なセキュリティ解説書の体裁をとっているが、その内部に著者の恐ろしい野望が秘められていると感じた。 重要事項説明 著者と評者には特筆すべき利害関係はない 評者は本書を自費で購入した（献本等ではない） この記事のリンクにはアフィリエイトが含まれる はじめに 本書は、ブルーバックスの１冊として、サイバーセキュリティの分野の、特に脆弱性について焦点をあて、入門的な解説を試みるものである。本書6ページから、「本書で扱う内容」の一節を引用しよう。 本書の目的は、適切なサイバー攻撃対策を講じる際の一助となることです。そこで、脆弱性そのものとそれを突く攻撃手法について、情報科学の知識を持たない人でも理解できるように、基本的なところから解説します。 この一節だけでも、本書の狙いが意
PHPカンファレンス2017にて講演する機会をいただきました。 日時：10月8日（日）10:00～17:00（徳丸の出番は14:10から） 場所：大田区産業プラザPiO（東京都大田区） 費用：無料（申し込みはこちら） 講演タイトル：著名PHPアプリの脆弱性に学ぶセキュアコーディングの原則 想定聴講者としては、SQLインジェクション対策は聞き飽きた、もう少し突っ込んだ話が聞きたいという方を念頭においていますが、小難しくならないように、できるだけ平易にお話したいと考えています。 私はセキュアなプログラミングに関して、とにかく個別の脆弱性を守るための各論が大切で、それを知らないとどうしようもないという立場を取ってきました。その考え自体は変わっていないのですが、そうは言っても個別の各論を束ねる原則論、総論はないかのという思いはもちろんあります。 従来から、そのような「セキュア開発の原則」については
エグゼクティブサマリ 秀スクリプトという小さな言語処理系を開発した。秀スクリプトは、TypeScriptを大幅に縮小した文法を持ち、コンパイラによって秀丸マクロに変換され、秀丸上で実行される。秀スクリプトコンパイラは秀スクリプト自身により記述される。 秀スクリプトの主な特徴は下記のとおり。 TypeScriptに似た文法を持ち、コンパイラも秀スクリプトで記述されている 秀丸マクロを生成し、秀丸上で実行される TypeScript同様、変数に型がある 数値（整数）型と文字列型、これらの配列をサポート if、while、do … whileの制御構造 関数のサポート はじめに Windows上で使用するエディタとして長年秀丸を愛用しています。最近はVisual Studio Codeなども人気で、僕もインストールして使ってみたりはするのですが、長年手に馴染んだツールというのは、中々乗り換えが難
エグゼクティブサマリ WordPress 4.7と4.7.1のREST APIに、認証を回避してコンテンツを書き換えられる脆弱性が存在する。攻撃は極めて容易で、その影響は任意コンテンツの書き換えであるため、重大な結果を及ぼす。対策はWordPressの最新版にバージョンアップすることである。 本稿では、脆弱性混入の原因について報告する。 はじめに WordPress本体に久しぶりに重大な脆弱性が見つかったと発表されました。 こんな風に書くと、WordPressの脆弱性なんてしょっちゅう見つかっているという意見もありそうですが、能動的かつ認証なしに、侵入できる脆弱性はここ数年出ていないように思います。そういうクラスのものが久しぶりに見つかったということですね。 WordPress、更新版で深刻な脆弱性を修正 安全確保のため情報公開を先送り Make WordPress Core Conten
以前の記事CMS四天王のバリデーション状況を調査したところ意外な結果になったで報告したように、Joomla!はログイン名の制限が非常にゆるやかになっています。であれば、🍣とか、💩などを含むログイン名が登録できるのだろうかという疑問が生じました。 とはいえ、以前、Joomla!の「ゼロデイコード実行脆弱性」はPHPの既知の脆弱性が原因で報告したように、少なくともJoomla! 3.4.5までは、MySQLの設定上 UTF-8 の4バイト文字は登録できず、それ以降の文字が全て切り詰められるという問題がありました。 このため、「admin🍣」というログイン名を登録しようとすると、🍣の切り詰めが起こって、adminユーザを二重に登録できなるのではないでしょうか? 試してみる Joomla! 3.4.8の環境を用意して管理者ユーザーを「admin」としておきます。下記のように、default
昨日の記事PHPMailerの脆弱性CVE-2016-10033について解析したにて、PHPMailerの脆弱性CVE-2016-10033の原因はmail関数が内部で呼んでいるescapeshellcmd関数の仕様が原因であると指摘しました。そして、mail関数の危険性については、小邨孝明さんが2013年12月23日の記事にて指摘していました。 mb_send_mail関数(mail関数も同様)ですが、第5引数(additional_parameter)にユーザの入力を使用する場合は注意が必要です。mb_send_mail関数の第5引数は、内部でescapeshellcmd(内部関数名:php_escape_shell_cmd)によって引数の文字列全体がエスケープされます。 escapeshellcmd() は、以前に徳丸さんから OS コマンドインジェクションの防止には不適切であると指
エグゼクティブサマリ PHPMailerにリモートスクリプト実行の脆弱性CVE-2016-10033が公表された。攻撃が成功した場合、ウェブシェルが設置され、ウェブサーバーが乗っ取られる等非常に危険であるが、攻撃成功には下記の条件が必要であることがわかった PHPMailer 5.2.17以前を使っている Senderプロパティ（エンベロープFrom）を外部から設定できる 現在出回っているPoCはMTAとしてsendmailを想定しており、postfixを使っている環境では問題ない 対策版として公開されている PHPMailer 5.2.19も不完全であるので、回避策の導入を推奨する。 はじめに 12月24日にPHPMalerの脆弱性CVE-2016-10033が公表され、とんだクリスマスプレゼントだと話題になっています。 PHPからのメール送信に広く使われているライブラリの「PHPMai
エグゼクティブサマリ PHP 5.5.21、PHP 5.6.5 以降、PHPにPDO::MYSQL_ATTR_MULTI_STATEMENTSというオプションが追加され、PDO+MySQLの組み合わせで、SQLの複文を禁止できるようになった。この設定はSQLインジェクションの緩和策として有効である。 はじめに 2013年12月に公開した PHP+PDO+MySQLの組み合わせではSQLインジェクション攻撃で複文呼び出しが可能 にて、PDOとMySQLの組み合わせで、SQLインジェクションの文脈で複文呼び出しが可能であることを報告していましたが、その後のPHPのバージョンアップで、複文実行を禁止するオプションが追加されていましたので報告します。 対象のバージョンは以下の通りです。 PHP 5.5.21 以降 PHP 5.6.5 以降 全ての PHP 7.0、7.1 前述の記事を書いた後、3大
この投稿は PHP Advent Calendar 2016 の16日目の記事です。 エグゼクティブサマリ PHPのバージョン間の挙動の違いを調査するツールとして、@hnwによるphpallや、それを改造したphpcgiallがあったが、現実のPHPの利用環境とは違いがあり、検証の妨げになる場合があった。このため、PHPのバージョン毎にApacheを異なるポートで動かすことにより、全てのバージョン(229種)のPHPをApacheモジュールとして動作させることに成功し、modphpallと命名した。modphpallはPHPの検証に有効であることを、キャリッジリターンのみで起こるPHPヘッダインジェクションを用いて確認した。 はじめに 昨日の日記では、PHPの全バージョンをCGIモードで試す phpcgiall について紹介しました。HTTPヘッダインジェクションやセッションの挙動について
IPAの安全なウェブサイトの作り方 改訂第7版が公開されました。 このエントリでは、安全なウェブサイトの作り方の元々もつ特徴（変わらない点）と、第7版の変更のポイントについて説明します。 なお、私は安全なウェブサイトの作り方の執筆者の一人ではありますが、以下の記述は私個人の意見であり、IPAを代表するものではありませんので、あらかじめご承知おきください。 安全なウェブサイトの作り方の変わらぬ特徴 安全なウェブサイトの作り方の特徴は、「まえがき」の中で述べられています。 本書は、IPAが届出を受けたソフトウェア製品およびウェブアプリケーションの脆弱性関連情報に基づいて、特にウェブサイトやウェブアプリケーションについて、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、その根本的な解決策と、保険的な対策を示しています。 すなわち、以下の2点がポイントと考えます。 脆弱性の選定
追記(2015/2/6) 大垣さんから訂正依頼のコメントを頂いておりますので合わせてお読みください。徳丸としては特に訂正の必要は感じませんでしたので、本文はそのままにしています。そう思う理由はコメントとして追記いたしました。 (追記終わり) 大垣さんのブログエントリ「GHOSTを使って攻撃できるケース」を読んだところ、以下のようなことが書いてありました。 1. ユーザー入力のIPアドレス（ネットワーク層のIPアドレスではない）に攻撃用データを送る。 2. バリデーション無しで攻撃用の不正なIPアドレスをgethostbyname()に渡される。 3. ヒープオーバーフローでヒープ領域のメモリ管理用の空きサイズを改竄する。 【中略】 どんなソフトウェアが危ないのか？ ユーザー入力のIPアドレスをバリデーションしないでgethostbyname()を使用している。 インタラクティブな動作を行っ
ポイントは下記の通りです。 X社（原告）はセキュリティ対策について特に指示はしていなかった 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった（2010年1月29日） X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた（2010年9月27日）が、その後X社は改良の指示をしなかった 以下の脆弱性その他が認められた システム管理機能のIDとパスワードが admin/password であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能（ディレクトリリスティングと意図しないファイ
この記事はPHPアドベントカレンダー2014の22日目の記事です 。 2002年3月に公開されたIPAの人気コンテンツ「セキュアプログラミング講座」が2007年6月に大幅に更新されました。そして、その一節がPHPerたちを激しく刺激することになります。 (1) プログラミング言語の選択 1) 例えば、PHPを避ける 短時日で素早くサイトを立ち上げることのみに着目するのであれば、PHPは悪い処理系ではない。しかし、これまで多くの脆弱性を生んできた経緯があり、改善が進んでいるとはいえまだ十分堅固とは言えない。 セキュアプログラミング講座（アーカイブ）より引用 「PHPを避ける」とまで言われてしまったわけで、当然ながらネット界隈では炎上を起こし、現在はもう少しマイルドな表現に変わっています(参照)。 本稿では、当時のPHPの状況を振り返る手段として、この後PHPのセキュリティ機能がどのように変化
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
