# cspj application

## attacks

1. sql injection
2. xss
3. command injection
4. file inclusion attacks
5. csrf
6. directory traversal
7. insecure deserialization
8. session hijacking
9. xml external entity injection
10. sever side request forgery
11. broken authentication and session management
12. clickjacking

## backend

backend-for-frontend server

!remember to set the environment variables
!include this in the setup instructions
!should we use a .env file and let the user set the variables?

PGHOST=localhost
PGPORT=5432
PGDATABASE=asdfdb
PGUSER=asdfuser
PGPASSWORD=asdfpassword

## Server

!only listening on localhost is supported. DO NOT run this on a public ip.  

- `/health`
- `/setup-demo-db`
- `/nuke-db`
- `/fetch-all-users`

### SQL Injection

- `/sql-execute`
- `/login-sql`
- `/secure-sql-execute`
- `/secure-login-sql`
- `/secure-get-user`

#### 1. Parameterization of Queries

Used `pool.Query()` with a parameterized query, instead of dynamically constructing the SQL query by directly inserting the user input.  
Parameterized queries separate the SQL code from the data, so user input is never directly put into the query's structure. Placeholders are used instead, and the data is passed as parameters. The DB will treat them as data, not executable code.  

#### 2. Input Validation and Query Type Restriction

Only allow `SELECT` statement by verifying that the input query starts with it.  
Sanitized the input to ensure that no other types of statements could be executed.  
The input is checked against a list of allowed query terms, and if it doesn't match, the query is rejected.

#### 3. Controlled JSON Input for Parameters

Instead of using raw SQL strings, we restructured the input to ONLY expect JSON data with `query` and `params` fields.
