-
Reconnaissance Find functionality that may execute server-side commands. Examples: Network diagnostics File processing System utilities Server administration features
-
Identify injection points Inspect the requests and identify user-controlled parameters that may be passed to an OS process.
-
Understand normal behavior Send a normal, valid request first and record the normal response.
-
Initial probe Use a safe, non-destructive test and observe whether the application behaves differently. ; && || | The goal : “Does my input appear to reach OS-level processing?”
-
Confirm execution If you get an indication, use a controlled, recognizable OS-level result such as whoami or hostname in an authorized test environment. Ex: whoami , hostname , uname ,
If the application returns the expected OS-level information, that's strong evidence of command execution. -
Determine the type Classify what you observed: In-band → command output appears in the normal response. Blind → command executes, but output isn't returned; you infer execution from controlled behavior such as timing. Out-of-band → execution produces an observable interaction through another channel.
-
Assess impact and report Determine what the vulnerability could allow, without unnecessarily accessing or changing sensitive data.
- Prefer a library/API instead of a shell
- Use white list or block list
- Parameterized process execution if a system utility is required
- Least privilege
Link: https://testrigor.com/blog/how-to-test-for-sql-injections/
Effective SQL Injection testing must address classic, blind, error-based, union-based, time-based, and second-order attack techniques.
Modern applications require testing for intent-based abuse in AI agents and autonomous systems, not just syntax-level SQL payloads.
Automated tools like SQLmap, Burp Suite, and OWASP ZAP are powerful but must be complemented with manual and behavioral testing.
SQL Injection is highly preventable through parameterized queries, least-privilege access, secure error handling, and continuous security testing.
Classic SQL Injection Blind SQL Injection Error-Based SQL Injection Union-Based SQL Injection Time-Based SQL Injection Second-Order SQL Injection
Data Theft Data Manipulation Privilege Escalation Database Takeover
Input is trusted SQL queries are dynamic Errors reveal information
Identify parts of the application that interact with a database, such as:
- Login forms
- Search boxes
- Query parameters in URLs
- Filters, dropdowns, or sorting options
- SQLmap: Automates SQL Injection testing.
- Burp Suite: Intercepts and manipulates HTTP requests.
- OWASP ZAP: A free web application security scanner
Manual testing involves directly entering SQL Injection payloads into input fields or modifying URLs. We will check for the different types of SQLi vulnerabilities. Here’s how you can do it:
Enter simple SQL characters like: ‘ “ — ;
Observe the application’s behavior. Look for:
- Error messages like “SQL syntax error” or “unclosed quotation mark.”
- Unexpected changes in the application’s output.
Example: Input: ‘ Response: An error like: “You have an error in your SQL syntax near ” at line 1” This indicates the application may be vulnerable.
Input conditions to check if the application evaluates them.
Example: Input into a search box: ' OR 1=1-- What it does: OR 1=1 always evaluates to true. Expected behavior: If the application shows all results instead of a filtered set, it’s likely vulnerable.
Inject a payload that causes the database to pause if a condition is true.
Example: If you input code: ' OR IF(1=1, SLEEP(5), 0)-- What it does: Delays the response for 5 seconds if the condition is true. Expected behavior: If the response takes longer, the application might be vulnerable.
Check if the application combines results from different tables using the UNION operator.
Example: If you input code: ' UNION SELECT NULL, NULL-- Gradually increase the number of NULL values to match the number of columns in the query. Once successful, replace NULL with actual data like: ' UNION SELECT username, password FROM users--
Enter complex payloads to intentionally cause errors.
Example: If you input code: ' AND 1=CONVERT(int, @@version)-- What it does: Tries to convert the database version into an integer, causing an error. Expected behavior: Reveals database details like the version or structure.
- Testing SQL Injection in Autonomous Agents
Q How to test a webiste authentication?
Ans: “I would first identify all authentication-related endpoints, including login, registration, logout, password reset, password change, MFA, and account recovery. Then I would test credential validation, account enumeration, brute-force and rate-limiting controls, authentication bypass possibilities, MFA enforcement, and session management. I would also review password-reset and recovery mechanisms for weaknesses. Finally, I would document each finding with evidence, impact, and remediation recommendations.”
How it fits into your authentication methodology Your overall testing process can therefore be:
Reconnaissance ↓ Find authentication endpoints ↓ Test input validation ↓ Test account enumeration ↓ Test brute-force/rate limiting ↓ Test authentication bypass ↓ Test MFA/2FA ↓ Inspect session creation and cookies ↓ Test session fixation/expiration/logout ↓ Test password-reset/recovery sessions ↓ Document and retest
Authentication → account enumeration → brute-force protections → authentication bypass → MFA → session/cookie security → XSS where applicable
1 Q: What is IDOR?
Ans: “IDOR is an authorization vulnerability where a user can manipulate a reference to an object and access or modify another object without the server properly verifying authorization.”
“IDOR is an access-control vulnerability that occurs when an application exposes a direct reference to an internal object, such as a user ID, order ID, document ID, or account ID, and does not properly verify authorization. An attacker may modify the object identifier and access another user's data or perform unauthorized actions.”
Q2: How I would test for IDOR?
Identify object reference → Capture request → Change the identifier → Send the modified request → Compare the response → Verify authorization
Q3: You are testing an application with two accounts: User A and User B. How would you test whether an endpoint is vulnerable to IDOR?
Ans: First, I would log in as User A and identify an endpoint that references a specific object, such as an order ID, user ID, document ID, or file ID. I would capture the request and record the object reference. Then I would log in as User B and identify an object belonging to User B. After that, I would use User A's session and request User B's object by changing the object reference. I would check whether the server properly denies access. If User A can access or modify User B's object without authorization, I would verify the finding and report it as an IDOR/access-control vulnerability.”
GET URL path — look for IDs in paths such as /orders/1001 or /users/25. GET query parameters — look for parameters such as ?order_id=1001 or ?user_id=25. POST request body — look for fields such as order_id=1001 or user_id=25. PUT/PATCH request body — look for identifiers of the object being updated, such as document_id=42. JSON request bodies — look for fields such as "order_id":1001, "file_id":42, or "account_id":25. Form parameters — inspect form fields that contain resource identifiers. Cookies — check whether a cookie contains an identifier that the application uses to select a particular resource. Not every cookie is an IDOR candidate. HTTP headers — occasionally an application may put a resource identifier in a custom header.
IDs UIDs / UUIDs Usernames Account numbers Order numbers User IDs Document IDs File IDs Invoice IDs Message IDs Ticket IDs Resource paths
Easy IDOR workflow Find the reference → Identify the object → Identify its owner → Use another authorized test account → Change the reference → Check authorization → Verify access
Q:
Ans:
- Implement server-side authorization checks.
- application should verify that the authenticated user has permission to access the specific object referenced in the request.
- Enforce object ownership. When User A requests Order 1002, the application should verify that Order 1002 actually belongs to User A.
- Don't rely only on unpredictable IDs. Using UUIDs instead of sequential IDs can make enumeration harder.
- Use centralized authorization logic. Centralized authorization means using a common authorization mechanism, such as a function, middleware, or service, to consistently check whether an authenticated user is allowed to access or perform an action on a particular resource.
Q: What is Business Logic Vulnerabilities??
Ans: “A business logic vulnerability is a security weakness where an attacker misuses a legitimate application function in an unintended way that violates the application's intended business rules.”
1 Q: You are testing a web application and discover that an error page reveals the following information: Internal server path Application framework and version Database error details Some internal configuration information
As a penetration tester, how would you assess this finding and determine whether it is actually a security vulnerability?
Ans: Your answer could be structured like this: Identify what information is disclosed — paths, framework/version, database details, configuration values, credentials, API keys, etc.
Determine whether it is sensitive — not every disclosed piece of information has the same security impact.
Check whether the information can help an attacker with further attacks, such as targeting a known framework vulnerability or understanding the application's internal structure.
Verify reproducibility — confirm that the information is consistently exposed and identify the affected endpoint/request.
Assess severity and impact — consider whether it is merely technical information disclosure or whether it exposes credentials, secrets, PII, or information that enables further exploitation.
Document evidence and recommend remediation — use generic error messages for users and keep detailed errors in secure server-side logs.
2 Q: How would you find exposed sensitive informations?? Ans: “I would start with reconnaissance and attack-surface enumeration. I would identify the application’s accessible directories, files, endpoints, parameters, and resources, including potentially hidden or unlinked resources. Then I would test relevant endpoints and observe the HTTP responses and error messages. I would inspect the responses, source code, JavaScript files, headers, and accessible files for accidentally exposed information such as internal paths, configuration details, credentials, API keys, tokens, or technology versions. Finally, I would verify whether the information is actually sensitive and assess its security impact.”
Reconnaissance → Enumerate resources → Test endpoints → Analyze responses/errors → Identify exposed information → Validate sensitivity → Assess impact
3 -Q: How do you provide a mitigation strategy for the information disclosure?
Ans: “First, I would identify exactly what information is being exposed and remove or restrict access to it. I would configure the application to return generic error messages instead of detailed technical errors, while storing detailed errors securely in server-side logs. I would remove unnecessary backup, configuration, and temporary files from publicly accessible directories and restrict access to sensitive resources. I would also avoid exposing credentials, API keys, tokens, or other secrets in source code and configuration files. Finally, I would review security headers and server/framework configuration to minimize unnecessary technology disclosure, and then retest the affected endpoints to verify that the information is no longer exposed.”
Identify → Remove/Restrict → Generic Errors → Secure Secrets → Harden Configuration → Retest