Saw the sign of Database Error : SQLSTATE 23000 : Integrity Constraint Violation. Is it a potential malware?
Is this database vulnerable to some sort of error based SQL injection?
After reading various research papers, I got to know that the SQLSTATE values are based on the SQLSTATE specifications contained in the standards: ISO/IEC 9075:1992, Database Language SQL and ANSI X3.135-1992 Database Language SQL. SQLSTATE values are returned to the application in the last five bytes of the SQLCA. Each five-character value is a return code that indicates the outcome of the most recently executed SQL statement.
SQLSTATE values are designed so that application programs can test for specific errors or classes of errors. The first character of an SQLSTATE value indicates whether the SQL statement was executed successfully or unsuccessfully (equal to or not equal to zero, respectively).
You cannot determine if the parameter is vulnerable to SQLi based on this error alone. For more definitive proof, you need to manipulate the s_id parameter and see if you can get it to return a syntax error. This would indicate that the input of s_id is not being properly sanitized or parameterized.
Since the error message is showing you the SQL query i.e SQLSTATE 23000, this is rather easy to test for. Try doing some of the following injections:
s_id=1,1,1&status=1
Query becomes: INSERT INTO a2.user_s_likes (s_id, user_id, status, added_on) VALUES (1,1,1, 924300, NULL, '2016-09-01 13:28:29')
If vulnerable, you would expect to get an error about too many arguments / parameters.
s_id=1)&status=1
Query becomes: INSERT INTO a2.user_s_likes (s_id, user_id, status, added_on) VALUES (1), 924300, NULL, '2016-09-01 13:28:29')
If vulnerable, you would expect to get an error message about an unexpected parenthesis.
s_id=1'&status=1
Query becomes: INSERT INTO a2.user_s_likes (s_id, user_id, status, added_on) VALUES (1', 924300, NULL, '2016-09-01 13:28:29')
If vulnerable, you would expect to get an error message about an unterminated literal string.
If you receive error messages about s_id having an incorrect data type / not being a number, then this would imply that the query is being parameterized and thus is not vulnerable.
In order to prove that an SQL injection vulnerability exists, you need to prove that the value of s_id is being interpreted as SQL. Syntax errors are the easiest way to do this.