|
去年sql注入很火,最近好像php注入开始流行了,其实都是最基本的知识的应用,没什么难度~~ i d know about you, oh most knowledgable of sql users, but when i learnt how to build a database driven website from various tutorials around the internet, i never came across the phrase "sql injection"... in fact, i never came across any sql security c at all. the purpose of this article is to inform the sql programmer of the dangers of sql injecti and ways to potentially minimize the severity of any exploits in your code.
all the examples in this article are going to be using php. the reason for this choice is that php seems to be the server-side solution of choice - it's free and powerful. i'm also using mysql, as it's all i've ever used. i think all the examples here should be applicable across different database servers, but i have menti the particular database servers affected where necessary. i assume knowledge of php database functi
to start with, i'll create a database and a couple of tables, so i can dem how a certain security risk could be exploited, and to what means. rather than make a graphical representation of these tables, i'll write it in insertion sql statements, so you can stick them on your own server and test it yourself. after all, the best way to learn is to get stuck in.
代码
######################
# database structure #
######################
create database sqlsecdemo;
create table users (int userid not null auto_increment primary key, text username not null, text password not null);
insert into users set username="netjester", password="blahblah123";
insert into users set username="some password="letmein";
insert into users set username="mrstheplague", password="god";
create table messages (int messageid not null auto_increment primary key, int>
insert into messages set>
insert into messages set>
insert into messages set> create table somemoreinfo (int infoid not null auto_increment primary key, text info);
insert into somemoreinfo set info="some info here";
insert into somemoreinfo set info="even more information.";
insert into somemoreinfo set info="information overload.";
now we have this foundati i can start off by showing you the most basic of attacks. c this php statement:
代码
$result=pg_query($db,"select message from messages where> this may appear in a script that displays all messages posted by a certain user, reached from a page with a list of users to choose from. the url for a page which displays all of some posted messages would be something like http://www.sqlinjection.com/postedby.php?uid=2 so the full sql statement, with substituted variables would be:
代码
select message from messages where> now c this url: http://www.sqlinjection.com/postedby.php?u...20messages%20--
if you were to replace the %20's with spaces, as %20 is simply a url-encoded space, you would see that the sql statement sent to the server now reads like this:
select message from messages where>
the semicolon ends the first sql statement, and the server is now ready for another... which we provide. the -- is the sql comment syntax - all text following that will be ignored by the server. this would be included by an attacker in case there are more search clauses or ordering directives and such following "where> mysql is not vulnerable to this attack, as it allows 1 statement per query, for exactly this reason. postgresql is vulnerable however, and probably others too, as they allow multiple sql statements per query.
protecting against this type of attack is fairly simple, and can be d in two ways.>
$result=pg_query($db,"select message from messages where> so, when our attacker tries the url above, the sql statements becomes:
select message from messages where>
the result of this is to put all the users input into a string, which will then be compared against> http://www.sqlinjection.com/postedby.php?u...20messages%20--
our sql statement then becomes:
select message from messages where> so it looks like we've made absolutely no progress at all. they key is to add backslashes to the user's input before each occcurrence of ' or ". this way, a user can no l open or close a string. with this implemented, the above url generates the sql statement below:
select message from messages where>
because of the escaping of the quote, the string compared to the>
another precaution that can be taken against this kind of attack is simple data validation. as> 代码
function nj_isinteger($checkstring) {
if($checkstring!='' && ereg("^[0-9]*$",$checkstring)) {
return true;
} else {
return false;
}
}
if(!nj_isinteger($_get['uid']))
exit('user inputted uid was not an integer.');
so there we have a good basis for some slightly more advanced sql injection attacks.
now, imagine you wanted a page to select and display everything from a particular table. which table it is the user decides. so it might look like this:
代码
mysql_query($db,"select * from ".$_get['table']);
here, injection can be achieved in much the same way. if the user gave the script the value "users where username='netjester'", they would be presented with my password. which is bad.
the way to protect against injection further than the table to select from, you again, add quotes around the value you're adding, and escape all quotes input by the user.
however, an important lesson is to be learnt here. if you wish to give a user a choice such as which table will be queried, decide which tables you want to allow the user to access, and then, for example, put them in a php array, and use the particular array element required using a number provided by the user. that way, a user can indirectly insert those table names you specify in the array.
ok, now how about we return to the postedby.php> 代码
on first glance, could be forgiven for thinking that even though this page allows a user to perform pretty much any select query they like on our database, they still wouldn't be able to see their results. this is, however, not true, because of sql's as keyword. if you do not know what as is for, it will be in any good sql tutorial. so, c this url:
http://www.sqlinjection.com/big/security/h...0from%20users--
because the password field has been given the name "message", every time the script goes to print a supposedly public message, it actually prints of our users passwords!
the rule here is again to delimit any user input with quotes, and escape any quotes within that input. better yet, give the user an indirect choice of what to add to the sql statement, so you still have 100% c of what goes in and out of the server. here's an example of a php script that uses indirection.
代码
|
|