Question

(select(0)from(select(sleep(15)))v)/*'+(select(0)from(select(sleep(15)))v)+'"+(select(0)from(select(sleep(15)))v)+"*/

Answer 1

That string is a time-based blind SQL‑injection probe. High level:

- What it does: it injects a SQL fragment that calls the database sleep/delay function (sleep(15)) so the query pauses for ~15 seconds. If the application’s response is delayed by that amount, that indicates user input is being embedded into SQL and an injection is possible.
- Why attackers use it: time delays are useful when the application does not return query results (blind injection). They can be used to infer data one bit at a time or to confirm vulnerability without seeing output.

I can’t help craft or extend exploits, but I can help you secure an application or investigate responsibly. Defensive advice and immediate steps:

1. Immediate checks
- Review server/web logs and database logs for anomalous slow queries or requests containing "sleep(" or similar.
- If this is an unauthorized test against a third‑party site, stop and follow responsible disclosure. If it’s against your own systems, proceed in a controlled test environment.

2. Short-term mitigations
- Apply request rate limiting and a Web Application Firewall (WAF) to block obvious malicious patterns.
- Set DB connection and statement timeouts so a single long-running query cannot hang a request.
- Remove detailed error messages from public responses (don’t leak DB errors).

3. Code remediation (the most important)
- Use parameterized queries / prepared statements everywhere — never construct SQL by concatenating user input.
- Example pattern (defensive, generic):
- Python (psycopg2): cur.execute("SELECT * FROM users WHERE id = %s", (user_id,))
- Java: PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE id = ?"); ps.setInt(1, id);
- PHP (PDO): $stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id"); $stmt->execute([':id'=>$id]);
- Use ORM libraries or query builders that separate code from data, but still verify they are used correctly.
- Whitelist and validate inputs: enforce types, length limits, allowed characters, and business rules instead of blacklisting patterns.
- Use least-privilege database accounts: the application DB user should have only the permissions it actually needs.
- Avoid enabling database features/functions that aren’t required. Apply principle of least functionality for DB users and roles.

4. System hardening & monitoring
- Configure DB statement timeouts and query limits.
- Monitor for unusual spikes in latency and failed/suspicious queries; alert on them.
- Keep database and framework packages up to date; apply security patches.
- Regularly scan and test your codebase with static analysis and authorized dynamic testing.

5. Testing and remediation workflow
- If you need to confirm and fix vulnerabilities, do so in a staging/test environment, or use an authorized security tester (internal or 3rd party).
- Create a repeatable fix (parameterization, validation) and deploy to production with monitoring to ensure the issue is resolved.

If you tell me what platform/language/framework you’re using and whether this is your app, I can:
- Point to concrete secure-coding examples for that stack, and
- Suggest safe ways to detect and triage this class of vulnerability in your environment.