Post cover image

October 14, 2026

Irish-Name-Repo 1 : CTF Write-up | SQL Injection Authentication Bypass

Introduction

By Affanhaxor

5 min read

Introduction

Login forms are one of the most common features of web applications. Usually, a website checks the username and password against records stored in a database before allowing access.

But what happens when the application builds its database query directly from user input?

In the Irish-Name-Repo 1 CTF challenge, the website provides an Irish-themed page with an admin login option. The goal is to understand how the login mechanism works and discover a way to authenticate without knowing the actual password.

This challenge introduces SQL injection (SQLi), a vulnerability that occurs when untrusted input is incorporated into a database query in an unsafe way. By examining the login behavior and testing a carefully constructed username, I was able to bypass the login and retrieve the flag.

Challenge Overview

The homepage is titled "List 'o the Irish!" and displays a collection of portraits. At first, there is no obvious indication of a vulnerability. The navigation menu provides access to an admin login page, which becomes the main focus of the investigation.

Challenge: Irish-Name-Repo 1

Category: Web Exploitation

Learning platform: CyLab Security Academy

None

Step 1: Finding the Admin Login Page

I started by exploring the homepage and opening the hamburger menu in the top-left corner.

The menu displayed two options: Support and Admin Login. Since the challenge involved authentication, I selected Admin Login to inspect the login form.

This was an important first step because it identified the part of the application that needed further testing.

None

Step 2: Testing the Login Form

The login page contained two fields:

  • Username
  • Password

I entered admin as the username and a password to test the normal authentication process.

The application returned the message:

Login failed.

This confirmed that the credentials I supplied were not accepted. Instead of continuing to guess passwords, I considered whether the application might be handling the submitted input insecurely.

A login form that interacts with a database can be vulnerable if the application inserts user input directly into its SQL query.

None None

Step 3: Understanding the SQL Injection Possibility

A vulnerable login system might construct a database query similar to this:

SELECT * FROM users
WHERE username = 'USER_INPUT'
AND password = 'PASSWORD_INPUT';

This is an illustrative example of how a login query might be constructed; it is not a claim that the challenge uses this exact SQL statement.

The problem occurs when the application combines user input with SQL syntax without using parameterized queries. Special characters entered into the form can then change how the database interprets the query.

For example, a single quote can affect the boundaries of a quoted string. SQL comment syntax can also cause the database to ignore the remainder of a statement.

With this in mind, I decided to test the username field rather than keep guessing passwords.

Step 4: Testing the Username Input

I returned to the login form and changed the username from:

admin

to:

admin'--

I left the password field populated and submitted the form again.

The important part of this input is the combination of the single quote and the two hyphens.

  • The single quote can close the username string in a vulnerable SQL query.
  • The -- sequence can begin a SQL comment, causing the remaining part of the query to be ignored when the database recognizes the comment syntax.

If the application constructs its query unsafely, this can remove the password condition from the effective query and allow the login check to succeed.

None

Step 5: Successfully Logging In

After submitting the modified username, the application displayed:

Logged in!

The page also showed the challenge flag.

This confirmed that the input had changed the behavior of the authentication process. Instead of validating the correct password normally, the vulnerable login logic accepted the modified query.

The challenge was therefore solved through SQL injection rather than password guessing.

None

Flag

academy{s0m3_SQL_271c9a2b}

Why Did This Work?

The underlying issue was an unsafe interaction between user input and SQL query construction.

The application apparently allowed the username field to influence the SQL statement's structure. The injected quote and comment marker changed how the database interpreted the authentication query, allowing the password check to be bypassed.

This is known as SQL injection authentication bypass.

The important distinction is that the payload did not discover the real password. It manipulated the query used to verify the login.

The exact SQL statement and database engine are not visible in the screenshots, so the example query above should be treated as an illustration of the vulnerability rather than the confirmed implementation.

Security Lessons Learned

This challenge highlights several important web security concepts:

  • Never trust user input: Form fields can contain special characters and unexpected values.
  • SQL injection can bypass authentication: Unsafe query construction can allow users to change the meaning of a database query.
  • Do not rely on input filtering alone: Blocking a few suspicious characters is not a reliable substitute for safe query construction.
  • Test behavior, not just appearance: A login page may look simple while its backend contains a serious vulnerability.
  • Use prepared statements: Parameterized queries separate SQL commands from user-supplied data and are the primary defense against SQL injection.

How Can This Vulnerability Be Prevented?

Developers should use parameterized queries or prepared statements instead of concatenating user input into SQL statements.

For example, in Python with SQLite:

cursor.execute(
    "SELECT * FROM users WHERE username = ? AND password = ?",
    (username, password)
)

Here, the database driver treats the supplied values as data rather than interpreting them as part of the SQL syntax.

A real application should also:

  1. Store passwords using a suitable password-hashing algorithm.
  2. Validate and normalize input where appropriate.
  3. Return generic authentication errors that do not expose internal database details.
  4. Apply least-privilege permissions to database accounts.
  5. Test authentication logic for injection vulnerabilities before deployment.

Input validation and a web application firewall can provide additional protection, but they should not replace parameterized queries.

Conclusion

Irish-Name-Repo 1 demonstrates how a small mistake in SQL query construction can undermine an entire login mechanism.

By exploring the homepage, locating the admin login form, testing the username field, and using admin'--, I was able to bypass authentication and retrieve the flag.

The biggest takeaway is that user input must always be treated as data, never as trusted SQL syntax.

This challenge is a useful starting point for understanding SQL injection, authentication bypass, and the importance of secure database interactions in web applications.

Further Reading

Connect With Me

LinkedIn: https://www.linkedin.com/in/affanhaxor

Instagram: https://instagram.com/affan_haxor

Follow me for more CTF write-ups, web security labs, and AppSec content.