4

I'm a developer and I'm creating a script to interface with game servers to update player stats. I was sending a POST request with multipart form data and on the last boundary accidentally had the wrong boundary.

Content-Type: multipart/form-data; boundary=--------484554302

But one character was missing ----------48455430-- which triggered this response from the server:

MySQL error 1064 (You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\r\n----------48455430-- = '' WHERE id = '463413'' at line 1)

I don't know too much about SQL but this seems like a potential vulnerability. Any advice?

Edward Severinsen
  • 189
  • 6

1 Answers1

4

Looks like you're passing whatever is supposed to be in the preceded set of data to MySQL without proper encoding or the use of prepared statements. As a result, MySQL is interpreting the boundary as SQL code, and throwing an error that it's not valid SQL.

At the very least, you need to encode any data which is included in SQL queries. Better yet, force the data to a specific type - if you're expecting an integer, ensure that only integers are allowed through, rejecting anything that isn't an integer before it hits the database. Even better, do that, and use prepared statements.

Prepared statements enforce the separation between executable SQL and data you're using within the SQL, so even if unexpected data makes it through, the database won't treat it as part of the SQL statement, but instead attempt to use it as data. They are available for most commonly used web languages with most common databases. They aren't perfect (see Are prepared statements 100% safe against SQL injection?) but they are a lot better than including raw data.

Matthew
  • 27,233
  • 7
  • 87
  • 101
  • I mostly agree, butI would suggest that you (always) really want 2 layers - validate input and escape output - here the output is where it leaves you application (in this case going into an SQL statement). Validating and escaping are very different things. And in the case of a numeric value, the code should explicitly cast it to an integer / float / whatever as the required escaping (while most SQL DBMS will do an implicit cast on a quoted string written to a numeric attribute, there are complications if the value is used for comparisons). – symcbean Jun 12 '18 at 12:14
  • Whether using prepared statements is better than escaping is large and complex question - confounded by the common belief that prepared statements are the same thing as parameter binding. – symcbean Jun 12 '18 at 12:17
  • @symcbean Agreed, hence the link to details about why they aren't perfect - seen too many answers claiming they fix everything from SQLi to dandruff... – Matthew Jun 12 '18 at 12:54
  • @Matthew Thanks, gonna send them an email with instructions to recreate the error. Much appreciated. – Edward Severinsen Jun 12 '18 at 19:13