前回はクロスサイト・スクリプティングのぜい弱性を突く攻撃の対策としてのHTMLエンコードの有効性を述べた。ただ，HTMLエンコードだけではクロスサイト・スクリプティング攻撃を完全に防御することはできない。そこで今回は，HTMLエンコードで対処できないタイプのクロスサイト・スクリプティング攻撃の手口と，その対策について解説する。 HTMLエンコードで対処できない攻撃には，次のようなものがある。 タグ文字の入力を許容している場合（Webメール，ブログなど） CSS（カスケーディング・スタイルシート）の入力を許容している場合（ブログなど） 文字コードを明示していないケースでUTF-7文字コードによるクロスサイト・スクリプティング <SCRIPT>の内容を動的に生成している場合 AタグなどのURLを動的に生成している場合注） 以下では，HTMLタグやCSSの入力を許容している場合と，文字コードを明
HTTPのTRACEメソッドを悪用する古い攻撃手法に「Cross Site Tracing(XST)」というものがあります。この攻撃手法を悪用すると、第三者が Cross Site Scripting（XSS）の脆弱性が存在するWeb サイトとブラウザの間でやり取りされる HTTP リクエスト・ヘッダを取得できてしまいます。この手法は一般的に HTTP リクエスト・ヘッダに含まれる Authorization ヘッダや Cookie ヘッダを奪取するために悪用されるようですね。 XST では一般的に JavaScript でXMLHttpRequest オブジェクトを悪用するようですが、最新のブラウザでも XMLHttpRequest オブジェクトで TRACE メソッドの HTTP リクエストを送信できるのでしょうか。というのも、W3C の XMLHttpRequest オブジェクトに関
Cross-Site Tracing(XST)という化石のような攻撃手法があります。「化石」と書いたように、既に現実的な危険性はないのですが、XSTに関連して「TRACEメソッドは危険」というコメントを今でも見ることがあります。 このエントリでは、XSTという攻撃手法について説明し、XSTおよびTRACEメソッドについてどう考えればよいかを紹介します。 TRACEメソッドとは HTTP 1.1(RFC2616)では、8種類のメソッドが定義されています。GET、POST、HEADなどはおなじみのものですが、それ以外にPUT、DELETE、OPTIONS、TRACE、CONNECTの5種があります。 このうち、TRACEメソッドは、HTTPリクエストを「オウム返しに」HTTPレスポンスとして返すもので、以下のようにGET等の代わりにTRACEとしてWebサーバーにリクエストします。 TRACE
XSS Filter Evasion Cheat Sheet¶ Introduction¶ This article is a guide to Cross Site Scripting (XSS) testing for application security professionals. This cheat sheet was originally based on RSnake's seminal XSS Cheat Sheet previously at: http://ha.ckers.org/xss.html. Now, the OWASP Cheat Sheet Series provides users with an updated and maintained version of the document. The very first OWASP Cheat S
クロスサイトスクリプティング（英: cross-site scripting）とは、Webアプリケーションの脆弱性[1]もしくはそれを利用した攻撃。脆弱性をツリー型に分類するCWEではこの攻撃を不適切な入力確認 (CWE-20) によるインジェクション (CWE-74) のひとつとして分類している (CWE-79)[2]。略称はXSS。かつてはCSSという略称も使われていたが、Cascading Style Sheetsと紛らわしいのでこの略称はあまり使われなくなった[1]。 「クロスサイト（サイト横断）」という名称は歴史的なもので、初期に発見されたXSSでは脆弱性のあるサイトと攻撃者のサイトを「サイト横断的」に利用して攻撃を実行することから名づけられたものだが[3][4]、XSSの定義は新しいタイプの攻撃が見つかるたびに拡張され、サイト横断的なものでなくともXSSと呼ぶようになった[3]
「クロスサイト・スクリプティング（XSS）脆弱性を悪用された場合の被害例としては『Cookieを盗まれる』ことがよく挙げられる。しかし，実際にはもっと深刻な被害を受ける恐れがある。管理者や開発者はその危険性を十分に認識して，対策を施す必要がある」――。京セラコミュニケーションシステムのセキュリティ事業部 副事業部長である徳丸浩氏は11月10日，ITproの取材に対して，XSS脆弱性の脅威を強調した。 さまざまなWebサイト（Webアプリケーション）において，XSS脆弱性が相次いで見つかっている。その背景には，開発者などの認識不足があると徳丸氏は指摘する。「適切に対策を施すには，XSS脆弱性のリスクを把握する必要がある」（徳丸氏）。しかしながら，実際には，XSS脆弱性のリスクを過小評価しているケースが少なくないという。 例えば，「（自分たちが運営している）携帯電話向けサイトでは（携帯電話上で
PHPカンファレンス2020での講演資料です。 アジェンダ 誤解1: Cookieは誤解がいっぱい 誤解2: 脆弱性があるページにのみ影響がある 誤解3: 脆弱なECサイトはセキュリティコードを保存している 誤解4: クレジットカードをサイトに保存すると漏洩リスクが高まる 誤解5: ハッシュ値で保存されたパスワードは復元されない 誤解6: 高価なSSL証明書ほど暗号強度が高い 誤解7: TRACEメソッドの有効化は危険な脆弱性である 誤解8: 怪しいサイトを閲覧すると情報が盗まれたりウイルスに感染する 誤解9: イントラのウェブサイトは外部からは攻撃できない 誤解10: セキュリティ情報はウェブで収集する
クロスサイトスクリプティング (cross site scripting) とは Web アプリケーションの脆弱性のひとつで、HTML を動的に生成する際に、リクエストデータやヘッダに埋め込まれた悪意のあるデータをそのまま HTML として表示してしまい、悪意のあるスクリプトが実行されてしまうものです。悪意をもったスクリプトがサイトを横断して実行されることからクロスサイトスクリプティングと命名されています。略称は、CSS(Cascading Style Sheet) と混同されるため、CSS ではなく XSS と略されます。 例えば、掲示板などで、利用者が入力した文字列をそのまま HTML として表示した場合、利用者は文字だけではなく、HTML のタグも埋め込むことが可能となります。<b> などの無害なものであれば構いませんが、<script>～</script> で悪意のあるスクリプトを
フロントエンド開発のためのセキュリティ 第1回 XSSの傾向と対策 本シリーズではフロントエンドの開発に関係するセキュリティについて、理解を深めます。第1回目はXSS（クロスサイトスクリプティング）です。実装失敗例を挙げつつ、対策のポイントを解説します。 セキュリティはサーバーサイドの問題？ セキュリティに関わるミスは「知らなかった」ではすまされない場合が、往々にしてあります。 ちょっとしたミスでプログラムにバグを作ってしまい、サービスが一部動かなくなったとしても程度にもよりますが、すぐに修正すれば一部のユーザーに少し不便をかけてしまう程度ですむでしょう*。 *注：サービス運営 この記事ではセキュリティの技術的な側面を扱います。ユーザーに不便をかけてしまったことに対するサービス提供側の倫理的問題についてはそのつど言及はしませんが、これらの側面を軽視すべきでないことはいうまでもありません。
kintoneはJavaScriptを使って自由にカスタマイズできます。 カスタマイズにより独自のリッチなUIを構築したり、新しい機能を追加したりできますが、セキュアなコーディングをしないと クロスサイトスクリプティング （以下、XSS）などの脆弱性を作り込んでしまう危険性があります。 この記事では、JavaScriptでセキュアなコーディングをするための基本的なポイントを解説します。
JavaScriptによるブラウザ上での処理量およびコード量の増加に伴い、JavaScript上のバグが原因で発生する脆弱性も増加しています。そのような脆弱性の最も代表的なものが、DOM-based XSSです。今回から数回に分けて、DOM-based XSSについて説明していきます。 DOM-based XSSとは 本連載第2回で説明したような一般的な反射型および蓄積型のXSSのほとんどは、Webアプリケーションがサーバ上でHTMLを生成する際に、攻撃者が指定した文字列のエスケープが漏れていることが原因で発生します。一方、DOM-based XSSは、サーバ上でのHTMLの生成時には問題はなく、ブラウザ上で動作するJavaScript上のコードに問題があるために発生します。 たとえば、以下のようなJavaScriptコードがあったとします。 // bad code div = docum
本稿はCodeZineに2015年12月28日に掲載された記事の再掲となります。 クロスサイトスクリプティング(XSS)は、古くから存在し開発者にもっともよく知られたセキュリティ上の問題のひとつでありながら、OWASP Top 10でも2010年に引き続き2013年でも3位と、未だに根絶できていない脆弱性です。 本記事では、Webアプリケーションの開発においてXSSを根絶するために必要な対策の基本を本気でお伝えします。 はじめに OWASPでは開発者に向けたセキュリティ対策のためのドキュメントやチートシートを多数用意しており、XSSへの対策としても「XSS (Cross Site Scripting) Prevention Cheat Sheet」というドキュメントが用意されています。 ただし、このXSS Prevention Cheat Sheetはシンプルなルールを定めたチートシートで
この記事では、XSSに詳しくないというWebエンジニア向けに、Railsのコード例とともに、 XSSとは？ XSSが起きる原因 XSSを起こさない対策 に分けて、解説していきたいと思います。 XSSとは？ XSS(Cross Site Scripting)をざっくり説明すると、 あなたの作ったページにXSSの脆弱性があると、 悪い人が自由にスクリプト(多くの場合Javascript)を埋め込むことができてしまって、 そのページを開いたユーザが攻撃を受けてしまうという脆弱性です。 これだけだと、あまりわかりにくかもしれないので、具体的な例を見てみましょう。 コメント機能の場合 例えばあなたがコメント機能を作っているとして、 ユーザの入力に <script>location.href="https://qiita.com/"</script>という文章が投稿されたとします。 これを何も考えずに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
