年別アーカイブ: 2013年

2013-12
10
00:23:28
SQLインジェクション対策で大垣靖男氏は何を勘違いしていたか


以下のTogetterでまとめて頂いているが、大垣靖男氏と「何故氏はSQLインジェクション対策においてプリペアドステートメントの利用よりも入力データのエスケープ処理を優先するのか」について議論させて頂いた。

SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論

僕の疑問は一番最初の方にもあるが、「プリペアドステートメント+プレースホルダーで複雑な自作エスケープなどせずともシンプルにさほどの技術力も無く少なくとも『SQLインジェクション対策』としては機能するのに、何故そこまでエスケープ処理対応を一義に拘るのか」という点だった。

この優先順位度合いは以下のブログの部分からも明らかだ。

出力先のシステムが同じでも、出力先が異なる、を意識する

実際の開発に利用するコーディングルールでは出力先によって「API > エスケープ > バリデーション」の順番になる場合もありますが、セキュリティを維持するための重要度は「エスケープ > API > バリデーション」であることは変わりません

さて経緯は上記Togetterに譲るが、結論として何故氏はそのような無謀な主張を延々繰り返すか、氷解したような気がする。
少しツイートもしたが誤解があるかも知れないのでもう少し詳しく説明しておきたい。またこれは以外に面白い視点も内包しているかも知れない。

Continue reading

2013-09
14
01:38:36
各社iPhone 5sの月額・総額コストをまとめてみた(MNP/機種変更版)


せっかくなので、ドコモ・au・ソフトバンクでのiPhone 5s の本日時点で明らかになった月額コストと1年および2年での総額コストをまとめてみた。内容は未保証です。間違いなどあればご指摘ください。対象はMNPにしています。5cや買い換え版は誰か別の方に任せます。

(追記 9/14 9:00)

機種変更分も作成して追加しました。以下内容はそれに応じて追加・変更しています。なお「新規購入」は対象にしていないことに注意

(追記 9/15 6:00)

コメントで頂きましたが各社2年契約解約可能時期や月々サポート/毎月割/月月割の期間にズレもあるため、原則として契約時期は月半ばと想定し、1年契約は純粋に12ヶ月間、2年契約は各社2年契約の解約月までとして結果的に26ヶ月間での比較としました。これに合わせて特徴などのコメントも変更しています。

Continue reading

2013-09
11
20:04:30
ドコモのiPhone販売開始は真の料金プラン競争へ向かわせられるだろうか


ドコモのiPhone販売開始は真の料金プラン競争へ向かわせられるだろうか
ドコモのiPhone販売開始は真の料金プラン競争へ向かわせられるだろうか

既報の通り、ドコモが正式にiPhone 5s/5cを取り扱うことが発表された。
特に注目したいのはこのことが日本で初めての「三大キャリアが全く同じ機種を同じように販売する」ケースになる、ということだ。
これまでも確かに同じメーカーの同じベースモデルの機種が発売されたことはあるものの、アップルのiPhoneのようにどのキャリアにも全く同じ条件・環境での販売をさせるケースは初めてだ。実際にはiPhoneでも国や対応周波数などで微妙に異なるモデル(SKU)をキャリア毎に投入することはあるのだが、今回の場合は5sだと全キャリアでA1453という同じモデルらしいと噂されている。

端末が全く同じだと言うことになると、当然消費者がどのキャリアを選ぶか、またはキャリアがどのような差別化や訴求をしてくるかは、まずはネットワーク性能であり、そしてそれでダメだとなれば次に「料金プラン」ということになるだろう。
個人的には実はこの「料金プラン競争」にこそ注目している。それは「各社が全く同じiPhoneを販売せざるを得ない状況」で「本当の意味での料金プラン競争」が起きてくれるのでないかと願っているからだ。

Continue reading

2013-09
04
06:44:48
ワンタイムパスワードの送付先にケータイメールは相応しくない


