タグ

cookieとXSSに関するraimon49のブックマーク (7)

  • 実例に学ぶXSS脆弱性の発見と修正方法/line_dm 16 20160916 how to find and fix xss

    LINE Developer Meetup in Fukuoka #16 http://connpass.com/event/38413/

    実例に学ぶXSS脆弱性の発見と修正方法/line_dm 16 20160916 how to find and fix xss
    raimon49
    raimon49 2016/10/02
    安全とレビュー完了した箇所にsafeコメント入れて行くのか。なるほど。
  • twitterに学ぶなりすまし投稿対策

    先日もtwitter上の犯行予告により20歳の青年が逮捕されたようですが、なりすましによる誤認逮捕ではなかったのか気になるところです。そこで、twitterが、なりすまし投稿をどの程度対策しているかを調べてみることにしました。twitterの安全性を確認することが目的というよりも、twitterが実施している対策を知ることにより、皆様のWebサイトを安全にする参考にしていただければと思います。 今回調べた「なりすまし投稿」の手法は下記の通りです。 クロスサイト・リクエスト・フォージェリ(CSRF) クロスサイトスクリプティング(XSS) HTTPヘッダーインジェクション クリックジャッキング DNSリバインディング クッキーモンスターバグ このうち、上の5つの解説は拙稿「“誤認逮捕”を防ぐWebセキュリティ強化術」、最後のクッキーモンスターバグについては、過去のエントリ「クッキーモンスター

    twitterに学ぶなりすまし投稿対策
    raimon49
    raimon49 2013/04/01
    Twtter webも一日にして成らず、だね。
  • クライアントサイドの巨大なクッキーとサーバーサイドのヘッダーサイズ制限の組み合わせによるDoSについて - デー

    もう10年以上前のネタなのですが、いまだに有効だし、最近、セッションを扱っていないならXSSがあってもあまり問題ないという意見を見ることがあるので、サービス提供側として案外面倒なことになる場合がある、という話を書きました。 POCです。 http://www.udp.jp/misc/largecookiedos.html 内容としては、 JavaScriptから巨大なCookieをブラウザに設定できる HTTPサーバーは受け取れるHTTPヘッダーサイズの上限を持っていて、それを超えていた場合にBad Requestを返す 1によって2を超えるサイズのCookieが設定可能な場合がある(たぶんほとんどの場合可能) よってXSSなどによって巨大なCookieを設定されると以降サービスが利用できなくなる というものです。 Cookieの有効期限を何十年も設定されるとユーザー側で勝手に回復すること

    クライアントサイドの巨大なクッキーとサーバーサイドのヘッダーサイズ制限の組み合わせによるDoSについて - デー
    raimon49
    raimon49 2012/04/18
    巨大なサイズのcookieを送りつけてサービス不能に
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
    raimon49
    raimon49 2012/04/05
    location.hashそのまま使わない、$()関数が汎用的過ぎるので素直にパラメータ渡さない、XHRのリクエスト先には必ず 絶対パス + 動的部分、関数の粒度を細かく、パスワード入力させるドメインをサブドメイン化
  • 間違いだらけの「かんたんログイン」実装法

    今回は、そのかんたんログインの問題点について説明します。 「契約者固有ID」を用いるかんたんログイン かんたんログインとは、携帯電話の「契約者固有ID」を用いたログイン手法です。 第1回で説明したように、携帯電話のブラウザのリクエストヘッダには契約者固有IDと呼ばれるIDを付けることができます。契約者固有IDは、携帯電話事業者によって詳細は異なりますが、すべての携帯電話事業者が対応しています。 図1は、NTTドコモの携帯電話がサポートしている契約者固有IDである「iモードID」がサーバに送信される様子です。この情報は、ユーザーがそれと意識することなく送信されます。携帯電話のかんたんログインとは、契約者固有IDのみを用いて認証を行い、ログイン機能を実現することです。 かんたんログインは、ベーシック認証のようにIDとパスワードを管理する必要もなく、Cookieのように対応する端末を考慮する手間

    間違いだらけの「かんたんログイン」実装法
  • Tender Surrender » Caja

    OpenSocial周りの調査をしていると、Cajaという言葉に遭遇します。セキュアなJavaScriptを実現するもの、ということだけ分かっていたのですが、詳細を調べてみました。 クロスサイトスクリプティングとブログパーツ gooやlivedoor、fc2などのホスティングを含めたブログサービスを使ったことのある方はご存知と思いますが、サービスによってブログパーツが貼れるもの、貼れないもの、一部だけ許可しているものがあります。なぜでしょうか? Cookieには同一ドメインから実行されたスクリプトしか参照できないという特徴があります。これを利用して、Cookieをセッション情報や閲覧履歴の保存場所として活用しているサービスは少なくありません。上記ブログサービスがブログパーツを許可しないのは、これらの情報を悪意のあるJavaScriptから守るためです。逆に言うと、同一ドメイン上でJavaS

  • CSRF と Cookie 漏洩は関係ない | 水無月ばけらのえび日記

    そしてcookieを奪うのがどれほど簡単かというのは、CSRFの事例が後をたたないことからも伺い知ることができる。 うーむ、CSRFの理解って結構浸透してきたと思っていたのですが、そうでもないようで……。 CSRF は Cookie を奪取してセッションハイジャックするような攻撃ではなく、攻撃者は Cookie の値を知る必要がありません。また、CSRF 攻撃によって攻撃者が Cookie を奪取することもできません。もちろん、別途 XSS があったりすれば Cookie を奪取できる余地がありますが、それは XSS による漏洩ということになるでしょう。 それから、User-Agent の一致チェックは対策としては不十分です。というのも、CSRF では原理上 User-Agent が一致するに決まっていますし、Cookie 奪取を想定するなら、攻撃者が User-Agent を一致させるこ

  • 1