3 min read

SQL injection still works?

SQL injection still works?
Photo by GuerrillaBuzz / Unsplash

I was a script kiddie in high school, and now that I've been away from the hacking community for ten years. Between 2015 and 2016, I took part in activities related to penetration testing and hacking. For example, I used botnets and zombies to launch DDoS attacks on websites, performed SQL injections, changed and tampered with POST requests, and uploaded malicious code and shells after getting root access. In the next blogs, I'll talk about other ways to do things. I didn't know or understand the rules and etiquette when I was in high school, so please don't judge me.

So, to make it a story, I was wondering if SQLI still works after the web technologies and security got a lot better and safer, especially for today.

Disclaimer: No tables or columns were deleted, and no data was lost during this penetration test.

After dorking, I found a number of websites that are vulnerable to this SQL injection attack. But for now, I will only show you one site.

Now that we have the SQL error, I will use Union Based SQLi for this type of vulnerability because it is much more appropriate. My next task is to inject the payload into the URL. as displayed below.

As expected, the table has private admin information that I can't share for educational reasons.

So, yes, there are a lot more things you can do after you get the leaked tables. You can insert malicious code, upload shells, and gain root access. But as someone who follows the etiquette, it's better to stay low and report to the webmaster if needed.

How to prevent it ?

OWASP’s top recommendation is simple: use prepared statements / parameterized queries so user input is treated strictly as data.

Must-do controls

1) Prepared statements everywhere

Allowlist validation for “structured” inputs (IDs, sort fields, status enums)

2) Least-privilege DB user

Only the tables/actions the app truly needs

3) Safe error handling

Don’t show DB errors to users; log internally instead

Avoid dynamic SQL, especially for ORDER BY / column names

If you must, allowlist permitted values (never pass raw user strings)

Security testing

Add SAST/DAST, and test regularly (especially before releases)

Is it limited to PHP only ?

I can't say for sure, because I also found vulnerabilities on sites that used ASP.NET, as I showed below. I found this example of a vulnerability,

Conclusion

Because an entire database can be exposed or altered by a single unsafe query, SQL injection remains one of the most harmful web vulnerabilities. The main lesson is that SQLi is "fixed" by using prepared statements and parameterized queries, validating inputs with allowlists, and enforcing least-privilege database access. It is not "fixed" by hiding errors or filtering a few characters. This post's screenshots demonstrate how anomalous output can be an early warning indicator, but regular security testing and secure coding techniques provide true protection. Use legal labs to learn SQLi responsibly, and use what you learn to strengthen real applications rather than undermine them.