1

I am developing a client-side only web application for learning purpose, using WebSQL to store and query data, and Javascript to process it. WebSQL is not mantained anymore, but the question may be valid for all client side databases.

In the proposed specification for WebSQL from the W3C, §8.5 recommends a specific syntax (parameterized queries using ? as placeholder for values) to avoid SQL injection attacks.

Given that the user is free to modify the Javascript code used in the web page, including SQL statements (or alter the database using the development Console or other browser tools) why should the program be prepared to avoid SQL injections?

I found three StackOverflow questions related to SQL injection in WebSQL, this one, this one and this answer but none of them highlights why SQL injection is a concern on client side databases.

May someone else has a clear motivation, why SQL injection is a concern on client side databases?

Community
  • 1
  • 1
Alban Kraus
  • 51
  • 1
  • 5

2 Answers2

0

SQL injection makes sense when considering unwanted third party operations on the database.

A client-side web application involves:

  • the developer, who designs the database and SQL statements;
  • the user, who can modify them using browser tools;
  • third-party scripts, such as libraries, which cannot access the application database.

Actually, databases are specific to one origin, so that a script cannot open a database belonging to an other origin:

  1. If no database with the given name from the origin origin exists, then create the database

(§4.1 of the WebSQL W3C specification)

A third party attack script may use the DOM of the page to fill in form inputs with attack code, which will be injected when the form is submitted (possibly by the attacker itself, calling the submit() method of the form element). To avoid this, use parameterized queries: user input will never be interpreted as SQL code.

Alban Kraus
  • 51
  • 1
  • 5
-1

I would say that "an SQL injection attack" is distinct from a "I'm gonna modify the program, or better yet, just write my own" attack.

Yes, you are entirely correct in observing that a user can do anything he wants to, to a database and to software source-code that winds up on his computer. But, this is not an "SQL injection."

"SQL injection," I think, represents any case where an outsider effectively modifies the database structure or content from the outside, and without directly modifying the source-code or supplying new source-code of his own.

It could well be argued, as essentially you just did, that SQL injection is much less likely to occur with regard to a database that exists only on the client computer. I think that your argument is sustained. But, I don't think that this is a successful argument for abandoning the use of parameters. I flatly recommend that one should never insert literal, externally-provided values into any SQL string, "period."

Mike Robinson
  • 8,490
  • 5
  • 28
  • 41
  • Thank you. I did not accept your answer because I did not have enough knowledge about web application architecture to understand it. However, your mention of a possible "outsider" headed me toward my solution. – Alban Kraus Jul 05 '16 at 09:39
  • Excellent! Glad you found your answer! *(Care to edit your post, say, to tell us a bit more about what you finally did? Would love to read it...)* – Mike Robinson Jul 06 '16 at 01:14
  • As the last sentence suggests, I finally used the placeholder syntax (something like `executeSQL("INSERT INTO person (name) VALUES (?)", [name], success, error)`). I am also more careful in respect to global variables, in order to avoid giving access to a function that alters the database to third-party scripts. However, I feel too inexperienced to advise any coding practice in my answer, and even to mark it as accepted without approval from experienced client-side developers. – Alban Kraus Jul 07 '16 at 14:01
  • I would suggest that you "accept" the answer, and that you already have more experience than you seem to give yourself credit for! :-) – Mike Robinson Jul 07 '16 at 14:10