Tag: Web Security

Directory Indexing Attacks: When Your Web Server Reveals Too Much

May 14, 2026

Directory Indexing occurs when a web server displays a file listing of a directory instead of the intended web page — typically because no default file (index.html, home.html, etc.) is present. While potentially harmless alone, it creates an information leakage vector that aids further attacks.

What Attackers Can Discover

  • Backup files with extensions .bak, .old, .orig
  • Temporary files not properly purged from the server
  • Hidden files starting with a period (.)
  • Naming conventions that reveal directory and admin path structure
  • Configuration files (.conf, .cfg) containing access control data
  • Script code in /cgi-bin/ if permissions are misconfigured

Controlling Indexing with .htaccess

# Disable all directory listing
Options -Indexes
# Block all files from appearing in listings
IndexIgnore *

The .htaccess file must be uploaded as ASCII (not binary) and set to permissions 644 to prevent browsers from reading it directly.

Prevention Guidance

  • Disable directory indexing in the web server’s Options Directive unless specifically required.
  • Use mod_security to detect directory-listing output in the HTTP response stream.
  • Ensure all directories that should not be browsable have a default index file or explicit deny rule.
  • Audit web server configurations after any structural changes.

Information Leakage Attacks: How Applications Unintentionally Reveal Sensitive Data

May 14, 2026

Information Leakage occurs when a web application unintentionally exposes sensitive data — through developer comments, verbose error messages, or plaintext content — that aids an attacker in planning SQL Injection, XSS, or other targeted attacks.

Three Categories of Information Leakage

CategoryExample
Comments in CodeHTML comment exposing server name: <!--If missing, restart VADER-->
Verbose Error MessagesSQL error revealing query structure and parameter names
Confidential Data in Plain SightCredentials or connection strings in source HTML

SQL Error Message Attack Example

Placing an apostrophe in a login field may trigger a verbose error such as:

System.Data.OleDb.OleDbException: Syntax error (missing operator)
in query expression 'username = ''' and password = 'g''

This reveals the username and password parameter names — exactly what an attacker needs to craft a SQL Injection payload.

Prevention Guidance

  • Filter all outbound data from web applications before sending to the client.
  • Intercept verbose database error messages and substitute a generic HTTP 500 response.
  • Strip all developer comments from HTML before deployment.
  • Redirect errors to a user-facing page that discloses no internal detail.
  • Transmit server-to-client data in encrypted form.
  • Remove or suppress server banners and version information.

HTTP Verb Tampering: Bypassing Security Controls with Unexpected HTTP Methods

May 14, 2026

HTTP Verb Tampering exploits Verb-Based Authentication and Access Control (VBAAC) mechanisms. When security rules explicitly list which HTTP methods are allowed, they inadvertently permit all unlisted methods. Attackers use HEAD, TRACE, or arbitrary strings like “JEFF” to bypass security constraints entirely.

The VBAAC Flaw (Java EE Example)

