This is a brief introduction to server-side vulnerabilities from ground level. The goal is to summarize my learning progress in Web Security Academy.

A vulnerability is a defect in a system that causes behavior different from the intended design. Such defects arise mainly from:

incomplete or incorrect implementation of functionality; or
unforeseen interactions between components.

Path traversal

A path traversal vulnerability lets an attacker read arbitrary files on the server (credentials, system files, application code) by manipulating filesystem paths.

Example:

Client request:

GET /loadImage?filename=001.png HTTP/1.1
Host: server.domain

Server may build:

/var/www/images/001.png

If the attacker requests:

GET /loadImage?filename=../../../etc/passwd

the server may attempt to read /var/www/images/../../../etc/passwd, which canonicalizes to /etc/passwd. The passwd file lists user account information on Unix-like systems.

Access control & authentication

Authentication verifies identity; authorization decides allowed actions. Vulnerabilities include bypassing identification or missing server-side authorization checks.

Horizontal escalation: access another user’s resources.
Vertical escalation: gain higher privileges (user → admin).

The worst practices: relying purely on hidden UI, robots.txt, or client-side checks. These provide not only no real protection, but also risk leaking the important URLs like /admin.

Server-side Request Forgery (SSRF)

SSRF occurs when the server makes HTTP (or other) requests using attacker-controlled URLs and thus can be forced to access internal services or cloud metadata endpoints.

Example parameter:

stockApi=http://stock.weliketoshop.net:8080/product/stock/check?productId=6&storeId=1

If attacker supplies http://127.0.0.1/admin, the server may request internal endpoints.

Server sometimes accept URLs from client and make requests on their behalf because of design or operational assumptions, for example:

The access control is handled by an external component that sits in front of the server, such as reverse proxy or API gateway and a check is bypassed when a connection is made back to the server from that component.
For disaster recovery purposes, the application might allow administrative access without logging if a user comes from the local machine.
The admin interface is not directly reachable by external user, for example, listen on a different port. These assumptions can become vulnerabilities if they are not implemented properly.

File upload vulnerabilities

Insecure file upload can allow shell upload, code execution, or data exfiltration.

Problems with naive checks:

Checking only Content-Type or user-supplied filename is insufficient.
Double extensions and polyglot files can bypass simple checks.

OS command injection

If the application constructs shell commands from user input and invokes a shell, attackers can inject commands using shell metacharacters (e.g., ;, &&, |, &, backticks).

Example:

stockreport.pl 381 29

Attacker supplies & echo hello & and the invoked command becomes:

stockreport.pl & echo hello & 29

which leads to unexpected execution.

SQL injection (SQLi)

Concatenating user input into SQL queries allows attackers to alter query semantics. Example:

SELECT * FROM users WHERE username='admin'--' AND password='pass';

Mitigations

Use parameterized queries / prepared statements and proper escaping.
Use least-privilege DB accounts; separate read vs write permissions.
Use input validation & allowlist where possible (e.g., integers).
Logging & alerting on suspicious query patterns or errors.

Shell scripts

Below are some of the scripts I used in learning labs.

#!/usr/bin/env bash
set -euo pipefail

cookie_file=$(mktemp)

get_csrf() {
  local src="${1:--}"
  local result
  result=$(xmllint --html --xpath 'string(//input[@name="csrf"]/@value)' "$src" 2>/dev/null || true)
  printf '%s' "$result"
  printf 'using csrf token:%s\n' "$result" >&2
}

login() {
  local login_url="$1"
  local username="$2"
  local password="$3"
  local csrf_token
  local resp

  csrf_token=$(curl -sS -L -b "$cookie_file" -c "$cookie_file" -- "$login_url" | get_csrf)
  # Use --data-urlencode to ensure values are encoded
  resp=$(curl -sS -L -b "$cookie_file" -c "$cookie_file" \
         --data-urlencode "csrf=$csrf_token" \
         --data-urlencode "username=$username" \
         --data-urlencode "password=$password" \
         -- "$login_url")
  printf '%s\n' "$resp"
}

login "$@"

Scan links (robust href extraction)

#!/usr/bin/env bash
set -euo pipefail

scan_link() {
  local url="$1"
  printf 'Scanning: %s\n' "$url"
  curl -sS -L -- "$url" \
    | xmllint --html --xpath '//a/@href' - 2>/dev/null \
    | sed -E 's/href="([^"]*)"/\1\n/g' \
    | sed '/^$/d'
}

if [[ $# -eq 0 ]]; then
  echo "Usage: $0 <url>"
  exit 1
fi

scan_link "$1"

IP scan

#!/usr/bin/env bash
set -euo pipefail

scan_ip() {
  local url="$1"
  for ((i = 0; i <= 255; i++)); do
    local ip="192.168.0.$i"
    printf 'scan: %s --> ' "$ip"
    # capture output, but avoid exiting on grep failing
    local out
    out=$(curl -s -X POST -F "stockApi=http://$ip:8080/admin" -- "$url" || true)
    if printf '%s' "$out" | grep -qF "Could not connect"; then
      echo "Miss"
    else
      echo "Find"
    fi
  done
}

if [[ $# -eq 0 ]]; then
  echo "Usage: $0 <url>"
  exit 1
fi

scan_ip "$1"

Notes: Use || true to prevent set -e from exiting on non-zero exit codes where handled, then inspect output.