はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
XSSとセキュリティリスクと正しい脆弱性報告のあり方 - 最速転職研究会
適当 XSSがある=なんでもやり放題ではない ブログサービスなど自由にHTMLをかけるようなサービスでは、害が及ばないように表示を丸ごと別のドメインに分けていたり、あるいは別ドメインのIFRAME内で実行したりしているのが普通です。個人情報を預かってるサイトは、重要個人情報についてはHTTPSじゃないと参照できなかったり、そもそも表示しなかったり(パスワードやカード番号等)、決済用のパスワードや暗証番号を入れないと操作できなかったりする。 参考までに http://blog.bulknews.net/mt/archives/001274.html (2004年のアメブロ脆弱性の話) http://d.hatena.ne.jp/yamaz/20090114 (信頼できないデータを取り扱うドメインを分ける話) 管理用と別ドメインに分けたにも関わらず、script実行できることに対してDISられ
ツッコミ hideden (2009-08-06 12:45) - 徳丸浩の日記 - i-mode2.0セキュリティの検討 - 携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性
SQLインジェクション対策はおすみですか? 開発開始時点からのコンサルティングから、公開済みWebサイトの脆弱性検査、 脆弱性発見後の適切な対策まで ●携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性 このエントリでは、携帯電話のブラウザに搭載されたJavaScriptと、WebサイトのXSSの組み合わせにより、いわゆる「かんたんログイン」に対する不正ログインの可能性について検討する。 5月28にはてなダイアリーに書いた日記「i-mode2.0は前途多難」にて、今年のNTTドコモの夏モデルP-07AにてJavaScript機能が利用停止されたことを指摘した。同日付のNTTドコモ社のリリースによると、「ソフトウェア更新に伴い、高度化した機能の一部をご利用いただけなくなっていますが、再びご利用いただけるよう速やかに対処いたします」とあったが、それ以
［柔軟すぎる］IEのCSS解釈で起こるXSS
［柔軟すぎる］IEのCSS解釈で起こるXSS：教科書に載らないWebアプリケーションセキュリティ（3）（1/3 ページ） XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます （編集部） なぜか奥深いIEのXSSの話 皆さんこんにちは、はせがわようすけです。 第1回「［これはひどい］IEの引用符の解釈」と第2回「［無視できない］IEのContent-Type無視」でInternet Explorer(IE)の独自の機能がクロスサイトスクリプティング（XSS：cross-site scripting）を引き起こす可能性があるということについて説明してきました。 第3回でも引き続き、IE特有の機能がXSSを引き起こす例ということで、
第3回 US-ASCIIによるクロスサイトスクリプティング | gihyo.jp
今回は、US-ASCIIによるクロスサイトスクリプティング(XSS)という話題について紹介します。 前回までで説明したUTF-7によるXSSと同様に、攻撃者はUS-ASCIIという文字コードを巧みに利用することで、IEを対象にXSSを発生させることができます。US-ASCIIによるXSSは、UTF-7によるXSSと類似点も多いため、前回までの説明も併せて読んでおくとよいでしょう。 US-ASCIIによるXSSについても先に対策を書いてしまうと、UTF-7のときと同様にHTTPレスポンスヘッダにて Content-Type: text/html; charset=UTF-8 Content-Type: text/html; charset=Shift_JIS Content-Type: text/html; charset=EUC-JP のいずれかを出力するという原則を守ることで、完全に攻撃
Twitter XSS 騒動 - Yaks
(2009/04/12 6：40 pm 追記しました) (2009/04/12 7：24 pm 再度追記しました) 先ほどから Twitter上にて XSS のよる被害が出ています。 既に海外のブログなどでも取り上げられています。 HOWTO: Remove StalkDaily.com Auto-Tweets From Your Infected Twitter Profile (Twittercsm) Warning: Twitter Hit By StalkDaily Worm (TechCrunch) 既に XSS の部分は改修されて大分収まったようですが、念のために書いておきます。 内容としては、 1. StalkDaily.com を宣伝するつぶやきが勝手に投稿される 2. プロフィールの Web が改ざんされる 3. 改ざんされたユーザーのページを見ると、自分のプロフィールも
CSSXSSを改良した？手法でmixiのpost_keyを抜き取るデモを作りました - ?D of K:
IDを抜き取る方法が思いつかなかったので、「はまちちゃん」の書き込みの二年来の再来とはいきませんが、セキュリティーホールだと思うので、早めに書いておきます。（修正済みです） 実証コード http://k75.s321.xrea.com/cssxss/mixi.html パッチ済みのIE6でmixiにログインしていた場合、post_keyの取得を確認できると思います。勘違いだったらすみません。その際、僕のmixiのあしあとに残るのでその点のみ注意してください。 手法 CSSの読み込み いわゆるCSSXSSと同じようにlinkを使って、ファイルを読み込みます。旧来の手法では中括弧があることでCSSと誤認識させ、cssTextで取得しましたが、今回は文中に「}selector{property:」という文字列を埋め込んで、selectorに該当する要素のcurrentStyle.property
printenv at xss-quiz.int21h.jp
printenv at xss-quiz.int21h.jp Your IP address: 133.242.243.6 () NameValue HTTP_ACCEPT*/* HTTP_CACHE_CONTROLno-cache HTTP_CONNECTIONclose HTTP_HOSTxss-quiz.int21h.jp HTTP_USER_AGENTHatenaBookmark/4.0 (Hatena::Bookmark; Analyzer) QUERY_STRING REMOTE_ADDR133.242.243.6 REQUEST_METHODGET REQUEST_SCHEMEhttp REQUEST_URI/
クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記
昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS
yohgaki's blog - いろいろ変わったXSSがありますが...
(Last Updated On: 2007年10月12日)私が知らなかっただけかもしれませんが、これにはかなり驚きました。いろんな所で問題が指摘されていますが、ECMAScriptにXML機能を追加したのはどうなんでしょうね…. 確かにかなり便利なのですが以下のコードでスクリプトが実行されることはほとんど知られていないでしょうね。 <script> 123[”+<_>ev</_>+<_>al</_>](”+<_>aler</_>+<_>t</_>+<_>(1)</_>); </script> 好むと好まざる関係なくFirefox 1.5から使えるのでWeb開発者は知っておかなればならないです。 日本語訳 http://www.ne.jp/asahi/nanto/moon/specs/ecma-357.html 原文 http://www.ecma-international.org/pu
第9回 クロスサイトスクリプティングの名称と種類 | gihyo.jp
前回はWeb開発に不慣れな開発者が行いがちな、不適切なクロスサイトスクリプティング対策を紹介しました。今回は適切な対策を理解するために必要な、クロスサイトスクリプティングの本質とクロスサイトスクリプティングの種類について解説します。 クロスサイトスクリプティングの名称 「クロスサイトスクリプティング」は、よくある攻撃方法を表した名前です。サイトをまたがって攻撃用のJavaScriptコード（スクリプト）を送るので、「クロスサイト」「スクリプティング」と命名したものと考えられます。 単語の頭文字を取ると「CSS」となりますが、カスケーディングスタイルシートの「CSS」と同じになり、区別できないので「XSS」と表記されるようになりました。クロスサイトスクリプティングの解説情報には「XSS」ではなく「CSS」と表記している場合もあります。 しかし残念ながらこの名前は直感的な名前とはいえません
第7回 いまさらながらクロスサイトスクリプティングの基礎の基礎 | gihyo.jp
今回はWebアプリケーションを作ったことがない方でも分かるようクロスサイトスクリプティング脆弱性を解説します。 クロスサイトスクリプティングとは？ 初めてクロスサイトスクリプティングと聞いて、どのような問題なのかすぐに理解できる人はいないと思います。サイトAに記述されたJavaScriptプログラムがサイトB上で実行されるために発生することが問題とされたので、「サイト間をまたがるスクリプトの実行」問題として、クロスサイトスクリプティング（XSS）と名前が付けられました。この命名では直感的に分かりづらい、サイト間にまたがらずHTMLメールなどにJavaScriptを挿入する攻撃でも同じ効果が得られることから、「JavaScriptインジェクション」とも呼ばれるようになっています。 図1 簡単なクロスサイトスクリプティング 例1 簡単な直接攻撃 掲示板サイトに投稿されたデータをエスケープ処
IE における "expression" の過剰検出による XSS の 誘因
IE における "expression" の過剰検出による XSS の 誘因 2006-08-31-1: [Security] http://archive.openmya.devnull.jp/2006.08/msg00369.html IE では expression(式) をスタイルシート内で記述することで JavaScript を記述することができるのは有名ですが， IE による expression の検出がやたら過剰で XSS を引き起こしやすいということらしい． 実態参照やコメントの挿入，Unicode 文字，全角文字で記述しても expression として検出される． 詳細は，上記サイトより引用． IE では、以下のようなスタイルを記述することで、JavaScript を動作させる ことが可能です。 1) <style>ブロック内での定義 <style>input { l
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://blogged-on.de/xss/