Ok guys now most of you on here will know me, i am an expert virus writer, good at programming in various languages but i'm still learning hacking. Well i've learnt alot since i've been here and i know quite a lot about basic hacking stuff. ONe area i would like to learn though is sql injection.
I've read loads of tutorials seen how people on here hack sites with the simple '1=1-- stuff. I've done it myself before but only once.
So i am asking if somebody who knows about that sort of stuff could perhaps tell me how to tell if a website is open to attack and which attack to use. Thats all i'm asking. Just some basic stuff.
I can't offer much in return, i'd offer you cash in buy sell trade but my cc is locked (Reasons i do not wish to discuss). Anyway i can offer you some hax points on here, maybe a rep and a favor in return.
So thats it. If nobody wants to help me then thats fine i understand i will ask again when i can get my cc sorted to pay you guys some money (if i get it sorted).
If you need anymore info please PM me.
Thanks, OXY.
Well the SQL language is easy. Understanding how it works is harder. And understanding what exactly a SQL injection is should shine the light upon what exactly you have to do. I could give you some mySQL books, that will teach you first two steps. But since im not good at SQL by any means, you will have to learn exactly how an SQL injection works by yourself, since I dont know the language well enough to explain it in my words. Basically you put SQL commands in login fields, or other places that interact with the SQL database,by ending the login SQL commands, and starting a new command right in the login box.
OK thanks for that nyx. I will come back to you on that one.
Well my RS account just got locked for fraud also. So for the next few weeks Im going to have to reupload everything onto my other account.
Basically once you inject vuln site you are getting control over the whole sql database through URL or login fields..
It's only on you to read and test, there is really a load of tutorials over the net.
Even if you can't understand it on English, try to find some on your mother language.
How to tell if a site is vulnerable to SQL injection can be one of the hardest parts of the exploit.
Sometimes it can be easy: you put a single quote into a field value and the site throws up a big error page...often with lovely details about "ODBC error" or "JDBC error" or "SQL Server" errors, etc. When this happens, you know that you have SQL injection.
If the site is a bit more robust than that (and they often are), it can be trickier. Let's say you're looking at a login form:
1. You login without attempting any attack (no single quotes). Note the message that's returned (e.g. "Username/password not found").
2. You login with single quotes in the username and/or password fields. Did the message change (e.g. "Invalid login")? If so, you _may_ have SQL Injection. Something changed on the back end. Maybe they passed the input through to the SQL query and it resulted in an error. Or they may have done proper input validation and failed on that (no SQL Injection). So you play a bit -- instead of just a single quote, try to make the SQL valid. Instead of just a single quote, enter a single quote and then comment out the rest of the statement (two dashes) "' --". If that doesn't work, try a single quote, ending parentheses, and then two dashes (in case it's a stored proc call).
It's really about getting inside the head of the developer of the site -- figuring out how they programmed things (without seeing the code) so that you can determine whether or not you have an exploitable vulnerability.
If you have further questions...please post. It's difficult to talk in generalities ;)
Thanks to all of you. Thats helped me understand a little more about sql injection.
One other tidbit for you:
In lines with "thinking like the developer" -- be aware that us devs are lazy by nature. "If it ain't broke, don't fix it" is a good developer motto. Applied to SQL Injection, this means that fields where you can freely enter any value may be checked/protected (text fields, text areas, etc.).....but fields that the user normally has no control over may be vulnerable (hidden form fields, drop-down lists, check boxes, etc.).
1. The developer mistakenly trusts those hidden fields -- he's the one that set the values into them, and they're hidden fields, so the user can't change them, right? (enter proxy tools)
2. The developer receives error reports as users fat-finger in their username or password (or other text-field values) and receive ugly server error messages....so the developer fixes those fields, but never bothers with the fields that aren't generating errors (like hidden fields, etc.)
Just some food for thought to help maximize the instances that you'll find.