So today at my job I notified a senior programmer that I found an SQL injection at our website. However, when I make an SQL injection, the page just returns 400, so I can't really see any errors or UNION SELECT some more info etc. That's why I guess a senior developer just said we're too busy to look into this now, and that I need to go back to testing other stuff (I'm a tester). Was he right? Is there no way to exploit an SQL injection that just returns 400?
Let's assume this is a valid SQL injection attack, and did actually make it to the database.
The fact that your query didn't return any data is really irrelevant. If you can execute arbitrary SQL, you can likely write to the database. This leads to nasty things like changing passwords, deleting data, dropping tables, etc. SQL Injection is far more than simply getting a web page to display data that isn't there.
Now, returning a 400 error really means nothing. It could mean your SQL injection worked, and the code just didn't know what to do with the database response and returned a 400 error. Or it could mean the injection failed and never got to the database.
If you have permission to write to the database during your test, I'd recommend trying to write a value to a table. Then see if the table was updated. If so, the developer needs to do something rather than brush it aside as this is a very serious vulnerability.
Errors such as 400 (and above) errors are thrown from the web-server side instead of the DB side. So your current query does not actually execute all the way yet. To correct it, you could possibly add linefeed characters such as %0A to the end of your injection test string. If you are on a windows platform you could try %0D%0A. These are HTML linefeed characters to assist with execution. E.g:
A better alternative is to use a SQL testing tool such as the tool from Acunetix or alternatively the tools listed on the OWASP website: https://www.owasp.org/index.php/Testing_for_SQL_Injection_%28OTG-INPVAL-005%29 These tools will be able to test a much larger range of possible injections than you could perform manually.
Glad your company got testers but wish the dev person did not just ignore the error.