解説 例えば個人情報の登録を必要とするWebサイトでは、盗聴やなりすましなどの攻撃を防ぐため、SSLによる通信路の暗号化が求められる。それにはWebサーバの出所を証明するデジタル証明書（以下、サーバ証明書）を証明機関（CA）から取得し、サーバにインストールする必要がある。 ただ、この作業は設定項目も多ければ手順もそれなりに複雑なので、どこかで失敗する可能性は否定できない。もしサーバ証明書の取得やインストールに失敗すると、SSLを必要とするWebページをユーザーが閲覧した際にエラーが表示されてしまう。SSLを必要とするような、信頼を求められるサイトでこのようなエラーはあってはならないものだろう。 サーバ証明書のインストールに失敗しているサイトのエラー表示例 これは、わざと誤ったサーバ証明書をインストールしたWebサイトをInternet Explorer（IE）で開いたときの例。IE以外のW

NFC・Wi-Fiなど端末間共有機能 【1】NFCでデータを共有する「Androidビーム」 「Androidビーム」は、NFC対応デバイス間で共有を行うための機能です。ユーザー同士が2つのNFC対応のデバイスを接触することで簡単に、お気に入りアプリ、コンタクト、音楽、動画など、ほとんどのコンテンツを交換可能にします。デバイス同士が数センチ範囲内にあると、システムはNFCの接続を設定して共有のためのUIを表示し、ユーザーは画面をタッチすることで共有が行えます。 例えば、ユーザーは連絡先を交換したり、マルチプレイゲームを開始したり、チャットやビデオ通話に参加したり、写真や動画などを共有したりできます。アプリを共有する場合、Androidマーケットのアプリ詳細ページへのリンクを送ります。リンクが送られた端末上のマーケットアプリは詳細ページを起動し、ユーザーはアプリを簡単にダウンロードできます。

“特殊だ”と形容されることの多い日本の携帯電話向けWebサイト。そこには、さまざまな思い込みや性善説の上しか成り立たないセキュリティが横行しています。本連載は、ケータイWebの特殊性をていねいに解説し、正しいケータイWebセキュリティのあるべき姿を考えます（編集部） 前回では、URLにセッションIDを埋め込むことの問題点を指摘した上で、今後はできるだけケータイでもCookieを使うことを提案しました。それを受けて今回は、前半で、ケータイWebでCookieを使う際の注意点について説明します。 そして後半では、連載の終わりに当たり、スマートフォンが普及しつつある状況下でのケータイWebの今後について説明します。 ケータイWebにおけるCookieは「取り扱い注意」 これまで説明したように、KDDIとソフトバンクのケータイでは従来からCookieが利用でき、NTTドコモの端末でも2009年夏モ

川口、官房長官就任 皆さんこんにちは、川口です。先月からセキュリティ監視センターJSOC（Japan Security Operation Center）のセキュリティアナリストのリーダーの座を後進に譲り、JSOCの官房長官として、JSOCセンター長を補佐するお仕事に就くことになりました。 今回は、そんな私が対応することになった標的型メール攻撃の顛末（てんまつ）を取り上げます。厳密にいうと今回届いたメールは、JSOCにとっては、脅威となり得る「標的型」ではありません。しかし受け取る組織によっては十分標的型メール攻撃となり得る内容ですので、紹介したいと思います。 ある日JSOCに届いた1通の標的型メール 5月のある日、JSOCで仕事をしていたところ、1人のセキュリティアナリストが話しかけてきました。 「サポート窓口に変なメールが来ているぞ。ヤバイと思うので見てほしい」 すぐに確認したところ、

実は厄介、ケータイWebのセッション管理：再考・ケータイWebのセキュリティ（3）（1/3 ページ） “特殊だ”と形容されることの多い日本の携帯電話向けWebサイト。そこには、さまざまな思い込みや性善説の上しか成り立たないセキュリティが横行しています。本連載は、ケータイWebの特殊性をていねいに解説し、正しいケータイWebセキュリティのあるべき姿を考えます（編集部） 「Cookieを使えない端末」でセッションを管理する方法は？ 第2回「間違いだらけの『かんたんログイン』実装法」ですが、多くの方に読んでいただきありがとうございました。 今回は、前回に引き続き架空のSNSサイト「グダグダSNS」のケータイ対応を題材として、ケータイWebのセッション管理の問題点について説明します。携帯電話向けWebアプリケーション（ケータイWeb）のセッション管理は、かんたんログインよりも対策が難しく、厄介な問

