Generally, you work with databases by sending SQL commands. In particular the SELECT command is used to get data from a database. These SELECT statements are simply built out of text. This is normally not a problem, but it can be when you start to concatenate text to build an SQL statement.

In particular, the risk occurs when you build an SQL statement with user-supplied input. For example, say you prompt the user for some information to filter (it doesn’t matter what) and then create an SQL statement by concatenating what they typed. You might have code that looks like this:

Dim sql As String
sql = "SELECT * FROM Tasks WHERE UserName = 'Paul' AND Title = '" + userValue " + "'"

If the user types “Mow” as the value then the SQL looks like this:

SELECT * FROM Tasks WHERE UserName = 'Paul' AND Title = 'Mow'

But what if the user types something a bit more nefarious, such as “Mow’ OR 1;”? This now results in SQL that looks like this:

SELECT * FROM Tasks WHERE UserName = 'Paul' AND Title = 'Mow' OR 1;'

Now there are two SQL statements. The first one returns all the data in the table (because of the “OR 1”) and the second statement (just a ‘) is likely just ignored. So now your app is displaying lots of data that the user was not meant to see (perhaps data from other users in this case).

This is called SQL Injection because the user was able to inject their own SQL into your query, all because you were using concatenation.

So how do you avoid this? Instead of concatenating, you use the databases built-in ability to create prepared statements by binding values to parameters. For Xojo, you use the appropriate PreparedStatement class for your database. In the case of SQLite, you would use SQLitePreparedStatement.

To start you first declare the SQL to have parameters:

Dim sql As String
sql = "SELECT * FROM Tasks WHERE UserName = 'Paul' AND TITLE = ?"

Then you create a prepared statement, bind the value and send it to the database:

Dim ps As SQLitePreparedStatement
ps = MyDB.Prepare(sql)
ps.BindType(0, SQLitePreparedStatement.SQLITE_TEXT)
ps.Bind(0, userValue)
Dim rs As RecordSet
rs = ps.SQLSelect

Update (October 10, 2019):

If you’re using API 2.0 in 2019r2 or later, the above code is even simper:

Var results As RowSet = MyDB.SelectSQL(sql, userValue)

Because the value is treated as a parameter, if evildoers again try to inject their own SQL, the resulting SQL sent to the database is actually equivalent to this:

SELECT * FROM Tasks WHERE UserName = 'Paul' AND TITLE = 'Mow'' OR 1;'"

This is a valid SQL statement that will simply return no rows.

Any apps that embed user input into SQL statements should always use prepared SQL statements. Do not think you can just write your own code to sanitize user input as this still poses a risk.

And there are also reasons to use prepared statements even when SQL injection is not a concern: some databases cache the parsing of the database command, which can result in some performance improvements if the database command is used repeatedly in the app.

Reference: SQL Injection in the Xojo User Guide

Unfortunately, because digital computers are based entirely on binary, they use powers of 2 and this is, by the very design of floating point values, not going to be precise on any CPU using the IEEE formats.

Let me explain: when you and I do math by hand we all have internalized the rules that decimals are stated as positional values:

1 = 10⁰
10 = 10¹

And that the fraction parts are also powers of 10:

.1 = 1 / 10 = 1 / (10¹)
.01 = 1 / 100 = 1 / (10²)
.001 = 1 / 1000 = 1 / (10³)

We could write 138 as 1*(10²) + 3*(10¹) + 8*(10⁰)

On our computers things are similar but instead of powers of 10, they use power of 2:

1 = 2⁰ (or as a binary literal in Xojo as &b01)
2 = 2¹ (or as a binary literal in Xojo as &b10)
3 = 2⁰ + 2¹ (or as a binary literal in Xojo as &b11)

Floating point values are also the sum of powers of 2. They use the same powers of 2 for the whole number portion and, at their simplest, sums of powers of 2 that are increasingly small. There are some optimizations to this that CPU’s use to normalize things, but the basics are still based on this notation:

.5 = 1 / (2¹)
.25 = 1 / (2²)
.125 = 1/ (2³)

So when you want 1.5 that’s easy: (2^0) + (1 / (2¹)) or 1 + .5 = 1.5
Since 0.5 can be represented exactly using binary there’s no issue. But trying to represent a number like 0.3 will result in what is a common complaint:

(1/ 2²) + (1 / 2⁴) + (1/2⁵) + (1/2⁸) + (1/2⁹) + (1/2¹²) + (1/2¹³)

This evaluates to:

.25 + .0125 + .03125 + .00390625 + .001953125 + .0002441402625 + 0.0001220703125 + 0.0000152587890625

The sum of which is:

0.29999084436406

And you can carry this on as long as you’d like and sum successive powers of 2, and while you can approximate 0.3 you never sum to exactly 0.3. There is no sum of successive powers of 2 that totals precisely to this fractional value, so it’s approximated as close as possible using those fractions.

Therein lies the problem. In a digital computer there are only so many bits used to represent a floating point values and they will be close but not precise.

There are entire books dedicated to the subject, should you want to learn more.

(xkcd license) 

Want more geek talk? Subscribe to the XojoTalk Podcast!