Ask @tokumaru:

他の言語利用者の芽を来にしているのか、PHPをメインに使ってるのにPHPをバカにしている人たちがいますよね。Mなんでしょうか?徳丸さんは胸を張ってPHPが好きと言えますか?

徳丸はPHPが好きか? ですが、元はそんなこと意識してなかったんです。日本のPHPコミッターの一人にコイズミモリヨシ( @moriyoshit )という男がいますが、たまたま彼と昼食が一緒になる機会があって、その席で彼からぼそっと言われたんです。『徳丸さん、PHP好きでしょ』…あぁ、それまでPHPが好きかどうかなんて、考えたこともなかったのです。自分はPHPが好きか? 考えているうちに、あっ、自分はPHPが好きなのかも…と思い始めました。おそらくモリヨシが私に呪いをかけたんだと思いますね(笑い)
同業者からは、徳丸はなぜあんなにPHPを追いかけ回すんだろと思われていると思います。「徳丸さんはPHPを安全に使う方法を示した罪深い方」と書かれたこともあります(揶揄なのか、批判なのか、まさか褒めているのか、なんなのかよくわかりませんがw)。
かつては、PHP界隈の一人から、面と向かって「徳丸さん、そんなにPHPをいじめないでくださいよ」と言われたことがある私ですが、今ではPHPカンファレンスでは毎年しゃべっていますし、毎年多くの方が聞きに来てくださいます。かつては「PHPをいじめている」と思われていた私をPHPerの方々は受け入れてくれていると感じています。
PHPには多くの欠点があります。そこに目を向ければ、PHPをけなしたくなる気持ちが出るだろうことはよく理解できます。それにも関わらず、多くの方々に使われ、そして大規模な著名Webアプリケーションの多くがPHPで記述されています。なぜだかよく分かりませんが、そういうPHPに惹かれる自分がいます。
ご質問の『徳丸さんは胸を張ってPHPが好きと言えますか?』については…どうでしょうか? 胸を張って「好き」というようなものでもないような気がします。ちょっと恥ずかしいけど、なぜだかよくわからないけど、PHPは好きです。
ご期待に沿う答えではないかもしれませんが、上記が正直な気持ちです。

View more

今日、小学生の女の子に「ネットの情報って、そのまま信じてもいいんかなぁ?」と相談されました。とっさに、今はどれがいい情報かわからないだろうから、見ておくだけにして、わかるようになってから活用すればいいよと答えましたが、何かもっといい答え方があったのではと考えております。子どもにネットの使い方を聞かれた場合は、どのような方向に持っていくのが良いと思われますか?また、注意しておいたほうがいいことなどありましたら、お聞かせ願いたいです。

これは本当に難しい問題で、こうすればよいという解は持ちあわせません。お子さんの性格によっても、接し方が変わるかもしれません。私は息子には時々わざと明らかに嘘と分かる話を(ニヤニヤしながら)して、息子が「(疑い深そうに)本当?」と聞いたら、「うそだよーん」と答えています。そして、「ネットの情報にも今みたいなのが多いから」と言っています。その効果か分かりませんが、時々「ネットにこんな馬鹿な書き込みがあった」と嬉しそうに話してくれることがあります。まずは、ネットの書き込みが、特に「偉い人」が書いているわけではなく、普通の人たちが書いていて、中にはウケ狙いや、誤解・偏見により書いてあるものもある…ということがわかればよいのではないでしょうか。その先の真贋の見分け方というのは非常に難しい話ですが、根拠が明確か、論理的に筋が通っているか、などの話ですから、それなりにトレーニングが必要です。そういう意味では、小学生相手ということであれば、今の接し方でも特に問題はないかと思います。

View more

気分が落ち込んだ時はどうしてますか?

何もしません。落ち込んでいる自分を静かに受け入れます。落ち込んでいる自分を責めたり、あせったりするのは得策でないと思います。そうして一晩寝ればたいてい立ち直ります。

View more

http://notice.nicovideo.jp/ni046768.htmlで自社からの流出ではないと断定できる理由はなんですか?こういうのいろんなサービスでみてきましたが、流出を隠蔽して他人のせいにしている気がしてなりません。

サイト運営者の立場で考えると、不正ログインに悪用されたIDとパスワードが、自社から流失したものか、他社に由来するものかの判定は比較的容易です。自社から流失したものであれば、ほぼ100%の確率で不正ログインに成功するはずです。また、パスワードが流失した経路などにもよりますが、サーバーに不正侵入してパスワード情報を得た経路の場合、それとは別に不正ログインをする動機がない場合も多いと考えられます。個人情報の取得などは、不正侵入の時点で終わっているはずだからです。一方、ポイントの不正利用等の場合、サーバー側のロジックを解析する手間よりも、不正ログインによりポイントを悪用した方が楽という場合もあるでしょう。この場合、パスワードがハッシュ値などで保護されているかどうかなどの条件も考慮する必要がありますが、サイト運営者であれば、ある程度判断は可能です。また、ログなどから悪用の状況を判断できる場合もあるでしょう。
一方、IDやパスワードの情報が他社由来の場合、すなわちパスワードリスト攻撃の場合は、不正ログインに成功する確率はかなり下がります(例えば0.1%)。このため、前述のように、不正ログインに悪用されたアカウント情報が自社由来のものか、他社由来のものかは、サイト運営者の立場であれば、ログなどの解析から比較的容易に判断できるはずです。
しかし、サイト運営者が嘘をついている可能性や、よく調べていないにも関わらず「他人のせいにしている」可能性も否定はできません。このあたり、結局は利用者とサイト運営者の信頼関係の問題ですので、あなたが「どうも××社は信頼できない」と思うのであれば、そのサイトを使わないか、万一不正アクセスされても被害を受容できる範囲での利用に留めることになるでしょう。それを判断するのは、利用者である貴方自身です。

