イントロ

少し前、私は会議FrontendConf 2015 （RIT ++）でこの記事のトピックについて話しました。 そして、レポートを準備する際に、彼は情報を探し始めました。そして、誰がこのトピックについて話し、現在ウェブ上にあるものでさえ話しました。



GoogleのMike Westからのレポートmikewest.org/2013/09/frontend-security-frontendconf-2013に言及できる情報はほとんどありませんでしたが、ある種の「非ペンテスター」の外観と非常に少ない資料であることが判明しました。 また、 www.slideshare.net / eoftedal / web-application-security-in-front-endでは 、トピックがより詳細に開示されていますが、2011年のプレゼンテーションです。 そして4年間、テクノロジーと攻撃は止まりませんでした。



トピックを選択する長い困難な時間、フロントエンド開発者にセキュリティについて何を伝えるべきか、少なくともバックエンドに触れる（これは不可分です）ので、レポートを受け取りました。

会話は何ですか？

しかし、本当に、ここで何について話せますか？ ハッキングとセキュリティについて言えば、これらは思わず思い浮かびます-彼らはデータベースを漏らし、サーバー上でOSコマンドを実行するためのアクセスを得て、他の誰かの通信を読みました。 しかし、これはすべてサーバー側のコードです。 そして、フロントエンドを「最前線」にできるものは何ですか？ もちろん、主な危険は、攻撃元のSOP-Same Origin Policyをバイパスすることです。これは、異なるOriginでの作業を規制する主要なブラウザセキュリティポリシーです。 だけでなく、理解しましょう。

Crossiteスクリプト

クロスサイトスクリプティング

XSSトピックはできる限り早く削除されますが、通常はサーバー側でのパラメーターの不適切な処理の問題です（攻撃者はページにJSコードを埋め込み、脆弱なオリジンに代わって被害者のブラウザーを含むそれを実行でき、結果はSOPバイパスです）。 そして、2種類のXSS攻撃を割り当てました-保存（「悪意のある」jsはサーバーに保存されます）および反映（保存せずにサーバーによって与えられます）。



さて、フロントエンドはどうですか？ また、別のケースもあります-攻撃者のJSはサーバーに送信されませんが（例外はありますが、そうではありません）、正当なJSコードのためにDOMに埋め込まれます。 したがって、XSS攻撃の3番目のタイプの名前はDOM XSSです。



脆弱なJSコードの典型的な例：

document.write("Site is at: " + document.location.href);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでページを開きます

 http://victim.com/action#<script>alert('xss')</script>ѕ
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

JSは、値document.location.hrefをツリーに追加し、そこに「悪意のある」jsが挿入されます。 この例から既にわかるように、このタイプの攻撃のベクトルを検索するには、ユーザーのブラウザーに何かを影響させる（ソース）と何らかの形で実行する（シンク）の2つのことが必要です。



ソースの例：

• document.URL
• 場所
• document.referrer
• window.name
• localStorage
• クッキー

シンクの例

• 評価する
• document.write
• （要素）.innerHTML
• （要素）.src
• setTimeout / setInterval
• execScript

このトピックの詳細については、リンク（ code.google.com/p/domxsswiki （およびここからレギュラーシーズンに進んで潜在的な脆弱性を検索してください）およびhabrahabr.ru/company/xakep/blog/189210 （同僚のAlexei Tyurinからの記事）に従ってください。



そして、これがtwitter.comの脆弱な（実際の）コードの例です（詳細）

 (function(g){var a=location.href.split("#!")[1];if(a){g.location=g.HBR=a;}})(window);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

twititer.comでのXSS DOMの例

情報漏洩

JS / CSSファイルには、システムインフラストラクチャに関する情報が含まれていることがよくあります。

JavaScriptについて

プロジェクトが非常に大きくなり、アプリケーションのさまざまな環境（test / dev / prod）が開始されると、松葉杖が始まり、クライアントを含め、作業が必要な環境が定義されます。



