| 日付 |
タイトル |
| 2007 |
WEB アプリケーションにおける権限拡張の自動テスト
権限拡張は、アプリケーションのバグを悪用してアクセスできないリソースまたはより高いアクセス権限が必要なリソースを入手することを意味します。この記事ではAppScan 7 で新たに導入された Web アプリケーションにおける権限拡張およびそれをテストするプロセスの自動化方法について詳しく検討します。
|
| 2006 |
Web Risk Exposure - Don't Forget Your Intranet(英文)
イントラネットは、通信や知識の保存、さらには従業員の生産性を高める効率的で効果的な方法です。しかしイントラネットには、機密性が高く取扱いに注意を要するデータや不適切なデータが含まれる場合が多いため、セキュリティ上のリスク低減のための監視と管理が必要です。このホワイトペーパーでは、イントラネットに関連するリスクについて論じ、セキュリティ上の脅威からサイトを守るためのベスト プラクティスを提供します。
|
| 2006 |
WEB アプリケーションのセキュリティ:自動スキャンと手動による侵入テストの比較
Web アプリケーションがますます複雑になるにつれ、個人情報、医療情報、財務情報など取り扱いに注意を要する膨大な量のデータがやり取りされ、保存されています。このような情報のセキュリティに対する消費者の姿勢は、期待というだけではなく、要求ともいえるでしょう。Web アプリケーションのセキュリティ確保は、手動でのアプリケーション テスト、あるいは自動化システムやツールを使用したアプリケーション テストだけで実現できるものではありません。セキュリティ確保のための作業は概念構築の段階からすでに始まっており、アプリケーションによってもたらされるセキュリティ上のリスクと実装すべき対策のモデル化が、その出発点となります。セキュリティは、すべてのアプリケーションにおいて品質指標の 1 つとみなされるべきであり、アプリケーション ライフサイクルのあらゆるステップを通して分析され、評価される必要があります。このホワイトペーパーの目的は、いくつかの脆弱性の検知手法を検証することです。特に手動による侵入テストと自動スキャン ツールを対比、比較します。
|
| 2006 |
WEB アプリケーション セキュリティ評価のための方法およびツール
Web アプリケーションのセキュリティ評価は、Web アプリケーション開発のライフサイクルにおけるきわめて重要なフェーズです。この評価プロセスは、単体テストや品質保証テストといった他のあらゆるテストと同じアプローチで取り扱われる必要があります。きちんと文書化された手法に注意深く従って行われるべきであり、そのようにすれば、多くの場合自動化ツールによりプロセスに要する時間を短縮できます。このホワイトペーパーでは、Web アプリケーションのセキュリティ評価のための 1 つの方法論と、その評価プロセスを高速化するための自動化ツールの使用法について解説します。
|
| 2005 |
Cross-Site Scripting Explained(英文)
クロスサイト スクリプティング (CSS) は、ハッカーが Web アプリケーションに潜入するために使用する、最も一般的なアプリケーションレベルの攻撃方法の 1 つです。CSS 攻撃の最終目標は、Web サイトのユーザーを特定できる Cookie やその他の機密情報を盗み出すことです。正規ユーザーのトークンを入手することにより、攻撃者はそのサイトにアクセスするユーザーとして振る舞うことができるようになります。このホワイトペーパーでは、典型的な CSS 攻撃がどのように行われるか、この攻撃に対してサイトをどのように守るか、さらには、サイトが防御されているかどうかをどのように確認するか、について論じます。
|
| 2005 |
Hacking Web Applications Using Cookie Poisoning(英文)
Cookie の改ざんは、ユーザー識別情報として維持管理されるセッション Cookie を操作することによってなりすましやプライバシー漏えいを行う、よく知られたテクニックです。攻撃者はCookieを偽造することで正規ユーザーへのなりすましが可能になり、被害者の情報を入手したり被害者に対して悪意のある行動を起こすことができます。セッション Cookie (一般にはセッション トークン) の偽造が可能であるということは、トークンが安全な方法で生成されていないという事実に端を発しています。
このホワイトペーパーでは、セッション管理 (およびセッション管理セキュリティ) がなぜ複雑な作業であるのかという点について説明します。また、2 つの市販エンジンのトークン生成方法について説明します。続いて、各メカニズムの長所について分析した上で短所を解説し、その短所がどのようにしてなりすましやプライバシー漏えいなどの攻撃に利用されるかを例示します。そのような攻撃が成功する可能性について論じ、最終的には、機能性とセキュリティを切り離したセッション管理へのアプローチを提言します。このアプローチは、機能性をアプリケーション エンジンによっイントラネットの規模、形状、形式は千差万別です。イントラネットでは、24 時間 365 日いつでもデータやアプリケーションにアクセスできるため、組織の効率性と生産性が向上します。従業員によるセルフサービスが可能になるとともに、データの印刷や配布にかかるコストを削減することにより財務上のメリットも得られます。しかし、組織が生み出す情報の大半は、比較的短期間で古くなってしまう性質のものであり、差し替えや更新が必要となります。また、古いデータが削除されないまま保存されていると、イントラネットのリソースを消費し、混乱を招いたりデータの喪失やポリシー違反の原因となりえます。
|
| 2005 |
Security and Regulatory Compliance: Don't Forget Your Intranet(IDC Viewpoint)(英文)
イントラネットの規模、形状、形式は千差万別です。イントラネットでは、24 時間 365 日いつでもデータやアプリケーションにアクセスできるため、組織の効率性と生産性が向上します。従業員によるセルフサービスが可能になるとともに、データの印刷や配布にかかるコストを削減することにより財務上のメリットも得られます。しかし、組織が生み出す情報の大半は、比較的短期間で古くなってしまう性質のものであり、差し替えや更新が必要となります。また、古いデータが削除されないまま保存されていると、イントラネットのリソースを消費し、混乱を招いたりデータの喪失やポリシー違反の原因となりえます。
法規制の高まりにより、すべての組織がセキュリティとコンプライアンスについてイントラネットを監査することが求められています。IDC によれば、イントラネット監査は、発見、分析、およびセキュリティ、という 3 つのステップで行うものとされています。企業は自社のイントラネットを、単に便利なツールというだけでなく戦略的な資産ととらえ、ほかのすべての戦略的資産と同様に管理すべきものと認識する必要があります。イントラネットは企業に価値をもたらしますが、そのためにはコスト効率が良く、安全で、かつ適切なものでなければなりません。
|
| 2005 |
金融サービス WEB サイトの責任者の皆様へ WEB サイトのセキュリティについて、すべての経営幹部が知っていなければならないこと
自社の Web サイトでプライバシーやセキュリティの侵害が起きた場合、誰が責任を取りますか? 責任を取るのはセキュリティ チームだと思っているとしたら、それは間違いです。Web サイトを持つビジネスの経営者は、顧客拡大から維持、そしてコスト削減まで、多くのことに責任を負います。しかし、オンライン チャネルが取引を行う顧客にとって安全で健全な場所でなければ、どのようにしてオンライン チャネルの成長を促進できるでしょうか?
このホワイトペーパーでは以下の内容について解説しています。
- ウォッチファイアが最近行った調査の手法と結果の詳細
- 一般的な 4 つの Web アプリケーション攻撃手法の概要
- 攻撃に対する防御は困難であるが不可能ではない理由
- 経営者が、セキュリティと開発を担当するチームとの対話を通じて、組織のオンライン リスク管理戦略の改善を図る方法の提案
|
| 2005 |
アプリケーション セキュリティの課題への取り組み
Web アプリケーションを攻撃するハッカーは、Web サイト側のアプリケーションを悪用して、サイトのデータを漏洩させたり、迷惑行為をしたり、盗んだりします。ファイアウォールや SSL も一般的ですが、最近の調査によれば、Web サイトの 4 つのうち 3 つは攻撃に対する脆弱性を有しており、その攻撃の大多数はアプリケーション セキュリティ攻撃であると言われています。企業はネットワークとホストのセキュリティを確保することで対応しようとしていますが、そういった Web アプリケーション攻撃を阻止するには、そのような手段だけでは不十分であることが多いのも事実です。
アプリケーション セキュリティは、ネットワークやホストのセキュリティとは異なります。ネットワークとホストのセキュリティを実装するための従来のアプローチを、同じように適用することはできません。このホワイトペーパーでは、アプリケーション セキュリティのために何をすべきかとその理由を解説し、セキュリティ向上への道筋を示します。
|
| 2005 |
HTTP Request Smuggling(英文)
HTTP リクエスト スマグリングは、ウォッチファイアが最近発見した新しい Web エンティティ攻撃手法です。これは、ユーザーと Web サーバーの間のデータ フローに 1 つまたは複数の HTTP デバイスかエンティティ(たとえばキャッシュ サーバー、プロキシ サーバー、Web アプリケーション ファイアウォールなど)がある場合に、解析における不整合を悪用するものです。この手法により、Web キャッシュ汚染、セッション ハイジャック、クロスサイト スクリプティングといったさまざまな攻撃が可能になり、さらに深刻なことに、Web アプリケーション ファイアウォールの保護を迂回することもできるようになります。
このホワイトペーパーで説明する詳細情報は、Web アプリケーションの所有者、開発者、および調査担当者が、これらの手法を使用するハッカーによって引き起こされる損害について理解し、その攻撃から Web アプリケーションをより適切に防御し保護するのに役立ちます。
|
| 2005 |
Blind XPath Injection(英文)
Blind XPath Injection では、攻撃者がクエリについての事前知識がなくても、XPath クエリに使用された XML ドキュメント全体を抽出できます。この攻撃では、XPath クローリングと XPath クエリのブール値への変換という 2 つの手法が使用されており、どのようなデータでも取り出すことができるために完璧な攻撃とされています。攻撃者は XPath クエリに使用された XML データベースにアクセスでき、認証、検索などのために XPath クエリ(および XML データベース)を使用するサイトに対して強力な攻撃手段となりえます。このホワイトペーパーでは、Blind XPath Injection の概念について説明し、この種の攻撃に対する防衛策を提案します。
|
| 2005 |
HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics(英文)
HTTP レスポンス分割は新しいアプリケーション攻撃手法で、Web キャッシュ汚染、Web ページ偽装といったさまざまな新しい攻撃や、ユーザーの秘密情報を含むページのハイジャック、クロス サイト スクリプティング(XSS)を仕掛けることを可能にします。この攻撃手法、またこの手法から派生した攻撃は、ほとんどの Web 環境を対象に実行することが可能で、アプリケーションがユーザーによる不正な入力値(この場合は、悪意のあるまたは予想外の文字を含む入力値)を許可してしまうために発生します。このホワイトペーパーでは HTTP レスポンス分割攻撃の概念について説明し、実際の使用例を紹介します。
|
| 2004 |
Developing and Deploying Secure Web Applications(英文)
開発サイクル全体を通したアプリケーションのセキュリティは、これまでになく重要になってきました。Gartner Group の調査によると、今日のハッカー行為の 75% がアプリケーション レベルで発生し、Web サイトの 4 つに 3 つは攻撃に対する脆弱性を持っているとされています。安全な Web アプリケーションを構築し展開するには、開発環境において "ハッカーに強い" ビジネス ロジックを構築し、QA/試験運用環境での品質テストを実施し、内部および外部の監査を通じてセキュリティとコンプライアンスを徹底する必要があります。
|
| 2004 |
アプリケーション レベルでの一般的な 12 種類のハッカー攻撃
Web サイトにおけるアプリケーションのセキュリティを確保するのが難しい一方で、アプリケーションをハッキングするのはきわめて簡単です。典型的なハッカーは、プログラマの視点で思考し、自分が開発者であったら作成したであろう抜け道を見抜き、ほんの数時間で Web アプリケーションを熟知してしまいます。そして Web ブラウザのみを使用して、アプリケーションやその周囲のインフラストラクチャに対する悪意あるアクセスを試みます。
Sanctum (ウォッチファイアが 2004 年 7 月 26 日に買収) が実施した監査の結果、合計 2,000 以上のアプリケーションが稼動する 500 の有名 Web サイトのうち 97 パーセント以上のサイトが、わずか数時間以内で悪用される可能性のあるアプリケーションレベルの重大な問題を抱えていることが判明しました。ほとんどの場合、これらの企業は、ファイアウォールや暗号化といった優れたネットワーク レベルのセキュリティ対策を講じていましたが、ハッカーはアプリケーション層を通じて重要な顧客情報や企業情報へのアクセスが可能であり、その点でこれらの企業サイトはきわめて脆弱なものでした。
|