近年大手のWEBサービスも含めて所謂リスト攻撃などで不正ログインが多発するなどしており、一躍注目を集めているのが二要素認証(二段階認証)だ。通常のユーザーID/パスワードでの認証に加えて、その一時にだけ有効なワンタイムパスワード(OTP/One Time Password)を発行しこれも一致しないとログインを認めない方法である。
このワンタイムパスワードの発行方法またはユーザーへの送付方法には幾つかのパターンがある。
最も「厳しい」物理的なハードウェアトークンをユーザー毎に配布して表示される番号をワンタイムパスワードとして入力する方法(Paypalでの例)や、より簡易にスマホなどのソフトウェアでワンタイムパスワードを確認できる方法(有名なソフトウェアとしてはGoogle Authenticatorなどがある。但しサービスがこれらのソフトへ対応していないといけない)のほか、もっとも一般的には「ユーザーが別途指定したメールアドレスへワンタイムパスワードをメールする」方法がある。

ワンタイムパスワード自体は二要素認証のためだけの方法でも無い。ログイン時だけでは無く、例えば銀行サイトで他口座への振込などの資金移動をする際にワンタイムパスワードの設定をしていなければ操作できなくしている銀行も多い。これもまた近年高まっているセキュリティ保護の機運を反映したものだろう。

最近ではスマホなどモバイル環境の一般化によってか、「メールアドレスへのワンタイムパスワードの送付」パターンの場合にはPC用メールアドレスでは無く「ケータイメール」(すなわち携帯キャリアが提供しているメール)への送信を強く要請してくるようになった。
例えば三菱東京UFJ銀行や楽天銀行では最近になって「携帯メールでの登録」を勧める旨の記載が増えた。

三菱東京UFJ銀行 / インターネットバンキングのログイン時の本人確認方法を一部追加します。(平成24年2月12日(日)より)

楽天銀行 / セキュリティ強化のためのワンタイム認証のルール変更について

一方以下はGoogleでの二要素認証設定時の様子だ。ワンタイムパスワードの取得方法としてGoogle Authenticatorを使用することも出来るが、デフォルトではこのように各携帯キャリアのメールアドレスを指定することになっており、設定後は信頼できない端末からのログインの際はこのアドレスへワンタイムパスワードが送られる。

スクリーンショット 2013-08-02 5.19.49

前述の通り幾つかのバリエーションはあるものの、これらの例のように近年ではワンタイムパスワードは「ケータイメール」へ送付することが大変一般的になってきたと感じるし、実際多くの方がそのようにされているのでは無いだろうか。

しかしながらPCメールなどよりも「ケータイメール」をワンタイムパスワードの入手元とすることは果たして「より安全」な方法だろうか。

Continue reading

2013-08
08
07:16:23
#Suica履歴提供 問題は何を問題にしなければならないか


#Suica履歴提供 問題はまだまだ一旦落着したわけでは無くて、JR 東日本と日立側にまだ問題解決を突きつけているし、また従来から暗に言われていたにも関わらず本当に「自分のプライバシーが自分の知らないところで売られることがある」点を明瞭にしたという意味では「素晴らしい」スタディケースであるというべきだろう。また現在進行中の総務省 「パーソナルデータの利用・流通に関する研究会」においても「想定外の」こうした具体的インシデントを得ることでより踏み込んだ議論や検討にも役立つことになるだろう。

一方で我々利用者である。果たして今回の問題で「何が悪かったのか」「何を問題としなければいけないのか」明瞭に理解し主張できる人も少ないかも知れない。
端的には「何だか気持ち悪い」「自分の知らないところで勝手なことをするな」でよいのだ。難しい議論は専門家に任せて我々は「庶民感覚で」JR東日本など庶民感覚にかけ離れた企業マインドを叩いて構わないのである。
しかしと同時に少しだけ今回の一連のことが「論理的には」どういう意味を持つことだったのか知ることもまた決して損では無いだろう。

Continue reading