このような実際のファイルの例、 mail.ru-img.imgsmail.ru/r/webagent/release/loader.js

 var dl = (''+document.location), host = document.location.host, branch = 'master', path = 'release/467', base = 'r/webagent/', probability = [ {"branch": "wa-514", "deprecated":1} ], lastForcedVersion = '20131126154524', isLocalhost = dl.indexOf('localhost') != -1, testServer = host.match(/[^.]+\.((?:f|my\.rapira)\d*)\.mail\.ru/), devServer = host.match(/^.+\.dev\.mail\.ru$/), isRapira = testServer && testServer[1].indexOf('my.rapira') == 0, utf = true,//!!window.IS_UTF, domainProps = {}, domain = '//img.imgsmail.ru', login = getUserLogin(), useBranch = (dl.match(/\Wwa_use_branch=([a-z0-9-]*)/i)||[0,false])[1], useLang = (dl.match(/\Wwa_lang=([az]{2})/i)||[0,false])[1], useOnce = (dl.match(/\Wbranch=([a-z0-9-]*)/i)||[0,false])[1], appVersion = (dl.match(/\Wwa_appver=([\.0-9]*)/i)||[0,false])[1], usedBranch = branch;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このファイルからわかるように、定期的な間隔でテストと開発を行うために、ドメインを決定できます（そして有効なドメインを削除しますか？）。 この場合、情報はそれほど重要ではないかもしれませんが（もしあれば-mail.ruは知っています）、時にはそのような構造があります：

 internalDevHOST = '172.16.22.2'; internalProdHOST = '172.16.22.5';
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、外部IPを使用する場合もあります（たとえば、内部IPはSSRFでも役立ちます）。

CSS

CSSでも同じです。 プロジェクトは成長しており、開発者はさまざまな「ビルダー」を使用し始めています。これらのビルダーは、たとえばhackerone.com/reports/2221などの「おいしい」情報を残しています。

 file\:\/\/\/applications\/hackerone\/releases\/20140221175929\/app\/assets\/stylesheets\/application\/browser-not-supported\.scss file\:\/\/\/applications\/hackerone\/releases\/20140221175929\/app\/assets\/stylesheets\/application\/modules\/add-category\.scss file\:\/\/\/applications\/hackerone\/releases\/20140221175929\/app\/assets\/stylesheets\/application\/modules\/alias-preview\.scss ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

MVCフレームワーク

AngularJS、Knockout、EmberJSなど、さまざまなJS MVCフレームワークの人気が高まっています。 それらは非常にクールで、DOMを使用した作業の拡大、新しい要素の作成（）、「バインダー」の作成などを可能にします。 当然のことながら、新しいものはセキュリティの世界に気付かれることなく通過できませんでした。



特に、ロジックのないテンプレートに興味があります。

 <ul> <li ng-repeat="phone in phones"> <span>{{phone.name}}</span> <p>{{phone.snippet}}</p> </li> </ul>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コピーアンドペーストの数を大幅に削減し、括弧内の指定された変数に値を割り当てることができます。



または、ブラケットを90°回転させると口ひげが生えます。 口ひげ！ mustache.github.io







MVCフレームワークのセキュリティに関する口ひげセキュリティプロジェクトcode.google.com/p/mustache-securityの登場です。 すでに次の情報があります。

• Vuejs
• Angularjs
• Canjs
• Underscore.js
• ノックアウト
• Ember.js
• ポリマー
• Reactive.js
• jQuery
• Jsender
• 剣道UI

それでは、ここで何が起こるのでしょうか？ AngularJSを使用してください。 たとえば、攻撃者がこれらのかっこ内に入っただけの状況があります。 そして、そのうちの何とかしてJSを実行する必要がありますが、これはデフォルトでは不可能です。 タスクは、サンドボックスを回避することです。



AngularJSを使用した例（1.1.5）

 <div class="ng-app"> {{constructor.constructor('alert(1)')()}} </div>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのため、AngularJS <1.1.5のバージョンではまだそれほど複雑ではありませんが、サンドボックスから出て、ウィンドウオブジェクト（上記の例では、アラート（1）を呼び出すだけ）、ブラウザウィンドウ全体に「到達」することができました。 Googleは修正プログラムをリリースし、...



