> For the complete documentation index, see [llms.txt](https://anekant-singhais-organization.gitbook.io/why-so-script-kiddie/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://anekant-singhais-organization.gitbook.io/why-so-script-kiddie/ctfs/htb-challenges/web/waywitch.md).
# WayWitch
## Looking at the code
The code is uses `NodeJs` framework which has this kind of file system:
```
├── build-docker.sh
├── config
│ └── supervisord.conf
├── Dockerfile
├── entrypoint.sh
├── flag.txt
└── src
├── database.js
├── index.js
├── package.json
├── routes
│ └── index.js
├── static
│ ├── css
│ │ ├── bootstrap.min.css
│ │ └── main.css
│ ├── images
│ │ └── logo.png
│ └── js
│ └── jose.min.js
├── util.js
└── views
└── index.html
```
**`util.js`**
* Contains utility functions shared across the application.
* Example tasks:
* File system operations.
* Generating or validating tokens.
* Parsing data or configurations
#### `Src/`
The folder that contains the core logic and handling of the web server
**`Database.js`**
Implements the database connection and sets up the tables according to the defined schema
We can see there's some kind of ticketing system going on which maybe used to authenticate the users. We also see that these tickets are made of `id` , `name` , `username`, `content`:
Look how the admin ticket contains the flag
Also the description said to craft the ticket
**`Index.js`**
* The application’s main entry point.
* Sets up:
* **Express server**.
* Middleware (e.g., for serving static files or handling requests).
* Routes (from `routes/index.js`).
* Also there's **`package.json`** file that defines what scripts to run
**`Routes/`**
* Contains route definitions (`index.js`).
* Responsible for:
* Handling HTTP requests.
* Sending responses (e.g., rendering views or returning JSON data).
The router is defined with `casesensitive:true` meaning they require exact word for the route. Now looking at the routes itself:
***
**1. `GET /tickets`**
* **Purpose:** Fetches all tickets, restricted to admin users.
* **Workflow:**
1. **Checks for Session Token:**
* Retrieves the `session_token` from cookies.
* If missing, returns a `401 Unauthorized` status.
2. **Validates the Token:**
* Decodes the `session_token` using `getUsernameFromToken`.
* If invalid, returns a `400 Bad Request` with the error message.
3. **Checks Admin Privileges:**
* If the username is not `"admin"`, returns `403 Forbidden`.
4. **Fetches Tickets:**
* Calls `db.get_tickets()` to retrieve all tickets.
* If successful, returns a `200 OK` with the tickets as a JSON object.
* On failure, returns `500 Internal Server Error`.
***
**2. `POST /submit-ticket`**
* **Purpose:** Allows authenticated users to submit a new ticket.
* **Workflow:**
1. **Checks for Session Token:**
* Retrieves `session_token` from cookies.
* If missing, returns `401 Unauthorized`.
2. **Validates the Token:**
* Decodes the `session_token` using `getUsernameFromToken`.
* If invalid, returns `400 Bad Request` with the error message.
3. **Validates Request Body:**
* Extracts `name` and `description` from the request body.
* If either is missing, returns `400 Bad Request`.
4. **Adds a Ticket:**
* Calls `db.add_ticket(name, username, description)` to insert the ticket into the database.
* If successful, returns `200 OK` with a success message.
* On failure, returns `500 Internal Server Error`.
## Browsing the application
shall we use the data we got from database file?
So we looked at the code , now we know how app works , let's test the theory:
JSon huh
So we control the name and description from client side and also:
So we craft a token to get the flag from the admin description as seen above in the code. We need the jwt secret for that -> which is in the `utils.js` file.
Not So Secret huh?
Then we craft the token:
and get the cookie:
```
HTB{k33p_th3s3_jwt_s3cr3t_s4f3f_br0}
```