タグ

xssに関するpenaltyのブックマーク (8)

  • Masato Kinugawa Security Blog: たぶんXSSが理由でインターネットがとまった

    昔自分が利用者だったサイトのセキュリティ問題(XSS)をいくつか報告していたのですが、おそらくそのリクエストを理由にインターネットが使えなくなりました。プロバイダに接続を止められたのです。 そのサイトで問題をみつけたとき、サービス提供者側の反応を示す兆候がありました。 問題を発見後、しばらくしてアクセスしようとすると、アクセスを拒否されたからです。 サービス提供者には問題を報告し、アクセス拒否についても、一応、今報告してる通りこれは攻撃ではないので誤解なきようよろしくとメール連絡したところ、問題は修正されました。 これで真意は伝わり、アクセスと関連付けられ、アクセス拒否に対する誤解も解決しただろうと思ったのですが、その後急にインターネットが使えない事態にまでなるとはだれが予想できたでしょうか…。(今は携帯の回線を使っています) プロバイダから書面が届き、書面には問題の報告時とほぼ同じ日付に

    penalty
    penalty 2013/09/11
    ブラック企業8傑にも選ばれたあの会社か
  • [デブサミ2012]趣味と実益の脆弱性発見

    神戸ITフェスティバル講演 http://kobe-it-fes.org/kif2014/seminar/entry-197.html

    [デブサミ2012]趣味と実益の脆弱性発見
  • Twitterの脆弱性3連発 - ma<s>atokinugawa's blog

    最近僕が発見し、修正されたTwitterの脆弱性を3つ紹介します。 1.旧Twitterの文字列処理に絡んだXSS 去年の夏くらいに、Twitter Web上で &#x80; 〜 &#xFF; の文字参照が含まれるツイートをXMLHttpRequestで読み込んだ際に表示が乱れるという問題に気付き*1、その時はこれは脆弱性には繋がらないだろうという判断をしたのだけど、今年の4月になって改めて調べたところ貫通しました。 表示が乱れるというのは、&#x80; 〜 &#xFF; の文字参照が含まれるツイートがあると、一部の文字が\XXXXの形式に化けたり、ツイート周辺の「"」が「\"」になったりするものだったのですが、今回は「"」が「\"」になる点が脆弱性を発生させていました。 この条件でXSSさせようと思ったら、ツイートを細工してURLや@や#などオートリンクが作成される部分にうまいことイベン

    Twitterの脆弱性3連発 - ma<s>atokinugawa's blog
  • perl - EncodeでXSSを防ぐ : 404 Blog Not Found

    2009年03月03日19:00 カテゴリLightweight Languages perl - EncodeでXSSを防ぐ 良記事。 第7回■文字エンコーディングが生み出すぜい弱性を知る:ITpro だけど、問題点のみ具体例があって、対策にないのが片手落ちに感じられたので、その点を補足。 結論だけ言ってしまえば、Perlなら以下の原則を守るだけです。 404 Blog Not Found:perl - Encode 入門 すでにOSCONでもYAPCでも、あちこちそちこちでこの基方針に関しては話したのですが、ここ 404 Blog Not Found でも改めて。 Perl で utf8 化けしたときにどうしたらいいか - TokuLog 改め だまってコードを書けよハゲ入り口で decode して、内部ではすべて flagged utf8 で扱い、出口で encode する。これが

    perl - EncodeでXSSを防ぐ : 404 Blog Not Found
    penalty
    penalty 2009/04/08
    perlのEncodeはマップに存在しないコードは全て、U+FFFD(REPLACEMENT CHARACTER )に割り当てられる。
  • 第7回■文字エンコーディングが生み出すぜい弱性を知る

    文字コードに関する問題は大別すると文字集合の問題と文字エンコーディングの問題に分類できる。前回は文字集合の取り扱いに起因するぜい弱性について説明したので、今回は文字エンコーディングに起因するぜい弱性について説明しよう。 文字エンコーディングに依存する問題をさらに分類すると2種類ある。(1)文字エンコーディングとして不正なデータを用いると攻撃が成立してしまう点と,(2)文字エンコーディングの処理が不十分なためにぜい弱性が生じることがある点だ。 不正な文字エンコーディング(1)――冗長なUTF-8符号化問題 まず,(1)の不正な文字エンコーディングの代表として,冗長なUTF-8符号化問題から説明しよう。前々回に解説したUTF-8のビット・パターン(表1に再掲)を見ると,コード・ポイントの範囲ごとにビット・パターンが割り当てられているが,ビット・パターン上は,より多くのバイト数を使っても同じコー

    第7回■文字エンコーディングが生み出すぜい弱性を知る
    penalty
    penalty 2009/04/08
  • 被はてなブックマーク画像表示ページにXSS攻撃してみる。 - ぎじゅっやさん

  • それ Unicode で

    UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。

  • XSS - 表示系パラメータに存在する盲点 :: ぼくはまちちゃん!

    こんにちはこんにちは!! クロスサイトスクリプティングの時間です! XSSというと…! まっさきに思いつくのが、入力データ送信 → 確認表示の部分での無害化漏れですよね! たとえばこんな感じのフォームから受け取ったパラメータを、 確認として表示するページとか! (入力) <form action="register.cgi" method="post"> タイトル:<input type="text" name="title"> ← 「ぼくはまちちゃん!」を入力 文:<input type="text" name="body"> ← 「こんにちはこんにちは!!<script>alert(1)</script>」を入力 </form> (確認) <p>この内容で登録していい?</p> <p> タイトル: ぼくはまちちゃん!<br> 文: こんにちはこんにちは!!<script>alert

  • 1