Browse Source

yr2/sem1/opnet: Add notes from latest databases lectures

Callum Renwick 2 months ago
  1. 20
  2. 25
  3. 9


@ -0,0 +1,20 @@
# Database Security
# GRANT command
GRANT privilege_name
TO object_name
ON user_name
This command grants a privilege to a user. The `WITH GRANT OPTION` clause allows the user with the permission to go onto grant that permission to other users, which is dangerous!
## Permissions revocation
Permissions can be revoked with `REVOKE privilege TO thing ON user`. Note that *this will not revoke privileges granted to other users via `WITH GRANT OPTION`*!
## Grantable permissions roles
**Permissions roles** are collections of privileges. You can grant permissions roles to people as well as individual permissions. They can be created with `CREATE ROLE`, deleted with `DROP ROLE`, and granted and revoked just like individual permissions using `GRANT` and `REVOKE` statements.


@ -0,0 +1,25 @@
# Database Security
Databases face threats not only from users who may accidentally damage the database by changing things they should not, but also users who should have no access to the database whatsoever (**intruders**) who might try to enter the network from outside.
The database automatically trusts that applications and users interacting with it are allowed to do so (assuming that the users have authorised credentials).
## Application code exposure
Details about the database in use can leak to the end user of a web app if, for example, database error messages appear in web pages sent to the user.
## Configuration file exposure
Misconfiguration of the web server can cause the configuration file for a database to be served by the web server and hence indexed by search engines! Since configuration files often contain plaintext database credentials, these are often a free ticket to access a database which is exposed to the Internet.
## SQL Injection
**SQL injection** is actually an attack against an application, not the database; the database is expecting to receive queries from an application. But if you make an SQL injection, you can cause the application to make an SQL query against the database which it was not designed to make. And since the database probably trusts the application implicitly, it will accept *any* query from the application. You can drop tables, create tables, drop rows, or drop the entire schema. And perhaps even better, if the output of the query gets put into the webpage output, you could *print the contents of the entire database*! In real life this can be extremely informing: lots of confidential personal information is often stored in the databases of web applications, not to mention probably all the user credentials, including the administrator account credentials.
### Accomplishing SQL injections
SQL injections are usually accomplished by entering part of an SQL query into a user input widget in a web app. Since the user input is then appended to part of an SQL query and sent to the database, if the user input is something along the lines of `'); SELECT * FROM Some_Table;` then you can effectively run any query you want. (The `');` ends any previous query.)
### SQL injection countermeasures
Rather than concatenating strings together to build an SQL query to submit to the database, you should use functions for building SQL queries provided by libraries, which will **sanitise** the input before it's inserted into the query and ensure that no extraneous SQL is used.


@ -0,0 +1,9 @@
# SQL (second half of semester)
## LIMIT clause
The `LIMIT` clause *limits* the number of results you see from a query. Adding `LIMIT 30` at the end of a `SELECT` query limits the number of records in the output to 30. To see records from a particular section of the query results, one can use the `OFFSET` keyword like this: `SELECT ... LIMIT 30 OFFSET 10`. This will show 30 results, starting from the result offset by 10 from the first result (that is, the 11th result). There is also a shorter syntax for this: `SELECT ... LIMIT 10, 30`. This query gives *the same output as the previous one*.
## ALTER TABLE statement
Used to change the fields and constraints of a schema. Using this statement, one can `DROP COLUMN` or `MODIFY COLUMN` (the latter of which can modify the constraints of a column). You can also change variables which control the functioning of the table; for example, `ALTER TABLE Table_Name AUTO_INCREMENT=100` changes the default starting point for auto-increment fields in that table.