joins sql injection stored procedures a2 teacher up skilling lecture 4
TRANSCRIPT
What’s to come today?
• Joins
• Inner Join
• Left Outer Join
• Right Outer Join
• Full Outer Join
• SQL Injection
• Stored Procedures
What is a Join?
• Joins are needed when we need to combine data from two or more
tables.
• Joins can be achieved in several different ways. We will consider each
of these joins in turn:
• Inner Join
• Right Outer Join
• Left Outer Join
• Full Outer Join
Inner Join
• Most common type of join.
• A typical inner join query has the form:
SELECT (Ai, A2 .. An)
FROM r1 INNER JOIN r2
ON P;
• Ai in the select clause represents an attribute
• ri in the from clause represents a relation – listing all relations
involved in the query
• P in the where clause is a predicate – describing what conditions the
query results need to satisfy.
Inner Join Example
• E.g. For all instructors who have taught courses, find their names and
the course ID of the courses they taught.
SELECT name, course_id
FROM instructor INNER JOIN teachers
ON instructor.ID = teaches.ID;
instructor (ID, name, dept_name, salary)
teaches (ID, course_id, sec_id, semester, year)
• Matches all rows in the instructor and teachers tables, where the
instructor’s ID is equal to the teachers ID.
Inner Join (cont.)
• What rows would be returned if we performed an inner join between
Course and Prereq based on the course_id attribute from both tables?
• What is the drawback of this inner join?
course
prereq
Inner Join Drawback
• The drawback of an inner join is that it leads to a loss of information.
In the example on the previous slide, the inner join meant that we lost
the information that the Robotics course (CS-315) has no prerequisite.
• Sometimes we won’t worry about this loss of information if the query
we are executing doesn’t need the information. However, if we
wanted to list any prerequisites for each course, we would like to see
courses that have a prerequisite as well as those who have no
prerequisites.
• To achieve this, we introduce a new type of join known as an outer
join.
Outer Join
• An extension of the join operation that avoids loss of information.
• Adds rows from one relation that does not match rows in the other
relation to the result of the join.
• Rows can added from the table on the left, the one on the right, or
both - three different types:
• Left Outer Join
• Right Outer Join
• Full Outer Join
• Uses null values for missing rows that do not match the join
condition.
Left Outer Join
• Returns all rows from the left table, with matching rows in the right
table. If there are no matching rows in the right table, then NULL is
used.
• A typical Left Outer Join query has the form:
SELECT (Ai, A2 .. An)
FROM r1 LEFT OUTER JOIN r2
ON P;
• This SQL command can also be called a LEFT JOIN instead of LEFT
OUTER JOIN, in some Relational Database Management Systems.
Right Outer Join
• Returns all rows from the right table, with matching rows in the left
table. If there are no matching rows in the right table, then NULL is
used.
• A typical Left Outer Join query has the form:
SELECT (Ai, A2 .. An)
FROM r1 RIGHT OUTER JOIN r2
ON P;
• This SQL command can also be called a RIGHT JOIN instead of RIGHT
OUTER JOIN, in some Relational Database Management Systems.
Full Outer Join
• The Full Outer Join is simply a combination of a LEFT OUTER JOIN and
a RIGHT OUTER JOIN. That is, a Full Outer Join returns all rows from
the left table and the right table,.
• A typical Full Outer Join query has the form:
SELECT (Ai, A2 .. An)
FROM r1 FULL OUTER JOIN r2
ON P;
SQL and Security
• When writing SQL commands, the programmer knows about the
internal structure of the database. That is, the programmer knows the
table names and the relationships between the tables.
• Users of our application shouldn’t be concerned with the database
that is behind the scenes driving the application. We want the user to
know nothing at all about the internal structure of our database. We
also want the user to never be able to send SQL commands directly
to the database through the User Interface. This is known as SQL
Injection.
• Imagine you are an employee in a company, and you find a hole in a
system that allows you to send SQL commands through the User
Interface. Pair this with the fact that you know in the database there is
an employee table with a column used to store every employee’s
salary. Well then a malicious user could send SQL commands to
double every employee’s salary.
SQL Injection
• SQL Injection is one of the key security threats when using SQL in
code.
• Suppose you had a method that took a String name as a parameter.
Inside this method, you constructed the following SQL query:
string sqlQuery = ”SELECT * FROM instructor WHERE name = ’" +
name + "’";
• What if the parameter passed as a name was Joe’;? Then the
resulting value stored in sqlQuery becomes:
sqlQuery = ”SELECT * FROM instructor WHERE name = ’Joe’;’";
• This may look harmless however we have modified the resulting SQL
query. This SQL query is no longer valid, and will cause an Exception
in our program.
SQL Injection (cont.)
• The exception that is thrown may allow the user to see potentially
sensitive data such as the name of a table.
• Even worse, a technical aware user could enter the following into the
Text Box: Joe'; UPDATE instructor SET salary = salary +
10000;--
• Now the sqlQuery variable will store a value that selects an instructor
where name=“Joe” but will also add 10000 on to every instructor’s
salary.
• Obviously, this is a critical security threat. The only proven way to
prevent SQL injection is the use of SQL parameters.
Stored Procedures
• A Stored Procedure is a precompiled piece of SQL code that can
accept parameters passed to it.
• When creating a Stored Procedure you must specify a name for which
that stored procedure can be referred to as. You must also specify the
parameters that this Stored Procedure accepts along with their
corresponding data type.
• The obvious benefit of a Stored Procedure is that it can be used over
and over again with different parameters.
Creating a Stored Procedure
• To create a Stored Procedure in Visual Studio, we use the following
form:
CREATE PROCEDURE ProcedureName
@parameter1 dataType,
@parameter2 dataType,
...
AS
BEGIN
//SQL STATEMENTS GO HERE
END
GO
Stored Procedure Example
• Here is a Stored Procedure to Select a Instructor based on their name.
CREATE PROCEDURE SelectInstructor
@name varchar(50),
AS
BEGIN
SELECT * FROM Instructor
WHERE name = @name;
END
GO
Stored Procedure SQL Injection
• Now even if we pass a parameter of “Joe'; UPDATE instructor SET
salary = salary + 10000;--” this will be try to select an instructor
with a name that matches the value specified.
• The Update SQL statement will not execute as the specified Stored
Procedure protects against this.
For example, here is the actual SQL that will be executed as a result of
calling our Stored Procedure with the specified parameter:
SELECT * FROM Instructor
WHERE name = “Joe'; UPDATE instructor SET salary = salary +
10000;--”;