タグ

ブックマーク / takagi-hiromitsu.jp (12)

  • 高木浩光@自宅の日記 - やはり退化していた日本のWeb開発者「ニコニコ動画×iPhone OS」の場合

    ■ やはり退化していた日のWeb開発者「ニコニコ動画×iPhone OS」の場合 一年前、「退化してゆく日のWeb開発者」という題で、ケータイWebの技術面での蛸壺化について次のように書いた。 iPhoneに契約者固有ID送信機能が搭載される日 (略)こうして退化してゆくケータイWebが、日のスタンダードとなってしまい、いつの日か、PC向けの普通のインターネットまで、単一IDの全サイト送信が必須になってしまうのではないかと危惧した。 (略)iPod touchでNAVITIMEを動かしてみたところ、下の図のようになった。 (略)契約者固有IDがないとどうやって会員登録システムを作ったらいいのかわからないんじゃないのか……というのはさすがに穿ち過ぎだと思いたい。NAVITIMEからソフトバンクモバイルに対して、契約者固有ID送信用プロキシサーバの用意を要請している……なんてことがなけれ

  • 高木浩光@自宅の日記 - 日本のインターネットが終了する日

    ■ 日のインターネットが終了する日 (注記:この日記は、6月8日に書き始めたのをようやく書き上げたものである。そのため、考察は基的に6月8日の時点でのものであり、その後明らかになったことについては脚注でいくつか補足した。) 終わりの始まり 今年3月31日、NTTドコモのiモードが、契約者固有ID(個体識別番号)を全てのWebサーバに確認なしに自動通知するようになった*1。このことは施行1か月前にNTTドコモから予告されていた。 重要なお知らせ:『iモードID』の提供開始について, NTTドコモ, 2008年2月28日 ドコモは、お客様の利便性・満足の向上と、「iモード(R)」対応サイトの機能拡充を図るため、iモード上で閲覧可能な全てのサイトへの提供を可能としたユーザID『iモードID』(以下、iモードID)機能を提供いたします。 (略) ■お客様ご利用上の注意 ・iモードID通知設定は

  • 高木浩光@自宅の日記 - 公開鍵暗号方式の誤り解説の氾濫をそろそろどげんかせんと

    ■ 公開鍵暗号方式の誤り解説の氾濫をそろそろどげんかせんと 「コンピュータセキュリティを基礎から」というと、暗号の解説、特に共通鍵暗号と公開鍵暗号の違いからなどといった解説をよく目にする。昔は専門の方によって注意深く書かれていたのに対し、ここ何年かはひどい状況になっている。先月、宮崎で開かれたSCIS 2008の席でも暗号研究者の方々との雑談でそういう話になった。私は暗号は専門でないのでその話題は迂闊に書けないできたが、このところの巷の誤り解説の氾濫ぶりは目に余るものがある。 最もひどく蔓延っていてしばらく消えそうにない間違い解説の典型例は次だ。 「公開鍵で暗号化したものを秘密鍵で復号するのと同様に、秘密鍵で暗号化したものを公開鍵で復号できるようになっている。」 事例1: 日ベリサイン株式会社による公開鍵暗号方式の解説 このような共通鍵暗号方式の問題点を解決する暗号方式が、公開鍵暗号方式

  • 高木浩光@自宅の日記 - WASF Times版「サニタイズ言うな!」

    ■ WASF Times版「サニタイズ言うな!」 技術評論社の「Web Site Expert 」誌に、Webアプリケーション・セキュリティ・フォーラム関係者の持ち回り企画「WASF Times」が連載されている。私の番も回ってきたので昨年9月発売号に寄稿させていただいた。近頃はサニタイズ言うなキャンペーンもだいぶ浸透してきたようだし、もういまさら不要という気もするが、以下、その原稿を編集部の承諾のもと掲載しておく。 「サニタイズしろ」だあ? Webアプリを作ったらセキュリティ屋に脆弱性を指摘された――そんなとき、「入力をサニタイズしていない」なんて言われたことはありませんか? 「入力」というのは、ブラウザから送信された情報をCGIパラメータとして受信した値のこと。これを「サニタイズしろ」というのです。なんでそんなことしないといけないの?プログラムの内容からして必要のないことなのに? そう

  • 高木浩光@自宅の日記 - 駄目な技術文書の見分け方 その1

    ■ 駄目な技術文書の見分け方 その1 はてなブックマークのホッテントリを見ていたところ、300を超えるユーザに登録された以下の記事があった。 今夜分かるSQLインジェクション対策, 上野宣, @IT, 2006年11月2日 また上野宣か。顔見知りなのでズバリいくことにする。 しかし、その対策はまだ当に理解されていないように思える。 へえ。 終わりの方を見てみると、 Webアプリケーションの対策 入力値のSQLの特殊文字を適切にエスケープ 入力値=プログラム(プロセス)に外部から入ってくるもの シフトJISの場合には1バイト文字を整理 SQLの記述をなくすためにO/R(Object/Relational)マッピングを活用 攻撃者に役立つ情報を与えないために、不要なエラーメッセージ(データベースが出力するエラーなど)の表示を抑止 対策に「準備された文」(prepared statement)

  • 高木浩光@自宅の日記 - 「リンクお断りは普通」と人の心に種を蒔くAC

    ■ 「リンクお断りは普通」と人の心に種を蒔くAC 公共広告機構ACがハンドルネームで運営のサイトからのリンクを固くお断り, スラッシュドットジャパン, 2006年09月17日 現時点で公共広告機構の「サイトについて」には以下のように書かれている。 1.リンクについて サイトへのリンクは、原則お断りいたします。特に以下のリンクは固くお断りいたします。 当機構の活動等を誹謗中傷、信用を毀損するおそれがあるサイトからのリンク 公序良俗に反する内容を含んだサイトからのリンク 違法なコンテンツを掲載したり、違法な活動に関与した、または関与した可能性のあるサイトからのリンク フレームやその他の方法で、サイト・コンテンツであることが不明となるリンク サイトの管理・運営者が不明、またはハンドルネーム等により運営されているサイト、 あるいは代理運営されているサイトなどからのリンク また、サイトをリン

  • 高木浩光@自宅の日記 - 飾りじゃないのよCAPTCHAは 〜前代未聞のCAPTCHAもどき, CAPTCHA機能の発注仕様をどうするか

    ■ 飾りじゃないのよCAPTCHAは 〜前代未聞のCAPTCHAもどき CAPTCHA*1が基的に荒らし対策目的で使用されるものであることは以前にも書いた。ユーザビリティの犠牲が少ないものは早いうちに破られるし、改良してもイタチごっこになることも目に見えている。それでもなお活用する意義があるのは、使用目的が荒らし対策だからだ。新規ユーザ登録や、ログインなしでできるコメントやトラックバックなど、元々自由に利用させる機能である限り、完全に防ぐことはできないのであり、たとえ将来破られる可能性があろうとも何もしないよりはましだというわけだ。(荒らしがよりハードルの低いところへ行ってくれることを期待できる。) そのようなCAPTCHAは、日ではあまり普及していないようだ。荒し行為が英語圏での状況ほど深刻なものになっていないためか、あるいは、イタチごっこになることが目に見えている技術の採用を嫌う国

  • 高木浩光@自宅の日記 - WinnyのDownフォルダをインターネットゾーンにする

    ■ WinnyのDownフォルダをインターネットゾーンにする いくつかの国々では、貧困層に薬物乱用が蔓延し、注射器の回し打ちで悪性の感染症が広がっているとき、無料で注射セットを配布するのが正義なのだという。 ニートにWinny乱用が蔓延し、Downフォルダのダブルクリックで悪性のトロイの被害が広がっているとき、私達にできることといえば、せめて安全なファイルの開き方だけは伝えていくことではないだろうか。どうしてもWinnyを使いたいならDownフォルダをインターネットゾーンにして使え、と。 Vector Softライブラリに、「ZoneFolder.VBS」というVBスクリプトのパッケージがある。 この中にある「インターネットフォルダ.VBS」を実行すると、作成するフォルダ名を入力するよう求められるので、できるだけランダムな名前を入力する。

  • 高木浩光@自宅の日記 - ASPとかJSPとかPHPとかERBとか、逆だったらよかったのに

    ■ プログラミング解説書籍の脆弱性をどうするか 印刷されて流通する書籍に脆弱性がある、つまり掲載されているサンプルコードにズバリ脆弱性があるとか、脆弱性を産みやすいコーディングスタイルを身につけさせている解説があり、それが脆弱なプログラマを生産し続ける根源になっている問題は、「なんとかしないといけないねえ」と以前から言われてきた。 ソフトウェア製品の脆弱性は、指摘があればパッチが提供されたり修正版に差し替えられたりするが、書籍の脆弱性はどうか。正誤表が差し込まれるとか、回収する措置がとられるかというと、それは望めそうにない。言論には言論で対抗すればよいということになるだろうか。 久しぶりにいくつかの書籍について調べてみた。先月園田さんの日記などで比較的評判良く紹介されていた2冊を読んだ。 山勇, PHP実践のツボ セキュアプログラミング編, 九天社, 2004年6月 GIJOE, PHP

  • 高木浩光@自宅の日記 - 攻撃者視点ではなく開発者視点での解説を

    ■ 攻撃者視点ではなく開発者視点での解説を 8月に@ITに「機密情報に合法的に近づけるWebアプリケーションを守れ」という記事が 出ていた。 タイトルからして意味がわからない。「合法的に近づける」とは何だ? 英文 の直訳か何かか? その連載第2回「多様化するWebアプリケーションへの攻撃」が今日掲載されたのだが、問題を正しく理解し ないまま書かれた記事と言わざるを得ない。例えば次のように書かれている。 この例では、「userid=-20298745283」がクエリストリング にあたる。クエリストリングはURL内に含まれているため、誰でも見ることが できる。従って、ユーザーのちょっとした出来心やいたずら(例えば 「この数字の最後を1つだけずらせばどうなるかなー?」) によって、脆弱性が露見することも多い。 この例であれば、誰が見ても明らかなように、「userid」のパラメー タがユーザー管理

  • 高木浩光@自宅の日記 - 警察庁の指示がスパイウェア感染を招き金融被害をもたらしている可能性

    ■ 警察庁の指示がスパイウェア感染を招き金融被害をもたらしている可能性 最近、必要もなくやたら文字を小さく表示させるWebサイトが増えている。 官公庁も例外ではない。そのくせ、「文字を大きくするには」などという案内 を用意して、曰く、「アクセシビリティ」なのだという。アホかおまえら。 作っていておかしいと思わないのだろうか。もしかすると彼らは、文字を大き くするブラウザ設定で作業しているのかもしれない。だから自分のページでは、 文字を少し小さく作りたくなるのだろう。すると、そこを閲覧する人がまた少 しブラウザの文字サイズを大きくする。そして、そこが作るページはさらにま た少し小さい文字となり、そこを閲覧する人がまた少しブラウザの文字サイズ を大きくする。つまり、文字サイズのデフレスパイラルに陥っているわけだ。 一度地獄まで落ちたらよい。 たとえば、最近リニューアルされた警察庁のトップページ

  • 高木浩光@自宅の日記

    ■ Claude 3による解説:「不適正利用禁止」規定は立案段階で内閣法制局にどう捻じ曲げられたか 昨日の日記「「不適正利用禁止」規定は立案段階で内閣法制局にどう捻じ曲げられたか」だが、おそらく「長すぎて読めない」という声が多そうなので、Claude 3に原稿を読ませて簡単に解説してもらった。これで興味が湧いたら原文を見てほしい。 Claude:はい、この文書の意味はよく理解できます。これは、個人情報保護法の2020年改正(令和2年改正)で新設された「不適正利用禁止」規定(第19条)がどのように立案されたかについて、情報公開請求で開示された内閣法制局審査資料を基に詳細に解説したブログ記事の原稿です。 主な内容は以下の通りです: 当初、個人情報保護委員会事務局は、プロファイリングなどの新技術に対応するため、「適正な利用」義務を新設しようとしていた。 しかし、内閣法制局との審査過程で、規範の明

  • 1