数年前であれば仕方なかったところですが、2018年の今となっては、パスワードハッシュの手動計算はもはや"悪"です。 まずログイン認証と称してmd5とかsha1とか書いてあるソースはゴミなので投げ捨てましょう。 hashやcryptは上記に比べればずっとマシですが、使い方によっては簡単に脆弱になりえます。 あと『パスワードを暗号化する』って表現してるところも見なくていいです。 PHPには、ハッシュに関わる諸々の落とし穴を一発で解消してくれるpassword_hashという超絶便利関数があるので、これを使います。 というか、これ以外を使ってはいけません。 以下はフレームワークを使わずに実装する際の例示です。 フレームワークを使っている場合は当然その流儀に従っておきましょう。 ハッシュの実装 データベース ユーザ情報を保存するテーブルを作成します。 パスワードカラムの文字数は、システム上のパスワ
下記の文章は、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 以降 脆弱性の種類:暗号論的な
11/15に開催されたこちらの勉強会に参加いたしました! デバッガでWordPress本体やプラグインの脆弱性を追いかけてみよう - connpass こちらの勉強会は、「WordPress本体とプラグインの脆弱性をデバッガで追跡することにより、脆弱性の中身について詳しく追跡し、理解を深める」という内容のものであり、なんとあの徳丸浩さんが講師をされています! 私個人としては、仕事というか半分趣味でゆるゆる脆弱性の検証をしており、今回の勉強会はまさに自分の興味分野にドンピシャな内容だったので、非常に楽しんで参加させていただきましたw 私はこちらの勉強会にブログ枠として参加いたしましたので、勉強会の内容について本ブログにてレポートいたします。 分析対象の脆弱性について 今回分析する題材となった脆弱性は以下の二つです。 なお、二つの脆弱性とも徳丸さんが詳細な解説記事をブログにて公開されております
WordPressの仕事をしていると、稀にPHP5.1.6とかが動いているサーバーのお客さんから依頼を頂くことがあったりする。 できれば開発環境はお客さんのサーバーと一緒の状態で開発したいので、PHP5.1+MySQL5.0の環境を一発で構築出来るDockerファイルを書いた。 仕様 CentOS 6.6 Apache 2 PHP 5.1.6 MySQL 5.0(動作未確認) SSHでログイン可 WordPress向けにPHPの拡張モジュールとかhttpd.confとかphp.iniとか最低限の設定込み WP-CLIとかXdebugとかComposerとかは環境が古くて動かなそうだったので入れていない。 Dockerfile FROM centos:6.6 MAINTAINER m.ietomi <jyokyoku@gmail.com> # TimeZoneの設定 RUN echo 'ZO
2017年10月にPHP5.3.3環境を作るのはとても大変でした。 PHP5.3はすでにEOLを迎えているため、セキュリティホールが修正されずに残りうる危険性があったりとプロダクションで使い続けるのは大変よろしくないですが、大人の都合でどうしても必要になってしまいました。 PHP5.3環境を構築するにあたって、試してダメだったことと、上手く行ったこととを残しておきたいと思います。 試してすんなりできなかったこと Homebrewのbrew install php53 なぜか/usr/local/bin/phpだけが作られず。 macOSをHigh Sierraにアップデートしたせいか? Sierraのときはこれで行けた。 同僚からCeller内のphp5.3.29をまるっともらったが、拡張が上手く入らず。 Docker Hub公式のphp:5.3-cli 5.3.29未満は提供されておらず
PHPオブジェクトインジェクション(PHP Object Injection)攻撃に関してまとめました。Webのインジェクション攻撃というと、SQLインジェクションやOSコマンドインジェクションなどが先に思い浮かびますが、PHPにはオブジェクトインジェクションと呼ばれるものがあります。 PHPにおけるオブジェクトインジェクションは、データのシリアライズに関係するunserialize関数を使用している場合、外部から安全でないシリアライズされた値が注入されることにより、脆弱性になりうる可能性があります。どのような影響があるかどうかは、コードの書き方によって様々です。 本稿は、独自の検証、調べによるもののため、厳密には誤りであったり、そもそも違っているということがあるかもしれません。 ●脆弱性を再現するコード 簡単に脆弱性を再現するコードを用意しました。次の攻撃シナリオはローカルのhostsフ
Joomla!にコード実行脆弱性(CVE-2015-8562)があり、パッチ公開前から攻撃が観測されていたと話題になっています。 Joomlaに深刻な脆弱性、パッチ公開2日前から攻撃横行 「Joomla!」に再び深刻な脆弱性、3.4.6への速やかなアップデートを推奨 パッチ公開の前に攻撃が始まる状態を「ゼロデイ脆弱性」と言いますが、それでは、この脆弱性のメカニズムはどんなものだろうかと思い、調べてみました。 結論から言えば、この問題はJoomla!側に重大な脆弱性はなく、PHPの既知の脆弱性(CVE-2015-6835)が原因でしたので報告します。 exploitを調べてみる 既にこの問題のexploitは公開されていますが、悪い子が真似するといけないのでURL等は割愛します。以下のページでは攻撃の原理が説明されています。 Vulnerability Details: Joomla! Re
hakaikosen.hateblo.jp 上記記事を「あら大変(棒読み)」とか思いながら読んでいたけれど、PHP の BTS の方を読んでみたら確かに原理から再現手順まで細かく記載されていて 「なんかこれまずそう」と思ったので、docker を使って検証してみることに。 PHP 入りの Docker コンテナは、Official のものを利用しました。registry.hub.docker.com 今回の脆弱性、POST しないページには関係ないのかな?と思ってましたが、よくよく見ると PHP さえ動くページであればなんでもいいらしい。 ということで以下のような PHP ファイルを用意し、ここにアクセス (攻撃) をします。 htdocs/index.php <!DOCTYPE html> <html> <head> <title>PHP Bugs #69364</title> </he
「PHP MongoDB administration tool(phpMoAdmin)」は、オープンソースのドキュメント指向データベース「MongoDB」をグラフィカルユーザインタフェース(GUI)で操作できる無料の管理ツールです。phpMoAdmin は 、NoSQL のデータベース「MongoDB」を管理する人気のツールで、PHP言語で記述されています。 2015年3月上旬、リモートでコードが実行されるゼロデイ脆弱性が、「phpMoAdmin」で確認されました。この脆弱性を利用することにより、攻撃者は、認証なしに任意のコードを実行することができます。これは、コマンドインジェクションの脆弱性で、通常は、Webアプリケーションがユーザの入力に基づいて特定のオペレーティングシステム(OS)のコマンドを実行する際に発生するものです。 ■脆弱性の解析 この脆弱性は、「moadmin.php」と
SQLインジェクションはかなり有名になりましたが、オブジェクトインジェクションはまだあまり聞かないので、まとめておきます。 Dependency Injection(DI)とは関係ありません。 オブジェクトインジェクション脆弱性とは? SQLインジェクションが外部からSQL文を注入する攻撃であるのと同じように、オブジェクトインジェクションとは外部からオブジェクトを注入する攻撃です。 外部からオブジェクトを注入できれば、そのオブジェクトの機能によりさまざまな攻撃ができる可能性があります。最悪の場合、任意のコードを実行できる脆弱性になります。 PHPの場合、この攻撃が可能なのは、unserialize()関数を悪用できる場合です。 攻撃の方法 unserialize()関数に外部から任意のデータを渡すコードがあった場合、攻撃者は自由にシリアライズされたデータを送信することで、生成されるオブジェ
PHP is an open-source server-side scripting language, and it is a widely used. The Apache/Nginx/Lighttpd web server provides access to files and content via the HTTP OR HTTPS protocol. A misconfigured server-side scripting language can create all sorts of problems. So, PHP should be used with caution. Here are twenty-five php security best practices for Linux and Unix sysadmins for configuring PHP
昨夜に、魔法少女アパッチ☆マギカ攻撃を観測しました。魔法少女アパッチ☆マギカとは、PoCのソースコードに Apache Magica by Kingcope とコメントされていることに由来しています(というか、私がそう訳しましたw)。 これは10月29日にPoCが発表されたPHP-CGI攻撃(CVE-2012-1823)の変種です。従来のPHP-CGI攻撃は、CGI版PHPが動作する環境で、PHPスクリプト(中身はなんでもよい)に対する攻撃でしたが、魔法少女アパッチマギカの方は、/cgi-bin/に置かれたPHP処理系(php-cgiなど)に直接攻撃するものです。 CGI版PHPを設置する方法は複数ありますが、よく使われる方法としてApacheのリダイレクトによりPHPスクリプトをPHP処理系に実行させる方法があります。この場合、/cgi-bin/php-cgiなどとしてPHP処理系を公開
CGI環境でPHPを動作させているサイトには、リモートからスクリプト実行を許してしまう脆弱性があります。php.netから提供されている修正リリース(PHP 5.3.12 / PHP 5.4.2)は不完全なため、該当するサイトは至急回避策を導入することを推奨します。 概要 CGIの仕様として、クエリ文字列に等号を含めない場合は、クエリ文字列がCGIスクリプトのコマンドライン引数として指定されます。 例えば、http://example.jp/test.cgi?foo+bar+bazという呼び出しに対しては、test.cgiは以下のコマンドラインで呼び出されます。 test.cgi foo bar baz この仕様を悪用して、CGI版のPHPにコマンドライン引数としてPHPのオプションを指定できます。例えば、http://example.jp/test.php?-s というリクエストは、-s
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く