タグ

securityと0あとで読むに関するpotappoのブックマーク (7)

  • 韓国がIT立国になった「もう1つの理由」

    「またか」。11月20日の朝刊を見て筆者は思わずつぶやいてしまった。また振り込め詐欺である。 静岡市駿河区の66歳の女性が,長男を名乗る男に電話で金を振り込むよう指示され,わずか1週間で1795万円もの大金を詐取されてしまった。一人暮らしをしているその女性は,東京都内に住んでいる長男のことがよほど心配だったのだろう,犯人に指定された6口座に12回にわたって合計1795万円を振り込んだのである。 振り込め詐欺事件では,他人名義の預金口座を悪用するケースが後を絶たない。国は口座の不正利用を防止するため,2004年12月に預貯金通帳の譲渡や売買に罰則規定を設ける法改正を実施した。しかし,どれだけ効果があっただろうか。 2004年に振り込め詐欺の認知件数は2万5667件,被害総額283億7866万円だった。2005年は同2万1612件,251億円5186万円とやや減少したものの,2006年は9月末

    韓国がIT立国になった「もう1つの理由」
  • 高木浩光@自宅の日記 - 暗黙的に形成する事実標準の話と回避策の話を混同してはいけない

    ■ 暗黙的に形成する事実標準の話と回避策の話を混同してはいけない 「ぼくはまちちゃん」 ――知られざるCSRF攻撃, 上野宣, @IT, 2005月4月27日初版、2006年11月8日修正版 ●リファラーで発信元をチェック HTTPリクエストを受けたとき、そのリクエストがどこのWebページから発行されたものかを示すリファラー(REFERER)と呼ばれる情報を得ることができる。この情報を活用し、来意図したWebページ以外からのリクエストを拒否することで、CSRFによる外部からのリクエストを防ぐことができる。 ただし、ユーザーがリファラー情報を出力しないブラウザを使っている場合、このチェックを導入すると正当な操作でも受け付けなくなってしまう。 懸念されるリファラー情報偽装に対する問題だが、以前はリファラー情報を発行するのは攻撃を踏んでしまった自分自身なので、リファラー情報を偽装する動機がなく

  • 情報処理推進機構:情報セキュリティ:脆弱性対策:安全なウェブサイトの作り方

    「安全なウェブサイトの作り方」は、IPAが届出(*1)を受けた脆弱性関連情報を基に、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、ウェブサイト開発者や運営者が適切なセキュリティを考慮したウェブサイトを作成するための資料です。 「安全なウェブサイトの作り方」改訂第7版の内容 第1章では、「ウェブアプリケーションのセキュリティ実装」として、SQLインジェクション 、OSコマンド・インジェクション やクロスサイト・スクリプティング 等11種類の脆弱性を取り上げ、それぞれの脆弱性で発生しうる脅威や特に注意が必要なウェブサイトの特徴等を解説し、脆弱性の原因そのものをなくす根的な解決策、攻撃による影響の低減を期待できる対策を示しています。 第2章では、「ウェブサイトの安全性向上のための取り組み」として、ウェブサーバの運用に関する対策やウェブサイトにおけるパスワードの取扱いに関す

    情報処理推進機構:情報セキュリティ:脆弱性対策:安全なウェブサイトの作り方
  • 高木浩光@自宅の日記 - ログアウトし忘れのブラウザをそうと知りつつ操作するのは不正アクセス行為に該当するか

    ■ ログアウトし忘れのブラウザをそうと知りつつ操作するのは不正アクセス行為に該当するか やじうまWatchによると、mixiにログインしたまま放置されていた店頭のPCを操作してプロフィールを「改ざん」した(当人曰く)という人がいて、それを著名サイトで公言していることが注目を浴びているという。いくつか反応を見てまわったところ、不正アクセス禁止法違反ではないかという議論*1があり、その中に、「パスワードを入力したわけではないから、不正アクセス行為にあたらない」などという主張をみかけた。 興味深い話題なのでちょっと検討してみる。なお、ここでは、技術的側面から行為の外形が不正アクセス禁止法3条の構成要件を満たしているかだけを検討するものであり、刑罰に値する違法性があるか否かについては検討しない。 まず、不正アクセス禁止法3条2項各号の「入力して」とは、手元のコンピュータにキーボードで入力することを

  • 高木浩光@自宅の日記 - Winnyの可視化と無断リンク禁止厨の共通関係に見る問題の本質

    ■ Winnyの可視化と無断リンク禁止厨の共通関係に見る問題の質 YouTubeでキャンディーズの映像の一つを視聴して衝撃を受けた*1。当時の私は小学3年から5年生。物心つく直前だった。みんなで春一番を歌いながら下校した記憶くらいしかない。中高校生になってから「懐かし映像」としてテレビで見たときには古臭いオバさんたちにしか見えなかった。それが今になって見たこの映像は新鮮だった。今風の言葉でいえばようするにエロい。同じ曲を3種類の衣装で歌った姿を編集で合成した映像だが、これは市販されているのだろうか。近い将来にまた見たくなりそうだが、そのときにはもう見つからないかもしれない。これは購入しておきたいと、amazonを探してみたが売られていないようだ。 Winnyネットワークが消滅するべき理由 4月19日の朝日新聞朝刊13面の記事に対して、次のような反応があった。 Winnyの朝日新聞記事,

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

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

  • 開発者のための正しいCSRF対策

    著者: 金床 <anvil@jumperz.net> http://www.jumperz.net/ ■はじめに ウェブアプリケーション開発者の立場から見たCSRF対策について、さまざまな情報が入り乱れている。筆者が2006年3月の時点において国内のウェブサ イトやコンピュータ書籍・雑誌などでCSRF対策について書かれている記事を調べた結果、おどろくべきことに、そのほとんどが誤りを含んでいたり、現実的 には使用できない方法を紹介したりしていた。そこで稿ではウェブアプリケーション開発者にとっての当に正しいCSRF対策についてまとめることとす る。また、採用すべきでないCSRF対策とその理由も合わせて紹介する。 ■あらゆる機能がターゲットとなりうる ウェブアプリケーションの持つ全ての機能がCSRF攻撃の対象となりうる。まずこのことを認識しておく必要がある。 Amaz

    potappo
    potappo 2006/03/31
    web2.0時代のセキュリティ。
  • 1