-1

I was pentesting a website when I discovered that the URL included the id parameter. Because of this, I knew that the id parameter might be vulnerable to SQLi. I received a 200 response and found no sign that the injection was successful after I sent the following request to the server:

Example.com/php?id=-15 /*!u%6eion*/ /*!se%6cect*/ 1,2,3,

After fighting with this website and WAF for about an hour, I noticed the website was continuing to respond with a 200 to every single request. I also tried running sqlmap, but the WAF blocked my connection.

So how can I know if this website is vulnerable to SQLi or not?

Can anyone please help me understand why my injection attempt was unsuccessful?

Improve this question
7
  • 4
    Your question is a bit controversial, at first you say: "So i knew "id" param is vulnerable to Sql injection" and then you ask "So how to know this website is vulnerable to sql injection or not?". Not every website that uses id as a parameter name is vulnerable to sql injection. – game0ver Jul 19 '18 at 22:09
  • I had read many blog posts about Sql injection. And "id" param is Vulenerble to Idor and sqli. I ask this question cause i am bit confused cause when I request any statement to the server it gives every response 200 Ok I am not sure about WAF blocking my payloads or not. If WAF block then the response would be 400 ,404 ,500 – Rifat Shommo Jul 19 '18 at 22:20
  • 3
    Just because it returns a 200 response does not mean there is sqli – pm1391 Jul 19 '18 at 22:26
  • 3
    My point is that the name of the parameter is not an indication that a website is vulnerable to sql-injection. Many websites use id as a parameter name and are not vulnerable. Also there might be many reasons why for every request you get a 200 status code. – game0ver Jul 19 '18 at 22:28
  • 1
    Just to remark @game0ver comment. Having a url parameter a specific name does not mean anything. You can have and URL like page.php?id=15&otherParameter=44 but the application could handle right the id parameter but handle wrong, and thus being vulnerable to SQLi, the otherParameter. Naming parameters means nothing about the behaviour of the underlying code. – bradbury9 Jul 20 '18 at 8:55
2

This statement is a false assumption

I discovered that the URL included the id parameter. Because of this, I knew that the id parameter might be vulnerable to SQLi.

Naming parameters means nothing about the behaviour of the underlying code.

For example, you could have and URL like page.php?id=15&otherParameter=44 but the application could handle right the id parameter and handle wrong, and thus being vulnerable to SQLi, otherParameter parameter.

So far, from the info provided, there is no way to tell if there is a posible SQLi (the WAF could be configured to return 200 responses for blocked requests to avoid leaking information), there is just a false asumption that it is vulnerable.

Improve this answer
1
  • 1
    I'm also curious if the existence of the WAF is an assumption. – schroeder♦ Jul 20 '18 at 9:24

Not the answer you're looking for? Browse other questions tagged or ask your own question.