セキュリティ・キャンプ全国大会2017の講義資料です(Masato Kinugawaさんとの共同制作です)。
![ブラウザの脆弱性とそのインパクト](https://cdn-ak-scissors.b.st-hatena.com/image/square/93993351ab104872ec66770d25c886fd26f8caa3/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F56c0261e12ba4320a6d3b662b6ad1069%2Fslide_0.jpg%3F8420030)
セキュリティ・キャンプ全国大会2017の講義資料です(Masato Kinugawaさんとの共同制作です)。
エグゼクティブサマリ PHPMailerのリモートコード実行脆弱性CVE-2016-10033は、従来MTAとしてsendmailを用いる場合のみ影響があるとされていた。また、WordPressはPHPMailerをバンドルしているが、CVE-2016-10033によるWordPressに対するリモートコード実行攻撃はできないとされていた。しかし、MTAとしてExim4を用いる場合には、PHPMailer単体およびWordPress 4.6からのリモートコード実行が可能であることがわかったので報告する。 はじめに 昨年末に話題となったPHPMailerのリモートコード実行脆弱性CVE-2016-10033ですが、当初公表されていたPoCがsendmailコマンドの -X オプションを用いたものであったため、-X オプションのないMTA(postfix, qmail, exim4等)は直ちに
関連キーワード Windows 10 | Microsoft(マイクロソフト) | JavaScript | セキュリティリスク | 脆弱性 研究者が明らかにしたRow Hammer悪用攻撃とは あるセキュリティ研究者が、メモリ重複排除と、「Row Hammer」(メモリセル間の干渉が引き起こすエラー)のエクスプロイト(攻撃コード)を組み合わせた攻撃の概念実証を発表した。JavaScriptを使ったこの攻撃では、攻撃者が「Windows 10」で稼働するWebブラウザ「Microsoft Edge」に対する読み取り/書き込みアクセス権限を入手できる。企業にとってこの脅威は重大なのか。この脅威に対策はあるのか。 併せて読みたいお薦め記事 「Microsoft Edge」はIEよりも安全なのか さようならIE、「Microsoft Edge」が挑むWebブラウザセキュリティの極北 “危険なIE
By Dan Century セキュリティ専門家のエイダン・ウッズ(Aidan Woods)氏がGoogleのログインページからマルウェアに感染する恐れのある脆弱性を発見、Googleのセキュリティチームに報告したのですが、Googleから「セキュリティバグとして追跡しないことに決定しました」という返答があったことがウッズ氏のブログで報告されています。 Aidan Woods: Google's Faulty Login Pages https://www.aidanwoods.com/blog/faulty-login-pages Google won't fix login page flaw that can lead to malware download | ZDNet http://www.zdnet.com/article/google-wont-fix-login-page
つい最近まで、グローバル・スタンダードのセキュリティ施策ではバリデーションが極めて重視されている、いささか過剰ではないかと思っていたのですが、OWASPの文書を読みなおしたところ、これは僕の思い過ごしだったかと思い始めました。あくまでOWASPに限った話ではありますが… OWASP Top 10 2004については、以下のようなプレゼンをしたことがあります(2012年3月27日)。 ここが変だよ、グローバルスタンダードの脆弱性対策~入力値の考え方~ OWASP Top 10 2004をはじめとして、バリデーションが過剰に重視されているのではないかという指摘でした。 しかし、最近OWASPの文書を読みなおしてみると、OWASP Top 10 2004当時にあった「バリデーション至上主義」のようなものはすっかり影を潜め、私が(そして日本の専門家の多くが)言っていることとほとんど変わらないことに
本日、とある会合にてTwitterで交わされていたこの会話が話題になりました。 紹介されている例はHostヘッダの操作を経路とする攻撃ということであり、Hostヘッダインジェクションという脆弱性はないと思いますよ / “PHPにおけるHostヘッダインジェクション脆弱性 ― A Day in Serenit…” https://t.co/sTzTQEE7a8— 徳丸 浩 (@ockeghem) 2015, 11月 6 @ockeghem @okumuri 実はIEでは細工したホストヘッダを送出できる手法が知られています。間違いなくIEのバグですが、このせいで値をそのまま出力しているサイトではXSSがありえてしまいます。ここが参考になります: https://t.co/G419aaUgNi— Masato Kinugawa (@kinugawamasato) 2015, 11月 9 知る人ぞ
WEB系の情報セキュリティ関連の学習メモです。メモなので他情報のポインタだけ、とかの卑怯な記事もあります。 ※2020.9 注記:本ブログの解説記事は内容が古くなっております。OWASP ZAPなどのソフトウェアの解説は現行バージョンの仕様から乖離している可能性があります。 EC-CUBEで脆弱性を見つけたり、mixiの脆弱性報告制度で成果を挙げたりしたせいか、「どうやって脆弱性を見つけてるんですか?」という質問をされることが時折あり、一応手順は説明するのですが、いつも口頭で細かくは説明できなくて申し訳ないので、自分のやり方をまとめてこのブログにアップしておきます。 標準的な脆弱性検査のやり方しか説明していないので、脆弱性検査のやり方を既に把握している人が読んでも得るものは少ないのではないかと思います。今回は脆弱性検査に興味があるが何をどうしたらいいか分からないような初心者向けコンテンツで
株式会社ミクシィは、お客様に安心してご利用いただけるサービスを提供するため、脆弱性に関する報告の重要性を認識しております。より安全なサービスの実現を目指し、脆弱性報告に対して、正当な対価をお支払いすることを目標に、脆弱性報告制度を開始しましたので、ご案内いたします。 概要 弊社のサービスにおいて、脆弱性を発見した場合に、窓口にご報告いただき、その重要度によって、報酬をお支払いする制度です。 対象 本制度は、株式会社ミクシィとその子会社がリリースした、ウェブアプリケーションおよびクライアントアプリケーションの脆弱性を対象とします。 ただし、次に該当するものは含まれません。 既に公表されている脆弱性 弊社にとって既知の脆弱性 報告されてから修正が完了する前に公表された脆弱性 攻撃が成立する可能性が著しく低いと考えられる脆弱性 原理的に修正が不可能な脆弱性 本制度の期間外に報告された脆弱性 窓口
WebアプリケーションにおいてJSONを用いてブラウザ - サーバ間でデータのやり取りを行うことはもはや普通のことですが、このときJSON内に第三者に漏れては困る機密情報が含まれる場合は、必ず X-Content-Type-Options: nosniff レスポンスヘッダをつけるようにしましょう(むしろ機密情報かどうかに関わらず、全てのコンテンツにつけるほうがよい。関連:X-Content-Type-Options: nosniff つかわないやつは死ねばいいのに! - 葉っぱ日記)。 例えば、機密情報を含む以下のようなJSON配列を返すリソース(http://example.jp/target.json)があったとします。 [ "secret", "data", "is", "here" ] 攻撃者は罠ページを作成し、以下のようにJSON配列をvbscriptとして読み込みます。もちろ
2012/07/05 NRIセキュアテクノロジーズ(NRIセキュア)は7月5日、同社が提供するマネージドセキュリティサービスやセキュリティ診断サービスから得られた集計データに基づいた「サイバーセキュリティ 傾向分析レポート 2012」を公表した。 2011年から2012年にかけては、グローバルに事業を展開している日本企業で、Webサイトの改ざんや情報漏えい事件が相次いだ。「セキュリティ対策が不十分な海外拠点のWebサイトが『ウィーケスト・リンク(最も弱い鎖の輪)』となっている」と、同社コンサルティング事業本部 テクニカルコンサルティング部 浅野岳史氏は指摘する。 NRIセキュアが2011年8月から9月にかけて実施した調査でも、海外拠点を持つ企業の66.2%が、情報セキュリティ対策の結果確認を「現地の裁量に任せている」と回答した。加えて、「海外拠点の支店長として、経理や総務といった業務に加え
皆さんこんにちは、川口です。コラムの第6回「IPSは“魔法の箱”か」でまっちゃ139で講演をしたお話を書きましたが、今度は関東でやっている「まっちゃ445」にお招きいただき、お話ししてきました。 まっちゃ445は募集開始から定員が埋まるまでがとても速く、今まで参加したことがなかったのですが、今回は運良く(?)講師側ということでキャンセル待ちにならずに参加することができました。ロックオンの福田さんがオープンソースのECサイト構築システム「EC-CUBE」に脆弱(ぜいじゃく)性が発見された際のインシデントハンドリングのお話をされていました。EC-CUBEにSQLインジェクションとクロスサイトスクリプティング(以下、XSS)が発見されたあとの対応のお話です。JSOCで日々インシデントにかかわっているいる自分としてはとても興味深い内容でした。 日本のエンジニアのセキュリティ意識は過剰? 今回のよう
※ご注意 他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。 本稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。 また、本稿を利用した行為による問題に関しましては、筆者および株式会社アットマーク・アイティは一切責任を負いかねます。ご了承ください。 完璧なアプリケーションをいきなり作り上げられる人はまずいないだろう。多くの人はアプリケーション中にデバッグ用のメッセージやコメントを残しながら開発を進めていくことになる。またユーザーにとって重要なのがエラーメッセージである。エラーメッセージを頼りにアプリケーションを利用していく。しかし、ユーザーにとって有用な情報なのだが、同様に攻撃者にも有用な情報を与えてしまうことにもなることがある
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く