Posts

My blog runs as a static S3 origin behind CloudFront, deployed by Terraform and GitHub Actions. The edge was producing access logs, but they were sitting inert in object storage. I could not yet answer questions and produce intelligence like: Who is requesting what? Why are certain clients requesting paths or filenames that result in 403 or 404? How often does CloudFront serve from cache versus reaching back to S3?

I wired up a GitHub Actions pipeline that runs terraform plan in the PR prior to merge. However before Terraform can pull the reality state of my existing AWS infrastructure to compare against terraform.tfstate and declarative *.tf files, the CI pipeline first needs to assume a properly scoped AWS IAM role. The mechanism for this depends on OIDC federation. This post walks through the technical procedure of issuing an OIDC token from the .yml pipeline, how the AWS IAM console is used to define authorization parameters, and finally how the CI pipeline uses those temporary AWS credentials to complete its Terraform job.

While cleaning up the CloudFront configuration for this blog, I removed a www.jhuk.tech → jhuk.tech 301 redirect that I assumed was redundant. My reasoning was simple: if both hostnames point at the same CloudFront distribution and the same S3 bucket, then both should serve the same site. Why force a redirect at all?

After deploying the change, I noticed something strange. The apex domain https://jhuk.tech rendered perfectly, but https://www.jhuk.tech returned the same page as a wall of unstyled HTML — no theme, no layout, no JavaScript. Two URLs, the same bytes on the server, two completely different experiences in the browser. This post is a breakdown of why that happened and the tradeoffs I weighed before settling on a fix.

For years, I used a managed WordPress instance behind a cPanel host to write this blog. Initially it was a great way to learn. I was able to abstract away hosting-as-a-service. But Wordpress exposes an administrative login page and my comments section was open to the public internet which resulted in many cybersecurity issues such as brute-force authentication and botnets posting XSS payloads and gambling links. As my interests grew farther into cloud and DevOps, I wanted my own site to reflect the way I now think about infrastructure—version-controlled, reproducible, and declarative in nature.

In the field of Cybersecurity and DevOps, there is no substitute for hands-on experience with cloud infrastructure. To further my own practice, I have recently started diving into the Microsoft Azure ecosystem. It’s an excellent sandbox for learning with $100 in credits and 750 hours of B1s compute, you have exactly what you need to keep a single VM instance running 24/7 while you experiment.

For this project, I set out to deploy a custom Nginx web server on a Linux VM. Here is a breakdown of the configuration and the logic behind my deployment.

I use Python locally within Visual Studio Code to call a public API. The goal of this exercise is not only to make a successful HTTP request, but also to understand the individual parts of a small Python script that interacts with a real internet service.

A good beginner API for this type of project is the GitHub REST API. This API is useful because it allows new developers to practice with real-world data while learning concepts that commonly appear in professional software development. These concepts include HTTP status codes, JSON responses, environment variables, API tokens, error handling, and storing project dependencies in a local virtual environment.

All modern websites consist of at least 3 fundamental components: HTML, CSS, and JavaScript. HTML creates structure, CSS is used for styling, and JavaScript enables interactive user experiences through manipulation of the DOM (Document Object Model). JavaScript however, can also be used by malicious actors to access sensitive information on the client-side. One major category of web application vulnerabilities is known as cross-site scripting (XSS). This vulnerability occurs precisely due to any malicious user’s ability to inject JS code into a vulnerable website. If proper security controls are not implemented, this vulnerability makes it possible for an attacker to read and steal an end-user’s cookies and session information that otherwise should be private and confidential.

In this lab exploring HTML forms-based authentication, I use Burp Suite to fuzz a username of interest to discover a valid password combination. “Fuzzing” in the context of web application security means any automated attempt to inject a large number variables into any field that accepts user input. The tester then monitors the application for unexpected behavior or unusual results that may indicate the presence of a vulnerability. Possibilities for fuzzing input ranges from common usernames, passwords, URLs, sensitive data patterns, executable shell commands and SQLi payloads. SecLists is a well-known repository that maintains wordlists for each of these mentioned categories. The choice of which wordlist to use depends on the context of the input field and what category of vulnerability the tester suspects may exist within the application.

An interception proxy is a must-have tool in any web application penetration tester’s arsenal. In brief, an interception proxy is an application downloaded on a host computer and sits in-between a client browser and the remote web server. This specialized tool is purpose-built to intercept HTTP requests that are initiated from the client browser before the message is delivered to the remote web server. The tool can manipulate certain elements of the request such as session cookies or parameter values. The application proxy also handles the HTTP response in-reverse, meaning the tool can examine the raw data contained in the server’s response before the content is ultimately rendered by the client browser.

In the world of digital forensics, we can envision data as belonging to two distinct categories. Those categories are either volatile, or non-volatile states of data (Mohanta, 2020). Volatile data includes random-access memory (RAM) that depends on a running power supply, whereas read-only memory (ROM) or data that is written to a hard disk is considered non-volatile. The readable contents of non-volatile data do not change upon power interruption. The industry standard open source tool I will explore this week to conduct memory forensics on traditional desktop endpoints has aptly been named Volatility.