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
• /health-db
• /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.