今回は、そのかんたんログインの問題点について説明します。 「契約者固有ID」を用いるかんたんログイン かんたんログインとは、携帯電話の「契約者固有ID」を用いたログイン手法です。 第1回で説明したように、携帯電話のブラウザのリクエストヘッダには契約者固有IDと呼ばれるIDを付けることができます。契約者固有IDは、携帯電話事業者によって詳細は異なりますが、すべての携帯電話事業者が対応しています。 図1は、NTTドコモの携帯電話がサポートしている契約者固有IDである「iモードID」がサーバに送信される様子です。この情報は、ユーザーがそれと意識することなく送信されます。携帯電話のかんたんログインとは、契約者固有IDのみを用いて認証を行い、ログイン機能を実現することです。 かんたんログインは、ベーシック認証のようにIDとパスワードを管理する必要もなく、Cookieのように対応する端末を考慮する手間

しばしば「パスワードは○日ごとに変更しましょう」といわれるけれど、それで本当にクラックの危険性は減るの？ ペネトレーションテストの現場から検証します（編集部） ※ご注意 本記事に掲載した行為を自身の管理下にないネットワーク・コンピュータに行った場合は、攻撃行為と判断される場合があり、最悪の場合、法的措置を取られる可能性もあります。また、今回紹介するツールの中には、攻撃行為に利用されるという観点から、アンチウイルスソフトにウイルスとして検出されるものも存在します。このような調査を行う場合は、くれぐれも許可を取ったうえで、自身の管理下にあるネットワークやサーバに対してのみ行ってください。また、本記事を利用した行為による問題に関しましては、筆者およびアイティメディア株式会社は一切責任を負いかねます。ご了承ください。 今回は久しぶりに、ペネトレーションテストの現場の話から始めよう。 ペネトレーショ

情報の入れ物、データベースは大丈夫ですか 皆さんこんにちは、川口です。そろそろGumblarの話に飽きてきたところでしょうか。今回は以下の4種類のデータベースで、管理用ポートをインターネットにオープンしているとどうなるかについて調べた結果を取り上げます。いずれも管理用ユーザーのパスワードは「脆弱なもの」に設定されています。 Oracle（1521/tcp） SQL Server（1433/tcp） MySQL（3306/tcp） PostgreSQL（5432/tcp） 右側に書いてある番号が管理用ポート番号です。データベースを管理する場合、これらのポートをインターネットに対してオープンにする必要はないはずです。しかし、これらのポートに対して外部から“直接”接続するインシデントが年に数回は発生しています。 このようなインシデントは、大学のネットワークに接続したサーバがほとんどですが、ホステ

「脆弱性根絶なんてできっこない」と嘆く前に：セキュリティ、そろそろ本音で語らないか（13）（1/3 ページ） 脆弱性は上流工程でつぶせるか 私は最近、多くの時間を割いてプログラムを書いています。本来の性格から来るものか、バグはゼロになりません。この原稿の場合、誤字脱字に相当するでしょうか。この原稿などは編集部でキッチリ見てもらっているので大丈夫だと思いますが、プログラムはお客さまに迷惑をかけるかもしれないので、テストを繰り返してバグをつぶしていきます。 私は性格がそもそもおっちょこちょいな上にずぼらですから、プログラマには最も向いていないのかもしれません。いや、脆弱性を考えると「プログラムを作ってはいけない」といわれそうです。 私は前職で、日本で初めて「セキュリティの脆弱性検査」を事業として立ち上げた経験があるのですが、始めた当初から「セキュアなプログラミングが普及すれば脆弱性検査の市場は

これまでは“コンサルタント”としての本音を語ってきた本連載ですが、実は筆者は筋金入りの“プログラマ”。第7回はプログラマ視点でのセキュリティを語ります（編集部） 私、現役プログラマです 私は学生のころからコーディングを行っていて、アルバイトで売上管理プログラムなどを作っていました。当時は容易に入手できる開発環境などもロクになくて、選択肢はBASICか機械語くらいでした。 その後もいろいろな言語でプログラムを書いてきました。タイヤの設計に使う3次元CADのマクロ、NeXT（これ自腹でローン組んで買いました）のアプリケーション、MacintoshでのThinkCなんかも経験しつつ、Windows 3.1とUNIX間のTCP/IP通信プログラムなど、いまから思えばプログラムは趣味の1つなのかもしれません。2008年には、Second LifeのLinden Scriptで書いた動くペットなんかも

［無視できない］IEのContent-Type無視：教科書に載らないWebアプリケーションセキュリティ（2）（1/2 ページ） XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます（編集部） 無視できないIEの「Content-Type無視」問題 皆さんこんにちは、はせがわようすけです。 第2回では、Internet Explorer（以下、IE）の仕様でも特に悪名高い「Content-Type無視」について説明します。 IEのContent-Type無視問題は非常に複雑で、私自身も完全に説明できる自信はないのですが、それでもセキュアなWebアプリケーションを開発するうえで避けては通れない問題ですので、取り上げることにしました。