I might be wrong here, but I think that the "SQL Injection (Blind)" section in dvwa is just a regular SQL Injection vulnerability.
According to DVWA what makes a SQLi vulnerability to be blind is not showing SQL error messages to the user.
Showing the SQL error messages to the user is just: a SQL injection vuln + a misconfiguration issue.
A blind SQL injection might occur when the columns of the results returned by a query are not shown to the user. However, the user can tell somehow if the query returned any records or none.
E.g.: Suppose the url "http://www.example.com/user?id=USER_ID" returns:
- 200 if USER_ID exists
- 404 if USER_ID not exists
But it won't show any information from the query results (e.g. username, address, phone, etc)
If the page is vulnerable to SQLi, an attacker won't be able get info from the DB printed in the result page, but he might be able to infer it by asking yes/no questions.
E.g. if user id 1 exits:
- ?id=1 and 1=1: will return 200
- ?id=1 and 1=2: will return 404
of course the attacker doesn't need to ask the DB if 1=1 or 1=2 (he can ask a calculator that), but he might ask more interesting yes/no questions like:
- is the length of the admin's password greater than 5?
- is the length of the admin's password equal to 10?
- is the first char of the admin's password greater than 'm'
- is the first char of the admin's password equal to 'r'
- is the second char of the ...
I suggest you add a real blind sql injection section in DVWA. While displaying or not SQL errors can be just a difference between the security=low and security=medium levels of the regular SQL Injection section.
More info:
https://www.owasp.org/index.php/Blind_SQL_Injection
http://en.wikipedia.org/wiki/SQL_injection#Blind_SQL_injection
I might be wrong here, but I think that the "SQL Injection (Blind)" section in dvwa is just a regular SQL Injection vulnerability.
According to DVWA what makes a SQLi vulnerability to be blind is not showing SQL error messages to the user.
Showing the SQL error messages to the user is just: a SQL injection vuln + a misconfiguration issue.
A blind SQL injection might occur when the columns of the results returned by a query are not shown to the user. However, the user can tell somehow if the query returned any records or none.
E.g.: Suppose the url "http://www.example.com/user?id=USER_ID" returns:
But it won't show any information from the query results (e.g. username, address, phone, etc)
If the page is vulnerable to SQLi, an attacker won't be able get info from the DB printed in the result page, but he might be able to infer it by asking yes/no questions.
E.g. if user id 1 exits:
of course the attacker doesn't need to ask the DB if 1=1 or 1=2 (he can ask a calculator that), but he might ask more interesting yes/no questions like:
I suggest you add a real blind sql injection section in DVWA. While displaying or not SQL errors can be just a difference between the security=low and security=medium levels of the regular SQL Injection section.
More info:
https://www.owasp.org/index.php/Blind_SQL_Injection
http://en.wikipedia.org/wiki/SQL_injection#Blind_SQL_injection