So I finally have a couple of dev environments up and running and I'm coding away, when I see something. Sometimes the easiest way to figure out REST API wonkiness is to look at the source code that handles the call. I should not have done that.

When interacting with a database you have to create calls to the db and in an app you usually make these dynamic. The easiest way to do this is also the most dangerous, concatenate variables in your string and throw that in your database handler. As in:

sql = "SELECT * FROM user_data WHERE username = %s" % (username)
cursor.execute(sql)

This adds whatever the username is to the SQL query call to the database, and it really could be whatever which is dangerous. You probably already knew this and it's horribly repetitious of me to belabor the point. But I see this all the time, anyone could create the username Johny; DROP TABLES users; (my favorite example) .

I've talked to developers who knowingly do this and they have a reasoning that it's ok in some use cases because the variable is just internal. This reasoning is flawed, often the way to hack an application is to find a way to control these internal variables and go to town. Dangerous user inputs and what a user can actually control in the application are often not what a developer thinks they are, so it's safer to always work with the database controls that prevent SQL injection and never take shortcuts.

Bobby Tables

Finding quite a few potential flaws that look like this has side tracked me into making sure an application I'm working with is safe. And if it's not safe, I'll work on getting the flaws fixed with the community. This requires a pen testing environment, some specialized tooling and worst of all time. I want to work on my app, but making sure it's dependencies are secure takes priority.