First SQLi I found while i was testing a wildcard , I started normally with Recon

I started with subdomain enumeration ( but I didn't copy the wildcard name exactly as it was missing one character ) , got the live subdomains using httpx , started testing the authentication endpoints

While the login and sign up endpoints are normal target for SQLi , the forgot password endpoint usually doesn't get that much of attention

The idea of SQLi is trying to break the SQL query and pass our input as part query to get executed not just a variable's value

The normal query can look like that :

SELECT id, email, username
FROM users
WHERE email = 'user@example.com'
  AND is_active = 1;

The vulnerability is passing the user input directly into the SQL query without sanitization or filtering which allows attacker to break the query syntax , inject another queries , and exfiltrate data and in some cases achieve RCE

And here is the tip , the normal thing to consider while testing this type of issues is injecting single quote ' or double quotes " or any other SQL syntax characters , while this is logical to think of , there is a good chance that there is filtering for this specific type of characters especially if there is WAF implemented and here is my tip , using unicode characters in the email field

a simple example can be like that :

instead of -> ahmedsameh@gmail.com

use -> ahmedsameh@gmàil.com

and this exact test is not useful for only SQLi , in the first place it is a test i perform to see if the database is considering if the 2 emails the same ( which can allow 0 click ATO as an attacker can register the same domain victim uses but in unicode form and get the password reset link instead of him ) the unicode char survives input, hits the DB driver, gets normalized in a way that breaks quoting

The real world example I faced :

  1. this one was in the registration endpoint
None

as we can see we got the SQL query exposed in the SQL exception which allows us to easily exploit the vulnerability and dump the DB in minutes

None

as well as the debugging was enabled , i could almost see all the backend code for this endpoint in the exception body

of course as ethical security researcher i reported the issue to the corporate but they were out of business at this point ( it wasn't in scope any way so The first 0$ was deserved I guess )

The 2nd SQLi i faced was in European logistics corporate :

I was testing a program that is in scope , but in the process I Mistakenly confused a partner's website as their asset and just realized it after discovering the issue ( again like the previous one )

Any way this SQLi was blind time-based one

a forgot password endpoint , if the query syntax is true it perform the check , return a response of user doesn't exist , but if the syntax is broken it returns a 302 response to submit the username/email again

unlike the previous one when I tried to break the syntax using single quote there was no visible error message but the behavior i described above was enough to awake my intuition to test for blind time based ( also not boolean based to avoid causing any destruction without intention )

I noticed .asp I went to test for the parameter as :

name=samehhh'+Sleep(5)--&&captcha=13121

but it didn't work , it even broke the syntax , and I know that the syntax is right so the only reason i thought of was that the DBMS is different so I tested it as :

name=samehhh'WAITFOR+DELAY+'0:0:5'--&mf_captcha_text=60172

and it worked , the server waited 5 seconds and to double check it works and it wasn't coincidence I sent the request again with 10 seconds this time

name=samehhh'WAITFOR+DELAY+'0:0:10'--&mf_captcha_text=60172
None

and again it worked , after confirming the issue , went to report it just to discover that for the second time I was testing asset not just out of scope it didn't even have bug bounty program , still reported the issue to them and that is the 2nd deserved 0$ SQLi : )

Back to the main question , Is SQLi still exist in the wild ?

Absolutely does , it just disappears in bug bounty programs as a result of continuous security testing and patching , but in almost any other website they are reckless about security treating penetration testing as regulations requirement and SSDL as luxury which can have catastrophic consequences , like the both companies above , it was a security researcher who discovered the issues but what if it was malicious actor ?

Linkedin : https://www.linkedin.com/in/ahmed-sameh-8924b728b/