正規表現でのメールアドレスチェックは見直すべき – ReDoS
(Last Updated On: 2018年8月13日)前のエントリでStackExchangeがReDoSで攻撃されサイトがダウンした問題を紹介しました。少しだけ掘り下げて見たところ、正規表現だけでメールアドレスをチェックしている場合、壊滅的なReDoS（十分短い文字列で指数関数的に実行時間が増加する）が可能なことが判りました。 結論を書くと、正規表現でのメールアドレスチェックは見直すべき、です。（特にRubyユーザー） 追記：影響範囲はメールアドレスチェックに限らないので、正規表現チェックは全体的に見直さないと、どこが脆弱なのか判りません。見直してチェックしたとしても、それが完全であったと保証することは困難です。ネット検索して直ぐに見つかった検索パターンは非常に脆弱であったこと、メールアドレスのマッチパターンは脆弱になりやすい繰り返しの繰り返しが含まれること、これらがあったのでタイト
セキュアプログラミング（防御的プログラミング）の歴史をざっと振り返る
(Last Updated On: 2019年2月12日)キュアプログラミング（防御的プログラミング）の歴史をざっと振り返ってみたいと思います。セキュアプログラミングは防御的プログラミングとも言われるプログラミングの原則の１つ※です。古くからある概念ですが、誤解または理解されていない概念の１つではないでしょうか？ ※ Defensive Programmingとして記載されています。 何故、一般に広く常識として理解されていないのか？その理由は防御的プログラミングの歴史にあるのかも知れません。 参考： セキュアプログラミングの７つ習慣 「出力対策だけのセキュリティ設計」が誤りである理由 セキュアプログラミングの必要性が認識された事件 コンピュータセキュリティの基礎的概念は60年代から研究されていました。その成果も踏まえ、インターネットの前身であるARPANETは1969年から稼働を開始しまし
OWASPのプロアクティブコントロールTOP10
(Last Updated On: 2018年8月4日)もう十年以上前に書いた本でプロアクティブなセキュリティ対策が重要と書いていたと思います。OWASPのプロアクティブコントロールTOP10を紹介します。 1: Parameterize Queries 2: Encode Data 3: Validate All Inputs 4: Implement Appropriate Access Controls 5: Establish Identity and Authentication Controls 6: Protect Data and Privacy 7: Implement Logging, Error Handling and Intrusion Detection 8: Leverage Security Features of Frameworks and Securi
JavaScript: / の \ によるエスケープのみによるセキュリティ対策は禁止
(Last Updated On: 2018年8月4日)RFC 4696をもう一度読みなおしてみると/もエスケープ可能文字に定義してありました。JavaScriptのエスケープシークエンスの処理の部分も間違っていたので全面的に書き直します。 RFC 4696（JSON）の定義では string = quotation-mark *char quotation-mark char = unescaped / escape ( %x22 / ; ” quotation mark U+0022 %x5C / ; \ reverse solidus U+005C %x2F / ; / solidus U+002F %x62 / ; b backspace U+0008 %x66 / ; f form feed U+000C %x6E / ; n line feed U+000A %x72 / ;
PHPのJSONのエスケープ
(Last Updated On: 2023年12月8日) 追記：最近のOWASPガイドの更新でJavaScript文字列はUnicodeエンコードで安全性を確保するよう変更されました。元々このブログでもUnicodeエスケープのまま利用するように書いています。他の言語のユーザーはUnicodeエスケープを利用しましょう。PHPもASCII領域の文字をUnicodeエスケープするようにした方が良いと思います。これは提案して実現するように努力します。 JSONはJavaScriptのオブジェクトや配列を表現する方式でRFC 4627で定義されています。メディアタイプはapplication/json、ファイル拡張子はjsonと定義されています。 PHPにJSON形式のデータに変換するjson_encode関数とjson_decode関数をサポートしています。 JSON関数がサポートされている
JavaScript文字列のエスケープを回避する方法
(Last Updated On: 2018年8月13日)JavaScriptの文字列をエスケープのエントリでJavaScript文字列をエスケープ後に直接出力するより、DOMから取得してはどうか？という提案があったのでエントリを作成しました。 まずJavaScript文字列をJavaScript文字列のエスケープで作成したescape_javascript_string関数を利用した場合の例です。 <span onmouseover="alert('<?php echo escape_javascript_string('Hello From <php>')?>');">マウスをのせてね！</span> JavaScriptでDOMの要素から取得する場合、以下のようになります。要素の取得にはjQueryを利用しています。 <script src="//ajax.googleapis.co
RailsのJavaScript文字列エスケープ
(Last Updated On: 2018年8月13日)RailsはJavaScript文字列エスケープメソッドをサポートしています。JavaScript文字列エスケープのエントリで様々な議論があったようです。弊社ではRailsアプリのソースコードも検査しているので、参考としてRailsのソースコードを確認したことを追記をしたました。Rails開発者に直して頂きたいので独立したエントリにしました。 参考： JavaScript文字列のエスケープ JavaScript文字列エスケープの解説 JavaScript文字列のエスケープを回避する方法 結論から言うとRailsのJavaScript文字列エスケープメソッドには問題があります。問題点の指摘の前にどのようなコードになっているかを見てみます。 module ActionView module Helpers module JavaScri
JavaScript文字列のエスケープ
これらの中で注目すべきは ‘ と ” と \ です。シングルクォート、ダブルクオートは文字リテラルを作成する為に利用され、\ でエスケープできることです。つまり、文字リテラルの最後に \ が現れると文字列の終端が無くなります。単独で不正なJavaScriptの挿入が可能になる訳ではありませんが、プログラムの構造が破壊される事を意味します。 PHPにはJavaScript文字列用のエスケープ関数が用意されていません。htmlspecialchars()やhtmlentities()で代用している場合も多いと思います。しかし、これらの関数ではJavaScript文字列のエスケープを十分に行う事ができません。 JavaScriptプログラムの構造が破壊される例 <?php $msg1 = 'test string\\'; $msg2 = ');alert(document.cookie); //
セッションアダプションとセッションフィクセイションとセッションハイジャックの違いとは
(Last Updated On: 2018年8月13日)徳丸さんがセッションアダプションをなくしても、セッションハイジャックが出来るのでsession_regenerate_id(true) （trueを付けると古いセッションデータは削除される）をしなければならないという記事を書かれています。 セッションアダプションがなくてもセッションフィクセイション攻撃は可能 http://tumblr.tokumaru.org/post/37676352092/session-adoption-and-session-fixation まず結論を書きます。徳丸さんが「セッションフィクセイション攻撃は可能」と言われているのは間違いです。正しくは「セッションハイジャックが可能」です。 この議論は別々の異なる脆弱性を一緒にした議論で正しい議論とは言えません。セッションアダプション、セッションフィクセイショ
セッションアダプション脆弱性がないセッション管理が必要な理由
(Last Updated On: 2018年8月18日)徳丸さんから「ブログ読みました。サンプルも動かしました。問題は分かるのですが、セッションアダプションがないPHPだと、何が改善されるのかが分かりません。教えて下さい 」とあったのでツイッターで返信するには少し長いのでこちらに書きます。まだ直していない脆弱性を詳しく解説するのはあまりよくないのですが、今なら影響を受けるアプリはほぼないと思うので構わないでしょう。 まず前提として、Webサーバと同様にJavascriptからもクッキーが設定できます。Javascriptインジェクションに脆弱なコードがサイトに1つでもあると、サイト上のセッションアダプション脆弱性をもつアプリへの攻撃が可能になります。この攻撃を緩和する対策もありますが、それはそれ、これはこれなので省略します。 セッションアダプションに脆弱なセッション管理機構で困る代表的な
PHPのセッションアダプション脆弱性は修正して当然の脆弱性
(Last Updated On: 2018年8月18日)PHPのセッションアダプション脆弱性がどのように影響するのか、広く誤解されているようです。セキュリティ専門家でも正しく理解していないので、一部のPHP開発者が正しく理解しなかったのは仕方ないのかも知れません。 Webセキュリティの第一人者の一人である徳丸氏は「PHPのセッションアダプション脆弱性は脅威ではない」と書いていますが、いろいろ間違いです。私は2005年頃から現在まで様々な機会に問題であると何度も繰り返し説明しており、しばらくすれば間違いに自分で気付くのでは？と思っていたので特に反論していませんでした。しかし、まだ気づかれていないようなので、幾つかある攻撃パターンのうち解りやすい例を1つだけ紹介しておきます。 以下の簡単なPHPスクリプトを利用します。興味がある方は実験してみてください。結果はブラウザに影響されます。私はLi
UPnPルータ+Flash=深刻なセキュリティ問題
(Last Updated On: 2008年1月18日)GNUCITIZENは重要なセキュリティ問題を次々に公開しているのでセキュリティに興味がある方はチェックしているのでご存知とは思いますが、 Hacking The Interwebs http://www.gnucitizen.org/blog/hacking-the-interwebs に非常には深刻なセキュリティ問題が解説してあります。具体的な攻撃方法などはGNUCITIZENを参照してください。日本でもいろいろ書かれるかな、と思っていたのですが予想より少ないのでブログに書くことにします。ここでは重要な部分だけ要約して書きます。 攻撃 Flashを利用したUPnPルータの攻撃シナリオは以下になります。 UPnPが有効なルータがある 悪意のあるFlashをWebブラウザで参照する UPnPルータの設定を変更するSOAPリクエストを
glibcの脆弱性で大量のメモリが割り当てられる – セキュリティ専門家は基盤ソフトウェアに期待させてはならない
(Last Updated On: 2016年2月18日)最近この種のエントリがありませんでしたが、個人的に面白いとセキュリティ系の話題はできるだけ書いていきたいと思っています。 glibcのstrfmon関数の実装に脆弱性があり、簡単なスクリプトで大量のメモリが割り当てられる脆弱性があるようです。影響するglibcは2.10.1以下なので影響範囲は非常に大きいです。 最初はBSDのlibcで脆弱性が発見され、glibcでも影響があることは脆弱性の発見者には分かっていたようです。詳細はアドバイザリに記載されています。 http://packetstormsecurity.org/0909-advisories/glibc-format.txt 参考：セキュアプログラミングの７つ習慣 詳しい説明はアドバイザリを読んで頂くとして、当初はBSD系OSのglibcで問題が発見されたそうです。Net
何故かあたり前にならない文字エンコーディングバリデーション
(Last Updated On: 2018年8月8日)私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けに
RFC原理主義者ではないですが… 迷惑な迷惑メール対策に反対！
(Last Updated On: 2018年8月14日)RFCの位置づけも、絶対的に崇め奉る技術者がいたり、そもそも読んでない(あることを知らない)なんて技術者がいたりとまちまちだが、相互接続に影響する部分は準拠しておいてほしいと思う。携帯各社のメールアドレス仕様でユーザより「PCのメールからメール送受信ができない！」とクレームを受けたことのあるタレコミ人としては、ユーザに対しきっちり警告も行わないままで、相互接続に問題がある形式を採用するのは迷惑なだけ、と思うのだが、みなさんはいかが？そもそも、メールの相互接続は保障していない！って？” DoCoMoもAUも何を考えているのだろう? 想像力が不足しているように思えます。不正なメールアドレスを使って他のドメイン/サーバからの迷惑メールを防ぎたいなら、自分のドメインからのみ受信できる状態をデフォルトにすれば良いだけでは? このような迷惑な仕
JavaScript無しでフォームをコントロール
(Last Updated On: 2008年9月3日)言われてみれば、そう言えばそんな機能があったね、と思うような機能はよくあります。 JavaScript無しでフォームを制御する方法はHTML4が策定されている時に追加された機能です。 http://www.w3.org/TR/html401/interact/forms.html#h-17.2.1 以下のLABELタグのサンプルは http://www.0x000000.com/?i=635 より拝借しています。 <label for="action"> <body> Etymology of "Foo" 1 April 2001 When used in connection with `bar' it is generally traced to the WW II era Army slang acronym FUBAR (`F
スクリプトインジェクション対策の特集 – gihyo.jp
(Last Updated On: 2008年4月10日)技術評論社でブログっぽい記事を書かせて頂いています。4月3日からスクリプトインジェクション対策で注意すべき項目が掲載されます。一般的なスクリプトインジェクション対策「バリデーションしエスケープする」ではなく、万が一スクリプトインジェクションに脆弱であった場合でも被害を最小限に留める対策、見落とされがちな対策を中心に解説しています。 # 一度に書いた記事なのでどう分割されるか私も分かりません。 # 物によっては2回に分割するかもしれないので20弱くらい # だと思います。 http://gihyo.jp/dev/serial/01/php-security から最新の一覧を参照できます。 ご意見やご希望などございましたらこのブログから送って頂いても、メールで送って頂いても歓迎致します。ご興味がある方はご覧ください。 現在（4/9）時点
LAMPのPをPHPからPerl/Python/Rubyに替えるだけではセキュリティは向上しない証拠
(Last Updated On: 2008年4月3日)誤解を招く記事 – LAMPセキュリティを強化する4つの方法で紹介した記事ように、最近「言語を替えるとセキュリティが向上する」といった間違った認識が広まりつつあるように思えます。 結論からいうと、セキュリティに関連する機能が同等な言語であれば「言語を替えるとセキュリティが向上するいう考え」は妄想です。言語を替えても、正しいセキュリティ知識を持ち合わせた開発者が開発しないと、危ないアプリケーションが簡単に作れます。 ちょうど良い証拠となるPloneのCVEエントリが公開されています。PloneはPythonで記述されたCMSです。私も利用したことがありますが、なかなかよくできているCMSです。出来立てのCMSではなく何年も前から実用されています。フレームワークとしてPythonのWebシステムよく利用されているZopeを利用しています。
OpenIDのライブラリにはCSRFに脆弱な物が多い
(Last Updated On: 2018年8月8日)GNUCitizenによると CSRF – It comes very handy. It seams that no matter how much you talk about it, very few pay attention on the problem. And it is not a problem that you can afford to have. And among the XSS issues, which most OpenID libraries have, CSRF (Cross-site Request Forgery) seams to be the most pervasive form of attack. http://www.gnucitizen.org/blog/hijacking-ope
責任あるDM送信者はどのようにメールを送信すべきか
(Last Updated On: 2018年8月14日)少し前のエントリ、宛先を個人のメールアドレスに設定しているメルマガは迷惑メールに！の続きです。DM業者はどのようにメールを送信すべきか考えました。 これから書く考えはDM送信側ではなく、DM受信側の視点から考えています。 メールの種類 まず簡単にメールを分類します。受信者から見ると 自分のアクションが必要な個人宛メール – 問い合わせ、確認等。 経緯などを知らせるだけアクションが不必要なメール – 通知、記録等。 情報系のメール – メルマガ、ニュース等。 スパムメール – 勝手に送ってる迷惑メール。 に分類できると思います。 受信する側から見るとそれぞれ適切であると思われる送付先アドレス設定は次の通りでしょう。 自分のアクションが必要な個人宛メール – To: 個人メールアドレス 経緯などを知らせるだけでアクションが不必要なメール
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
