タグ

webとsecurityに関するwkbyshnbtkのブックマーク (15)

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

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

    情報処理推進機構:情報セキュリティ:脆弱性対策:安全なウェブサイトの作り方
  • Togetter - まとめ IPAの「安全なウェブサイトの作り方 改訂第4版」におけるCSRF対策の「擬似乱数の生成」について高木先生に聞いてみた

    (・∀・)キムティ♪@荒浪一城 @kimtea @HiromitsuTakagi IPAの安全なウェブサイトの作り方 改訂第4版を参照していますが、CSRF対策において、「生成するIDは安全な擬似乱数を用いて、第三者に予測困難なように生成する必要があります。」とありますが、この擬似乱数の生成はどのように生成すべきでしょうか? 2010-06-28 02:44:22

    Togetter - まとめ IPAの「安全なウェブサイトの作り方 改訂第4版」におけるCSRF対策の「擬似乱数の生成」について高木先生に聞いてみた
  • WEBプログラマー必見!WEB脆弱性基礎知識最速マスター - 燈明日記

    以下は、WEBプログラマー用のWEB脆弱性の基礎知識の一覧です。 WEBプログラマーの人はこれを読めばWEB脆弱性の基礎をマスターしてWEBプログラムを書くことができるようになっているかもです。 また、WEB脆弱性の簡易リファレンスとしても少し利用できるかもしれません。 WEBアプリケーションを開発するには、開発要件書やプログラム仕様書通りに開発すれば良いというわけにはいきません。 そう、WEB脆弱性を狙う悪意のユーザにも対処しないといけないのです。 今回、WEBアプリケーションを開発にあたってのWEB脆弱性を、以下の一覧にまとめてみました。 このまとめがWEBアプリケーション開発の参考になれば幸いです。 インジェクション クロスサイト・スクリプティング セッション・ハイジャック アクセス制御や認可制御の欠落 ディレクトリ・トラバーサル(Directory Traversal) CSRF(

    WEBプログラマー必見!WEB脆弱性基礎知識最速マスター - 燈明日記
  • CSRFの評価とCVSS現状値 | 水無月ばけらのえび日記

    公開: 2009年12月19日14時10分頃 Amebaスタッフブログに「Amebaのセキュリティ対策について (ameblo.jp)」という文章が出ていますね。 弊社では新規サービスの開発時はリリース前に、既存サービスは定期的に、外部セキュリティ監査会社による調査を必ず実施しております。 調査報告は深刻度別に分類され、これまでユーザーの皆様のデータ漏洩や破壊につながる可能性がある部分については即時の対応を、それ以外の部分については一定期間内での対応実施を徹底して参りました。 現在、昨今の事情を鑑み、影響の大きな部分については優先度を最上級にし、緊急対応を行っております。 はっきりとは書かれていませんが、AmebaなうのCSRFの問題の話であるように思えます。たぶんこういうことですね。 セキュリティ監査会社による調査を実施している。報告された脆弱性は深刻度によって分類し、即時対応するもの、

  • CSRF対策は基本? | 水無月ばけらのえび日記

    コミュニティーサイト構築に詳しい専門家は、「CSRF対策は基的なところ。Amebaなうが対策していなかったのは意外だ」と話している。 「CSRF対策は基的なところ」と言われると、発見も対処も容易であるような印象を受けますが、これは少し違和感がありますね。 半年ほど前の話ですが、弊社 (www.b-architects.com)のクライアントが新規のECサイトを立ち上げるにあたって脆弱性診断をしようという話になり、外部の会社に見積もり依頼をしたことがあります。その際、業界では知らない人がいないような大手会社の診断メニューも見せていただきました。 そこで印象的だったのは、標準とされるプランにCSRFの診断が含まれていなかったことです。標準のコースにはXSSやSQLインジェクションの診断が含まれますが、CSRFは「アドバンスド」プランの方にしか含まれていませんでした。普通のサイトではXSSや

  • 知らなかったらNGなWEBアプリケーション脆弱性一覧 : mwSoft blog

    先日、AmebaなうがCSRFという非常にポピュラーな脆弱性を披露したかと思ったら、ここ数日はセブンネットショッピングでXSSの脆弱性と、ID推測による他ユーザの個人情報閲覧の問題が発生しているという噂が流れています。 ユーザの情報を預かっておきながら、基的なセキュリティの対策もできていないというのは、銀行に例えるなら、お金を預けようとした時に「お金は預かります。ちゃんと保管します。でも警備はあまりしないので盗まれたらスイマセン」と言われるようなものだと思う。 警備に穴があったというのではなく、まともに警備してませんでした、というのはさすがにありえないことです。 そこで、野良WEBプログラマである私が知っている脆弱性を列挙してみた。 私はプログラマであってセキュリティの専門家ではないです。しかも今年の春辺りからずっと外向けのWEBプログラムは組んでません。 その人間が知っているものを並べ

  • スラッシュドット ジャパン | 正しいCSRF対策、してますか?

    あるAnonymous Coward曰く、"最近WebアプリのCSRF脆弱性への対策が注目されていますが、30日に金床氏が「開発者のための正しいCSRF対策」という秀逸なテキストを発表してくれました。 Googleで「CSRF 対策」で検索すると高木浩光氏の「クロスサイトリクエストフォージェリ(CSRF)の正しい対策方法」がトップに出てきますが、金床氏によると、この方法は誤った対策であり「CSSXSS脆弱性が知られている現在では、絶対に実施すべきでないもの」とのことです。この対策は、IPAの「情報セキュリティ白書2006年版」や「用語「CSRF」@鳩丸ぐろっさり (用語集)」ほか書籍などにも書かれており、金床氏は「記事の内容を訂正していただきたい」としています。スラドの開発者のみなさんはきちんと正しいCSRF対策をしていますか?"

  • 高木浩光@自宅の日記 - 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

  • 主要ブラウザすべてに影響する「クリックジャッキング」攻撃とは

    Windows SQL Server 2005サポート終了の4月12日が迫る、報告済み脆弱性の深刻度も高く、早急な移行を

  • ヤフーがyimg.jpを使う本当のワケ - 最速配信研究会(@yamaz)

    ヤフーの画像はなぜyimg.jpドメインなのか? サイト高速化の手法とヤフーの失敗例 でヤフーがなぜドメインを変えて画像サーバを運用しているかが書かれている.「静的なコンテンツに対してクッキーフリードメインを使うことによって速度向上を狙う」というのが理由とあって,これはこれでもちろん正しいのだけれど,これはどちらかというと副次的な理由で当の理由は違う. クッキーフリードメインを使うことで悪意あるFlashコンテンツなどから自社ドメインのクッキーを守るためというのが当の理由で,これはあちこちで使われているテクニックだ.Flashコンテンツは外部の業者さんに作ってもらったり,広告の入稿素材として入ってくるので,信頼できないデータとして取り扱う必要があり,万一まずいデータがアップされることがあっても大丈夫にしておく必要がある. 最近ユーザからの任意のコンテンツを受けつけて同一ドメインで配信し

    ヤフーがyimg.jpを使う本当のワケ - 最速配信研究会(@yamaz)
    wkbyshnbtk
    wkbyshnbtk 2009/01/15
    本当の理由:自社ドメインのクッキーを守るため
  • ついに "マッシュアップ・ウイルス”が登場

    11月16日,これまで平和な時代を謳歌(おうか)してきたと言えるWeb 2.0の世界に,衝撃的なニュースが走りました。Web2.0が浸透,定着してきたことを“裏側”から示す出来事として,コーナーで取り上げないわけにはいきません。まずはこちらの記事をご覧ください。 ■「ウイルス作者の新手口,Googleマップで感染マシンの場所を突き止める」 “散弾銃”のように進化したウイルスによる攻撃 マルウエア(Malware)とは,「malicious(悪意ある)」から派生した造語です。いわゆるコンピュータ・ウイルスやスパイウエア,またスパム・メールに仕込まれたフィッシング詐欺のURLなど,多くはネット経由で送りつけられる,悪意あるプログラムやコンテンツの総称です。上記記事によれば,感染の成功率を上げる手口が次の要素(アイデア)を備えて高度化していることがわかります。 1.自ら散弾銃(Wikipedi

    ついに "マッシュアップ・ウイルス”が登場
  • AjaxとPHPを使ったワンタイムパスワード方式のログイン認証:phpspot開発日誌

    JamesDam.com ? AJAX Login System Demo This is an example of a login system that does not require page refreshes, but is still very secure. Ajax+PHPでの画面遷移なしのログイン画面作成サンプルが公開されています。 フォームに、user1, pass1 を入力すると即時認証が行われ、次のようにログイン状態になります。 認証には、Ajaxを使ったワンタイムパスワード方式が使われます。 具体的には、Ajaxでサーバからチャレンジコードを取得し、チャレンジコードとパスワードをmd5でハッシュして、更にその値をサーバに送信し、認証を取ります。 このため、従来の方式よりは安全な認証が可能となります。 Ajaxが出てきたことで、ブラウザを開いたままの状態でインタ

  • http://japan.internet.com/webtech/20061012/1.html

  • 「Web 2.0」導入が進む中、後回しにされるセキュリティ - CNET Japan

    「Web 2.0」は、ウェブサイトで実現できることの限界を拡張する新技術として、導入が急速に進んでいる。しかし、機能を追加しようと急ぐあまり、セキュリティが後回しにされていると、専門家は指摘する。 Web 2.0の流行には、高額な参加費のカンファレンス、大量に生まれる新興企業、革新的な企業(「MySpace」を保有していたIntermix Mediaや「Writely」を開発したUpstartleなど)の巨額買収といった特徴から、1990年のインターネットブームを思い起こさせるところがある。そして、また別の面でこうした既視感をいっそう強く抱いている専門家たちもいる。デスクトップソフトウェアが登場して間もない頃と同じように、開発の推進力となっているのはすべて機能に関することで、セキュリティの確保はおろそかにされていると、専門家たちは話す。 ウェブセキュリティ企業のSPI Dynamicsでリ

    「Web 2.0」導入が進む中、後回しにされるセキュリティ - CNET Japan
  • 1