nerdexam
GIAC

GCIH · Question #683

A system administrator finds the entry below in an Apache log. What can be done to mitigate against this? 192.168.116.201 - - [22/Apr/2016:13:43:26 -0400] 'GET +mysql.user+limit+0%2C1%29%3D1 HTTP/1.1'

The correct answer is C. Filter user input before it gets passed to the application. The Apache log entry reveals a SQL injection attempt targeting the mysql.user table via URL-encoded query parameters; server-side input filtering is the correct mitigation.

Web Application Attacks & Post-Exploitation

Question

A system administrator finds the entry below in an Apache log. What can be done to mitigate against this? 192.168.116.201 - - [22/Apr/2016:13:43:26 -0400] 'GET +mysql.user+limit+0%2C1%29%3D1 HTTP/1.1' 200 453 '-' 'Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0'

Options

  • AFilter user input using Javascript on the client browser
  • BReduce the permissions of the user account running the web application
  • CFilter user input before it gets passed to the application
  • DCreate drop-downs for users to choose their search terms

How the community answered

(23 responses)
  • A
    4% (1)
  • B
    9% (2)
  • C
    83% (19)
  • D
    4% (1)

Why each option

The Apache log entry reveals a SQL injection attempt targeting the mysql.user table via URL-encoded query parameters; server-side input filtering is the correct mitigation.

AFilter user input using Javascript on the client browser

Client-side JavaScript filtering is trivially bypassed by an attacker who can craft raw HTTP requests, as demonstrated by this log entry which was sent directly without a browser form.

BReduce the permissions of the user account running the web application

Reducing web application account privileges follows the principle of least privilege and limits damage if exploitation succeeds, but it does not prevent the SQL injection from being attempted or from returning data.

CFilter user input before it gets passed to the applicationCorrect

The log shows URL-encoded characters (%2C, %3D) forming a SQL fragment referencing mysql.user, confirming an in-band SQL injection attempt sent through the HTTP GET parameter. Server-side input validation and sanitization - using parameterized queries, prepared statements, or an input filtering library - prevents malicious SQL fragments from ever reaching the database engine, addressing the root cause regardless of client behavior.

DCreate drop-downs for users to choose their search terms

Drop-down menus can be bypassed by intercepting and modifying HTTP requests; an attacker can still inject arbitrary SQL via direct HTTP calls, so this does not constitute a reliable mitigation.

Concept tested: Server-side input validation to prevent SQL injection

Source: https://owasp.org/www-community/attacks/SQL_Injection

Topics

#SQL injection#input validation#Apache log analysis#web application defense

Community Discussion

No community discussion yet for this question.

Full GCIH Practice