「XSS脆弱性は危険，Cookieを盗まれるだけでは済まない」専門家が注意喚起
「クロスサイト・スクリプティング（XSS）脆弱性を悪用された場合の被害例としては『Cookieを盗まれる』ことがよく挙げられる。しかし，実際にはもっと深刻な被害を受ける恐れがある。管理者や開発者はその危険性を十分に認識して，対策を施す必要がある」――。京セラコミュニケーションシステムのセキュリティ事業部 副事業部長である徳丸浩氏は11月10日，ITproの取材に対して，XSS脆弱性の脅威を強調した。 さまざまなWebサイト（Webアプリケーション）において，XSS脆弱性が相次いで見つかっている。その背景には，開発者などの認識不足があると徳丸氏は指摘する。「適切に対策を施すには，XSS脆弱性のリスクを把握する必要がある」（徳丸氏）。しかしながら，実際には，XSS脆弱性のリスクを過小評価しているケースが少なくないという。 例えば，「（自分たちが運営している）携帯電話向けサイトでは（携帯電話上で
秋元@サイボウズ研究所プログラマーBlog: iHack - 脆弱なHTMLフォームの突破ゲーム
脆弱性のあるHTML Formをゲームとして公開している 「このフォームを突破してもハック(クラック?)したことにはならないよ」とのこと。安心してアタックされたし。 さっそく遊んでみたが、レベル3で既に悩んでしまい停滞。そんなわけで先がどれぐらいの難易度なのかはまったく不明。我ながら才能無いなあ。 猛者がいるサイボウズ・ラボの社内掲示板に紹介しておいた。 # くれぐれも、解いて進んだ先のURLを直接紹介しないこと、との注意書き。ゲームがつまんなくなるんでね。 [追記] ということで社内の猛者達が全6問を解き終わった。 レベル3は「そりゃないんじゃないの」に近い仕掛けだった。技術じゃない。このへん関連のニュース、「よく使われるパスワード」みたいなのを漁るのかこれ。 この記事は移転前の古いURLで公開された時のものですブックマークが新旧で分散している場合があります。移転前は現在とは文体が違い「
2006-08-03
強いはずの日差しが空々しく感じられてしまうのはどうしてかしら？ 久しぶりにちゃんとした技術ネタよ。特に、いわゆるWebアプリケーション*1を作ったり設計したりしている連中は耳かっぽじってお聞きなさい。よろしくってかしら？ なんていうか…なんとも言えず愚かなセキュリティホールを拝見いたしましたの私ったら。 そのサイトは、セブンアンドワイ株式会社さんの運営なさってらっしゃる セブンアンドワイ ( http://www.7andy.jp/ ) 。 あたくしったら、ここの会員になってみましたの。で………とても驚くものを拝見したわ？ 会員情報の変更画面があるの。 少なくとも今時点では、メールアドレスを変更する、住所/電話番号を変更する、ID/パスワードを変更する、の３つのメニューがあるわ*2 もちろんこの時点で「３つともURL一緒じゃん」とかいう突っ込みは置いておくとして。とりあえずその画面に伺って
フィッシング詐欺に新手法，本物のSSLサイトから偽サイトへリダイレクト：ITpro
XSS脆弱性を悪用したフィッシング詐欺（英Netcraftの情報より引用）<br>表示されているのは本物のページだが，XSS脆弱性を悪用されて，偽のメッセージやリダイレクトのためのメタ・タグなどが埋め込まれている。 フィッシング対策ツールなどを提供している英Netcraftは現地時間6月16日，米PayPalをかたる新たなフィッシング詐欺が確認されたとして注意を呼びかけた。細工が施されたリンクをクリックすると，PayPalの本物のWebサイトが表示されてから，偽サイトへリダイレクトされる。このため，通常のフィッシングよりもだまされる可能性が高いとする。 今回のフィッシングは，PayPalのサイトに見つかったクロスサイト・スクリプティング（XSS）の脆弱性を悪用する。Webページ（Webアプリケーション）にXSS脆弱性が存在する場合，攻撃者は細工を施したリンク（URL）をユーザーにクリックさ
クロスドメインのHTML読み取り(IEのバグ CSSXSS）とCSRF
(Last Updated On: 2014年12月5日)追記：このブログを記載する理由となったURLを記載された方が内容を削除されたようです。「間違っている」と言われるのは心外である、と思ったことは確かですがページの内容が削除されるのは私の本意ではありません。書かれていた情報はとても役に立つ情報だと思います。非常に残念なので再度掲載されることを望みます。（本当 —– セキュリティ対策ではよくあることですが、条件の見落としによりセキュリティ対策を行っていても脆弱性が発生することがあります。「Webアプリセキュリティ対策入門」に書かれているCSRF対策にも「クロスドメインのHTML読み取り(IEのバグ）」の問題が修正されていない為、書籍に記載した対策を行ってもバグを持つIEに対してはCSRFに脆弱になります。 しかし、このバグの影響を持って「Webアプリセキュリティ対策入門」のCSRF対策を
なぜCSSXSSに抜本的に対策をとることが難しいか - いしなお! (2006-03-31)
_ なぜCSSXSSに抜本的に対策をとることが難しいか CSSXSSの説明について、その脅威を過剰に表現している部分がありました。その部分について加筆訂正しています。 @ 2006/4/3 tociyukiさんによる「[web]MSIE の CSSXSS 脆弱性とは何か」および「[web]開発者サイドでの CSSXSS 脆弱性対策」には、より正確なCSSXSS脆弱性の内容およびそれに対するサーバーサイド開発者で可能な対策について紹介されていますので、是非そちらもご覧ください。 @ 2006/4/4 今までも何度かこの辺の話はあまり具体的ではなく書いてきたけど、そろそろCSSXSSを悪用したい人には十分情報が行き渡っただろうし、具体的な話を書いてもこれ以上危険が増すということはないだろうから、ちょっと具体的に書いてみる。 ちなみに私自身は、CSSXSSの攻撃コードなどを実際に試したりといった
高木浩光＠自宅の日記 - 「高橋メソッド」的突貫工事と、脆弱性を排除する構造設計は両立するか
■ 「高橋メソッド」的突貫工事と、脆弱性を排除する構造設計は両立するか こんな記事が出ていた。 「3年で陳腐化するWebサイトの構築には軽量言語のほうが向いている」，日本Rubyの会，高橋征義会長, 日経ソフトウェア, 2006年2月10日 高橋氏は「Webサイトは構築してから3年経つと陳腐化する」と指摘する。ただ，壊れたわけでもないWebサイトを3年でリニューアルするには，事前に顧客と話をつけておく必要がある。3年で捨てる予定のアプリケーションの予算は少ない――これが，WebにはPHPやRubyといったLLが向いている理由である。Javaのような重量級の言語だと，10年持ちそうな設計や構造のアプリケーションを作ることになり，費用もそれなりに高額になってしまう。 それは話が逆だろう。「10年持ちそうな」という言葉で比喩されるような、つまり、しっかりとした設計や構造のアプリケーションを作ると
XSS (Cross Site Scripting) Cheat Sheet
XSS (Cross Site Scripting) Cheat Sheet Esp: for filter evasion By RSnake Note from the author: XSS is Cross Site Scripting. If you don't know how XSS (Cross Site Scripting) works, this page probably won't help you. This page is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion. This page will also not show you how to
日本のアイドルサイトからのリファラSPAM?
(Last Updated On: 2018年8月14日)久しぶりにブログへのSPAM掃除をしていたら、日本のアイドルサイトからのリファラSPAMと思われるログが複数ありました。 #リンクにならないようにhttpのhを削除しました。 ttp://suzukiairi.net/cgi-bin/up/upload.php?page=all ttp://www.umedaerika.com/ume/uperika.php?page=all ttp://melon-kinenbi.plala.jp/~ayumi/sam.php?start=100 ttp://ai-flavor.com/upload/flavorupload.php?page=all ttp://www.sudomaasa.com/rabi/upmaasa.php?page=all なにこれ?と思っていたところどうもこのアップロー
Vulnerability Security Testing & DAST | Fortra's Beyond Security
BeSTORM A black box fuzzer, a method of dynamic application security testing, that uncovers unknown security weaknesses during the product development stage, so fixes can be made before a product is launched. This chaos testing style requires no source code to run and offers more than 250 pre-built protocols and modules or the option for custom protocols. LEARN MORE BeSECURE A vulnerability assess
ysk-style memo: ブログサービスの XSS 脆弱性対策はいらない
http://deztec.jp/design/06/02/05_xss.html 面白い指摘。そういう視点もあるか。 でも、はてなの方針としては「そういうのがやりたい人は他でやってくれ」って感じなんだろうね。 他のblogサービス見てても、一長一短でどれがどういう特徴あるのか分からないよね。それに対して、はてなは「はてなっぽさ」を出すことで他のblogサービスとは違う特徴をうまく出してる。他のblogサービスとは明らかにちがうじゃない？それがはてなユーザーを取り込むことに成功してると思うんだ。もちろん、私も取り込まれた一人ね。 性善説に頼るのが現実的かどうかはさておき、面白い視点でみてるなーって思った。 技術的な見地から、ひとつ突っ込んでみる。 ていうか、レンタルサーバサービスの類が XSS 脆弱性を気にしていたなんて話は聞かないのに、なんでブログサービスとなると、気にする会社が出てくる
「脆弱性を生みやすいプラットフォームはどれだ？」，セキュリティ団体が実態調査
Webアプリケーションのセキュリティ対策を協議・普及する団体であるWAS（Web Application Security）フォーラムが，脆弱性を生みやすいプラットフォームがあるか否かを確認するため，Webアプリケーション・ソフトをサンプル抽出してテストしたことが分かった。「セキュリティ侵害事件が多発する中で，マイクロソフトは危険，Javaは安全－－といった根拠のない“神話”が広まっている。本当のところを実証する必要性を感じた」（代表である奈良先端科学技術大学院大学 助教授 門林雄基氏）。 テスト対象は，Active Server Pages，PHP，Java，ASP.NETといった，異なるプラットフォームで動作するオープンソースの電子商取引パッケージ7製品。テスト内容は三つ。（1）まず，推奨される構成でパッケージをインストールして脆弱性テスト・ツールで検査した。これにより，プラットフォー
Kazuho@Cybozu Labs: 安全なリダイレクタ
« フィードビジネス・カンファレンス リンク集 | メイン | Live HTTP Headers で Firefox の裏技を解析する » 2005年12月13日 安全なリダイレクタ リダイレクタの存在は脆弱性か？ (高木浩光＠自宅の日記) 等で、リダイレクタが脆弱性かどうか、というのが話題になっていました。 個人的には、脆弱性かどうかはともかく、不要なリスクを回避するためにも、サービス事業者は自社のリダイレクタに何らかの制限機構を入れるべきだと思います。 その技術的な実現方法についてですが、必ずしもデータベース等を用意する必要はありません。一番楽なのは、メッセージ認証コード (MAC) を使う方法だと思います。 HMAC を使ったリダイレクタにおいては、たとえば、 http://kazuho.31tools.com/redirector/redirect.cgi?url=http%3A
Underconstruction by Taiyo@hatena
来年ものすごく流行りそうな手法が公開された。 これは痛い。 Google Desktop Exposed: Exploiting an Internet Explorer Vulnerability to Phish User Information 関連： eWeek記事 ITmediaの記事 I call this attack CSSXSS or Cascading Style Sheets Cross Site Scripting. うまいこと名前を付けたもんだなぁ…… 記事ではGoogle DesktopからHDDの情報を抜けることが問題視されるような書き方になっているが、CSSXSS自体はGDSとは関係がない。 一言で言うと、cssのimport文で任意のWebサイトの情報を抜き出せることを利用した攻撃だ。ログインして利用するWebサイトのHTMLが、ほかのWebサイトで利用で
高木浩光＠自宅の日記 - 攻撃者視点ではなく開発者視点での解説を
■ 攻撃者視点ではなく開発者視点での解説を 8月に@ITに「機密情報に合法的に近づけるWebアプリケーションを守れ」という記事が 出ていた。 タイトルからして意味がわからない。「合法的に近づける」とは何だ？ 英文 の直訳か何かか？ その連載第2回「多様化するWebアプリケーションへの攻撃」が今日掲載されたのだが、問題を正しく理解し ないまま書かれた記事と言わざるを得ない。例えば次のように書かれている。 この例では、「userid=-20298745283」がクエリストリング にあたる。クエリストリングはURL内に含まれているため、誰でも見ることが できる。従って、ユーザーのちょっとした出来心やいたずら（例えば 「この数字の最後を1つだけずらせばどうなるかなー？」） によって、脆弱性が露見することも多い。 この例であれば、誰が見ても明らかなように、「userid」のパラメー タがユーザー管理
＠IT：Wabアプリケーションファイアウォールの必要性 第1回
機密情報に合法的に近づけるWebアプリケーションを守れ：Webアプリケーションファイアウォールの必要性（1）（1/3 ページ） 「SQLインジェクション」や「クロスサイトスクリプティング」という用語に聞き覚えはないだろうか。セキュリティに関連する用語であることを知る人は多くても、詳細な説明をできる人はまだ少ないかもしれない。どちらもWebアプリケーションの脆弱性を指す用語である。 個人情報の保護に関する法律（個人情報保護法）の施行によって、より多くの注目を集めるようになった個人情報漏えいに関するニュースが毎日のように流れている。漏えいした個人情報が、もしWebサイトから盗み出されたものであれば、原因はSQLインジェクションであった可能性がある。 この連載では、Webアプリケーションの脆弱性、攻撃手法の実例を挙げて解説するとともに、その脆弱性を防御する装置として市場に現れたWebアプリケーシ
mod_securityでWebサーバを守る(第1回)
一体、Webサイトを持たない組織は今どれくらいあるでしょうか。 Webサーバを自前で持つ、ホスティングサービスを利用する、など運用形態はさまざまですが、Webサイトを持たない組織はほとんどないと思える程に Webは普及しています。 ファイアウォールはほとんどの組織で導入済みであり、多くのWebサーバはファイアウォールの中で運用されているのが一般的です。 しかしながら、最も普及しているファイアウォールはIPアドレス、ポートレベルでのフィルタリングです。この方法でのフィルタリングでは、許可していないサービスが持つ脆弱性を狙った攻撃を阻止できるため有用ではありますが、HTTPを許可している場合Web自体への攻撃に対して無力です。一方で、HTTPを不許可にした場合にはWebサイトへアクセスできなくなってしまうため本来の目的を達成できません。しかもここ数年、Webサイトを狙ったワームや不正アクセスは
フィッシング詐欺サイト情報
ClamAVでEmail.Phishing.Bank-63と検知されています。ゾンビPC詐欺サイトです。 URLは以下 ttp://commercial.wachovia.online.financial.service.onlineupdate.QG4TGcD97seyqNP.sitesurvey.ptcontrol.ioejnvi.com/support.html?/sessionervlet/siteminderagent/OSL.htm?LOB=1224903340&refer=4TGcD97seyqNP1W 午後の部 ttp://commercial.wachovia.online.financial.service.privatelogin.7mJAvNR6ht1fzGg.carehtmlclient.privatelogin.kilegre.com/support.html
HTTP Request Smuggling Attack
(Last Updated On: 2018年8月3日)HTTP Request Smuggling攻撃はクライアントからのリクエストをこっそり持ち出す攻撃です。HTTP Response Splitting攻撃の様にWebアプリケーションの脆弱性はHTTP Request Smuggling攻撃に必要ありません。キャッシュシステムの脆弱性が攻撃に利用されます。 攻撃例として 1. Webキャッシュ汚染 2．Webファイアーウォール回避 3．後方・前方のリクエスト持ち出し 4．リクエストの乗っ取り 5．クレデンシャルの乗っ取り（HTTP認証の強奪） があげられています。 メジャーなWebキャッシュ製品が脆弱である事が検証されているようです。 各製品のアップデートがリリースされています。バージョンアップが必要な方はお早めに。 キャッシュシステムのバージョンアップ以外にも 1．SSLを使用する
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://japan.internet.com/busnews/20061027/6.html