Follow us on Twitter!
Capitalism is an Island of wealth in a sea of poverty
Wednesday, April 23, 2014
HellBoundHackers Main:
HellBoundHackers Find:
HellBoundHackers Information:
HellBoundHackers Exploit:
HellBoundHackers Programming:
HellBoundHackers Think:
HellBoundHackers Track:
HellBoundHackers Patch:
HellBoundHackers Other:
HellBoundHackers Need Help?
Members Online
Total Online: 16
Guests Online: 14
Members Online: 2

Registered Members: 82876
Newest Member: bhl1986
Latest Articles

SQL Injection PoC

Arrow Image Another method for looking preventing and securing your site from SQL Injections

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)

2. 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.

3. 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 :-)


chislamon October 18 2006 - 23:17:51
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
netfishon October 19 2006 - 01:19:46
Good stuff, mozzer. Keep 'em coming -- very interesting.
T-Metal-Risenon October 20 2006 - 18:06:46
Perhaps you should've gone into more detail as to why addslashes() alone is insufficient.
T-Metal-Risenon October 20 2006 - 18:07:18
Gah, clicked the button too soon, just wanted to comment that this was a fairly well written article. Wink
mozzeron October 20 2006 - 21:55:37
That good enough?
mr noobon October 22 2006 - 12:02:35
wouldnt it be easier to just htmlentities all your sql variables?
mozzeron March 08 2007 - 17:36:22
@mr noob - AHHHHHHH!!!!!!!!!!!!!!!!!!!!!! No, that would be easy to fit a quote in, no offence
Post Comment


You must have completed the challenge Basic 1 and have 100 points or more, to be able to post.