AngularJS（1.2.18）、修正後

 {{ (_=''.sub).call.call({}[$='constructor'].getOwnPropertyDescriptor(_.__proto__,$).value,0,'alert(1)')() }}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

希望するアラート（1）も受信しました！



それで私は何をしていますか。 フレームワークの更新は、機能だけでなく、セキュリティにとっても重要です！

クッキー

この点を考慮して、私たちはすでに小さなバックエンドに触れ始めています。 しかし、かなり。

通常、サーバー側でどのようにクッキーを設定しますか？



PHPの例：

 <?php setcookie('foo','bar1'); ?>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Pythonの例：

 import Cookie C = Cookie.SimpleCookie() C["foo"] = "bar" print C
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初と2番目のケースの両方で、サーバーはヘッダーで応答します：

 Set-Cookie: foo=bar
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり ブラウザに指示して、バーの値をfooキーに設定します。 しかし、あなたはそれを熟考し、チェックリストで自分自身をチェックする必要があります：

1. Cookieを設定するドメインを指定します。 上記の例では、IEは現在のサブドメインとすべてのサブドメインの両方にCookieを設定します。 つまり XSSが何らかの「左」サブドメインで見つかった場合、データが危険にさらされる可能性があります。 詳細
2. セッション値のHttpOnlyフラグ（たとえば、phpsessid、デフォルトなし）。 ブラウザは、JSからこの値へのアクセスを禁止する必要があります（XSSを使用すると、ユーザーアカウントの盗難のリスクが軽減されます）
3. サイトがHTTPSでのみ動作し、安全でないチャネルを介して重要な値を送信する必要がない場合のセキュアフラグ

HTTPSに切り替える

3番目の段落ではHTTPSについて説明しました。 ブラウザでの作業を正確に目的としているため、これについて説明します。 含む 通常、移行はサーバー管理の問題です-証明書の選択、Webサーバーのセットアップ、準備ができたら-HTTPからHTTPSへのリダイレクト



人生で起こるように。 管理者は、HTTPS上のHTTP経由でサイトに入るときにリダイレクトを設定します。 しかし、この瞬間、ユーザーは最初にHTTP経由でログインします。この時点で、ユーザーにHTTPSバージョンのサイトを提供せずに、HTTPSおよびプロキシトラフィックへのリダイレクトをさらに「ドロップ」できます。



なぜ人々はHTTP経由でもサイトにアクセスするのですか？ 誰もがブックマークにそれを持っているので、すべてがHTTP経由でもあります。



coolstoryに気を取られる:)





ストーリーはこの写真のすぐ下にあります。



私は「最愛の」VKについて話さずにはいられません。 現在、VKのアカウントの「ハイジャック」の波は過ぎ去り、勢いを増しています。 ほとんどの場合、これらは、VKアドレスが異なる修正されたDNSサーバー、つまり「悪意のある攻撃者の悪意のあるサーバー」を持つハッキングされたユーザールーター（ルーターに十分な脆弱性があります）です。 ユーザーはこのトリックを使用するだけで、ユーザーはサイトのHTTPSバージョンにアクセスしてリダイレクトを「ドロップ」することはできません。ユーザーはまだHTTPバージョンでブックマークされたサイトを持っているためです（h_ttpsページで見る：//vk.com/settings？Act = securityまだ強制HTTPSではありません）。



それで、どのように治療するのですか

これを行うために、HSTSヘッダーを発明しました

 Strict-Transport-Security: max-age=31536000;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

HTTPを介したこのサイトへの要求はもうないことをブラウザに伝えます。 このルールが機能する時間を指定します（オプションで、このルールのサブドメインへの配布を指定できます）。



妄想モードをオンにして、初めてサイトにアクセスしたときにトラフィックがインターセプトされ、ユーザーがこのヘッダーを受信しないという状況を想像すると、HSTSプリロードリストにリソースを追加できます-www.chromium.org/hsts 、ブラウザが常にアクセスするリソースのリストHTTPS経由でアクセスします（つまり、リソースのリストはブラウザーに直接「接続」され、ブラウザー間で共有されます）。

