タグ

ブックマーク / blog.tokumaru.org (5)

  • PHPのmail関数、mb_send_mail関数のマニュアルに警告が追記されていた

    昨日の記事PHPMailerの脆弱性CVE-2016-10033について解析したにて、PHPMailerの脆弱性CVE-2016-10033の原因はmail関数が内部で呼んでいるescapeshellcmd関数の仕様が原因であると指摘しました。そして、mail関数の危険性については、小邨孝明さんが2013年12月23日の記事にて指摘していました。 mb_send_mail関数(mail関数も同様)ですが、第5引数(additional_parameter)にユーザの入力を使用する場合は注意が必要です。mb_send_mail関数の第5引数は、内部でescapeshellcmd(内部関数名:php_escape_shell_cmd)によって引数の文字列全体がエスケープされます。 escapeshellcmd() は、以前に徳丸さんから OS コマンドインジェクションの防止には不適切であると指

  • HTTPSを使ってもCookieの改変は防げないことを実験で試してみた

    寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP(アクセスポイント)があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します(Secure属性使うと盗聴は防げますが、改変は防げません)。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe

    HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
  • 多発するWeb改ざんに備えてinotifywaitによる改ざん検知を導入した

    Webサイトの改ざん事件が多発しています。Webサイトに対する基的なセキュリティ施策を実施していればまず被害にあうことはないとは思うものの、全ての手口が公開されているわけではないので、何となく「嫌な感じ」もします。 【参考】 Web サイト改ざんに関する注意喚起(JPCERT/CC) 2013年6月の呼びかけ 「 ウェブサイトが改ざんされないように対策を! 」(IPA) @Police ウェブサイト改ざん事案の多発に係る注意喚起について(pdf) 5月から多発しているHP改ざんインシデントをまとめてみた。 - piyolog 当方のサイト(会社、個人)は、一通りのセキュリティ施策は実施しているつもりですが、絶対に改ざんされないかというと、改ざんされることは想定しておかなければならないと考えています。 当方のセキュリティ施策の例 FTPをやめ、sshのみで管理運用 sshのパスワード認証を

  • ログアウト機能の目的と実現方法

    このエントリでは、Webアプリケーションにおけるログアウト機能に関連して、その目的と実現方法について説明します。 議論の前提 このエントリでは、認証方式として、いわゆるフォーム認証を前提としています。フォーム認証は俗な言い方かもしれませんが、HTMLフォームでIDとパスワードの入力フォームを作成し、その入力値をアプリケーション側で検証する認証方式のことです。IDとパスワードの入力は最初の1回ですませたいため、通常はCookieを用いて認証状態を保持します。ログアウト機能とは、保持された認証状態を破棄して、認証していない状態に戻すことです。 Cookieを用いた認証状態保持 前述のように、認証状態の保持にはCookieを用いることが一般的ですが、Cookieに auth=1 とか、userid=tokumaru などのように、ログイン状態を「そのまま」Cookieに保持すると脆弱性になります

    ログアウト機能の目的と実現方法
  • 処理開始後の例外処理では「サニタイズ」が有効な場合もある

    このエントリでは、脆弱性対処における例外処理について、奥一穂氏(@kazuho)との会話から私が学んだことを共有いたします。セキュアプログラミングの心得として、異常が起これば直ちにプログラムを終了することが推奨される場合がありますが、必ずしもそうではないというのが結論です。 はじめに Webアプリケーションの脆弱性対策では、脆弱性が発生するのはデータを使うところであるので、データを使う際の適切なエスケープ処理などで対処するのがよいと言われます。しかし、処理内容によってはエスケープができない場合もあり、その場合の対処についてはまだ定説がないと考えます。 エスケープができない場合の例としては、以下があります。 SQLの数値リテラルを構成する際に、入力に数値以外の文字が入っていた メール送信しようとしたが、メールアドレスに改行文字が入っていた 入力されたURLにリダイレクトしようとしたところ、U

  • 1