## https://sploitus.com/exploit?id=4627B035-1A34-56D9-BC75-CFBAC1454527
# Secure Coding Review — MiniBank
A complete secure code review: a deliberately vulnerable banking app, a
professional-grade audit that finds **13 vulnerabilities**, working exploits
that prove every one is real, and a fully remediated version where the same
exploits are proven to fail.
> 📄 **The audit is the deliverable → [SECURITY_REVIEW.md](SECURITY_REVIEW.md)**
```
14 exploits → prove the attacks work against vulnerable_app/
27 checks → prove the attacks fail against secure_app/ (features intact)
────────────
41 tests, one command: python -m pytest exploits/ secure_app/
```
---
## Why it is built this way
The task is to *audit an application and document findings with remediation*.
Auditing a real third-party project and publishing unpatched exploits would be
irresponsible disclosure, so — the approach OWASP and PortSwigger use for
training — this repository contains its **own** target: a realistic internal
banking app written with the kinds of flaws these apps genuinely ship with.
That choice makes the review stronger, not weaker, because it can prove every
claim. A review that says *"this looks like SQL injection"* is an opinion. This
review ships the request that logs in as admin with no password, and a test that
runs it. Then it ships the fix, and a test that the same request now fails while
real logins still work.
```
vulnerable_app/ the application under review (INTENTIONALLY INSECURE)
secure_app/ the same app, every finding remediated
exploits/ 14 tests that perform the real attacks and pass against vulnerable_app
reports/ Bandit static-analysis output, before and after
SECURITY_REVIEW.md the audit report — findings, exploits, impact, fixes
```
The **diff between `vulnerable_app/` and `secure_app/` is exactly the set of
security fixes** — same routes, same templates, same behaviour for a legitimate
user — so the remediation can be read directly.
---
## The findings
| # | Vulnerability | Severity |
|---|---------------|----------|
| V-01 | SQL injection in login → authentication bypass | 🔴 Critical |
| V-07 | OS command injection in `/export` | 🔴 Critical |
| V-08 | Insecure deserialization (`pickle` cookie) → RCE | 🔴 Critical |
| V-11 | Privileged password reset behind a hard-coded token | 🔴 Critical |
| V-02 | SQL injection in `/search` → cross-user data theft | 🟠 High |
| V-03 | Broken access control / IDOR on accounts & transfers | 🟠 High |
| V-04 | Stored & reflected XSS | 🟠 High |
| V-06 | Path traversal → arbitrary file read | 🟠 High |
| V-05 | Open redirect after login | 🟡 Medium |
| V-09 | Passwords stored as unsalted MD5 | 🟡 Medium |
| V-13 | Race condition in `/transfer` → money created from nothing | 🟡 Medium |
| V-10 | Debug mode + secrets in source | 🔵 Low |
| V-12 | No session rotation on login (fixation) | 🔵 Low |
Full write-ups — vulnerable code, the exploit, impact, and the applied fix — in
**[SECURITY_REVIEW.md](SECURITY_REVIEW.md)**.
---
## Run it yourself
```bash
git clone
cd CodeAlpha_SecureCodingReview
pip install -r requirements.txt
# The whole thing: 14 attacks succeed on the vulnerable app,
# 27 checks confirm they fail on the remediated app.
python -m pytest exploits/ secure_app/ -v
```
Read [`exploits/test_exploits.py`](exploits/test_exploits.py) as documentation:
each test's docstring is the vulnerability, and its body is the exploit.
### See a specific attack
```bash
# SQL injection logging in as admin with no password:
python -m pytest exploits/test_exploits.py::test_sql_injection_login_as_admin -v
# The race that manufactures money out of a transfer:
python -m pytest exploits/test_exploits.py::test_transfer_race_allows_overdraft -v
```
### Re-run the static analysis
```bash
bandit -r vulnerable_app/app.py # 3 High, 3 Medium, 5 Low
bandit -r secure_app/app.py # 0 High, 0 Medium, 2 Low (informational)
```
---
## Methodology
Three passes, because each finds what the others cannot:
1. **Manual source review** — the only pass that catches logic and
access-control flaws. Found the IDOR (V-03) and the transfer race (V-13),
which no scanner reports.
2. **Static analysis (Bandit)** — an automated sweep that independently flagged
the dangerous-sink findings (injection, `pickle`, `subprocess`, MD5, debug).
3. **Dynamic proof-of-exploit** — a test per finding that runs the real attack.
This is what separates a genuine vulnerability from a false positive, and
what proves each fix actually closes the hole.
---
## ⚠️ Safety
`vulnerable_app/` is **intentionally insecure and must never be deployed or
exposed to a network.** It exists only to be audited. It binds to `127.0.0.1`,
ships no real data, and the flaws in it are the subject of the review, not a
mistake. No third-party or production system was tested in this work.
---
## Author
Built for the CodeAlpha Cyber Security Internship. MIT licensed — see
[LICENSE](LICENSE).