PHPのJSON HashDosに関する注意喚起
4年前にHashDos（Hash Collision Attack）に関する効率的な攻撃方法が28C3にて公開され、PHPを含む主要言語がこの攻撃の影響を受けるため対策を実施しました。しかし、PHP以外の言語が、ハッシュが衝突するデータを予測困難にする対策をとったのに対して、PHPは、GET/POST/COOKIE等の入力データの個数を制限するという対症療法を実施したため、PHPにはHashDosに対する攻撃経路がまだ残っているということは、一部の技術者には知られていました。例えば、以下の様なつぶやきにも見ることができます。 だって、 hashdos 脆弱性の時、 Python とかの言語が、外部入力をハッシュに入れるときに衝突を狙えないように対策したのに、phpだけPOST処理で対策したからね？ json を受け取るような口もってるphpアプリのほとんどがhashdos残ってるんじゃない
PHPにないセキュリティ機能
PHPカンファレンス関西2015での私のセッション「PHPに無いセキュリティ機能」のスライドです。 何が無いのか、知っていれば対応できます。 何が問題になっているのか、知っていれば対応できます。 セキュリティ対策は職人技敵（脆弱性対策をコード中に散りばめ、全体を把握しないと安全にできない作り方）ではなく、CERT/SANS/OWASPが推奨するセキュリティ対策を行い、エンジニアリング的（科学的、体系的な作り方）を行う方が簡単かつより安全、高品質なアプリケーションを作れます。 PDFをダウンロードしたい方はブログをご覧ください。 http://blog.ohgaki.net/missing-security-related-parts-of-phpRead less
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 したパッケージや、リネームしたパッケージ から 、元のパッケージを置き換えることのできる機能が存在する (本エン
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
なぜPHPでrequire("http://...")したらセキュリティホールなのに、Goならいいのか - kazuhoのメモ置き場
go言語なんか import "http://github.com/mattn/xxx " だったりする。rubyもそういうの面白いかもしれない。require "http://github.com/mattn/xxx "みたいな。 mattn on Twitter: "go言語なんか import "http://t.co/9qiwho7OMZ" だったりする。rubyもそういうの面白いかもしれない。require "http://t.co/9qiwho7OMZ"みたいな。" @mattn_jp それコンパイル型言語なら許されるけどスクリプト型だとセキュリティホールとされるものでは？ (e.g. PHP) Kazuho Oku on Twitter: "@mattn_jp それコンパイル型言語なら許されるけどスクリプト型だとセキュリティホールとされるものでは？ (e.g. PHP)" と
安全なPHPアプリケーションの作り方2013
PHPカンファレンス2013における徳丸のプレゼン資料です。後から、参考文献などを加筆しました。Read less
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
Supercolliding a PHP array
28. December 2011 Did you know that inserting 2^16 = 65536 specially crafted values into a normal PHP array can take 30 seconds? Normally this would take only 0.01 seconds. This is the code to reproduce it: $size = pow(2, 16); // 16 is just an example, could also be 15 or 17 $startTime = microtime(true); $array = array(); for ($key = 0, $maxKey = ($size - 1) * $size; $key <= $maxKey; $key += $size
PHPのescapeshellcmdの危険性 - 徳丸浩の日記
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2011年1月1日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 本を書いています。初稿を一通り書き上げ、第2稿を作成中です。その過程で見つけたことを報告します。 PHPのescapeshellcmdはパラメータをクォートしないので呼び出し側でクォートする必要がありますが、escapeshellcmdの仕様がまずいために、呼び出し側でクォートしても突破できることが分かりました。 escapeshellcmdの仕様 PHPにはシェルのパラメータをエスケープする関数が2つあります。escapeshellargとescapeshellcmdです。escapeshellargは、エ
ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2010年7月1日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPのデータベース・アクセス・ライブラリPDOは、DB接続時の文字エンコーディング指定ができないため、文字エンコーディングの選択によっては、プレースホルダを使っていてもSQLインジェクション脆弱性が発生します。 追記(2011/06/19) ここに来て急にブクマが追加されはじめていますが、このエントリを書いてから状況が改善しています。PHP5.3.6(2011/03/17)にて、PDOでもデータベース接続の文字エンコーディングを指定できるようになりました。この版で、UNIX版のPHPでは解決しましたが、Win
PHPで予め許可したタグと属性以外を除去できるライブラリ「kses」:phpspot開発日誌
CSS3のでのボックス要素デザインを圧倒的に簡単化できる「CSS3 Click Chart... 次の記事 ≫：アプリやWEBサイトに使えそうなフリーな244個のアイコンセット kses - PHP HTML/XHTML filter | Download kses - PHP HTML/XHTML filter software for free at SourceForge.net PHPで予め許可したタグと属性以外を除去できるライブラリ「kses」。 外部からの入力値は基本的にhtmlspecialcharsでタグを無効化するのが通常の考え方ですが、掲示板なんかで特定のタグを許可したいという場合があります。 PHPにはstrip_tagsというようなタグを除去しつつ、特定のタグのみを残すという関数が標準であったりしますが、これだと属性までは制御しきれません。 更には、<a href=
文字エンコーディングの妥当性確認(バリデーション)について - t_komuraの日記
大垣さんからコメントをいただきましたので、最後に追記しました(2009.09.22)。 少し時間が経ってしまいましたが、以下のページを読んで、PHP に関連する部分について思ったことを書きたいと思います。 http://blog.ohgaki.net/char_encoding_must_be_validated http://blog.ohgaki.net/is-char-encoding-problem-difficult 私の理解が間違っていなければ、「Web アプリケーションで文字エンコーディングに関連する問題を無くす」ことを目的として、全ての Web アプリケーション開発者が以下を実行しようという主張だと思います。 全ての入力文字列の文字エンコーディングの妥当性を確認する 文字エンコーディングを厳格に取り扱う データベースなどで「バイナリ」に近い文字エンコーディングは利用しない
今更ながらmagic_quotes_gpcの欠点 - teracc’s blog
今更ながらですが、PHPのmagic_quotes_gpcをOnにすべきでない理由を整理してみます。 世の中には、magic_quotes_gpcはOffにすべき、と書いた文章は多数あるのですが、その理由を（私が見る限りで）十分に説明しているものは無いからです。 以下では、 1. 対象外の変数の存在 2. 弊害（副作用） 3. エスケープの不完全さ という三つの観点から記述します。 対象外の変数の存在 magic_quotes_gpcの、「gpc」はGET/POST/COOKIEを表しています。つまり、この3種類のリソースからの入力はエスケープされますが、それ以外は原則エスケープされません。 エスケープされているもの、されていないものを、以下にまとめてみます。 エスケープ済み ・$REQUEST $_GET・$_POST・$_COOKIE 場合によってエスケープ済み ・$_SESSION（
PHPのSession Fixation問題
(Last Updated On: 2006年10月24日)PHPのセッション管理はセッションの固定化（Session Fixation）に脆弱であることは広く知れらていると思っていました。先日、php-users(ja)のMLに「Hardened PHPプロジェクトのStefanさんのパッチにSQLite Sessionモジュール用のセッションセーブハンドラパッチを追加したパッチを公開しました」と投稿しました。しかし、ダウンロード数等から推測するとセッションの固定化のリスクが正しく認識されていないのではないかと思えます。 セッション固定化のリスクを分かりやすく説明するには具体的な攻撃のシナリオを紹介した方がわかり易いのでいくつか説明します。以下の説明はデフォルト状態のPHPインストールでSession Fixation対策を行っていないのPHPアプリケーションに対して可能な攻撃の一例です
PHP:既知のセキュリティ脆弱性 – Session Adoption
(Last Updated On: 2018年8月13日)追記：より新しい情報については間違いだらけのHTTPセッション管理とその対策をどうぞ。 PHPには広く知られているにも関わらず放置されている既知のセキュリティ脆弱性が幾つかあります。その一つがセッションモジュールのセッションアダプション(Session Adoption)脆弱性です。この脆弱性は現在広く利用されているWebアプリケーションの安全性に、非常に大きな影響を与える脆弱性です。 セッションアダプション脆弱性とはセッション固定化攻撃を可能とする脆弱性の一種です。セッションアダプションに脆弱なセッション管理システムは、ユーザ(ブラウザ)が送信してきた未初期化のセッションIDを受け入れ、セッションを初期化してしまいます。PHPに限らず、RailsやJavaのフレームワーク等、多くのWebフレームワークに発見されている脆弱性です。
PHP/脆弱性リスト/メモ - yohgaki's wiki
なんだかやけに長い説明ばかり検索に引っかかったので書きました。 Linuxのローカル環境でDockerコンテナ内のXアプリ（GUIアプリ）を利用するには $ xhost localhost + を実行した後に $ docker run --rm --net host -e "DISPLAY" container_image_name x_app_binary_path とすれば良いです。 もっと読む SSHなどよく知られたサービスポートで何も対策せずにいると数えきらないくらいの攻撃リクエストが来ます。不必要なログを増やしてリソースを無駄にし、もし不用意なユーザーやシステムがあると攻撃に成功する場合もあります。 SshguardはC作られており、flex/bisonのパーサールールを足せば拡張できますがカスタム版をメンテナンスするのも面倒です。必要なルールを足してプルリクエストを送ってもマー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2012