Welcome to HBH! If you have tried to register and didn't get a verification email, please using the following link to resend the verification email.

SQL Injection PoC


SQL Injection PoC

By ghostghost | 5756 Reads |
0     0

SQL Injection PoC

Theory about securing a site.

  1. General SQL Injection

  2. Prevention

  3. New Theory

Basically, in PHP, mysql_query() is an eval() command of SQL. Similar to eval() but rather than running PHP it runs SQL. This means that a well written intrusion into your mysql_query(), and I'm not talking ' OR 1=1 more, UNION SELECT, UPDATE or INSERT can potentially lead to news articles being edited and a major hack taking place. (The news article may even be eval()'ed and therefore there is a potential risk of PHP Injection)

  1. To stop the SQL Injection there are two common techniques, the 1st (and more popular) is the "addslashes" command. This means that the string is parsed and bad characters are cleaned from the string. Unfortunately, this does not work perfectly, see here and therefore the 2nd technique "mysql_real_escape"

This works well but I was thinking the other day about problems with this and then I realized that say someone hacked the site, and found the db user and password. What if they then remotely accessed the site with complete privileges.

  1. My theory works on the principle of having many users and passwords to the database and all with only one privilege, be it INSERT, UPDATE whatever and therefore limiting the amount of power given to the hacker should he find the password in the source.

If you do this what advantages does it bear to the user in question? Well, firstly it should, in theory, mean that there is less possibility in our hacker altering pages by injecting in logins or searches. The only editing area would be the admin area or in the forum, which could even be in a different database. Also this technique will make it easier in the logs to stop malicious actions and where the potential loop hole is.

For instance;

Say out hacker has found the injection point in the search function.

We know that there is one user which uses SELECT and LIKE and therefore we can limit the number of SQL queries to check by looking at the ones who's user has the privileges of SELECT and LIKE.

Problems with this theory.

Time - how long will it take to make all the different users and different queries?

Thanks for reading.

P.S. I know it is kinda short but I ran out of ideas, please suggest them and I will add them :-)

Comments
ghost's avatar
ghost 18 years ago

good idea with the multiple user's to the db's with their own priveleges. ya it could kind of get confusing to have that but it would make things that are bad not as bad if you get what im sayin lol. nice article

ghost's avatar
ghost 18 years ago

Good stuff, mozzer. Keep 'em coming – very interesting.

ghost's avatar
ghost 18 years ago

Perhaps you should've gone into more detail as to why addslashes() alone is insufficient.

ghost's avatar
ghost 18 years ago

Gah, clicked the button too soon, just wanted to comment that this was a fairly well written article. ;)

ghost's avatar
ghost 18 years ago

That good enough?

ghost's avatar
ghost 18 years ago

wouldnt it be easier to just htmlentities all your sql variables?

ghost's avatar
ghost 17 years ago

@mr noob - AHHHHHHH!!!!!!!!!!!!!!!!!!!!!! No, that would be easy to fit a quote in, no offence