If so, is trying to exploit through a time-based injection enough to prove there's a vulnerability in said site?

5 Answers 5


As stated, the answer to the question is "certainly not", HTTP 500 Internal Server Error is used by pretty much every web server in the world for any uncaught exception, which could be anything from a divide-by-zero to a null pointer dereference to an out-of-memory. It could even be from a database connection without meaning there's a SQLi vulnerability; maybe the developer has a typo in their procedure name or a function sometimes tries to insert a null in a non-optional column.

In the specific case that you were attempting SQLi against the server, it's certainly evidence. You'd still want to verify it in a few ways (do queries without any SQL metacharacters always work? Do those with metacharacters always either fail or "work" in a way consistent with the injection?) but it's probably worth trying a few more things, including time-based attacks. However, if a time-based attack attempt just returns a 500 without actually delaying or anything, then you haven't succeeded in an attack, you've just sent a request the developer didn't anticipate and handle correctly by sending a 400 instead.

If you want to prove there's a vulnerability, you have to actually exploit it. Get an actual delay, or return an extra value, or log in as the wrong user, or insert spurious data, or whatever. HTTP 500 is literally just "an unspecified error occurred" and doesn't prove anything at all (maybe a passing cosmic ray flipped a bit that caused the exception and it didn't have anything to do with your request at all...).

EDIT: Since apparently this isn't clear: a server can also return 500 Internal Server Error (or anything else) in response to any request, at the whim of its programmer. It's just bits on a wire, data sent by a program to a network socket. The spec says it's a catch-all for errors where something went wrong while processing the request and it wasn't a recognized client error, and it's the default response when there's an uncaught exception (though that too can be overridden), but web developers sometimes send it for other situations too.

  • 5
    Even if the developer predicted such input many applications return HTTP/500 to the user after a security exception is detected to not reveal any specifics. HTTP/400 with some sort of information may be too helpful to the attacker.
    – kiler129
    Commented Aug 2, 2021 at 7:03
  • 400 is just "Bad Request" and usually doesn't have any other info than that, but yes, sometimes people deliberately return 500 even for anticipated failures even though that's not exactly the intended use of that code.
    – CBHacking
    Commented Aug 2, 2021 at 7:06
  • 1
    I can configure the webserver to return any HTTP error I want, regardless of whether there are real errors or not. I can make it display with HTTP 500 errors when you get your password wrong, for example.
    – Nelson
    Commented Aug 2, 2021 at 8:37
  • @Nelson Sure, and I never claimed otherwise (though it's a decent response to the OP's question). It'd be kind of silly, and arguably a violation of the HTTP spec, but you could do it! You could also make it return 418 I'm a teapot if you want. 4xx and 5xx are both errors, just one of them says "client did something wrong" and the other one is "server did something wrong". They don't have to convey any more info than that, and they don't technically have to convey even that much if you want to be deliberately obtuse to clients. I suppose that might be useful for a honeypot?
    – CBHacking
    Commented Aug 2, 2021 at 11:19
  • @Nelson: I had this brilliant (not) idea to host a blog off 404 pages.
    – Joshua
    Commented Aug 2, 2021 at 14:12

No. In particular it might be also be the sign that there isn't an SQL injection vulnerability because a defensive middleware detected invalid characters in the request possibly indicative of an attack attempt and rejected the request with non-specific error.

A smarter attempt with less obvious character may or may not get to a deeper layer that may or may not be vulnerable, but you are likely to be getting just a 500 Internal Server Error anyway. It's the default error and most programmers won't bother making it more specific, especially when the security auditors tell them not to.


If you have time-based injection (i.e, running a sleep() command and seeing the delay) then potentially yes. Time-based blind SQLi should be proven by having more than an sleep command, you should be able to query the application based on binary statements to enumerate and disclose data, or better yet confirm you can inject data. A good resource for that can be found here.

Obviously the HTTP 500 Internal Server Error can mean many things since it is just telling us that the error is from the servers side and could be anything from the web server being overloaded (DDoS) to the application being restarted (uncommunicated/emergency maintenance)


We use a different query language that gets compiled to SQL. If you manage to get something past our front-end checks and it tries to compile twisted/invalid intermediate language to SQL it will throw on the server, quite likely yielding a 500 error. In fact no SQL injection is possible here and the exception was thrown at compile time because the statement was nonsensical.

And it just so happens that the security constraints are applied to the parse tree of the intermediate language after parsing and typechecking so injecting the intermediate language won't work either. You can get it to do something oddball, but you can't get it to do something your user couldn't have done anyway.

Generally speaking, don't make assumptions about code that's not yours.


It depends on the target that you're working on! And sometimes yes, the 500 error can be caused by the WAF. the target is not supporting some HEX chars used in your injection.

  • Why do you mention hex? That's not mentioned anywhere in the question.
    – schroeder
    Commented Aug 2, 2021 at 7:12
  • I'm talking about the 500 internal server error caused by the WAF during sql injection!, sometimes your query must contain HEX chars see this for more info : here , its just my point of view because i had many experiences with sql injections on ctfs and always getting this error...
    – 9ys
    Commented Aug 2, 2021 at 7:25
  • 3
    Sometimes your SQLi requires all kinds of different encodings that get kicked out by a WAF. But your mentioning just one encoding without any context, relevance or complete sentences makes it very difficult to understand. The question does not state that they used hex, so to say "used in your injection" is a big guess and an assumption.
    – schroeder
    Commented Aug 2, 2021 at 7:45
  • @schroeder yeah u right, i'm not enough good for explanations.
    – 9ys
    Commented Aug 2, 2021 at 7:49
  • 1
    You have an opportunity to edit your answer to make it better
    – schroeder
    Commented Aug 2, 2021 at 9:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .