The Simple SQL Injection Hack
SQL Injection involves entering SQL code into web forms, eg. login fields, or into the browser address field, to access and manipulate the database behind the site, system or application.
When you enter text in the Username and Password fields of a login screen, the data you input is typically inserted into an SQL command. This command checks the data you've entered against the relevant table in the database. If your input matches table/row data, you're granted access (in the case of a login screen). If not, you're knocked back out.
In its simplest form, this is how the SQL Injection works. It's impossible to explain this without reverting to code for just a moment. Don't worry, it will all be over soon.
Suppose we enter the following string in a User name field:
' OR 1=1
The authorization SQL query that is run by the server, the command which must be satisfied to allow access, will be something along the lines of:
SELECT * FROM users WHERE username = ‘USRTEXT '
AND password = ‘PASSTEXT’
…where USRTEXT and PASSTEXT are what the user enters in the login fields of the web form.
So entering `OR 1=1 — as your username, could result in the following actually being run:
SELECT * FROM users WHERE username = ‘' OR 1=1 — 'AND password = '’
Two things you need to know about this:
['] closes the [user-name] text field.
'
' is the SQL convention for Commenting code, and everything after Comment is ignored. So the actual routine now becomes:SELECT * FROM users WHERE user name = '' OR 1=1
1 is always equal to 1, last time I checked. So the authorization routine is now validated, and we are ushered in the front door to wreck havoc.
Let's hope you got the gist of that, and move briskly on.
Brilliant! I'm gonna go to hack a Bank!
Slow down, cowboy. This half-cooked method won't beat the systems they have in place up at Citibank,evidentlyBut the process does serve to illustrate just what SQL Injection is all about — injecting code to manipulate a routine via a form, or indeed via the URL. In terms of login bypass via Injection, the hoary old ' OR 1=1 is just one option. If a hacker thinks a site is vulnerable, there are cheat-sheets all over the web for login strings which can gain access to weak systems. Here are a couple more common strings which are used to dupe SQL validation routines:
username field examples:
- admin'—
- ') or ('a'='a
- ”) or (“a”=”a
- hi” or “a”=”a
Cross site scripting ( XSS ):
Denial of service ( Ddos attack )
A denial of service attack (DOS) is an attack through which a person can render a system unusable or significantly slow down the system for legitimate users by overloading the resources, so that no one can access it.this is not actually hacking a webite but it is used to take down a website.
If an attacker is unable to gain access to a machine, the attacker most probably will just crash the machine to accomplish a denial of service attack,this one of the most used method for website hacking
Cookie Poisoning:
Well, for a starters i can begin with saying that Cookie Poisoning is alot like SQL Injection
Both have 'OR'1'='1 or maybe '1'='1'
But in cookie poisoning you begin with alerting your cookies
Javascript:alert(document.cookie)
Then you will perharps see "username=JohnDoe" and "password=iloveJaneDoe"
in this case the cookie poisoning could be:
Javascript:void(document.cookie="username='OR'1'='1"); void(document.cookie="password='OR'1'='1");
It is also many versions of this kind... like for example
'
'1'='1'
'OR'1'='1
'OR'1'='1'OR'
and so on...
You may have to try 13 things before you get it completely right...
Password Cracking
Hashed strings can often be deciphered through 'brute forcing'. Bad news, eh? Yes, and particularly if your encrypted passwords/usernames are floating around in an unprotected file somewhere, and some Google hacker comes across it.
You might think that just because your password now looks something like XWE42GH64223JHTF6533H in one of those files, it means that it can't be cracked? Wrong. Tools are freely available which will decipher a certain proportion of hashed and similarly encoded passwords.
Know more about Brute force attack
A Few Defensive Measures
* If you utilize a web content management system, subscribe to the development blog. Update to new versions soon as possible.
* Update all 3rd party modules as a matter of course — any modules incorporating web forms or enabling member file uploads are a potential threat. Module vulnerabilities can offer access to your full database.
* Harden your Web CMS or publishing platform. For example, if you use WordPress, use this guide as a reference.
* If you have an admin login page for your custom built CMS, why not call it 'Flowers.php' or something, instead of “AdminLogin.php” etc.?
* Enter some confusing data into your login fields like the sample Injection strings shown above, and any else which you think might confuse the server. If you get an unusual error message disclosing server-generated code then this may betray vulnerability.
* Do a few Google hacks on your name and your website. Just in case…
* When in doubt, pull the yellow cable out! It won't do you any good, but hey, it rhymes.
Both have 'OR'1'='1 or maybe '1'='1'
But in cookie poisoning you begin with alerting your cookies
Javascript:alert(document.cookie)
Then you will perharps see "username=JohnDoe" and "password=iloveJaneDoe"
in this case the cookie poisoning could be:
Javascript:void(document.cookie="username='OR'1'='1"); void(document.cookie="password='OR'1'='1");
It is also many versions of this kind... like for example
'
'1'='1'
'OR'1'='1
'OR'1'='1'OR'
and so on...
You may have to try 13 things before you get it completely right...
Password Cracking
Hashed strings can often be deciphered through 'brute forcing'. Bad news, eh? Yes, and particularly if your encrypted passwords/usernames are floating around in an unprotected file somewhere, and some Google hacker comes across it.
You might think that just because your password now looks something like XWE42GH64223JHTF6533H in one of those files, it means that it can't be cracked? Wrong. Tools are freely available which will decipher a certain proportion of hashed and similarly encoded passwords.
Know more about Brute force attack
A Few Defensive Measures
* If you utilize a web content management system, subscribe to the development blog. Update to new versions soon as possible.
* Update all 3rd party modules as a matter of course — any modules incorporating web forms or enabling member file uploads are a potential threat. Module vulnerabilities can offer access to your full database.
* Harden your Web CMS or publishing platform. For example, if you use WordPress, use this guide as a reference.
* If you have an admin login page for your custom built CMS, why not call it 'Flowers.php' or something, instead of “AdminLogin.php” etc.?
* Enter some confusing data into your login fields like the sample Injection strings shown above, and any else which you think might confuse the server. If you get an unusual error message disclosing server-generated code then this may betray vulnerability.
* Do a few Google hacks on your name and your website. Just in case…
* When in doubt, pull the yellow cable out! It won't do you any good, but hey, it rhymes.
hope u like this article...