HTML5セキュリティ

記事は非常に大きく、絶望しないでください：0新しい要素のコンテキストだけでなく、新しいAPIメソッドについてもHTML5について話すと、それ（HTML5）は多くの便利で安全なものをもたらしました。 クロスドメイン作業。 そして、思い付かなかったのは、サーバーのルートにある「proxy.php」ファイル、およびその他のひどい松葉杖です。

Window.postMessage（）

2つのウィンドウオブジェクトがあるとします（たとえば、現在のウィンドウとiframeからのウィンドウまたはwindow.openの後）。



abc.comドメインのページが「秘密」メッセージを別のウィンドウに送信します

 otherWindow.postMessage(message, targetOrigin);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

xyz.comドメインのページはメッセージをリッスンし、メッセージの送信元を確認します

 window.addEventListener("message", receiveMessage, false); function receiveMessage(event) { if (event.origin !== "http://example.org:8080") return; // ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一般に、このオプションは正しい-発信元、送信先（攻撃者に送信しないように）を示し、受け入れ、メッセージの送信元を確認します。 しかし、実際にはこれはめったに起こりません。プロジェクト全体（すべてのサブドメイン）でこのようなソリューションが必要になることがよくあります。



脆弱なコード！

 if(message.orgin.indexOf(".example.com")!=-1) { /* ... */ }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、時にはそのような脆弱なコードに出会うことができます。 example.com.attacker.comも失敗します（攻撃者ドメイン）。 だから：

• データの送信先を確認する
• どこから入手したかを確認する
• 上記のように動作しないようにチェックを再確認します

HTTPアクセス制御（CORS）

また、クロスドメイン作業についてです。 CORSはクールでファッショナブルで安全なもので、扱いにくいものです。 非常に難しいですが、...それは起こります:)



また、ブラウザはSOPをバイパスして動作する方法を伝えることができます。 クロスドメイン操作と最初のOPTIONS要求の間、サーバーは次のようなものを返します

 Access-Control-Allow-Origin: *
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

または

 Access-Control-Allow-Origin: example.com
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初のケースでは、どのドメインからでもSOPをバイパスできることが報告されています。2番目のケースでは、example.comのみです。 この場合、利用可能な方法などを指定できます。



ただし、デフォルトでは、ブラウザーが送信する識別データ（Cookieなど）はまだ送信されません。これは、ほとんどの場合に必要です。 タイトルを追加する必要があります

 Access-Control-Allow-Credentials: true
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これにより、Cookieを使用してクロスドメインリクエストをブラウザで実行するようになります（ユーザーセッションで作業できるようになります）。 しかし！ 最も興味深いのは、Allow-Originの設定ミスがすでにそれ自体を要求していることです：*（任意のサイト）+ Allow-Credentialsは一緒に機能しません。 ブラウザはCookieを送信せず、これは適切です（この場合、攻撃者はセッションでユーザーからアクションを実行できません）。 つまり このオプションは、特に許可されたドメインが指定されている場合にのみ機能します。



「出来事」について。 開発者は、GETパラメーター（カーテン）から許可ドメインを示します。

Webソケット

Web Sockets（WS）に関しては、まず第一に、かなり重要な変更を加えたいくつかの標準があることに注意する価値があります。 したがって、ここにはかなり一般的なものがあります

• WSには承認がありません（それぞれが完了します）
• WS-暗号化されていない形式でデータを送信します。 機密データにはWSSを使用します。
• サーバー（攻撃者はソケットにデータを書き込むこともできます）とクライアントの両方で、データ検証をキャンセルした人はいません
• データの送信元をチェックしても、ポイント1はキャンセルされません。
• ...

ここでは、不完全なものの（サービスワーカー-sirdarckcat.blogspot.ru/2015/05/service-workers-secureに加えて）owasp.orgを参照していますが、これは忙しい読み取り です-www.owasp.org/index.php/HTML5_Security_Cheat_Sheet -open -redirect.html 、 sirdarckcat.blogspot.ru / 2015/05 / service - workers - new - apis - new - vulns - fun.html ）

コンテンツセキュリティポリシー