View more

人生の先輩!好きな女性にどうやってアピールしたらいいのか教えてください

タキシード着て、女性の前にひざまずき、大きな花束を差し出しながら、「大好きです。一生大切にしますので結婚してください」と言いなさい。そして、その結果を教えてください

View more

UTF-8とShift_JISそれぞれのphp.iniの推奨設定がわかりません。こういったものを公開しているところもみかけません(見かけたことありますが古いし設定がおかしかったりする)。徳丸先生がおすすめするphp.iniを公開してほしいです。

特におすすめのphp.iniというものはありません。
漠然と「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を避ける」ということです。どうしてもShift_JISを使わなければならない場合は…

View more

取得したプログラミング言語を教えてください

今まで開発者としてお仕事で使った言語はFortran、C、C++、VisualBasic、Java等です。そうそう、Smalltalkを一つのプロジェクトで使いましたね。
それ以外に趣味でPascalコンパイラをPascal言語で書いたことがあります。ライブラリ用にちょびっとアセンプリ言語も使いました。
セキュリテイのお仕事では、Perl、PHP、Ruby、Pythonを少しずつ使っています。

View more

Apache で Require all denied と書かれていて、ドキュメントルート以下のディレクトリでBASIC認証をするため .htaccess を設置して、更により深い階層で認証不要にするため Satisfy Any と書いた .htaccess を設置すると、そこ以下では .ht から始まるファイルが外部から読めてしまいます。冒頭の記述に Satisfy All を書けばよさそうですが apache2.conf には Satisfy が書かれていませんでした。このことに関連する情報や事例をご存知でしょうか。

このような個別具体的な質問はスタック・オーバーフローなどにお願いします

View more

パスワードのハッシュ管理で、ソルトは秘密情報ではない(バレてもいい)のはどうしてでしょうか?ハッシュがバレた場合に元パスワードが探索されてしまいませんか?

積極的にバレてもいいと言うことではないのですが、ハッシュ値が漏洩するような状況ではソルトだけ秘密にしておくことは難しいという判断によるものです。
仮に「絶対に漏洩しない保存手段」があるのであれば、
(1)パスワードをその方法で保存する または
(2)暗号鍵をその方法で保存してパスワードの暗号化する
方が安全です。とくに(2)は、ハードウェア セキュリティ モジュール (HSM)という形で実現しています。しかし、HSMは高価なことから、廉価で安全性も高い方法として、(最悪バレるかもしれない)ハッシュ値とソルト、加えてストレッチングという方法がよく使われます。
例えばソルトをDBとプログラムハードコーディングに分けて保存すると、片方だけバレても平文パスワードの復元は難しいという状況は作れます。拙著で紹介している方法です。

View more

外部入力のないwebサイトをphpでつくるときには、xss対策は必要ないのでしょうか?

ご質問に対する答えは、YESでありNOです。
外部入力が、HTTPリクエスト、メール、ファイル、DB等を含めてまったく存在しないのであれば、XSS攻撃の経路がないので、XSS攻撃はできません。そのため、XSS攻撃の対策も不要ということになります。
しかし、XSS対策として通常実施するHTMLエスケープ、属性値をダブルクォートで囲む、HTTPレスポンスヘッダに文字エンコーディングを指定する…などが不要になるわけではありません。これらは「攻撃を防ぐ」ために実施するわけではありません。これらは、開発者が意図した通りの表示にするために必要な処理だからです。
このため、攻撃の経路があろうが、なかろうが、XSS対策と同等のことは元々Webシステムではやらなければならないこと、ということです。ご質問の答えがNOでもあるというのはそういうことです。

View more

$_SERVER['SERVER_NAME']をブラウザに出力する場合にもhtmlspecialcharsに通すべきでしょうか?

通すべきです。型変換という立場からは通すべきだということと、仮にエスケープすべき文字が来ないことがわかっていても、それを一々確認することが煩わしく、バグや脆弱性の元です。一律に通すと決めたほうがシンプルで、バグや脆弱性も混入しにくくなります。

View more

ログイン画面の次画面への遷移のときに存在するオープンリダイレクタと、GET一発で簡単にリダイレクトしてしまうふつうおオープンリダイレクタ、それぞれの脅威の差などについて何かご意見ありますか?

脅威の差はあると思いますが、それを説明するには余白が狭すぎます

View more

徳丸先生の結城浩さんについての印象を教えてください。(浩繋がりで)

1990年代はじめに、Cマガジン誌に連載を持っていたのですが、その頃にCマガジンにて結城さんの記事を目にしました。あまりの分かりやすい記事にびっくりして、すごい人が出てきたなと思ったことを今でも覚えていて、その印象は今も変わりません。

View more

セキュリティエンジニアの端くれです。子どもと妻がいるのですが、仕事が忙しく、なかなか家族のための時間を作ることができません。徳丸さんはご家族を大切にしていらっしゃるとのことですが、家族サービスとして何か心がけていることはありますか?

朝ご飯と夕ご飯をできるだけ家族全員でとるようにしています。そのため、起床のタイミングを合わせることや、夜間の外出や飲み会をできるだけ控えることを心がけています。

View more

Next