As an application developer, we want our users to trust our application. That is the only way we can make sure that our users will use our application. But how about trusting our users equally and expecting them not to do anything wrong? Specifically, trusting them with the input they will provide us through the use of input mechanisms our application exposes to the user for taking input from them.

The following snippet of code shows a simple example of not filtering the input provided by the user:

username = request.args.get('username')
email = request.args.get('email')
password = request.args.get('password')
user_record = User(username=username, email=email, password=password) #Let's create an object to store in database
# Let's store the object into the database
db.session.add(user_record)
db.session.commit()

This code snippet takes the input of some of the details of the users, creates an object out of those details, and then performs a simple SQL insert in the background by running a statement, as shown here:

INSERT INTO users(username, email, password) VALUES(username, email, password);

With this code, we are now assured that we trust our users. The code is absolutely fine and will store the user details in the database, but only until the point when a user comes in and issues the following as an input to one of the fields:

(select password from mysql.user where user='root')

As soon as this statement is executed, based on the configuration of the database server, it can result in the exposure of the password of the root user of the database.

Another kind of issue that may arise due to such trust is a cross-site scripting attack. Imagine a user submitting the following as an input to your application:

<script>alert('XSS attack'),</script>

Now, since the application does not filter any of the user input, this HTML snippet will be stored inside the database. When the user visits a page that requests this information from the server, the browser will consider the data as valid HTML and render the HTML, thus executing the code inside the script tags.

Now, this was a harmless input, but a real attacker may craft something more serious to steal data from the user, maybe to do a session hijack of the user.