一般的に、彼はそのようなブラウザです。だまされやすく、CSS / JS /画像からデータをダウンロードする場所を教えられ、そこからアップロードされました。 また、攻撃者がXSS攻撃中に別のドメインから悪意のあるjsファイルを単純に接続することも役立ちます。 XSS攻撃によるリスクを軽減するために（だけでなく）、コンテンツセキュリティポリシー（CSP）を考案しました。



このヘッダーは、ブラウザにリソースの読み込み元（たとえば、js）を示し、どこから読み込むことができないかを示します。 したがって、攻撃者はjsを挿入することさえできません（たとえば、インラインjs +信頼できるドメインからのみの外部が禁止されている場合）。





ホワイトリストにないドメインからのJSファイルの読み込みエラー



しかし、たとえば、アプリケーション（レター、メッセージ）がホワイトリストのドメインにある場合、攻撃者はjsをダウンロードして実行することができます。



詳細については、モスクワで行われたOWASP Russiaの最後の会議、プレゼンテーション-www.slideshare.net/OWASP-Russia/yourprezi-49135416を含め、CSPが何度も分析されました。

フラッシュ

本気ですか？ フラッシュについて？ 一般的にはい。 一部の人にとっては、これは関連性がありますが、多くの人にとって、歴史的には、まだどこかで機能しています。 はい、すでに今年は「新しい」バグのあるフラッシュを使用した大規模なケースが1つありましたが、RuNetには誰も書いていませんでした:(しかし、順番に見てみましょう。

crossdomain.xml

最も一般的なフラッシュ関連ファイルはcrossdomain.xmlファイルです。 これは、このドメインを操作するためのアプリケーションのフラッシュポリシーを示すxmlファイルです（ここでもSOPについて説明しています）。 ここでは、CORSの状況は機能しません。 任意のドメインが（Cookieとともに）アクセスできることが示されている場合-任意。 そして、これはもちろん悪いことです。 そのようなファイルの例：

 <cross-domain-policy> <allow-access-from domain="*" to-ports="80"/> </cross-domain-policy>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

任意のドメインのフラッシュドライブは、ユーザーのCookieとともにこのリソース（クロスドメインが存在する場所）にアクセスできます。 しかし、これは最も一般的なケースであり、より興味深いものです。



wamba.comでのバグハンティングの経験から、このファイルには多くのドメインがありました（リソースの名前を何度も移動し、変更していました）。 その結果、ファイルには有効期限が長いドメインが含まれています。 wamba.comユーザーを正常に登録して攻撃することができました。 彼らは3000（：

フラッシュ経由のXSS

XSSはFlashファイルでも可能です。 脆弱なASコードのサンプル

 getURL(_root.URI,'_targetFrame');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

操作例：

 http://victim/file.swf?URI=javascript:evilcode
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Flashはjavascript：に移動して、任意のJSコードを実行しようとします。 SWFは簡単に逆コンパイルできるため、ソースコードは（直接）必要ありません。 この攻撃方法の詳細については、 OWASP-www.owasp.org/index.php/Testing_for_Cross_site_flashing_ （OTG-CLIENT-008）にある機能のリストを参照してください。

CVE-2011-2461が帰ってきた！

さて、2015年からのフラッシュについてのちょっとした話から。この春Troopersは、動作するPoCと、Adobe Flex（脆弱性バージョン）で構築されたフラッシュファイルの古い脆弱性を悪用する方法を分析するツールを発表しました。 これは非常に人気のあるフラッシュ開発者フレームワークです。 そのようなベクトル-リソース上にそのようなフラッシュドライブ（脆弱なAdobe Flexでアセンブルされた）を見つけ、そのための特別なペイロード（リソース）を生成して接続します。 ロードされたドメインからのフラッシュドライブは、ペイロードで実行されています。 ボトムラインは再びSOPをバイパスしています。



そのようなファイル（SWFに脆弱かどうか）を確認するには、ツールgithub.com/ikkisoft/ParrotNGを使用できます。

 java -jar parrotng_v0.2.jar <SWF File | Directory>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

詳細情報

• blog.nibblesec.org/2015/03/the-old-is-new-again-cve-2011-2461-is.html
• www.slideshare.net/ikkisoft/the-old-is-new-again-cve20112461-is-back

この研究の著者は、このようなフラッシュドライブをGoogleやその他の有名なリソース（Qiwi、Yandexなど）で発見しました。 彼の「削減」:)

