Simplify the structure of the introduction (#80)

* Simplify the structure of the introduction

I'm taking a stab at a small reorganization of the introduction to try and make it flow a little better. 

This PR aims to leave the original meaning intact, while also tightening some of the prose and removing things that don't seem critical in the introduction. Specifically, it:
- Removes the mention of CSRF in the overview. Since we're discussing a different class of vulnerabilities, and CSRF is not a canonical example of an XS-leak (and may not be immediately known to all readers), I think we could omit it without loss of understandability.
- Moves some of the explanation of how an XS-leak works from the "Principle" section into the "Overview". I think the "Principle" section reads nicely when it focuses on introducing the notion of an oracle and the questions that leak data. The more general information, such as what kind of information can be learned via an XS-leak, seems to fit in well in the "Overview".
- (Less importantly) It changes the capitalization of some terms to lowercase. E.g. "same-origin policy" is commonly lowercased, except when it's in a heading. I've also lowercased it as "cross-site leaks" in the first sentence, because I think it's _slightly_ more common to lowercase XSS and CSRF when expanding the acronyms (this is what Wikipedia and PortSwigger do; OWASP title-cases them, but I think they're in the minority.)

This is just an idea -- if you feel like some pieces of this PR are useful while others aren't, let me know and I can revert the bad ones.

* Add mention of XS-leak principles in text, change section heading

* Add the CSRF reference back

Co-authored-by: terjanq <terjanq@users.noreply.github.com>

* Add the CSRF reference in the footer.

* Update content/_index.md

Co-authored-by: terjanq <terjanq@users.noreply.github.com>

content/_index.md

@@ -7,28 +7,29 @@ bookToc: false
 # XS-Leaks Wiki
 ## Overview
 
-Cross-site leaks (aka XS-Leaks, XSLeaks) are a class of vulnerabilities derived from browser side-channel techniques [^side-channel]. These techniques are similar to Cross-site request forgery [^csrf] (CSRF) techniques, but instead of allowing other websites to perform actions on behalf of a user, they can be used to infer information about a user. This is done by exploiting a variety of features built in to browsers [^browser-features].
+Cross-site leaks (aka XS-Leaks, XSLeaks) are a class of vulnerabilities derived from side-channels [^side-channel] built into the web platform. They take advantage of the web's core principle of composability, which allows websites to interact with each other, and abuse legitimate mechanisms [^browser-features] to infer information about the user. One way of looking at XS-Leaks is to highlight their similarity with cross-site request forgery (CSRF [^csrf]) techniques, with the main difference being that instead of allowing other websites to perform actions on behalf of a user, XS-Leaks can be used to infer information about a user. 
 
+Browsers provide a wide variety of features to support interactions between different web applications; for example, they permit a website to load subresources, navigate, or send messages to another application. While such behaviors are generally constrained by security mechanisms built into the web platform (e.g. the [same-origin policy](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy)), XS-Leaks take advantage of small pieces of information which are exposed during interactions between websites. 
 
-## The principle of an XS-Leak
+The principle of an XS-Leak is to use such side-channels available on the web to reveal sensitive information about users, such as their data in other web applications, details about their local environment, or internal networks they are connected to.
 
-The fact that websites interact with each other is core to the behavior of the web. Browsers provide a wide variety of interfaces to support such interactions between different web applications. These interfaces have different security measures built on top which are intended to constrain the behavior of websites (e.g. the [Same-Origin Policy](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy)). XS-Leaks take advantage of small pieces of information that can leak during these interactions in order to infer sensitive information about users such as their data on other websites, operating systems they use, or internal networks they are connected to.
+## Cross-site oracles
 
-These pieces of information usually have a binary form and are referred to as "oracles". These oracles usually answer with *YES* or *NO* to cleverly prepared questions. For example, an oracle can be asked:
+The pieces of information used for an XS-Leak usually have a binary form and are referred to as "oracles". Oracles generally answer with *YES* or *NO* to cleverly prepared questions in a way that is visible to an attacker. For example, an oracle can be asked:
 
-> Does the word *secret* exist in the search results?
+> Does the word *secret* appear in the user's search results in another web application?
 
-In a vulnerable application, the above question might be equivalent to asking:
+This question might be equivalent to asking:
 
-> Does the query *?query=secret* return *HTTP200* status code?
+> Does the query *?query=secret* return an *HTTP 200* status code?
 
-Since it is possible to detect the *HTTP200* status code with [Error Events]({{< ref "./docs/attacks/error-events.md" >}}), this has the same effect as asking:
+Since it is possible to detect the *HTTP 200* status code with [Error Events]({{< ref "./docs/attacks/error-events.md" >}}), this has the same effect as asking:
 
-> Does the query *?query=secret* trigger the *onload* event?
+> Does loading a resource from *?query=secret* in the application trigger the *onload* event?
 
-The above query could be repeated by an attacker for many different keywords, and as a result the answers could be used to infer sensitive information about the user from a cross-site website.
+The above query could be repeated by an attacker for many different keywords, and as a result the answers could be used to infer sensitive information about the user's data.
 
-Browsers provide a wide range of different APIs that, while well-intended, can end up leaking small amounts of cross-origin information.
+Browsers provide a wide range of different APIs that, while well-intended, can end up leaking small amounts of cross-origin information. They are described in detail throughout this wiki.
 
 ## Example