지식로그
G03zWTL1' OR 853=(SELECT 853 FROM PG_SLEEP(15))--

[질문] G03zWTL1' OR 853=(SELECT 853 FROM PG_SLEEP(15))--

2025.02.20. 15:12:18 | 문서번호: 21998

전체 답변:
[무물보AI]

That string is a time-based SQL-injection payload targeting PostgreSQL. Briefly what it does and what to do about it:

What the payload does

  • "G03zWTL1'": closes a quoted string in an SQL statement.
  • "OR 853=(SELECT 853 FROM PG_SLEEP(15))": injects a boolean expression that evaluates after the subquery runs PG_SLEEP(15). PG_SLEEP(15) pauses for 15 seconds then the SELECT returns 853; the comparison becomes true after the sleep.
  • "--": comments out the rest of the original query.
  • Effect: if the application is vulnerable, the injected condition makes the query either return data or simply delay the response by ~15s. Attackers use this pattern to confirm SQL-injection (time-based blind SQLi) or to infer database state via timed responses.

Why this is dangerous

  • Confirms the presence of SQL injection.
  • Can be used to exfiltrate data via time-based techniques.
  • May allow arbitrary SQL execution depending on the context and privileges.

How to detect

  • Unexplained response delays correlated with unusual input values.
  • Repeated requests that include SQL metacharacters (single quote, OR, SELECT, PG_SLEEP).
  • Database/slow-query logs showing PG_SLEEP or long-running queries from the application account.
  • WAF/IDS alerts for time-based SQLi signatures.

How to mitigate (recommended)

  • Use parameterized queries / prepared statements (never concatenate user input into SQL).
    • Example (psycopg2, defensive):
      • cursor.execute("SELECT * FROM users WHERE username = %s", (username,))
  • Enforce strict input validation/whitelisting where practical (e.g., allowed formats, lengths, character sets).
  • Apply least privilege to the DB user (no unnecessary rights).
  • Set a statement timeout at application or DB level so long-running queries are terminated (Postgres: statement_timeout).
  • Monitor and alert on slow queries and suspicious input patterns.
  • Use a WAF as an additional layer to catch obvious injection attempts.
  • Keep software, DB drivers and ORMs up to date.

Important: only test for SQL injection on systems you own or where you have explicit authorization. Unauthorized testing is illegal.

If you want, I can:

  • Review a snippet of your code (server-side query code) and show how to parameterize it.
  • Suggest a detection rule for your WAF/IDS or SIEM.
  • Describe safe, authorized testing steps or tools to use in a controlled environment. Which would you like?
댓글 달기:
이전 질문:

다음 질문:
관련 질문:

인기 질문:

이야기 로드하기

당신은 어느 그룹입니까?

비밀번호를 입력하세요.