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 hack me a Bank!
Slow down, cowboy. This half-cooked method won't beat the systems they have in place up at Citibank,
evidently


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 routines:
username field examples:
admin'—

') or ('a'='a


”) or (“a”=”a


hi” or “a”=”a

… and so on.

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 security threat 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 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 it 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.