PHPの脆弱性への攻撃名称と対策メモ - Qiita
自分用メモ。ごちゃごちゃすると忘れるので、なるべくシンプルにまとめたい。 誤り、不備などあれば、随時追加修正します（ご指摘ありがとうございます）。 クロスサイトスクリプティング（cross site scripting、XSS） 概要 訪問者に目的のサイトとは別の罠サイトを踏ませて不正な処理を実行させる行為。 原因 フォームから受け取った値を、エスケープせずに画面に出力するために発生 （偽のフォームを作成する手法も有るので、JavaScriptの対策だけでは不足） HTMLの実体参照を用い、& を & に、< を < に、> を > に、" を " に、それぞれ置換する。 PHPではhtmlspecialchars関数を用いれば、一括で対策できる （ただしENT_QUOTESを設定しないとシングルクォーテーションはエスケープされない）
『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
この記事はPHPアドベントカレンダー2014の22日目の記事です 。 2002年3月に公開されたIPAの人気コンテンツ「セキュアプログラミング講座」が2007年6月に大幅に更新されました。そして、その一節がPHPerたちを激しく刺激することになります。 (1) プログラミング言語の選択 1) 例えば、PHPを避ける 短時日で素早くサイトを立ち上げることのみに着目するのであれば、PHPは悪い処理系ではない。しかし、これまで多くの脆弱性を生んできた経緯があり、改善が進んでいるとはいえまだ十分堅固とは言えない。 セキュアプログラミング講座（アーカイブ）より引用 「PHPを避ける」とまで言われてしまったわけで、当然ながらネット界隈では炎上を起こし、現在はもう少しマイルドな表現に変わっています(参照)。 本稿では、当時のPHPの状況を振り返る手段として、この後PHPのセキュリティ機能がどのように変化
JSON SQL Injection、PHPならJSONなしでもできるよ
DeNAの奥さんと、はるぷさんがJSON SQL Injectionについて公表されています。 The JSON SQL Injection Vulnerability 不正なJSONデータによるSQL Injectionへの対策について (Json.pm+SQLクエリビルダー) 上記の記事は、主にPerlスクリプトがJSONデータを受け取るシナリオで説明されています。もちろん、この組み合わせに限定したはなしではないわけで、それではPHPではどうだろうと思い調べてみました。 JSON SQL Injectionとは 以下、はるぷさんの「不正なJSONデータによる…」にしたがってJSON SQL Injectionについて説明します。 Perl向けのSQLジェネレータの一つであるSQL::Makerにおいて、以下のスクリプトを想定します。 my ($sql, @bind) = $builde
よくわかるPHPの教科書 PHP5.5対応版のクロスサイト・スクリプティング
たにぐちまことさんの よくわかるPHPの教科書がこのたび改版されて、よくわかるPHPの教科書 【PHP5.5対応版】として出版されました。旧版はmysql関数を使ってSQL呼び出ししていましたが、mysql関数がPHP5.5にて非推奨となったための緊急対処的な内容となっているようです。つまり、従来mysql関数を呼び出していた箇所をmysqliの呼び出しに変更したというのが、主な変更点のようで、これ以外はあまり変更点は見あたりません。 既に、Amazonでは、熱烈な読者の方からの詳細のレビューが届いています。 神本御降臨！ 言わずと知れたPHPプログラミング書籍のロングセラー。 2010年9月に発売された前作の改訂版。 PHPのバージョンも最新の5.5に対応、内容は前作と殆ど同じ。 少し前に前作を購入した方も本書を購入した方がいいでしょう。 【中略】 それにしても、帯の「３万人に読まれた定
Composer のセキュリティ上の問題が直ったので PHP な方は今すぐ更新を - co3k.org
Composer の以下の問題が 2 月半ばあたりから話題になっていました。 Limit Replace / Provides to packages required by name in root package or any dep · Issue #2690 · composer/composer https://github.com/composer/composer/issues/2690 一言で言うと、 条件によってはユーザの意図しないパッケージがインストールされてしまう という問題です。悪意のあるパッケージをインストールしたことに気づかれなければ、攻撃者の思い通りのコードを実行させることができてしまいます。 ざっくり説明すると、 Composer には fork したパッケージや、リネームしたパッケージ から 、元のパッケージを置き換えることのできる機能が存在する (本エン
PHP本体でタイミング攻撃を防御できるようになります
(Last Updated On: 2021年3月25日) PHP 5.6からタイミング攻撃に対する対策が導入されます。メジャーなアプリケーションはタイミング攻撃対策が導入されていますが、PHP 5.6から簡単に対策できるようになります。 タイミングセーフな文字列比較関数はhash_equalsとして実装されました。 http://php.net/manual/es/function.hash-equals.php タイミング攻撃とは タイミング攻撃とは、コンピュータが動作する時間の違いを測って攻撃する、サイドチャネル攻撃（副作用攻撃）と呼ばれる攻撃手法の１つです。HTTPSの圧縮の副作用を利用したサイドチャネル攻撃が有名です。 コンピュータの動作時間、温度、音、電子ノイズ、電力使用量など、アルゴリズム自体の脆弱性を攻撃するのではなく副産物を利用する攻撃方法でサイドチャネル攻撃の一種です。
書籍「気づけばプロ並み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_
PHPのセッションIDは暗号論的に弱い乱数生成器を使っており、セッションハイジャックの危険性がある : DSAS開発者の部屋
下記の文章は、PHPのセッションIDに対する攻撃についてFull Disclosure MLに2010年に投稿された文章を和訳したものです。訳者の意見としては、攻撃の成立条件は極めて厳しく、そこまで深刻度は高くないと考えています。 とはいえ、疑似乱数列への攻撃がどのように行われるのか、その可能性を示す文章は比較的珍しいもののように思います。暗号論的に安全な疑似乱数とは何か、なぜ必要なのかといった内容を間接的に教えてくれる面白い文章だと感じましたので、今回翻訳してみました。 （以下、原文の和訳です） 原文：http://seclists.org/fulldisclosure/2010/Mar/519 Advisory (c) 2010 Andreas Bogk <andreas () andreas org> Product:PHP Version:5.3.2 以降 脆弱性の種類:暗号論的な
PHPとセキュリティの解説書12種類を読んでSQLエスケープの解説状況を調べてみた
この投稿はPHP Advent Calendar 2013の13日目の記事です。昨日は@tanakahisateruのPHPが糞言語なのはどう考えても参照をポインタだと思っているお前らが悪いでした。 現在twitterのタイムラインで、史上空前のSQLのエスケープブームが起こっています。 オレオレSQLセキュリティ教育は論理的に破綻している | yohgaki's blog 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ エスケープとプレースホルダをめぐる議論 - Togetterまとめ SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論 - Togetterまとめ IPAの「安全なSQLの呼び出し方」が安全になっていた | yohgak
フィルター／デコード時のセキュリティ対策の鉄則
(Last Updated On: 2018年8月4日)ブラックリスト型（サニタイズ型）のセキュリティ対策クイズ 解答編 ではバリデーション時の注意点をまとめに書きました。 ホワイトリスト型のバリデーションを行う場合でも以下の項目に注意しなければなりません。 特殊な意味を持つ文字を許可する場合、細心の注意を払う そもそも特殊な意味を持つ文字は許可しない方が良い 絶対の自信が無いのであれば、特殊な意味を持つ文字を許可してはならない ブラックリスト型（サニタイズ型）のセキュリティ対策クイズ 解答編 でパストラバーサルを禁止するようなフィルター処理（ブラックリスト型サニタイズ処理）は基本的には行うべきではありません。しかし、どうしてのフィルター／デコード処理が必要になる場合があります。 正当な理由でフィルター／デコード処理が必要となる代表例はUnicode文字列の正規化です。Unicode文字列
iniscan·php.iniの設定ファイルをチェックして危険なポイントを洗い出し MOONGIFT
PHPは年々進化していて、それでいて過去のバージョンとの互換性もほぼ維持されています。しかしネットワークが進化する中で従来は使われていた設定が非推奨になっていることも少なくありません。 もしかするとWebサーバのPHPの設定が危険な状態になっているかも知れませんよ。それをチェックできるのがiniscanです。 iniscanはcomposerを使ってインストールします。まずはcomposer.jsonを下記の内容で作成します。 $ cat composer.json { "require": { "psecio/iniscan": "dev-master" } } そしてインストールを実行します。 $ sudo composer install Loading composer repositories with package information Installing depende
LDAPエスケープ – PHPのldap_escape関数
(Last Updated On: 2018年8月4日)OWASP TOP10の1位のセキュリティ脅威はインジェクションです。 https://www.owasp.org/index.php/Top_10_2013-A1-Injection SQLインジェクション、コマンドインジェクションはリファレンスとして掲載されていますが、何故かLDAPインジェクションは掲載されていません。しかし、OWASPの別の文書では簡単に解説されています。 https://www.owasp.org/index.php/Testing_for_LDAP_Injection_(OWASP-DV-006) LDAPサーバの設定が脆弱な場合、LDAPインジェクションでLDAPデータベースの中身を大量に盗む事が可能になります。 LDAPライブラリの問題はエスケープ方法が定義されているにも関わらず、LDAPクエリ文字列用
PHPのsetcookie関数で空文字列を設定しようとするとクッキーが削除される
PHPでスクリプトを書いていて、setcookieの第2パラメータ(クッキーの値)の変数をタイプミスしたところ、以下のレスポンスヘッダが送信されていました。 setcookie('A', $misspelled_variable); ↓ 結果 Set-Cookie: A=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT 日付が大昔になっているし、クッキーの値に「deleted」は指定していません。これは、クッキーを削除する時の書き方ですが、PHPでクッキーの削除というと、expiresに過去日付を明示する方法をよく見かけますが、単に第2パラメータを空文字列にすればよかったのか…と思いマニュアルを見たら、一応書いてありました。 http://php.net/manual/ja/function.setcookie.php 陥りやすい失敗 クッキーは
session_regenerate_id関数の第1引数はtrueにすべきか
以前tumblrに書いたエントリ「データベースのデータを信用してはいけないか?」にて、PHP技術者認定試験の想定問題について取り上げましたが、その後、書籍「徹底攻略 PHP5 技術者認定 [上級] 試験問題集 [PJ0-200]対応」が刊行されたことを知り、購入しました。 同試験は、比較セキュリティの配点が高い(12%)ことから、試験問題集にはセキュリティの独立した章として第10章が割り当てられ、セキュリティの問題が21個集められています。 先のエントリで紹介した「ITトレメ PHP技術者認定・初級 過去問題一覧 － ＠IT自分戦略研究所」の問題を見た時の印象は、問題の癖が強く、独自の用語を使っている箇所が多いことが懸念点でしたので、そのような観点から同書第10章「セキュリティ」の問題を確認したところ、全体的に下記の印象を持ちました。 用語としてIPA等で使われている一般的なもの(例:静的
PHP5.5.4にてstrict sessionsのバグ(bug65475)が修正されたがテストがないことに気づいた
以前のエントリで、PHP5.5.2にて大垣さん提案のstrict sessionsがマージされたと報告しましたが、PHP5.5.4にて、このバグ(bug65475)が修正されました。バグの例として紹介したアクセスカウンタも、カウントアップすることを確認しました。 しかし、bug65475のテストを見て、重大な抜けがあることに気づきました。 $ cat bug65475.phpt --TEST-- Bug #65475: Session ID is not initialized when session.usr_strict_mode=1 --INI-- session.save_handler=files session.name=PHPSESSID --SKIPIF-- <?php include('skipif.inc'); ?> --FILE-- <?php ob_start();
PHP5.5.2以降のstrict sessionsモードでセッションフィクセイション対策はどうすればよいか
先日のエントリ『【速報】PHP-5.5.2にて大垣さんのstrict sessionsが実装されました』にて、PHP5.5.2でセッションアダプションが解消されたことを報告しました（session.use_strict_mode=1の場合）。 セッションアダプションとは、未初期化のセッションID（たとえばPHPSESSID=ABC）をPHPが受け入れる問題のことです。strict sessionsを使用すると、PHPが生成し、現在有効であるセッションIDのみを受け入れ、そうでない場合、PHPはセッションIDを振り直します。 あいにくPHP5.5.2（PHP5.5.3も）にはバグがあり、session.use_strict_mode=1によるstrict sessionsは使用できませんが、既に大垣さん自身によりバグ修正されているので、PHP5.5.4からは使えるようになるでしょう。 str
Webノウハウシェア2013のスライド
(Last Updated On: 2018年8月13日)5月24日（金）に開催されたWeb担当者向けのセミナーの「Webノウハウシェア2013」にBOSS-CON JAPANのPHP Security AlianceのCTOとして講演してきました。その講演のスライドです。 http://www.slideshare.net/yohgaki/boss-conphp Javascriptを利用した内部ネットワークのスキャンが可能である事は良く知られていると思います。ここ数年セキュリティ研究者は更に企業ネットワーク内の奥深くに侵入する手法を研究しています。 企業内のシステムはインターネットに公開するシステムに比べると甘いセキュリティ対策が採用される事が多いですが、インターネットと同様のセキュリティ対策を行わないと思わぬリスクが発生します。特にSSRFの脅威は広範囲に渡ります。正しく理解しておく
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文の脆弱性から、個人情報を得る手法を説明します。 脆弱性のおさらい ここで、脆弱性のおさらいをしまし
セッションアダプションがなくてもセッションフィクセイション攻撃は可能
大垣（@yohgaki）さんと、セッションアダプション脆弱性が「重大な脅威」か否かで論争を続けています。 大垣さん:第25回 PHPのアキレス腱 ── セッション管理徳丸:PHPのSession Adoptionは重大な脅威ではない大垣さん:PHPのセッションアダプション脆弱性は修正して当然の脆弱性議論がかみ合わないので、twitterで「ブログ読みました。サンプルも動かしました。問題は分かるのですが、セッションアダプションがないPHPだと、何が改善されるのかが分かりません。教えて下さい」とツイートしたところ、大垣さんがブログで返信下さいました。 大垣さん: セッションアダプション脆弱性がないセッション管理が必要な理由これを読んでかみ合わない理由が分かりました。大垣さん、ありがとうございます。以下大垣さんのブログの末尾を引用します。 脱線しましたが、何が改善されるのか？結論は ログイン時に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
