The Simple SQL Injection Hack
involves entering SQL code into web forms, eg. login fields, or into the browser address field, to access and manipulate the database 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 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 , 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 hack me a Bank!
Slow down, cowboy. This half-cooked method won't beat the systems they have in place up at Citibank,
But 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 :
username field examples:
- ') or ('a'='a
- ”) or (“a”=”a
- hi” or “a”=”a
Cross site scripting ( XSS ):
Cross-site scripting or XSS is a threat to a website's security. It is the most common and popular hacking a websiteto gain access information from a user on a website. There are hackers with malicious objectives that utilize this to attack certain websites on the Internet. But mostly good hackers do this to find security holes for websites and help them find solutions. Cross-site scripting is a security loophole on a website that is hard to detect and stop, making the site vulnerable to attacks from malicious hackers. This leaves the site and its users open to identity theft, financial theft and data theft. It would be advantageous for website owners to understand how cross-site scripting works and how it can affect them and their users so they could place the necessary security systems to block cross-site scripting on their website.
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 totake 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
I recently wrote an article on Hack a website using denial of service
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
Then you will perharps see "username=JohnDoe" and "password=iloveJaneDoe"
in this case the cookie poisoning could be:
It is also many versions of this kind... like for example
and so on...
You may have to try 13 things before you get it completely right...
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 .
* Update all 3rd party modules as a matter of course — any modules incorporating web forms or enabling member 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 , use this guide as a reference.
* If you have an admin 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.