docs(security): improve xsrf description and add it to http chapter as well

Author: wardbell

public/docs/ts/latest/guide/security.jade

@@ -200,11 +200,12 @@ h2#http HTTP-level vulnerabilities
 
 h3#xsrf Cross-site request forgery
 :marked
-  In a cross-site request forgery, an attacker tricks the user into visiting a
-  _different_ page and has them, for example, submit a form that sends a request to your application's
-  web server. If the user is logged into your application, the browser will send authentication
-  cookies, and the attacker could—for example—cause a bank transfer in the user's name with
-  the right request.
+  In a cross-site request forgery (CSRF or XSRF), an attacker tricks the user into visiting
+  a different web page with malicious code that secretly sends a request to your application's web server. 
+  If the user is logged into your application, the browser sends the request along with authentication cookies.
+  An _unprotected_ server can't tell the difference between a legitimate request and a forged request.
+  
+  In this manner, for example, a knowledgable attacker could transfer money from the user's account to the attacker's account.
 
   To prevent this, your application must ensure that user requests originate in your own
   application, not on a different site. A common technique is that the server sends a randomly
@@ -213,27 +214,36 @@ h3#xsrf Cross-site request forgery
   each API request, the server then validates the client by checking that the token is sent back,
   usually in an HTTP header called `X-XSRF-TOKEN`.
 
-  The Angular `http` client has built-in support for this technique. The default
-  `CookieXSRFStrategy` looks for a cookie called `XSRF-TOKEN` and sets an HTTP request header named
-  `X-XSRF-TOKEN` with the value of that cookie on every request. The server must set the
-  `XSRF-TOKEN` cookie and validate the response header for each state-modifying request.
+  Angular's `http` has built-in support for the client-side half of this technique in its `XSRFStrategy`. 
+  The default `CookieXSRFStrategy` is turned on automatically.
+  During each HTTP request, the `CookieXSRFStrategy` looks for a cookie called `XSRF-TOKEN` and 
+  sets a header named `X-XSRF-TOKEN` with the value of that cookie. 
+  
+  The server must do its part by setting the
+  initial `XSRF-TOKEN` cookie and confirming that each subsequent state-modifying request
+  includes a matching `XSRF-TOKEN` cookie and `X-XSRF-TOKEN` header.
 
-  CSRF tokens should be unique per user and session, have a large random value generated by a
-  cryptographically secure random number generator, and expire.
+  XSRF/CSRF tokens should be unique per user and session, have a large random value generated by a
+  cryptographically secure random number generator, and should expire after a reasonably short period of time.
 
-  Angular applications can customize cookie and header names by binding their own
-  `CookieXSRFStrategy` value or implement an entirely custom `XSRFStrategy` through providing a custom
-  binding for that type by adding either of the following to your providers list:
+  Angular applications can customize cookie and header names by providing their own `CookieXSRFStrategy` values.
+code-example(language="typescript").
+  { provide: XSRFStrategy, useValue: new CookieXSRFStrategy('myCookieName', 'My-Header-Name') }
+:marked
+  Or you can implement and provide an entirely custom `XSRFStrategy`:
 
 code-example(language="typescript").
-  { provide: XSRFStrategy, useValue: new CookieXSRFStrategy('myCookieName', 'My-Header-Name')}
-  { provide: XSRFStrategy, useClass: MyXSRFStrategy}
+  { provide: XSRFStrategy, useClass: MyXSRFStrategy }
 
 :marked
   For information about CSRF at the Open Web Application Security Project (OWASP) see
-  [Cross-Site Request Forgery (CSRF)](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29) and
-  [Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet](https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet). The Stanford University
-  paper [Robust Defenses for Cross-Site Request Forgery](https://seclab.stanford.edu/websec/csrf/csrf.pdf) is also a rich source of detail.
+  <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29" target="_blank">Cross-Site Request Forgery (CSRF)</a> and
+  <a href="https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet" target="_blank">Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet</a>.
+  The Stanford University paper 
+  <a href="" target="_blank">Robust Defenses for Cross-Site Request Forgery</a> is a rich source of detail.
+
+  See also Dave Smith's masterful, easy-to-understand 
+  <a href="https://www.youtube.com/watch?v=9inczw6qtpY" target="_blank" title="Cross Site Request Funkery Securing Your Angular Apps From Evil Doers">talk on XSRF at AngularConnect 2016</a>.
 
 h3#xssi Cross-site script inclusion (XSSI)
 :marked

public/docs/ts/latest/guide/server-communication.jade

@@ -27,11 +27,12 @@ block includes
   - [Always handle errors](#error-handling).
   - [Send data to the server](#update).
   <li if-docs="ts"> [Fall back to promises](#promises).</li>
-  - [Cross-origin requests: Wikipedia example](#cors).
+  - [Cross-Origin Requests: Wikipedia example](#cors).
     <ul if-docs="ts">
       <li> [Search parameters](#search-parameters).</li>
       <li> [More fun with observables](#more-observables).</li>
     </ul>
+  - [Guarding against Cross-Site Request Forgery](#xsrf)
   - [Appendix: Tour of Heroes in-memory server](#in-mem-web-api).
 
   A <live-example>live example</live-example> illustrates these topics.
@@ -46,7 +47,7 @@ block demos-list
   :marked
     - [The Tour of Heroes *HTTP* client demo](#http-client).
     - [Fall back to !{_Promise}s](#promises).
-    - [Cross-origin requests: Wikipedia example](#cors).
+    - [Cross-Origin Requests: Wikipedia example](#cors).
     - [More fun with observables](#more-observables).
 
 :marked
@@ -446,7 +447,7 @@ block hero-list-comp-add-hero
 
       To understand the implications and consequences of subscriptions, watch [Ben Lesh's talk on observables](https://www.youtube.com/watch?v=3LKMwkuK0ZE) or his video course on [egghead.io](https://egghead.io/lessons/rxjs-rxjs-observables-vs-promises).
 
-h2#cors Cross-origin requests: Wikipedia example
+h2#cors Cross-Origin Requests: Wikipedia example
 :marked
   You just learned how to make `XMLHttpRequests` using the !{_Angular_Http} service.
   This is the most common approach for server communication, but it doesn't work in all scenarios.
@@ -628,6 +629,26 @@ block wikipedia-jsonp+
       You added the `debounceTime`, `distinctUntilChanged`, and `switchMap` operators to the RxJS `Observable` class
       in `rxjs-operators` as [described above](#rxjs).
 
+a#xsrf
+.l-main-section
+:marked
+  ## Guarding against Cross-Site Request Forgery
+
+  In a cross-site request forgery (CSRF or XSRF), an attacker tricks the user into visiting
+  a different web page with malicious code that secretly sends a request to your application's web server. 
+  If the user is logged into your application, the browser sends the request along with authentication cookies.
+  An _unprotected_ server can't tell the difference between a legitimate request and a forged request.
+  
+  In this manner, for example, a knowledgable attacker could transfer money from the user's account to the attacker's account.
+
+  The server and client application must work together to thwart this attack.
+  In one common technique, the server sends a randomly
+  generated authentication token in a cookie, often named `XSRF-TOKEN`. 
+  The HTTP client adds that token to the request header, typically named `X-XSRF-TOKEN`, of subsequent requests. 
+  The server receives both the cookie and the header, compares them, and processes the request only if the cookie and header match.
+  
+  Angular's `Http` client supports this strategy automatically. See the [XSRF topic on the Security page](security.html#xsrf) for more information.
+
 a#in-mem-web-api
 .l-main-section
 :marked