タグ

webとsecurityに関するscorelessdrawのブックマーク (23)

  • 高木浩光@自宅の日記 - 2年前に書いた懸念がいよいよ現実のものになりつつある, 追記, 追記2

    ■ 2年前に書いた懸念がいよいよ現実のものになりつつある 2008年に書いた懸念、 単純所持刑罰化ならウイルス罪を同時施行しないとセキュリティバランスが悪化する, 2008年5月5日の日記 これが現実になりつつある。 先週、長崎市立の中学校の校長が、自宅のパソコンで、児童ポルノに該当し得ると疑われるファイル名のファイルを開いたと疑われる事態が、ウイルス(トロイの木馬)によって暴露され、三流下劣メディアから嘲笑されるという事件が起きた。 中学校校長がロリコン画像を大量所持か / 性的画像と一緒に学校資料も, ロケットニュース24, 小林涼子編集長(システム担当 矢野さとる)(29日16:30修正、下記の追記2参照), 2010年3月21日 (略)この人物が校長だといわれているのはなぜか? それはロリコン画像のほかに最近使ったデータとして学校名付きで学力向上対策.jtd、学校生協への学校紹介.

  • 高木浩光@自宅の日記 - こたえはきっとソースの中に 〜 ドコモのCAPTCHAモドキ

    そもそもこのサービスにとってCAPTCHAが何の意味をなすのか疑問*1だが、それはともかく、この部分のHTMLソースを見ると、画像のURLに答えが書かれている。(図2の「gifcat/call.php?SID=948545」) これでは何の意味もない。 これの目的がもし、他サイトからのリンクで検索させられる事態を防ぐためであるなら、画像なんか表示せず、直接INPUTフィールドに値を埋め込むようにしておけばいい話だ。*2 <input name="attestationkey" value="948545" type="hidden"> ちなみに、図2で示される画像のURLに直接アクセスしてみると、図3のように、リロードする毎に(同じ番号の)違う画像が現れる。何回か繰り返してみると、1つの数字あたり4種ほどの画像が用意されているだけだとわかる。 背景のノイズのようなものも、動的に生成されてい

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

    ■ 「日のインターネットが終了する日」あとがき 10日の日記「日のインターネットが終了する日」には、書ききれなかったことがある。また、頂いた反応を踏まえて追記しておきたいこともある。 青少年は結局どうすればいいのか はてなブックマークのコメントに、「当に知らなければいけない人には理解されないかと思うとね・・・哀しくなってくる」という声があった。リンク元のどこだったかには、「肝心の子供たちにはどう説明したらいいんだ」というような声もあったと思う。 契約者固有IDの送信を止める設定をしてしまえば、モバゲータウンや魔法のiらんどなどが使えなくなってしまう。設定をアクセス先毎に変更しながら使うという方法もあり得るが、子供たちにそれをさせるのは無理な話だろう。保護者としては、確実に安全に使える設定を施した上で電話を子供に渡したいはずだ。「住所氏名は入れちゃ駄目」というのは、これまでも子供たちに

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

    ■ 日のインターネットが終了する日 (注記:この日記は、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通知設定は

    scorelessdraw
    scorelessdraw 2008/07/14
    "重要なのは、IDがどのように使われ得るかの個別の検討であって、IDが付くことではない。"
  • 高木浩光@自宅の日記 - B-CAS社の個人情報登録サイトのSSL証明書がNTT DATA

    ■ B-CAS社の個人情報登録サイトのSSL証明書NTT DATA B-CAS社の「オンラインによるB-CASカードのユーザー登録」の画面から、登録画面に進むと、個人情報入力画面が現れるのだが、ここでページが https:// になっていることを確認の上、サイト証明書の内容を確認してみると、「NTT DATA CORPORATION」と表示される。 よく見てみると、さっきまでは b-cas.co.jp を閲覧していたはずが、この画面はいつのまにか、b-cas.jp という別サイトに飛ばされている。 しかも、b-cas.jp ドメインの保有者が誰なのか、whois で調べてみると、さらに別の会社になっている。 不特定多数からの大量の登録を受け付けるサイトにしてはずいぶんと稚拙だ。

    scorelessdraw
    scorelessdraw 2008/06/26
    次は電凸?
  • クレジットカード決済における本人認証について : LINE Corporation ディレクターブログ

    こんにちは、ライブドアで決済システムを担当している森です。 今回は、クレジットカード決済における人認証について書かせていただきます。 【01】3D Secure と e-SCOTT 皆さんは「3D Secure」というクレジットカード人認証サービスをご存知でしょうか。 「3D Secure」とは、クレジットカード決済を行なう際に、カード番号と有効期限のほかに、クレジットカード会社に登録してあるパスワードでも認証を行なうサービスです。 パスワード認証を行なうことで、カードの「盗難」や「なりすまし」などによる不正利用の防止が可能となります。 また、入力されたパスワードは、カード発行会社に直接暗号化されて送信されるため、サイト運営会社(livedoor デパートなど)では取得できない仕組みになっており、情報漏洩による事故も防ぐことができます。 このサービスは、元々ビザ・インターナショナルが

    クレジットカード決済における本人認証について : LINE Corporation ディレクターブログ
    scorelessdraw
    scorelessdraw 2008/05/29
    セキュリティってよりもチャージバック対策って意味の方が大きい気もするんだが
  • OpenID や OAuth の役割と、既存のシングル・サインオンとの違い:Goodpic

    This shop will be powered by Are you the store owner? Log in here

  • Webアプリケーションを作る前に知るべき10の脆弱性 ― @IT

    Webアプリケーションが攻撃者に付け込まれる脆弱性の多くは、設計者や開発者のレベルで排除することができます。実装に忙しい方も、最近よく狙われる脆弱性のトップ10を知ることで手っ取り早く概要を知り、開発の際にその存在を意識してセキュアなWebアプリケーションにしていただければ幸いです。 Webの世界を脅かす脆弱性を順位付け OWASP(Open Web Application Security Project)は、主にWebアプリケーションのセキュリティ向上を目的としたコミュニティで、そこでの調査や開発の成果物を誰でも利用できるように公開しています。 その中の「OWASP Top Ten Project」というプロジェクトでは、年に1回Webアプリケーションの脆弱性トップ10を掲載しています。2004年版は日語を含む各国語版が提供されていますが、2007年版は現在のところ英語版のみが提供さ

    Webアプリケーションを作る前に知るべき10の脆弱性 ― @IT
    scorelessdraw
    scorelessdraw 2007/06/15
    ブクマ数
  • 高木浩光@自宅の日記 - ログイン成功時のリダイレクト先として任意サイトの指定が可能であってはいけない

    ■ ログイン成功時のリダイレクト先として任意サイトの指定が可能であってはいけない これが「脆弱性」として合意されるかどうかわからなかったが、脅威と対策をまとめてIPAに届け出てみたところ、受理され、当該サイト(複数)は修正された。以下、この問題がどういうもので、どうするべきなのか、はてなのケースを例に書いておく。 4月にこんな話が盛り上がりを見せていた。*1 ソーシャルブックマークユーザーのIDとPASSをいとも簡単に抜き取る手口, ホームページを作る人のネタ帳, 2007年4月6日 Bボタンフィッシングとは何? 記事の最後には私のブログでもおなじみの、はてなブックマークへ追加ボタンや、バザールのブックマークボタン(Bボタン)を設置しているブログを最近良く見かける。何気なく私はそれを利用したりしている。(略)『あれ?セッションがきれたのかな』と思い、自分のIDとパスワードを入れてログイン。

  • x.com

  • 携帯業界の認証事情 - y-kawazの日記

    巡回サイトの一つである高木浩光@自宅の日記で以下のようなエントリーがあった。 高木浩光@自宅の日記 - 携帯電話向けWebアプリの脆弱性事情はどうなっているのか ここではいつもの高木氏の口調で、「携帯向けWEBアプリ開発では未だにGETパラメータでセッションIDを渡しており、それはこれまでも何度もいかんことだと言っている。」というような内容が語られている。 確かにWEB+DBの記事に対して高木氏が注釈で言っているように「IPアドレスによる制限に関して書いていない」という点に関してはWEB+DB側の落ち度だと思う。実際これを行わない限り端末IDやユーザID*1による認証が意味をなさなくなってしまうからだ。*2 但し、キャリア毎にIPアドレス制限をする限りにおいては端末IDやユーザIDは偽装不可能*3なので、むしろ他人でも入力可能なパスワード認証よりも強力な認証かもしれません。逆にいえばその認

    携帯業界の認証事情 - y-kawazの日記
  • http://cgi36.plala.or.jp/tera5/v/security/webap_sec2/chap01.html

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

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

  • IPAたんからお礼が! - ぼくはまちちゃん!

    はじめてのほうこく IPAたんからの返事 IPAたんからへんじこない のつづきです!!! 返事きたよ! きてました>< Date: Thu, 01 Feb 2007 20:43:06 +0900 To: Hamachiya2 Subject: 【IPA#32334280/IPA#11631745/IPA#92669403/IPA#94436430】 届出いただいた件について - ----------------------------------------------------------------- このメールは、以下の取扱い番号に関する連絡です。 IPA#32334280/IPA#11631745/IPA#92669403/IPA#94436430 - ----------------------------------------------------------------

    IPAたんからお礼が! - ぼくはまちちゃん!
  • IPAたんからの返事 - ぼくはまちちゃん!

    Date: Tue, 30 Jan 2007 10:37:05 +0900 From: "IPA/vuln/Info" To: root@hamachiya.com はまちや2様 ウェブアプリケーションの脆弱性関連情報を届出いただき、ありが とうございます。 件につきまして、ガイドラインの以下の項目に記載がありますよ うに、届出の際には発見者様の氏名をご記入頂いております。 これは、責任ある届出を促すためであり、匿名やハンドルネームの 届出は受理できませんので、実名での届出にご協力をお願い致します。 ----------------------------------------------------------- 「情報セキュリティ早期警戒パートナーシップガイドライン」P.17 V.ウェブアプリケーションに係る脆弱性関連情報取扱 2. 発見者の対応 4) 届け出る情報の内容 ・発見者

    IPAたんからの返事 - ぼくはまちちゃん!
  • 高木浩光@自宅の日記 - 蔓延する「サイバーパテントデスクのWWWサーバ」

    ■ 蔓延する「サイバーパテントデスクのWWWサーバ」 「現場でコピペしてるんだ」の話から、5年前の話を思い出し*1、再び検索してみると、該当ページは増えていた。 http://www.yurinsha.com/ssl.htm インターネットセキュリティ(SSL)は安全です!! SSL(Secure Sockets Layer)は、WWWブラウザとWWWサーバ間でデータを安全にやりとりするための業界標準プロトコルです。 SSLには、認証と暗号化の機能があります。 認証機能により、接続しているWWWサーバが確かにNRIサイバーパテントデスクのWWWサーバであることを保証します。 また、暗号化機能により、検索内容が暗号化された上でインターネット上で通信されます。これにより、データがインターネット上で盗聴、改竄される危険性が小さくなります。 http://tweb.omt.ne.jp/ssl_in

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

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

    scorelessdraw
    scorelessdraw 2006/11/05
    「SQL文の作成を正しく行うという『1つだけ』の方法で『決定的手段』なのに、なんで併用とか言い出すわけ? たくさんのSQL文があるときに漏れが生じるからということが言いたいなら、そう書けばいい。」
  • 2006-05-07

    あなたが10の理由を示すべき10の理由。 「7の理由」ではパターン化しすぎているから。 9では少なすぎ、11では切りが悪いから。 体系的に広い視野で考えているように見てもらえるから。 なんだかんだいって10個くらいの理由は思いつくから。 10個も示せば一つくらいは「なるほど」と言ってもらえるから。 10個も示せば一度には読みにくいためブックマークしてもらえるから。 10個も示せば時間経過とともにランキング変動も調査できるから。 10位から発表していけば「1位は何だろう」と盛り上げられるから。 タイトルで「10の理由」と書いておいても、実際に10個も示す必要なんてないから。 ※流行ものらしいので、書いてみました。 はてな認証APIに関連して、kazuhoさんが以下のエントリを書いておられます。(via まちゅダイアリー) Re: はてな認証 API Hash ≠ MAC これは「秘密鍵をメッ

    2006-05-07
  • 高木浩光@自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由

    水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest(ヘッダおよび、POSTの場合はボディを含む)を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse(ヘッダおよび、HTML)を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更

    scorelessdraw
    scorelessdraw 2006/04/10
    「CSRF攻撃による被害は、Webアプリが設計上想定していない画面遷移を辿られることによって起きる。であれば、Webアプリが想定している画面遷移しか許さないようにすることによっても解決できるということになる。」
  • 適切なエスケープ処理でクロスサイトスクリプティングに備える ― @IT

    Webアプリケーションのセキュリティホールが注目を浴びたことから、セキュリティを意識した開発の必要性が高まってきている。今後の流れとして、セキュリティ上満たすべき項目が要件定義の段階から組み込まれるケースが増えていくことが予想されるが、実際の開発現場においてはセキュリティホールをふさぐための実装方法が分からないという声も多いのではないだろうか。 そういった開発者の負担を少しでも軽くすることができるように、連載ではJavaにおけるWebアプリケーション開発時に最もよく利用されているStrutsフレームワークの実装に踏み込んで、セキュリティ上注意すべきポイントを解説していきたい。なお、連載ではStruts 1.2.8を対象として解説を行っていくが、すでにStrutsを利用したWebアプリケーション開発を行っている開発者をターゲットとしているため、Strutsの使用方法、各機能の詳細な説明な

    適切なエスケープ処理でクロスサイトスクリプティングに備える ― @IT