ChatWorkのコピーサイトを調べてみました
(Last Updated On: 2018年8月4日)ChatWorkをまるごとコピーしたコピーサイトが中国に登場で紹介したように、まるごとコピーしたサイトが現れました。こういうコピーサイトが現れると、内部のソースコードが漏洩したのでは？と不安になる方も居ると思います。調べてみたので参考にして下さい。 ChatWorkの画面 コピーサイトのWokingIMの画面 まず結論から書きます。サーバー側のソースコードは漏洩しておらず、HTML、CSS、イメージなど外部から取得した物、通信などからリバースエンジニアリングした物と思われます。 本家ChatWorkとコピーChatWorkとの違いを、アカウントを作成し外見から分かる範囲で調べてみました。 まずサーバーのIPアドレスとドメイン保持者ですが間違いなく中国です。 プロバイダ：China Telecom ドメイン保持者：HICHINA ZHI
セッションのクッキーを設定する場合のベストプラクティス
(Last Updated On: 2018年8月18日)HTTPセッションは通常クッキーを利用して行います。クッキーを利用したセッションの場合、お薦めする設定は以下の通りです。 ドメイン名は指定しない パスはルート(/)を指定する セッション管理用のクッキーはセッションクッキー（有効期間０）にする httponly属性を付ける 可能な場合は必ずsecure属性をつける 複数アプリケーションを利用する場合はsession.nameまたはsession_name()でセッションクッキー名で指定する （アプリケーションの固有名デフォルトで設定し、設定項目として変更できるようにする） 3まではPHPデフォルト設定です。4から6までは自分で設定しなければなりません。PHPの場合、すべてphp.iniで指定できます。session_set_cookie_params()でセッション開始前に指定すれば
セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?
(Last Updated On: 2018年8月13日)一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。 その間違いとは 意図の取り違い – 誤読 言語の仕様と実装の理解不足 HTTPやPHP仕様の理解不足 セキュリティ対策をすべき場所の理解不足 です。(※0) 徳丸さんは非常勤とは言え、国の出先機関の研究員であるし、その出先機関は職務放棄とも言える文書（「例えば、PHPを使用しない」と勧める文書）を公開している(いた?)のでしっかり反論しておく必用がありますね。IPAのあの文書は職務放棄と言える文書だと思っています。これについても後で意見を述べます。 意図の取り違い – 誤読 最初の間違いは私のブログのエントリ「何故かあたり前にならない文字エンコーディングバリデーション」に対する理解です。特にPHPユーザに
何故かあたり前にならない文字エンコーディングバリデーション
(Last Updated On: 2018年8月8日)私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けに
PHP開発者とユーザが知っておくべきシェルコマンドエスケープの内部処理
(Last Updated On: 2018年8月13日)これから紹介する脆弱性はPHP 5.2.6で修正されています。修正された、とは言え注意が必要です。 PHPは古くからシェルコマンドとシェル引数をエスケープ処理する為に、escapeshellcmd関数とescapeshellarg関数を提供しています。 この関数はマルチバイト文字にも対応しているのですが、ビルドや環境によっては対応できていないときがあります。 escapeshellcmd/escapeshellarg関数ではC99で定義されてるmblen関数を利用しています。一般的なUNIX系システムではmblen関数は利用可能でると考えられるので、問題となる事は少ないと思いますが、PHPではphp_mblenマクロが以下のように定義されています。 #ifndef HAVE_MBLEN # define php_mblen(ptr,
ホワイトリストとブラックリスト – Proactiveセキュリティ対策 vs. Reactiveセキュリティ対策
ホワイトリストとブラックリスト – Proactiveセキュリティ対策 vs. Reactiveセキュリティ対策 (Last Updated On: 2018年4月5日)「プログラミングはホワイトリスティングが基本」にブラックリストもホワイトリストもどちらも同じ事を言っていて違いが分からない、とコメントを頂きました。 追記：ブラックリストとホワイトリストの違いが解らない方は、恐らくホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることを理解していないのだと思われます。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。 http://pfrb.blog114.fc2.com/blog-entry-5.html ホワイトリストとブラックリストは単純な場合は分かりやすいコンセプトですが、ちょっと複雑になると分かりやすいようで境界が分かり辛いコンセプトです。
プログラミングではホワイトリスティングが基本
(Last Updated On: 2018年8月8日)「ホワイトリスト方式の優位は神話」と題するエントリに私のブログホワイトリストはどう作る? が引用されている事を教えていただきました。 ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。 誤解されないように書こうとすると、どうしても長文になります。暇な方だけお付き合いください。 参考： セキュリティを論理的に構築する方法 （こちらは科学的なセキュリティの基本構造の作り方の話です。ぜひどうぞ） 意地悪なブログエントリと書籍の文章 まず、ちょっと意地悪なブログエントリと書籍の文章を同列に比較されても困ります。言い訳ですが著書の”Webアプリケーションセキュリティ対策入門”では金床さんと同様の表現になっています。90年代にホワイトリ
スクリプトインジェクション対策の特集 – gihyo.jp
(Last Updated On: 2008年4月10日)技術評論社でブログっぽい記事を書かせて頂いています。4月3日からスクリプトインジェクション対策で注意すべき項目が掲載されます。一般的なスクリプトインジェクション対策「バリデーションしエスケープする」ではなく、万が一スクリプトインジェクションに脆弱であった場合でも被害を最小限に留める対策、見落とされがちな対策を中心に解説しています。 # 一度に書いた記事なのでどう分割されるか私も分かりません。 # 物によっては2回に分割するかもしれないので20弱くらい # だと思います。 http://gihyo.jp/dev/serial/01/php-security から最新の一覧を参照できます。 ご意見やご希望などございましたらこのブログから送って頂いても、メールで送って頂いても歓迎致します。ご興味がある方はご覧ください。 現在（4/9）時点
PostgreSQL 8.3の全文検索機能（TSearch2）を日本語で利用する
(Last Updated On: 2018年8月13日)PostgreSQL 8.3.0から、ユーザから提供されている追加機能（contrib）として利用できた全文検索機能（TSearch2）が本体に取り込まれました。 本体に取り込まれたため、PostgreSQL 8.3.0以降ではソースから構築する場合に ./configure make make install と実行するだけで全文検索機能が利用できるようになりました。 TSearch2は単語単位で全文検索できます。しかし、日本語のように単語に区切りがない場合、単語に分解（形態素解析）してからインデックス化する必要があります。 # N-gramは使えません。 残念ながら日本語をそのまま扱える機能はPostgreSQL 8.3では実装されていません.しかし、TSearch2(textsearch)を日本語で利用するための追加機能がpg
APCにStack Overflow脆弱性
(Last Updated On: 2018年8月13日)件名の通り、APCのStack Overflow脆弱性が公開されています。 http://sla.ckers.org/forum/read.php?3,21615,21615#msg-21615 このポストに書いてある通り、PHP4ではインクルード攻撃に脆弱なアプリならallow_url_fopenをoffにしていても効果はありません。PHP4+APCを使っている方は今すぐAPCをCVSバージョンにバージョンアップするか、APCをロードしない方が良いでしょう。 MomongaLinux等、パッケージをビルドする際にstack smashing attackから防御するstack protectorオプションを使ってビルドしているバイナリであればリンク先の攻撃方法では攻撃できません。しかし、インクルード攻撃に脆弱であれば、他の脆弱性を
誤解を招く記事 – LAMPセキュリティを強化する4つの方法
(Last Updated On: 2014年12月5日)LAMPセキュリティを強化する4つの方法 http://enterprisezine.jp/article/detail/311 書いてある情報は有用な事も記載されていますが、偏狭な視点からの記述により誤解を招く記事になっていると考えられます。著者はセキュリティの専門家ではないようなので仕方ないかも知れませんが、間違った認識は有害です。 # 原本は読んでいません。もしかすると日本語訳にも問題があるのかも知れません。 実行できる最も重要な対策は、PHPを使わないことです。腐った果物を導入する前に、以下に目を通してください。 後にPerl/Ruby/Pythonの方がかなり安全である旨の記述があります。メモリ管理が必要ない同じスクリプティング言語のレベルで「Perl/Ruby/Pythonを使えばセキュアなアプリケーションができる」と考
LAMPのPをPHPからPerl/Python/Rubyに替えるだけではセキュリティは向上しない証拠
(Last Updated On: 2008年4月3日)誤解を招く記事 – LAMPセキュリティを強化する4つの方法で紹介した記事ように、最近「言語を替えるとセキュリティが向上する」といった間違った認識が広まりつつあるように思えます。 結論からいうと、セキュリティに関連する機能が同等な言語であれば「言語を替えるとセキュリティが向上するいう考え」は妄想です。言語を替えても、正しいセキュリティ知識を持ち合わせた開発者が開発しないと、危ないアプリケーションが簡単に作れます。 ちょうど良い証拠となるPloneのCVEエントリが公開されています。PloneはPythonで記述されたCMSです。私も利用したことがありますが、なかなかよくできているCMSです。出来立てのCMSではなく何年も前から実用されています。フレームワークとしてPythonのWebシステムよく利用されているZopeを利用しています。
企業ユーザはPHP4からPHP5への移行は慎重にすべき
(Last Updated On: 2018年8月13日)2008年1月3日のPHP4.4.8のリリースを持ってPHP4サポートが終了しました。海外では「PHP5へ移行しよう」キャンペーンも始まりました。 私は従来から「PHP5へ早く移行すべきです」と繰り返し勧めて来ました。現在でも全てのオープンソースアプリケーションの開発者は、今すぐPHP5に移行すべき、と考えています。 しかし、新規開発を除き、企業ユーザには今すぐPHP5へ移行すべきだ、と一概にアドバイスできません。3つのお薦めしない理由があります。 PHP4からPHP5へのマイグレーションはそれほど簡単ではない PHP5に移行するとマイナーバージョンアップに追随しないとならない PHP5.3のリリースが準備されている PHP4からPHP5へのマイグレーションはそれほど簡単ではない PHP4からPHP5への移行でチェックしなければなら
SquirrelMailのコードが改竄される
(Last Updated On: 2007年12月16日)追記: 攻撃が目的の改竄だった模様です。 http://blog.ohgaki.net/index.php/yohgaki/2007/12/16/squirrelmail-1 —- http://squirrelmail.org/index.php によると、12/8にSquirrelMail 1.4.12のコードが改竄されていたようです。 While we believe the changes made should have little impact, we strongly recommend everybody that has downloaded the 1.4.12 package after the 8th December, to redownload the package. The code modifi
SET NAMESは禁止
(Last Updated On: 2018年8月13日)MySQLには文字エンコーディングを変更する「SET NAMES」SQL文が用意されています。（PostgreSQLも同様のSQL文、SET CLIENT_ENCODINGがあります）この機能はSQLコンソールからは使ってよい機能ですが、アプリケーションからは使ってはならない機能です。SQLインジェクションに脆弱になる場合があります。 Ruby on Railsの本を読んでいて、ActiveRecordを説明している部分にMySQLの文字エンコーディングを変更する場合の例としてSET NAMESが利用されていました。アプリケーションからはSET NAMESは使ってはならない事を周知させるのは結構時間が必要かなと思いました。 PHPも5.2の途中からMySQLモジュールにlibmysqlの文字エンコーディング設定APIのラッパー関数が
PHP4からPHP5への移行について
(Last Updated On: 2018年8月13日)PHP4のサポート終了がアナウンスされことに伴い、技術評論社の方からPHP4からPHP5への移行の記事を書く事になりました。毎週新しい記事が公開されます。下記のURLが最初の記事で8/2（予定）から順次続きが公開されます。 http://gihyo.jp/dev/feature/01/php-migration/0001?page=1 記事を書いてみて思ったのですが、自分にとってはPHP4とPHP5両方で動作するコードを書くのはそう難しくないのですが時々PHPでコードを書いている方、PHPの開発状態を把握していない方には結構難しいのではないかと思いました。今回の記事は「移行」にのみ焦点をあててPHP5の新機能はほとんど紹介しませんでしたがかなりボリュームになってしまいました。それでも十分とは言えないです。PHP5への移行をお考えのか
画像ファイルに PHP コードを埋め込む攻撃は既知の問題
(Last Updated On: 2015年9月10日)国内外のメディアで「画像ファイルに攻撃用のPHPコードが含まれていた」と比較的大きく取り上げられています。しかし、この攻撃手法は古くから知られていた方法です。条件は多少厳しくなりますがPerl, Ruby, Pythonでも同様の攻撃は考えられます。PHPの場合は言語仕様的に他の言語に比べ攻撃が容易です。 典型的な攻撃のシナリオは次の通りです。 追記：Tokenizerを使った例に修正しました。 アバダなどの画像ファイルをアップロードできるサイトを探す ローカルファイルインクルードバグを探す 画像ファイルにサイトが利用している言語のコードを埋め込む 攻撃コードを含んだファイルを画像ファイルとしてアップロードする ローカルファイルインクルードバグを利用して攻撃コードを実行する PHPの場合、リモートインクルードバグを攻撃するための攻撃
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
