Laravel の脆弱性 CVE-2017-14775 の対処法 - Innovator Japan Engineers’ Blog
こんにちは。エンジニアの @localdisk です。2017/09/27に CVE-2017-14775 という Laravel の脆弱性が報告されました。CVE-2017-14775 はオートログイン処理に*1タイミング攻撃の脆弱性があるというものです。 タイミング攻撃についてとその対策については下記エントリに詳しくまとまっています。 PHP本体でタイミング攻撃を防御できるようになります | yohgaki's blog この脆弱性は 2017/09/21 にリリースされた 5.5.10 で修正されています。対象のクラスは下記になります。 Illuminate\Auth\DatabaseUserProvider Illuminate\Auth\EloquentUserProvider 修正された PR は下記になります。 [5.5] [Security] Close remember_
PHP7調査(31)暗号論的に安全な疑似乱数生成器（CSPRNG）を提供する新関数 - Qiita
PHP5までは暗号論的に安全な疑似乱数生成器(CSPRNG)を提供する標準関数がなかったため、CSPRNGが必要な場合に自分で明示的に/dev/urandomにアクセスしたりしていました。opensslエクステンションおよびmcryptエクステンションもCSPRNG関数を提供していますが1、どちらも必須のエクステンションでは無いため、ライブラリなどでは採用しにくい状況があったはずです。 PHP7から、どの環境でも動くCSPRNG関数としてrandom_bytes()とrandom_int()の2つが新規実装されます。 <?php // ランダムな2バイトの文字列を返す。各バイトは0x00から0xffのどれか。 var_dump(bin2hex(random_bytes(2))); // 5以上9以下の整数をランダムに返す var_dump(random_int(5,9)); 実装 Wind
PHP: openssl_random_pseudo_bytes と mcrypt_create_iv の比較
PHP 5.5 でパスワードハッシュ関数が導入されるPHP: パスワードハッシュライブラリのコードスニペットPHP: PBKDF2 を使ってパスワードハッシュを生成するPHP: 疑似乱数の文字列を生成するPHP: openssl_random_pseudo_bytes で疑似乱数を生成するPHP: openssl_random_pseudo_bytes と mcrypt_create_iv の比較PHP: フォームに CSRF 対策のトークンを導入するPHP: フォームに CSRF 対策のトークンを導入する (その2)JavaScript: CSRF 対策のトークンヘッダーを送信する ランダムな文字列を生成するにはファイル関数を使って /dev/urandom に直接アクセスするやりかたがもっとも明快であり、OS のしくみを学ぶ機会を提供するので、教育的でもある。徳丸本でもそのやりかたが採
PHPで本気で安全なパスワードを生成する - espresso3389の日記
Twitterで PHPで、いわゆる安全な秘密鍵を生成する方法っていうのがネットにほとんど記述されてないという事実に愕然としている。みんな、暗号乱数ぐらい勉強してくれ・・・。— Takashi Kawasaki (@espresso3389) April 12, 2014 なんて発言をしたら結構反響があったので、責任を取って、これならまぁ許せるというサンプルを出しておく。エントロピーの無駄遣いなどというぐらいの理解がある人は自分で実装してください。マジ実装すると結構面倒なので諦めました。 コピペするならここからどうぞ <?php // パスワードに使っても良い文字集合 $password_chars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789'; $password_chars_count = strl
htmlspecialcharsは不正な文字エンコーディングをどこまでチェックするか
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2009年9月30日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、PHPのhtmlspecialchars関数の第三パラメータ（文字エンコーディング指定）により、どこまで文字エンコーディングの妥当性チェックをしているかを報告します。 2007年4月に、寺田氏(id:teracc)の素晴らしいエントリ「htmlspecialcharsと不正な文字の話」により、htmlspecialcharsは、第三パラメータの文字コードを実質的に無視しており、不正な文字エンコーディングが指定された場合、その文字はチェックされずにすり抜けてしまうという結果が報告されています。
phpMyAdminにおける任意スクリプト実行可能な脆弱性の検証 - ockeghem's blog
phpMyAdmin（3.3.10.2未満、3.4.3.1未満）には、リモートから任意のスクリプトが実行可能な脆弱性があります。このエントリでは、この脆弱性が発生するメカニズムと対策について報告します。 概要 phpMyAdminには下記の2種類の脆弱性の組み合わせにより、リモートから任意のスクリプトを実行させられる脆弱性があります。 CVE-2011-2505 CVE-2011-2506 該当するバージョンは以下の通りです。 phpMyAdmin バージョン3.3.10.2未満 phpMyAdmin バージョン3.4.3.1未満 影響を受ける条件は、上記バージョンのphpMyAdminを使用していることに加えて、以下をすべて満たす場合です。 setup/index.phpとsetup/config.phpを外部から実行できる phpMyAdminのconfigディレクトリが存在し、PHP
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を避ける』以降PHPはどれだけ安全になったか
この記事はPHPアドベントカレンダー2014の22日目の記事です 。 2002年3月に公開されたIPAの人気コンテンツ「セキュアプログラミング講座」が2007年6月に大幅に更新されました。そして、その一節がPHPerたちを激しく刺激することになります。 (1) プログラミング言語の選択 1) 例えば、PHPを避ける 短時日で素早くサイトを立ち上げることのみに着目するのであれば、PHPは悪い処理系ではない。しかし、これまで多くの脆弱性を生んできた経緯があり、改善が進んでいるとはいえまだ十分堅固とは言えない。 セキュアプログラミング講座（アーカイブ）より引用 「PHPを避ける」とまで言われてしまったわけで、当然ながらネット界隈では炎上を起こし、現在はもう少しマイルドな表現に変わっています(参照)。 本稿では、当時のPHPの状況を振り返る手段として、この後PHPのセキュリティ機能がどのように変化
大垣本を読んで「バリデーションはセキュリティ対策」について検討した - ockeghem(徳丸浩)の日記
このエントリでは、セキュリティの観点から、バリデーション実装について検討します。大垣さんの本を読んで「大垣流バリデーション」について勉強した結果を報告します。 はじめに 大垣さんの記事「入力バリデーションはセキュリティ対策」では、「入力バリデーションはセキュリティ対策である」が力説されています。この記事はおそらくid:ajiyoshiさんのブログ記事「妥当性とは仕様の所作 - SQLインジェクション対策とバリデーション」を受けてのことだと思います。id:ajiyoshiさんのエントリでは、「妥当性検証は仕様の問題であってセキュリティ対策ではありません」と明言されています。私はid:ajiyoshiさんに近い考えを持っていますので、大垣さんの主張について、私なりに考えてみました。 記事を書くにあたり、徳丸の立場を明確にしておきたいと思います。 バリデーションの基準は仕様の問題 バリデーション
PHPMailerのリモートコード実行脆弱性(CVE-2016-10033)の影響範囲 - Qiita
今回の脆弱性 CVE-2016-10033 CVE-2016-10045 CVE-2016-10074(Swift Mailer) 追記 2016/12/28 14:15 Postfixを使っていて、sendmailコマンドの代わりにPostfixのsendmailコマンドを使っている場合は、Postfixのsendmailコマンドが -X オプションを無視するようですので大きな影響を受けないと思います。ただ、別のオプションで違う脆弱性が発生する可能性もあるので、PHPMailerはアップデートしたほうが良いですね。 2016/12/28 15:35 PHPMailer5.2.18の修正を回避する新しい攻撃が見つかり、 CVE-2016-10045として登録されその攻撃方法も公開されてます。こちらはPHPMailer5.2.21で対応されています。 この攻撃は、PHPMailer5.2.1
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
PDOにおける一応の安全宣言と残る問題点
8月18日にPHP5.3.7がリリースされました。このリリースにより、PDOのSQLインジェクションの問題が一応解決されたと判断しましたので、ここに「一応の安全宣言」を表明するとともに、残る問題について報告します。 PDOの問題とは何か 以前、ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)にて報告したように、PHP5.3.5以前のPDOにはDB接続時に文字エンコーディングを指定する機能がないため、文字列リテラルのエスケープの際に文字エンコーディングをLatin1を仮定してしまうという問題がありました。この状態ですと、DBにShift_JISで接続している際に、SQLインジェクション脆弱性が混入しました。 ※ 実は、先のエントリの「追記(2010/07/01 22:20)」に紹介した方法で文字エンコーディングを指定できるのですが、ほとんど知られていないのと
PHPでデータベースに接続するときのまとめ - Qiita
【2021/10/15 追記】 この記事は更新が停止されています。現在では筆者の思想が変化している面もありますので，過去の記事として参考程度にご覧ください。PDO に関しては大きく変わっていない部分が多いとは思いますが， PHP 8.x 以降での動作保証はありません。 あらかじめ読んでおきたい記事 Qiita - 【PHP超入門】クラス～例外処理～PDOの基礎 by @7968 初心者がやりがちなミス 以下のどれかに1つでも当てはまるコードは見直す必要があります．付録にリンクを貼っておきましたので，「該当するかも？」という人はクリックして飛んで読んでください．太字にしてあるものは脆弱性に直結する危険度の高いものです． mysql_query などの非推奨関数を利用している SET NAMES あるいは SET CHARACTER SET などで文字コードを指定している そもそもデータベース
PHPとセキュリティの解説書12種類を読んでSQLエスケープの解説状況を調べてみた
この投稿はPHP Advent Calendar 2013の13日目の記事です。昨日は@tanakahisateruのPHPが糞言語なのはどう考えても参照をポインタだと思っているお前らが悪いでした。 現在twitterのタイムラインで、史上空前のSQLのエスケープブームが起こっています。 オレオレSQLセキュリティ教育は論理的に破綻している | yohgaki's blog 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ エスケープとプレースホルダをめぐる議論 - Togetterまとめ SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論 - Togetterまとめ IPAの「安全なSQLの呼び出し方」が安全になっていた | yohgak
最新の PHP スナップショットでの htmlspecialchars()/htmlentities() の修正内容について - t_komuraの日記
前の記事(Shift_JIS では、htmlspecialchars() を使用しても XSS が可能な場合がある)で Shift_JIS ではブラウザによっては XSS が発生する可能性があることを書きました。この問題は、PHP の開発版のスナップショット(snaps.php.net)で修正されたことを確認しましたが、それ以外にも、EUC-JP や UTF-8 について修正が行われました。この件で、行動された方に感謝します。どうもありがとうございました。その後、修正内容について調べましたので、メモしておきます。他の修正点など、何か気付いた方がおられましたら、ぜひ教えてください。 この修正は、PHP 5.3.2/PHP 5.2.12 で反映されることになると思います。実際の修正内容の大半は、以下で行われました。 http://svn.php.net/viewvc?view=revision
PHP と Web アプリケーションのセキュリティについてのメモ
このページについての説明・注意など PHP は、Apache モジュールや、CGI、コマンドラインとして使用できるスクリプト言語です。このページでは、主に PHP における、Web アプリケーションのセキュリティ問題についてまとめています。 Web アプリケーションのセキュリティ問題としては、以下の問題についてよく取り挙げられていると思いますが、これらのセキュリティ問題について調べたことや、これら以外でも、PHP に関連しているセキュリティ問題について知っていることについてメモしておきます。 クロスサイトスクリプティング SQL インジェクション パス・トラバーサル(ディレクトリ・トラバーサル) セッションハイジャック コマンドインジェクション また、PHP マニュアル : セキュリティや、PHP Security Guide (PHP Security Consortium) には、PH
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
