laravelのヤバい脆弱性をついたkinsing(kdevtmpfsi)というマルウェアに感染した話 CVE-2021-3129 - Qiita
laravelのヤバい脆弱性をついたkinsing(kdevtmpfsi)というマルウェアに感染した話 CVE-2021-3129PHPSecurityLaravelkinsingkdevtmpfsi webサーバー上でlaravelを動かしていれば、ちょっとした設定のミスで誰でもマルウェアに感染する可能性がある激ヤバセキュリティホール(CVE-2021-3129)が2021年1月20日に報告されています！ composerでインストールしたパッケージをバージョンアップせずに使っていませんか？ インターネット上に公開されているサーバー、特にステージングや開発環境でDEBUG=ONにしていませんか？ エラー画面がこんな風に見えますか？ この3つの条件を満たしていると、あなたのlaravelは、今すぐにでもマルウェアに感染する可能性があります。 laravelの脆弱性をついたkinsing(k
password_hash()の安全性について
パスワードの保存にハッシュ値を用いるのは、「もっと良い方法がない」からというのが単純化した理由です。 たとえば、暗号鍵を安全に保存でき、外部に漏洩しないことが確実であるならば、ハッシュ値よりも暗号化して保存した方が確実です。 しかし、そもそもパスワードを保護する理由というのは、なんらかの理由でパスワード情報が漏洩した後の保護をしたいわけなので、パスワード情報は漏洩するが鍵は漏洩しないというシナリオは描きにくいわけです。絶対にできないわけでもありませんが、ハードウェアセキュリティモジュール(HSM)を使用するような高価な方法となりますし、サーバーに侵入されているという前提では、HSMとて絶対とまでは言えません。 このため、暗号鍵のような秘密情報を安全に保存できるという前提をさわやかにあきらめた方法が、pashword_hash等で採用されている方法で、これが現在の主流です。 まず、ハッシュ値
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_
t_komuraの日記
以下の徳丸さんの記事を読んで、以前にmb_send_mail()の関連で調べたことがあったのを思い出しましたので、少し書きます。 PHPだってシェル経由でないコマンド呼び出し機能が欲しい 環境は Unix 系の OS で OS コマンドを使用してメールを送信する場合です。メール送信コマンドは php.ini で sendmail_path を設定します(デフォルト: "sendmail -t -i")。 mb_send_mail関数(mail関数も同様)ですが、第5引数(additional_parameter)にユーザの入力を使用する場合は注意が必要です。mb_send_mail関数の第5引数は、内部でescapeshellcmd(内部関数名:php_escape_shell_cmd)によって引数の文字列全体がエスケープされます。 escapeshellcmd() は、以前に徳丸さんから
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
CGI版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処理系を公開
FuelPHP でのセキュリティ対策(1) - A Day in Serenity @ kenjis
FuelPHP Advent Calendar 2011 の 20日目です。 昨日は、@regepan さんの「FuelPHPでメールフォーム雑感。」でした。今日は、FuelPHP でのセキュリティ対策について解説します。1回では終わりそうにないので、何回か続く予定です。 では、FuelPHP での主要なセキュリティ対策について解説していきます。この記事は FuelPHP 1.1 を前提としています。 FuelPHP では、デフォルトのセキュリティ機能として以下が用意されています。 デフォルトのセキュリティ機能 出力フィルタ URI フィルタ SQL インジェクション対策 また、デフォルトではありませんが、以下のセキュリティ機能もあります。 セキュリティ機能 入力フィルタリング CSRF 保護 XSS フィルタリング Validation クラス Validation については、4日目の
安全なPHPアプリケーションの作り方2013
PHPカンファレンス2013における徳丸のプレゼン資料です。後から、参考文献などを加筆しました。Read less
PHPでデータベースに接続するときのまとめ - Qiita
【2021/10/15 追記】 この記事は更新が停止されています。現在では筆者の思想が変化している面もありますので，過去の記事として参考程度にご覧ください。PDO に関しては大きく変わっていない部分が多いとは思いますが， PHP 8.x 以降での動作保証はありません。 あらかじめ読んでおきたい記事 Qiita - 【PHP超入門】クラス～例外処理～PDOの基礎 by @7968 初心者がやりがちなミス 以下のどれかに1つでも当てはまるコードは見直す必要があります．付録にリンクを貼っておきましたので，「該当するかも？」という人はクリックして飛んで読んでください．太字にしてあるものは脆弱性に直結する危険度の高いものです． mysql_query などの非推奨関数を利用している SET NAMES あるいは SET CHARACTER SET などで文字コードを指定している そもそもデータベース
PHP on the Cake !: フォームのリロードと遷移
PHP on the Cake ! CakePHP のインストール、設定法、使用例。愛すべき駄目プログラム言語・PHP による Web アプリケーションの品質向上の為に。 2008年4月10日木曜日 一般的な登録フォームの画面遷移は次の様に考えられる。 入力画面→入力確認画面→完了画面 「完了画面」で登録や送信の処理が実行されるので、この画面で再読み込み(リロード)をされると同じ処理を繰り返すことになる(メールが2通送られたり)。 これを防ぐ手段としてはチケットやトークンというものを発行して、処理が完了したら破棄させて再処理させないようにするのがおそらく一般的(要するに未処理・未送信を表すフラグを使う)。 【PHP TIPS】 58. すごいリロード対策 - ITpro リンク先では、「確認画面」で乱数のチケットを発行しセッションに保存、「完了画面」で確認することでリロード対策とCSRF
すごいリロード対策 - p4lifeのメモ
メモ, PHP【PHP TIPS】 58. すごいリロード対策紹介されているのはシンプルなワンタイムトークン．単純なリロード対策であれば ticket の値は乱数でなくても良い．ここを乱数にすることで CSRF 対策も兼ねている．ただこの方法は，場合によってはフォームを正常に送信できなくなってしまう問題がある． 例えば，入力画面→入力確認画面と遷移してから別のウィンドウで入力画面→入力確認画面と遷移すると，前の入力確認画面のフォームは ticket が無効になり，フォームを送信できなくなる（複数画面同時編集ができない）． 解決策としては，発行したトークンを全て記憶しておき，POST されたトークンと照合する方法がある． confirm.php session_start(); $token = sha1(uniqid(mt_rand(), true)); // トークンをセッションに追加す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
安全なPHPアプリケーションの作り方2014
PHPでセキュリティを真面目に考える
これからの「パスワード」の話をしよう