<security-constraint>
  <web-resource-collection>
    <url-pattern>/admin/*</url-pattern>
    <http-method>GET</http-method>
    <http-method>POST</http-method>
  </web-resource-collection>
  <auth-constraint><role-name>admin</role-name></auth-constraint>
</security-constraint>

This rule intends to restrict /admin/* to admins. In practice, a HEAD or “JEFF” request bypasses the rule and executes the admin function without authentication.

Avoid Sending Sensitive Data via GET

# NEVER — card number is logged in clear text in server logs:
http://www.example.com/process_card.asp?cardnumber=1234567890123456

Prevention Guidance

  • Enable “deny all” as the default — protect all HTTP methods, not just listed ones.
  • Remove all <http-method> elements from web.xml to protect methods equally.
  • Configure the server to disallow HEAD requests entirely.
  • Ensure all GET-accessible functions are idempotent (read-only, no state changes).

Site Probing: How Attackers Scan and Map Your Web Application

May 14, 2026

Site Probing is the initial reconnaissance phase of any web application attack. The attacker systematically maps the web application’s structure, pages, parameters, OS, database, and infrastructure — building a complete profile before launching targeted exploits.

Probing Methodology

  1. OS Detection: Identify via HTTP response headers, file extensions, or automated tools.
  2. Infrastructure Mapping: Directory traversal, database server identification, content platform discovery.
  3. Application Scanning: Map all pages, dynamic parameters, cookies, and transaction flows.

Attacker Techniques During Probing

TechniqueGoal
Non-Existent URLsGenerate error messages that reveal application structure
Long Parameter ValuesDetect buffer overflow candidates
Unauthorized Path AccessFind unprotected admin paths (/iisadmin/, /iissamples/)
Adding/Removing ParametersIdentify required vs optional parameters per URL

Important: Ports 80 and 443 must remain open for business. Traditional firewalls and IDS/IPS do not protect against application-layer probing — a dedicated Web Application Firewall (WAF) is required.

Prevention Guidance

  • Disable unnecessary protocols and lock down ports with firewall rules.
  • Configure web servers to suppress banner information.
  • Deploy an IDS configured to detect and reject scanning patterns.

OS Commanding Attacks: Injecting System Commands Through Web Applications

May 14, 2026

OS Commanding attacks compromise web applications by injecting Operating System commands through unsanitised input. The injected commands execute with the web server’s privileges — potentially giving the attacker access to the entire underlying OS and filesystem.

PHP Attack Example

http://example/directory.php?dir=%3Bcat%20/etc/passwd
# %3B = semicolon; shell reads: ls -la ; cat /etc/passwd
# Result: /etc/passwd contents returned to attacker

Perl Pipe Injection Example

http://example/cgi-bin/showInfo.pl?name=John&template=/bin/ls|
# Pipe character causes Perl's open() to execute /bin/ls

Prevention Techniques

  • Restrict OS Command Permissions: Apply least-privilege so the web server user cannot execute system commands maliciously.
  • Whitelist Allowed Characters: Input filter allowing only: !^[a-zA-Z/_-\.0-9]+$
  • Filter OS Command Paths: Block known OS command directories in output: /^(etc|bin|sbin|tmp|var|opt|dev|kernel)$/
  • Never pass unvalidated user input to shell execution functions (exec, system, popen).

SQL Injection: The Attack That Can Empty Your Entire Database

May 13, 2026

SQL Injection is one of the most prevalent web vulnerabilities. It involves passing crafted SQL commands through unsanitised input fields to interact directly with the backend database — potentially exposing, modifying, or deleting all data. Once exploited, it is equivalent to handing the attacker direct database access.

The Classic Bypass: ‘ or 1=1–

-- Normal authentication query:
SELECT * FROM users WHERE username='John' AND password='secret'
-- After injection of: ' or 1=1--
SELECT * FROM users WHERE username='John' AND password='' or 1=1--'
-- WHERE clause always TRUE → login bypassed

UNION Injection

SELECT header, txt FROM news
UNION ALL SELECT name, pass FROM members
-- Exposes all member credentials

Four Categories of SQL Injection

CategoryMechanism
SQL ManipulationModify WHERE clauses or use UNION to change query results
Code InjectionAppend EXECUTE commands to run arbitrary stored procedures
Function Call InjectionInject calls to database functions (mainly Oracle PL/SQL)
Buffer OverflowsExploit extended stored procedures to overflow memory

Prevention Guidance

  • Use parameterised queries / prepared statements in all database interactions — this is the primary defence.
  • Filter all input: strip single quotes, double quotes, slashes, backslashes, semicolons, NULL, and carriage returns.
  • Convert numeric values to integers before using in SQL; validate with ISNUMERIC.
  • Run the database server with a low-privilege account.
  • Delete unused stored procedures (xp_startmail, xp_sendmail, sp_makewebtask).
  • Never return detailed database error messages to users.