(no subject)
An SQL injection works something like this.
First, you have an SQL statement, like this:
INSERT INTO table_users (firstname, lastname, age) VALUES ('Jim', 'Dogfort', 17);
That's a specific format which tells SQL to look up the database table named "table_users" and put three values into three specific fields, such that "Jim" goes into the "firstname" field, "Dogfort" goes into the "lastname" field, and "17" goes into the "age" field.
(SQL treats strings of text and numbers differently, which is why 17 isn't enclosed in single-quotes.)
The end of a line (or a command) is noted by the semicolon. Generally we put each command on their own line because it makes it more readable to humans, but SQL doesn't care so long as each command ends with a semicolon.
All fairly straightforward.
Now, what if someone does something like that xkcd comic I listed? Let's change the lastname entry to '); DROP TABLE table_users; instead.
INSERT INTO table_users (firstname, lastname, age) VALUES ('Jim', ''); DROP TABLE table_users;', 17);
Reading through this, SQL sees three things:
1. It sees an INSERT statement just like our first one. As far as it can tell, we're telling it to insert "Jim" into "firstname", put nothing into "lastname", and we're not giving it a value for age. At this point, depending on the SQL version and the server settings, it may give an error, because we told it we're putting something in "age" but we're not.
2. The second thing it sees is a new statement. DROP TABLE means "delete this table and everything inside it." So even if there's 10,000 entries, it all just got deleted.
3. Then it sees "', 17);" which doesn't make any sense. It'll spit out an error here, but at this point it doesn't matter because the damage is done.
In order to avoid this, good coders will scrub any incoming text in order to clean up stuff like quotation marks so that the SQL won't misunderstand it. Lazy coders don't bother.
With an SQL injection attack like the one LulzSec used, they probably did something similar to this, but instead of having the table deleted, they got SQL to echo back to them the contents of the table. So they can see who all the users are and all of their information.
((all of the above is a comment from reddit. i find it interesting that most 'hacking' activities consist of the above. it's interesting from a coding perspective, because it exemplifies that most security vulnerabilities aren't due to the software, but the people using it.))
First, you have an SQL statement, like this:
INSERT INTO table_users (firstname, lastname, age) VALUES ('Jim', 'Dogfort', 17);
That's a specific format which tells SQL to look up the database table named "table_users" and put three values into three specific fields, such that "Jim" goes into the "firstname" field, "Dogfort" goes into the "lastname" field, and "17" goes into the "age" field.
(SQL treats strings of text and numbers differently, which is why 17 isn't enclosed in single-quotes.)
The end of a line (or a command) is noted by the semicolon. Generally we put each command on their own line because it makes it more readable to humans, but SQL doesn't care so long as each command ends with a semicolon.
All fairly straightforward.
Now, what if someone does something like that xkcd comic I listed? Let's change the lastname entry to '); DROP TABLE table_users; instead.
INSERT INTO table_users (firstname, lastname, age) VALUES ('Jim', ''); DROP TABLE table_users;', 17);
Reading through this, SQL sees three things:
1. It sees an INSERT statement just like our first one. As far as it can tell, we're telling it to insert "Jim" into "firstname", put nothing into "lastname", and we're not giving it a value for age. At this point, depending on the SQL version and the server settings, it may give an error, because we told it we're putting something in "age" but we're not.
2. The second thing it sees is a new statement. DROP TABLE means "delete this table and everything inside it." So even if there's 10,000 entries, it all just got deleted.
3. Then it sees "', 17);" which doesn't make any sense. It'll spit out an error here, but at this point it doesn't matter because the damage is done.
In order to avoid this, good coders will scrub any incoming text in order to clean up stuff like quotation marks so that the SQL won't misunderstand it. Lazy coders don't bother.
With an SQL injection attack like the one LulzSec used, they probably did something similar to this, but instead of having the table deleted, they got SQL to echo back to them the contents of the table. So they can see who all the users are and all of their information.
((all of the above is a comment from reddit. i find it interesting that most 'hacking' activities consist of the above. it's interesting from a coding perspective, because it exemplifies that most security vulnerabilities aren't due to the software, but the people using it.))