ibernal1815/sql-security-lab
GitHub: ibernal1815/sql-security-lab
一个基于Flask和PostgreSQL的安全实验室，通过对比演示SQL注入攻击与防御并修复漏洞。
Stars: 0 | Forks: 0
# SQL安全实验
两个Flask应用，一个PostgreSQL数据库，一个疑问。当你跳过输入验证时，后果究竟会有多严重？
我创建这个实验，目的是将SQL注入从一个概念转化为可以实际演示、衡量和修复的问题。实验室同时运行同一应用的易受攻击版本和加固版本，这样差异就不再是理论上的。你可以亲眼目睹攻击如何成功，然后又如何失败。
## 背景 / 我构建此项目的初衷
SQL注入数十年来一直稳居漏洞排行榜首。每门安全课程都会讲授它，但大多数时候你只在幻灯片中看到一个单行示例。我想要实际构建易受攻击的应用，亲自执行攻击，然后逐层加固。不仅仅是修补查询，而是像在真实环境中那样锁定数据库。
因此，我构建了两个版本。`vulnerable_app.py` 包含有缺陷的登录。`secure_app.py` 包含参数化查询、基于角色的访问控制、行级安全以及强制SSL连接。相同的模式，相同的数据，完全不同的安全姿态。
## 项目功能
**阶段 1 — 易受攻击的应用**
一个由PostgreSQL支持的Flask登录表单，使用原始字符串拼接构建查询。一个经典的 `' OR TRUE --` 就能完全绕过身份验证。重点在于亲眼见证其工作原理，而不仅仅是阅读。
**阶段 2 — 数据库加固**
三个遵循最小权限原则的PostgreSQL角色：`app_user`、`app_reader`和`admin`。移除应用用户的超级用户权限。强制使用SCRAM-SHA-256身份验证。要求SSL连接。撤销默认权限。
**阶段 3 — 安全应用**
相同的登录流程，使用参数化查询和连接上下文中的正确角色重写。启用行级安全，使用户只能访问自己的行，无论查询如何编写。注入尝试将不返回任何数据。
**阶段 4 — 监控**
启用`pg_stat_statements`以跟踪两个应用的查询执行模式。有助于精确查看每个版本运行的查询以及攻击面所在。
## 项目布局
```
sql_security_lab/
├── app/
│ ├── config.py
│ ├── db.py
│ └── seed.py
├── database/
│ ├── roles.sql
│ ├── schema.sql
│ └── seed_data.sql
├── scripts/
│ ├── start_postgres.sh
│ └── init_db.sh
├── vulnerable_app.py
├── secure_app.py
├── requirements.txt
└── .env
```
## 设置说明
```
git clone https://github.com/ibernal1815/sql-security-lab.git
cd sql-security-lab
python3 -m venv venv
source venv/bin/activate
sudo -u postgres psql -f database/roles.sql
sudo -u postgres psql -f database/schema.sql
sudo -u postgres psql -f database/seed_data.sql
```
运行易受攻击的应用：
```
python vulnerable_app.py
```
运行安全应用：
```
python secure_app.py
```
## 技术栈
Python 3 · Flask · PostgreSQL · psycopg2 · pg_stat_statements
标签：API密钥检测, CISA项目, Flask, GitHub Advanced Security, PostgreSQL, RBAC, SSL, Web安全, 参数化查询, 安全加固, 安全实验室, 数据库监控, 最小权限, 测试用例, 漏洞演示, 网络安全, 蓝队分析, 行级安全, 角色管理, 认证安全, 输入验证, 隐私保护