ブックマーク / blog.tokumaru.org (5)

  • 決済代行を使っていてもクレジットカード情報が漏洩するフォーム改ざんに注意

    先日以下の記事が公開されました。決済代行会社を使っていたのにカード情報が漏洩したというものです。 同社は、薬局への医薬品の卸売りのほか、運営するショッピングサイト「eキレイネット」でコラーゲンやヒアルロン酸などの美容関連製品を販売している。流出した疑いがあるのは、平成26年10月8日~27年11月5日、サイトでカードを使って商品を購入した顧客の氏名や住所、クレジットカードなどの情報だった。この間、1955人が利用していた。 名の売れた大企業ではない。従業員わずか10人の小さな会社がサイバー攻撃の標的になったのだ。 問題が発覚したのは昨年11月。決済代行会社からカード情報が流出した疑いがあると指摘があった。 従業員10人なのに「標的」に サイバー攻撃、中小企業が狙われる理由より引用 これに対して、以下のブックマークコメントがつきました。 そもそも、決済代行会社を使っているのになぜカード情報が

    szks
    szks 2016/05/01
    フォームが改竄できるような脆弱性が何に由来するものなのかが不思議。
  • 書籍『Webアプリケーションセキュリティ対策入門』のCSRF脆弱性 | 徳丸浩の日記

    図のように、大垣のCSRF対策方式(以下、「大垣方式」と表記)では、トークン(同書ではフォームIDと表記)をランダムな鍵として生成(②)し、それをフォームの隠しフィールドとDBに保存します(③、④)。ユーザーがフォームをサブミット(⑤)すると、送信されてきたトークンがDB上に存在するか確認(⑥)し、あればトークンを削除(⑦)して、サーバー上の処理に進みます。⑥でトークンがDBにない場合は、エラーとして処理には進みません。 一般的なCSRF対策手法との違い 大垣方式が一般的なCSRF対策と異なる点は以下の2点です。 フォームの2重投稿防止機能を兼ねている トークンがセッション変数ではなくDBに保存される トークンの有効範囲は? トークンがDBに保存される場合、トークンの有効範囲が気になるところです。大垣および第二版のソースを見ると、トークンを保存するテーブルの定義は以下の通りです。 CR

    szks
    szks 2015/06/30
    「トークンがセッションを越えて共有されてると攻撃者が取得したトークン使ってCSRFできる」という当たり前のことを「誰にでも」わかるよう親切丁寧に解説した記事.
  • SQLインジェクション対策もれの責任を開発会社に問う判決

    ポイントは下記の通りです。 X社(原告)はセキュリティ対策について特に指示はしていなかった 損害賠償について個別契約に定める契約金額の範囲内とする損害賠償責任制限があった 当初システムはカード決済を外部委託し直接カード情報を扱っていなかった X社が「カード会社毎の決済金額を知りたい」とY社に依頼をして、その結果カード情報をいったんDBに保存する仕様となった(2010年1月29日) X社からの問い合わせに対してY社は、カード情報を保持しない方式に変更することが可能で、そのほうが安全となり、費用は20万円程度である旨を伝えた(2010年9月27日)が、その後X社は改良の指示をしなかった 以下の脆弱性その他が認められた システム管理機能のIDとパスワードが admin/password であった 個人情報が記載されたお問い合わせログファイルの閲覧が可能(ディレクトリリスティングと意図しないファイ

    szks
    szks 2015/01/22
    http://d.hatena.ne.jp/redips+law/20141026/1414327403 に続いてまた脆弱性について開発会社の責任を重く見る判例……と思ったら同じ裁判だった。
  • リセット後のパスワードをメール送信するパスワードリセット方式の注意点

    先日のエントリパスワードリマインダが駄目な理由にて、現在のパスワードをメール送信する「パスワードリマインダ」がパスワードリセット方式に比べてリスクがある(リスクのコントロールが弱い)という説明をしました。その際に説明したパスワードリセット方式は、パスワード変更の画面URLをメール送信するというものでしたが、もう一つのパスワードリセット方式としては、サイト側でパスワードをリセットして、リセット後のパスワードをメール送信するという方式もあります。このエントリでは、後者の仕様上の注意点について説明します。 とあるサイトのパスワードリセット方式 あるサイトのパスワードリセットの仕様を確認したところ下記の通りでした。 パスワードリセット画面では、ユーザIDとメールアドレスを入力する ユーザIDとメールアドレスが共に該当するアカウントがないとエラーになる サイト側でパスワードがリセットされ、リセット後

    リセット後のパスワードをメール送信するパスワードリセット方式の注意点
    szks
    szks 2013/05/16
    メールで送るのがパスワード再設定画面にしても仮パスワードにしても、パスワードリセットを実行したブラウザのセッションと紐付けておけばメール盗聴のリスクは無視できるのでは.
  • パスワードリマインダが駄目な理由

    昨日、某著名サイトのパスワードリマインダの方式が変更になっていることに気がつきました。 旧: 現在のパスワードをメールで送信する(パスワードリマインダ) 新: パスワード再設定の画面のURLをメールで送信する(パスワードリセット) 新しい方式(パスワードリセット)の方が優れていますが、それでは何故パスワードリマインダは駄目で、パスワードリセットの方がよいのでしょうか。このエントリではその理由について説明します。 パスワードリマインダのリスク 良く指摘されるように、パスワードリマインダの場合、2つの問題があります。 現在のパスワードをメール送信できるということは、パスワードをハッシュ値で保存していない証拠である メールは平文通信なので、パスワードを書いたメールが盗聴されると被害が甚大になる これらのうち、パスワードの保存方法については別稿にゆずるとして、このエントリでは盗聴のリスクについて検

    szks
    szks 2013/05/10
    10年前にどっかでパスワードリマインダって危ないよねって話をしたら全く賛同が得られなかった。DBからパスワードが漏れるとかメールが盗聴されるとかって心配したらサービスなんかできない、というのが理由
  • 1