Top他の言語利用者の芽を来にしているのか、PHPをメインに使ってるのにPHPをバカにしている人たちがいますよね。元はそんなこと意識してなかったんです。)という男がいますが、たまたま彼と昼食が一緒になる機会があって、その席で彼からぼそっと言われたんです。『徳丸さん、PHP好きでしょ』...あぁ、それまでPHPが好きかどうかなんて、考えたこともなかったのです。考えているうちに、あっ、自分はPHPが好きなのかも...と思い始めました。モリヨシが私に呪いをかけたんだと思いますね(笑い)同業者からは、徳丸はなぜあんなにPHPを追いかけ回すんだろと思われていると思います。「徳丸さんはPHPを安全に使う方法を示した罪深い方」と書かれたこともあります(揶揄なのか、批判なのか、まさか褒めているのか、なんなのかよくわかりませんがw)。PHP界隈の一人から、面と向かって「徳丸さん、そんなにPHPをいじめないでくださいよ」と言われたことがある私ですが、今ではPHPカンファレンスでは毎年しゃべっていますし、毎年多くの方が聞きに来てくださいます。「PHPをいじめている」と思われていた私をPHPerの方々は受け入れてくれていると感じています。PHPには多くの欠点があります。そこに目を向ければ、PHPをけなしたくなる気持ちが出るだろうことはよく理解できます。それにも関わらず、多くの方々に使われ、そして大規模な著名Webアプリケーションの多くがPHPで記述されています。分かりませんが、そういうPHPに惹かれる自分がいます。胸を張って「好き」というようなものでもないような気がします。恥ずかしいけど、なぜだかよくわからないけど、PHPは好きです。ご期待に沿う答えではないかもしれませんが、上記が正直な気持ちです。question今日、小学生の女の子に「ネットの情報って、そのまま信じてもいいんかなぁ?」と相談されました。とっさに、今はどれがいい情報かわからないだろうから、見ておくだけにして、わかるようになってから活用すればいいよと答えましたが、何かもっといい答え方があったのではと考えております。子どもにネットの使い方を聞かれた場合は、どのような方向に持っていくのが良いと思われますか?また、注意しておいたほうがいいことなどありましたら、お聞かせ願いたいです。agoこれは本当に難しい問題で、こうすればよいという解は持ちあわせません。お子さんの性格によっても、接し方が変わるかもしれません。私は息子には時々わざと明らかに嘘と分かる話を(ニヤニヤしながら)して、息子が「(疑い深そうに)本当?」と聞いたら、「うそだよーん」と答えています。「ネットの情報にも今みたいなのが多いから」と言っています。その効果か分かりませんが、時々「ネットにこんな馬鹿な書き込みがあった」と嬉しそうに話してくれることがあります。ネットの書き込みが、特に「偉い人」が書いているわけではなく、普通の人たちが書いていて、中にはウケ狙いや、誤解・偏見により書いてあるものもある...ということがわかればよいのではないでしょうか。その先の真贋の見分け方というのは非常に難しい話ですが、根拠が明確か、論理的に筋が通っているか、などの話ですから、それなりにトレーニングが必要です。いう意味では、小学生相手ということであれば、今の接し方でも特に問題はないかと思います。落ち込んでいる自分を静かに受け入れます。落ち込んでいる自分を責めたり、あせったりするのは得策でないと思います。して一晩寝ればたいてい立ち直ります。questionhttp://notice.nicovideo.jp/ni046768.htmlで自社からの流出ではないと断定できる理由はなんですか?こういうのいろんなサービスでみてきましたが、流出を隠蔽して他人のせいにしている気がしてなりません。agoサイト運営者の立場で考えると、不正ログインに悪用されたIDとパスワードが、自社から流失したものか、他社に由来するものかの判定は比較的容易です。自社から流失したものであれば、ほぼ100%の確率で不正ログインに成功するはずです。パスワードが流失した経路などにもよりますが、サーバーに不正侵入してパスワード情報を得た経路の場合、それとは別に不正ログインをする動機がない場合も多いと考えられます。個人情報の取得などは、不正侵入の時点で終わっているはずだからです。ポイントの不正利用等の場合、サーバー側のロジックを解析する手間よりも、不正ログインによりポイントを悪用した方が楽という場合もあるでしょう。この場合、パスワードがハッシュ値などで保護されているかどうかなどの条件も考慮する必要がありますが、サイト運営者であれば、ある程度判断は可能です。ログなどから悪用の状況を判断できる場合もあるでしょう。IDやパスワードの情報が他社由来の場合、すなわちパスワードリスト攻撃の場合は、不正ログインに成功する確率はかなり下がります(例えば0.1%)。このため、前述のように、不正ログインに悪用されたアカウント情報が自社由来のものか、他社由来のものかは、サイト運営者の立場であれば、ログなどの解析から比較的容易に判断できるはずです。サイト運営者が嘘をついている可能性や、よく調べていないにも関わらず「他人のせいにしている」可能性も否定はできません。このあたり、結局は利用者とサイト運営者の信頼関係の問題ですので、あなたが「どうも××社は信頼できない」と思うのであれば、そのサイトを使わないか、万一不正アクセスされても被害を受容できる範囲での利用に留めることになるでしょう。それを判断するのは、利用者である貴方自身です。agoタキシード着て、女性の前にひざまずき、大きな花束を差し出しながら、「大好きです。一生大切にしますので結婚してください」と言いなさい。questionUTF-8とShift_JISそれぞれのphp.iniの推奨設定がわかりません。いったものを公開しているところもみかけません(見かけたことありますが古いし設定がおかしかったりする)。徳丸先生がおすすめするphp.iniを公開してほしいです。ago特におすすめのphp.iniというものはありません。php.iniの設定ということになるわけですが、php.ini-productionがそれであるべきで、もしそうでないならば、php.ini-productionの方を変更してもらわなければなりません。そこまでphp.ini-productionは悪くないと思います。従って、php.ini-productionを出発点として、使っていない機能を削るくらいでよいのではないでしょうか。Shift_JISを使う場合の設定は難しいと思います。Shift_JISが「どこの」文字エンコーディングを指すかが不明ですが、おそらくHTTPメッセージの文字エンコーディングと仮定します。すると、mbstring.internal_encodingには以下の3種類の選択肢があります。・Shift_JIS・EUC-JP・UTF-8それぞれ一長一短がありますが、Shift_JISをmbstring.internal_encodingに設定するのは危なっかしいので避けた方が良いでしょう。EUC-JPを設定するのは無難な方法としてお勧めです。これはShift_JISと文字集合が共通するからです。データベースはUTF-8で文字が格納されている場合は、アプリケーションとデータベースで文字集合が違うことになります。ここで、U+00A5(円記号)がバックスラッシュに化ける可能性があり、潜在的な脆弱性の可能性があります。mbstring.internal_encodingをUTF-8にして、HTTPメッセージをShift_JISにすると、XSSの可能性があります。これについては、以下のスライドをご覧下さい。http://www.slideshare.net/ockeghem/ss-5620584ということで、徳丸のお勧めは「Shift_JISを避ける」ということです。ago本物のオノを投げつけたことはありませんし、投げられたこともありません。ago今まで開発者としてお仕事で使った言語はFortran、C、C++、VisualBasic、Java等です。そうそう、Smalltalkを一つのプロジェクトで使いましたね。それ以外に趣味でPascalコンパイラをPascal言語で書いたことがあります。ライブラリ用にちょびっとアセンプリ言語も使いました。セキュリテイのお仕事では、Perl、PHP、Ruby、Pythonを少しずつ使っています。その方のニーズや興味によって変わると思います。始まるファイルが外部から読めてしまいます。書かれていませんでした。このことに関連する情報や事例をご存知でしょうか。ago積極的にバレてもいいと言うことではないのですが、ハッシュ値が漏洩するような状況ではソルトだけ秘密にしておくことは難しいという判断によるものです。(2)暗号鍵をその方法で保存してパスワードの暗号化する方が安全です。(HSM)という形で実現しています。HSMは高価なことから、廉価で安全性も高い方法として、(最悪バレるかもしれない)ハッシュ値とソルト、加えてストレッチングという方法がよく使われます。ソルトをDBとプログラムハードコーディングに分けて保存すると、片方だけバレても平文パスワードの復元は難しいという状況は作れます。拙著で紹介している方法です。agoご質問に対する答えは、YESでありNOです。外部入力が、HTTPリクエスト、メール、ファイル、DB等を含めてまったく存在しないのであれば、XSS攻撃の経路がないので、XSS攻撃はできません。そのため、XSS攻撃の対策も不要ということになります。XSS対策として通常実施するHTMLエスケープ、属性値をダブルクォートで囲む、HTTPレスポンスヘッダに文字エンコーディングを指定する...などが不要になるわけではありません。これらは「攻撃を防ぐ」ために実施するわけではありません。これらは、開発者が意図した通りの表示にするために必要な処理だからです。このため、攻撃の経路があろうが、なかろうが、XSS対策と同等のことは元々Webシステムではやらなければならないこと、ということです。ご質問の答えがNOでもあるというのはそういうことです。型変換という立場からは通すべきだということと、仮にエスケープすべき文字が来ないことがわかっていても、それを一々確認することが煩わしく、バグや脆弱性の元です。一律に通すと決めたほうがシンプルで、バグや脆弱性も混入しにくくなります。question徳丸先生の結城浩さんについての印象を教えてください。ago1990年代はじめに、Cマガジン誌に連載を持っていたのですが、その頃にCマガジンにて結城さんの記事を目にしました。分かりやすい記事にびっくりして、すごい人が出てきたなと思ったことを今でも覚えていて、その印象は今も変わりません。question徳丸先生は、セミの中で、どのセミが好きですか?アブラゼミ、クマゼミ、ニイニイゼミ、ヒグラシ、ツクツクボウシ・・・。question徳丸さんのファン向けのオフ会を開いてください。questionセキュリティエンジニアの端くれです。子どもと妻がいるのですが、仕事が忙しく、なかなか家族のための時間を作ることができません。ago朝ご飯と夕ご飯をできるだけ家族全員でとるようにしています。そのため、起床のタイミングを合わせることや、夜間の外出や飲み会をできるだけ控えることを心がけています。