JavaScript文字列のエスケープ
これらの中で注目すべきは ‘ と ” と \ です。シングルクォート、ダブルクオートは文字リテラルを作成する為に利用され、\ でエスケープできることです。つまり、文字リテラルの最後に \ が現れると文字列の終端が無くなります。単独で不正なJavaScriptの挿入が可能になる訳ではありませんが、プログラムの構造が破壊される事を意味します。 PHPにはJavaScript文字列用のエスケープ関数が用意されていません。htmlspecialchars()やhtmlentities()で代用している場合も多いと思います。しかし、これらの関数ではJavaScript文字列のエスケープを十分に行う事ができません。 JavaScriptプログラムの構造が破壊される例 <?php $msg1 = 'test string\\'; $msg2 = ');alert(document.cookie); //
PHPに関するHTTPOXY脆弱性の問題と対応方法 - Code Day's Night
外部から簡単にHTTP_PROXYという環境変数がセットでき、サーバ間通信や外部サイトと連携している場合に影響があるかもしれない脆弱性です。(HTTPoxy. CVE-2016-5385) PHPの場合はphp-fpm, mod_php, Guzzle4以上やいくつかのライブラリで影響あります。 対応方法は簡単です。 Apache側で対応する場合は、mod_headerを使える状況であれば、confファイルに下記の1行を追加。 RequestHeader unset Proxy FastCGIの場合は下記の1行を追加。 fastcgi_param HTTP_PROXY ""; Guzzleは6.2.1で対応されたようです。 Release 6.2.1 release · guzzle/guzzle · GitHub コミットログを見ると、CLIの時のみ、getenv('HTTP_PROXY
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_
bashにおける脆弱性「Shellshock」について
2014/09/26 コース：元祖こってり 「元祖こってり」記事はネットエージェント旧ブログ[netagent-blog.jp]に掲載されていた記事であり、現在ネットエージェントに在籍していないライターの記事も含みます。 bashにおける脆弱性「Shellshock」について LinuxやMac OS XなどのUNIX系OSで広く使用されているbashに見つかった脆弱性(Shellshockと呼ばれています)が先日から話題になっています。 弊社でもこのbashの脆弱性について調査を行いました。 ■概要 環境変数に特定の文字列を設定するだけでその環境変数内の文字列をシェルが関数として実行してしまいます。 シェルを通じてコマンド等を実行する幅広い環境で影響がありますが、特に顕著に影響を受けるのはCGI等のWebアプリケーション環境です。 CGIをはじめとするWebアプリケーションではWebブラ
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 したパッケージや、リネームしたパッケージ から 、元のパッケージを置き換えることのできる機能が存在する (本エン
間違いだらけのHTTPセッション管理とその対策
(Last Updated On: 2018年10月12日)HTTPセッション管理はWebセキュリティの中核と言える機能です。Webセキュリティの中核であるHTTPセッション管理に設計上のバグがある事は少なくありません。今回のエントリはPHP Webアプリ開発者ではなく、主にWebフレームワーク側の開発者、つまりPHP本体の方に間違いがあるという話しです。Webアプリ開発者の回避策も紹介します。 まずセキュリティの基本として「入力のバリデーションを行い、正当な入力のみを受け入れる」があります。しかし、PHPに限らず多くのセッション管理機構は当たり前の「入力のバリデーションを行い、正当な入力のみを受け入れる」を行っていません。セッションIDの再生成（リセット）も不完全な物が多いと思います。 参考： 知らないと勘違いする「合成の誤謬」の罠 開発者は必修、SANS TOP 25の怪物的なセキュリ
PHP5.5.0 から導入されたパスワードハッシュ関数を使ってみた - mikanmarusanのブログ
概要 パスワードのハッシュ パスワードハッシュ API は crypt() を手軽に使えるようにしたラッパーで、 パスワードの作成や管理を安全な方法で行えます。 crypt() を利用すればパスワードハッシュの生成は可能なんだけど、経験上煩雑なコードになりやすい気がして（自分がPHPを書くのが下手なだけかもしれないけど）ちょっと勉強してみた。 環境構築 vagrantでUbuntu(raring)を用意し、php5.5.7をLaunchpadのPersonal Package Archiveでインストール。 $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 13.04 Release: 13.04 Codename: raring $ php -v PHP 5.
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 以降 脆弱性の種類:暗号論的な
Webブラウザが「PHP.net」へのアクセスを遮断、マルウェア配布の疑い
PHP.netへのアクセスが遮断されたのは誤検知とみられていたが、同サイトが改ざんされ、マルウェア配布に使われた可能性も指摘されている。 多くの開発者が利用する「PHP.net」のドメインがGoogleのSafe Browsing機能によって不正サイトと認識され、一時的に同ドメインへのアクセスが遮断される状態になった。PHPのサイトが改ざんされ、マルウェア配布に使われた可能性も指摘されている。 米セキュリティ機関SANS Internet Storm Center（ISC）などが10月24日に伝えたところでは、PHP.netのドメインのWebサイトにアクセスしようとすると、「このWebサイトはマルウェアに感染しています」というSafe Browsingの警告がWebブラウザに表示される状態になっていた。 当初はSafe Browsingによる誤検知とみられていたが、セキュリティ企業のBar
続) ロリポップのWordPress大量乗っ取りについての推測と対応
昨晩、すでに寝ていましたら、GMO総帥の熊谷氏からツイート来てました。埋もれてて気づかなかったのですが友人が教えてくれました。倉持さん、ありがとう。 株価についてはブログには書いてないのですが、つい口が滑ってツイートしてしまいました。申し訳ございません。m(_ _)m しかしながら、事実でなかったらという意味が分かりません。ブログのタイトルも内容もGMO運用のサーバで大量のWordPressの乗っ取りが発生している」ということで事実を確認してから書いてます。その理由としてWordPressフォーラムに複数の被害者から投稿された内容から推測して、「これだけ一度に大量の乗っ取られるということはDB侵入の可能性がある」とあくまで可能性について触れただけです。これは誰もが同じ推測をしたわけで、WordPressフォーラムでも同様に言及されております。いらだちの気持ちはわかりますが、わたしに怒りをぶ
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
【速報】PHP-5.5.2にて大垣さんのstrict sessionsが実装されました
大垣さんのツイートで、strict sessionsがPHPにマージされることを知りました。 やっとStrict Sessionがマージされました。8年越しです。... http://t.co/ZBuVTHunqy — Yasuo Ohgaki (大垣靖男) (@yohgaki) August 5, 2013 本日、PHP-5.5.2が公開されましたので、ChangeLogを確認したところ、確かに入っているようです。 Sessions: Implemented strict sessions RFC (https://wiki.php.net/rfc/strict_sessions) which protects against session fixation attacks and session collisions. PHP 5 ChangeLog より引用 8年越しのstrict
WAFの限界 – WAFが追加のセキュリティ対策である理由
(Last Updated On: 2018年8月8日)このエントリは何年も前（日付を見たら2008年８月）に書きかけで放置していたエントリです。最近書いた、セッションアダプション脆弱性をPHPのモジュールレベルで修正するパッチについての議論の参考になると思うので公開します。私は補助的な意味合いを持つ追加のセキュリティ対策は無意味であるとは全く考えていません。対策の限界を知って、有効に利用する。それで良いのでは無いでしょうか？以下、書きかけで未公開だったエントリです。 関連エントリ： セッションフィクセイションはアダプション脆弱性修正で防御可能 （特にコメント欄） WAFは有用なセキュリティ対策です。これに異論は無いでしょう。ゼロデイ対策にはWAFは非常に有効であり、可能であれば導入すべきだ、とセミナーでも繰り返し説明しています。しかし、WAFは万能ではありません。導入すれば安全性が簡単か
PHP 5.3.4以降ではヌルバイト攻撃が成立しにくくなった - hnwの日記
今回はWebセキュリティの話題です。実はid:t_komuraさんの記事で既報なんですが、案外知られていない気がしたので改めて紹介します。 PHPアプリケーションに特化した攻撃手法として、ヌルバイト攻撃というものがあります。PHPの大半の関数がヌル文字\0（0x00）を文字として認識する一方、Cの関数を直接呼び出すような一部関数では文字列の終端文字として機能することがあり、このねじれを利用する攻撃のことを言います。 特に、これまではディレクトリトラバーサル脆弱性やLFI（Local File Inclusion）脆弱性との組み合せでヌルバイト攻撃が言及される印象がありました。例えば次のような状況です。 <?php function __autoload($class_name) { require 'lib/' . $class_name . '.php'; } $obj = new $_
JVN#63650108: Smarty におけるクロスサイトスクリプティングの脆弱性
Smarty は、PHP 用のテンプレートエンジンです。Smarty には、エラーメッセージを出力する際の処理に起因する、クロスサイトスクリプティングの脆弱性が存在します。
FuelPHPのCSRF対策トークンは何が問題だったのか
田中ひさてる @tanakahisateru 話題のFuelPHPのCSRFの件は https://t.co/e2Wh7p5p あたりかな。 uniqid() がもうすでに時刻に準拠した値なのに time() 付けてもねぇ、このソース公開しちゃってるしねぇということ? 2012-06-06 14:06:50
CVE-2012-1823 CVE-2012-2311 PHP の CGI モードにおける脆弱性について – IIJ Security Diary
この脆弱性は2012年5月3日にリリースされた PHP バージョン 5.3.12 と 5.4.2 において明らかになりました。CGI モードにて動作させている場合のみ影響を受けますが、対象となる環境ではリモートからソースコード漏洩、任意コード実行を引き起こす攻撃が可能です。 以下のサイトに脆弱性の発見者による解説が公開されています。 Eindbazen PHP-CGI advisory (CVE-2012-1823) 該当するPHPのリリースノートは以下です。 PHP 5.3.12 and PHP 5.4.2 Released! PHP 5.4.3 and PHP 5.3.13 Released! 既に攻撃も観測されているようです。 PHP-CGI Vulnerability Exploited in the Wild この脆弱性に対しては CVE-2012-1823 が割り当てられており
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
れいさの本当に目が覚めるPHP - Togetterまとめ
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2012
hnw on Twitter: "@do_aki ダメっぽいですね。RAND_bytesは「cryptographically strong pseudo-random bytes」を返すけどRAND_pseudo_bytesは「are not necessarily unpredictable」だそうで。"