vault backup: 2024-04-16 16:47:25

This commit is contained in:
2024-04-16 16:47:25 +01:00
parent 9d548c7912
commit 34266b15bc
5 changed files with 719 additions and 38 deletions

View File

@@ -24,7 +24,7 @@ If the "street" attribute is unneeded, less IO operations are needed to retrieve
#### i)
![](Pasted%20image%2020240415135455.png)
# Add Projections
#### ii)
Root Node: $\pi$ ( factory.name )
@@ -41,32 +41,30 @@ Line-by-line:
# Q2
# **a)**
### a)
*Consistency: Database should be in a consistent state, prior to a transaction and after. e.g. Following constraints, relationships, etc.
Isolation: All transactions should by fully independent from concurrently executing transactions.
Durability: When a transaction is committed, it's effect should be permanent in the database, withstanding system failures or restarts.*
*Atomicity: A transaction must be completed, or aborted. If a transaction fails, a DBMS ensures the rollback of data to allow the database to remain consistent.
Consistency: A DBMS would enforce constraints on a transaction, assuring the defined rules / relationships are followed.
Isolation: Reduces concurrency issues by restricting access to shared data until a transaction is committed.
Durability: Guarantees data is permanent once committed, preventing inconsistency after failures.*
Atomicity: A transaction must be completed, or aborted. If a transaction fails, a DBMS ensures the rollback of data to allow the database to remain consistent.
Consistency: Database should be in a consistent state, prior to a transaction and after. A DBMS would enforce constraints on a transaction, assuring the defined rules / relationships are followed.
Isolation: All transactions should by fully independent from concurrently executing transactions. Reduces concurrency issues by restricting access to shared data until a transaction is committed.
Durability: Guarantees data is permanent once committed, preventing inconsistency after failures. Should withstand system failures or restarts.
### b)
To guarantee consistency, a DBMS handles the enforcement of atomicity, consistency, isolation and durability, along with concurrency control to prevent conflicts.
Transfer of crates:
Ideal SQL Transfer of crates:
```sql
UPDATE warehouses
UPDATE warehouse
SET crates = crates - 3
WHERE wname = 'warehouse1'
UPDATE warehouses
UPDATE warehouse
SET crates = crates + 3
WHERE wname = 'warehouse2';
```
If the second query is not run, it is not the fault of the DBMS. A DBMS can only enforce ACID rules and ensure consistency, not transaction logic.
### c)
By allowing concurrent execution of transactions, system resources are allocated more efficiently due to multiple operations occurring simultaneously. This has an effect of being more performant, since more transactions can be processed per second.
@@ -114,7 +112,7 @@ Deadlock does not occur, since there are no cycles in the graph
### d)
#### i)
# TO DO
The recovery manager would first identify in-progress transactions at the time of failure
# Q4
@@ -132,5 +130,45 @@ WHERE partPrice > 100;
#### ii)
```sql
SELECT
SELECT carModel
FROM car
JOIN carPart ON car.carId = carPart.carId
GROUP BY car.carModel
HAVING COUNT(carPart.partID) > 4;
```
### b)
If the DBA revoked auth from U2 -> U1, U4, and U5 would also have auth revoked due to cascading revokes. There is no path from U1, U4 or U5 to the DBA if U2's authorisation is revoked. U3 and U6 still have a path to the DBA, as they do not depend on U2 for authorisation, authorisation is still valid.
### c)
#### i)
```sql
GRANT ALL PRIVILEGES ON * TO Isavella
CREATE VIEW employeeView AS
SELECT *
FROM employee
GRANT SELECT, UPDATE ON employeeView TO Laura, Naser;
```
#### ii)
```sql
CREATE VIEW projectsView AS
SELECT *
FROM project
WHERE level = 'advanced'
GRANT SELECT ON projectsView TO Jane;
```
#### iii)
```SQL
REVOKE ALL PRIVILEGES ON * FROM Naser;
```

View File

@@ -0,0 +1,95 @@
# SQL Injection
- Using SQL injection, attackers can
- Add new data
- Modify current data
- Delete Data
## Example 1
$username $password
```js
$sql = "SELECT * FROM users WHERE username = ' " . $username " ' AND password = ' " . $password . " ' ";
```
```sql
SELECT * FROM users WHERE username = 'fred' AND password = 'Fr3dRu13S';
```
**.** concatenates
An attacker could circumvent the authentication by entering ` OR 1=1 --` into the username field
- This would select all users from the database, since `1=1` is always true.
- The rest of the query is then commented out with `--`.
```SQL
SELECT * FROM users WHERE username = '' OR 1=1 -- ' AND password = 'Fr3dRu13s'
```
In this statement, it would select all data from `users`, since the where clause is always true.
## Example 2
```SQL
SELECT prodinfo FROM prodtable WHERE prodname = 'dvd'
```
By using `dvd '; DROP TABLE prodtable; --`, the query would look like
```SQL
SELECT prodinfo FROM prodtable WHERE prodname = 'dvd'; DROP TABLE prodtable; -- '
```
Which would remove the entire product table.
## Avoiding SQL Injection
To avoid SQL injection, user inputs must be sanitised. This is achieved by escaping all characters that could be misused in the DBMS.
However, application developers are not usually database experts - may not know which characters to be escaped.
### Parameterised Queries
The best way to avoid SQL injection is to use prepared statements.
```SQL
SELECT * FROM users WHERE username = ? AND password = ?
```
This query would then be sent to the DBMS with the values for the 2 variables.
The values of these 2 variables will then automatically be used in place of the `?`, and the DBMS will sanitise the content of the variables using its own resources. This ensures new vulnerabilities will be handled by the DBMS rather than the developers of the application.
However, some values cannot be sanitised.
```SQL
SELECT * FROM mytable WHERE id = 23
SELECT * FROM mytable WHERE id = 23 OR 1=1
```
### Other Defences
- Checking Syntax for validity
- Fixed formats, e.g email, dates, part numbers.
- Verify input is valid in context
- If possible, exclude quotes and semicolons
- Have length limits on input
- Many attacks depend on entering long strings.
# Chapter 37
## 1
Backup mechanism, make copies of database and log
Log File, keep track of state of transactions
Checkpoints
Recovery Manager
## 2
T2 Safe, commit before checkpoint
T3 ignored, still running
T1 redone, did not commit until after checkpoint
## 3
DBMS recovery is responsible for Durability and Atomicity
## 4
T1 committed after checkpoint, redo
T2 running at failure, undo
T3 committed, safe
T4 committed after checkpoint, redo
T5 running at failure, undo