はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記
2011-01-06: IE8ということを追記 & ちょっと間違いを修正。あけましておめでとうございます。 年明け早々ですが、Internet Explorerの話題です。IEはご存じの通り、Content-Type だけでなくコンテンツの内容なども sniff することでファイルタイプを決定しているため、画像ファイルやテキストファイルをHTMLと判定してしまい、クロスサイトスクリプティングが発生することが昔からたびたび報告されていました*1。現在は幾分マシになったとはいえ、IEのファイルタイプの判定アルゴリズムは非常に難解であり、現在でも状況によってはWebサイト運営者のまったく意図していないかたちでのXSSが発生する可能性があったりします。そういうわけで、IEがコンテンツを sniff してHTML以外のものをHTML扱いしてしまうことを防ぐために、動的にコンテンツを生成している場合に
XSS対策:JavaScriptのエスケープ(その2) - ockeghem's blog
5/11の日記XSS対策:JavaScriptなどのエスケープ - ockeghem(徳丸浩)の日記に対する金床さんのコメントに触発されて、JavaScriptのエスケープについて検討してみよう。ただし、現実のアプリケーション開発においては、私はJavaScriptの動的生成を推奨していないが、これはエスケープ処理をどのように考えるかと言うレッスンのつもりで検討することにする。 金床さんのコメントで紹介されたリンクには、以下のようなガイドライン案が提案されている。 JavaScriptの文字列でのエスケープ手順としては、以下が今のところ正解っぽい感じです。 1. 「\」を「\\」に置換する 2. 「"」を「\"」に置換する 3. 「'」を「\'」に置換する 4. 「/」を「\/」に置換する 5. 「<」を「\x3c」に置換する 6. 「>」を「\x3e」に置換する 7. 「0x0D（CR)
文字コードのセキュリティ問題はどう対策すべきか: U+00A5を用いたXSSの可能性 - 徳丸浩の日記(2009-03-11)
_U+00A5を用いたXSSの可能性 前回の日記では、昨年のBlack Hat Japanにおける長谷川陽介氏の講演に「趣味と実益の文字コード攻撃(講演資料)」に刺激される形で、Unicodeの円記号U+00A5によるSQLインジェクションの可能性について指摘した。 はせがわ氏の元資料ではパストラバーサルの可能性を指摘しておられるので、残る脆弱性パターンとしてクロスサイト・スクリプティング(XSS)の可能性があるかどうかがずっと気になっていた。独自の調査により、XSS攻撃の起点となる「<」や「"」、「'」などについて「多対一の変換」がされる文字を探してきたが、現実的なWebアプリケーションで出現しそうな組み合わせは見つけられていない。 一方、U+00A5が処理系によっては0x5C「\」に変換されることに起因してXSSが発生する可能性はある。JavaScriptがからむ場合がそれだ。しかし、
2007年のクロスサイトスクリプティングを振り返って - 葉っぱ日記
最近あちこちで「日記書くのサボってるよね」とか言われたので、サボってるわけじゃなくって書くネタがないだけだけど、無理やり2007年のXSSを振り返ってみるというネタで書いてみます。以下、著名サイトで見つけたXSSです。 産業技術総合研究所のXSS 404応答のページにてcharsetの指定がないため、UTF-7を利用したXSSが可能でした。ただし、ページ中に日本語を含むため、CVE-2007-1114を利用しIE7にてUTF-7で書かれたiframeを経由した場合のみXSS可能でした。ですので、実際の脅威にはつながりにくいと思います。届出:2007年4月11日、修正完了:2007年6月5日 sourceforge.jpにおけるXSS cvs.sourceforge.jpにおける404応答のページにてcharsetの指定がないため、UTF-7によるXSSが可能でした。ログインした状態ではセッ
第11回 スクリプトインジェクションを防ぐ10のTips | gihyo.jp
前回はスクリプトインジェクションがなくならない理由を紹介しました。それをふまえて今回はスクリプトインジェクションを防ぐ10のTipsを紹介します。 デフォルト文字エンコーディングを指定 php.iniには、PHPが生成した出力の文字エンコーディングをHTTPヘッダで指定するdefault_charsetオプションがあります。文字エンコーディングは必ずHTTPヘッダレベルで指定しなければなりません。しかし、デフォルト設定ではdefault_charsetが空の状態で、アプリケーションで設定しなければ、HTTPヘッダでは文字エンコーディングが指定されない状態になります。 HTTPヘッダで文字エンコーディングを指定しない場合、スクリプトインジェクションに脆弱になる場合あるので、default_charsetには“UTF-8”を指定することをお勧めします。サイトによってはSJIS、EUC-JP
クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記
昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなダイアリーのヘルプ - はてなダイアリーXSS対策