インフラストラクチャ情報漏洩

JS / CSSと同じリークが発生する可能性があります。 サーバー、APIキーなど

JSONPを介した開示

これについては、APIセキュリティに関する記事で既に書いていますが、この記事を完全にするために、繰り返す価値はあります。

APIはエンドユーザーだけでなく、プロジェクト内でデータを送信するために提供されることもあります。 これは、多くの場合、異なるドメインを持つ大規模なサイトで見られます。 そしてどういうわけか、クライアント側でドメイン間でやり取りする必要があり、ここでJSONPが助けになります。 これは、ドメイン1に必要なJSONがあり、コールバックになります。 ドメイン1にアクセスすると、ユーザーはCookieを送信します。ユーザーが承認されているかどうかを確認し、必要なデータを提供できます。 2番目のドメインでは、同様のJSが挿入されます

 <script type="application/javascript" src="http://server1.example.com/api/getUserInfo?jsonp=parseResponse"> </script>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

parseResponse関数が既に定義されています。 しかし、要点は、攻撃者がこのスクリプトを自分のドメインに貼り付け、コールバックを決定し、機密データがある場合はどうにかしてそれを使用できることです。 このような脆弱性の優れた使用例は、記事「Fighting Anonymity」に示されています。

Xフレームオプション

彼らは1000回と1回言ったようですが、再び繰り返します。 追加なしの各リソース。 設定はフレームに表示できます。 フレームには、現在のユーザーのCookie、つまり フレーム内で、許可されたリソースを開きます（もちろん、許可されている場合）。 このフレームは攻撃者によってそのページに埋め込まれ、アクションを要求する何かがボタンの上に描かれます（ボタンをクリックするなど）、ユーザーがクリックしますが、実際にはフレーム内の要素をクリックします（たとえば、グループにサブスクライブします）。 この攻撃はクリックジャックと呼ばれます。



Webサーバー応答のX-Frame-Optionsにより、

• ページがフレームに表示されないようにします
• 部分的に禁止（たとえば、同じ起源のみを許可）

VKでのclickJackingに関する記事

拡張機能/ SmartTV

ブラウザの機能を拡張するために、プラグイン（たとえば-Flash）がありますが、拡張機能があります。 2つ目は、HTML / CSS / JSのみを使用して記述されています。これについては、この記事で説明します。 SmartTVアプリケーションは、高度なTV API（カメラへのアクセスなど）を使用して同様の方法で作成されます。 そしてもちろん、ここで混乱することができます。 拡張機能のセキュリティについてはすでに説明しましたが、後でSmarTVアプリケーション（およびSmartTVユーザーの攻撃ベクトル）のセキュリティについて説明します。 私はビデオだけを残します

デザート用

さて、フロントエンドの読者の1人が「CSSを書いて、写真を挿入してください！ セキュリティについて教えてください！」...これが物語です。



参照による遷移時（「典型的な」条件で）

 <a href=“http://external.com”>Go!</a>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リクエスト内のブラウザは、リファラー、前のページのアドレスを渡します。 スタイル、写真などはどうですか？ 渡されたリファラーをロードしますか？ 私は今読んで停止し、自分のために質問に答えることをお勧めします。





なぜこれが悪いのですか？ hackerone.comリソースで、レイアウト設計者は...外部リソースから（ユーザーがGETパラメーターでトークンを取得する）パスワード回復ページにコミックを挿入しました。 その結果、このリソースの所有者は、このコミックをダウンロードするときに、パスワードをリセットするためのすべてのトークンをaccess.logで確認しました。 必要な自動化により、アカウントをすばやく「盗む」ことができます。

そして、それは見えるだろう-"私はちょうどhtmlに画像を挿入します"（：



パフォーマンスからのプレゼンテーション