MySQL

[Tormod]

The easiest way to avoid injections like this is to validate the data before you use it in a query.

 

For example, if you want to look up a number, make sure that the variable used is indeed a number. A typical script injection method is to add extra content to the query string so that the database executes something else that you were planning...

 

Read more here:

SQL injection - Wikipedia, the free encyclopedia

[C1ay]

Look at it this way. You create a form where you intend for someone to put in some type of bird and you pass it to a query that takes that form field and sends it to the database as

 

"Select form_field_birdname from bird_table;"

 

but hackerboy searches for a bird named "* from mysql.user; /*" so that the actual query passed to the database is

 

"Select * from mysql.user; /* from bird_table;"

 

and hackerboy gets back a list of database users with password hashes from the system table mysql.user. Using form validation you would make sure that any bird name submitted does not contain a ;, /*, mysql system tablename, various SQL keywords etc.. before passing that info to your SELECT statement.

[alexander]

similarly as clay have demonstrated above (btw props, clay :phones: ), i can also inject arbitrary user side code into the mix, actually i take that back, if you dont validate your query, i can inject server side code as well as user side which is waaay more dangerous

 

injecting something like

;"))); php_info();

would now let me know what you have running on the box, and how i might use it... at this point i can inject php code to copy php shell or something to your box, and then that would allow me to root it, and pwnxor your box.

 

that also allows me to inject user-side code, may have read my post on XSS here.

 

Moral of the story, validate, validate, validate! when i was writing my own CMS, i had up to 5-6 levels of validation, every function validated its own input, every page validated the data it was passed, every form self-validated with JS, on top of that to provide quick feedback, and that ensured me that sql injection was possible, infact data was also validated coming back from functions, in case someone was arbitrarily executing the display functions... too bad i lost my code, i could have given you some examples... :lol: i could whip something up for a demo purpose, if you'd like, to outline the concepts we have been discussing here of multi layer input validation...

[Cedars]

Snipped birdwatcher friendly security / injection translation.

Ah HA!

Thanks much for the explanation!

 

For example, if you want to look up a number, make sure that the variable used is indeed a number. A typical script injection method is to add extra content to the query string so that the database executes something else that you were planning...

 

i can also inject arbitrary user side code into the mix...

OMG! Now I understand!

i could whip something up for a demo purpose, if you'd like, to outline the concepts we have been discussing here of multi layer input validation...

I am going to read some more and be back with more questions.

 

Again Thanks for the Help!

[Buffy]

There's another approach that I've used extensively not mentioned so far which is very clean and does not require the simple-sounding-but-not-so-simple step "validate your input".

 

Here's what you do:

• Write all your code as stored database procedures. This is simply good practice for inserting and updating data because it ensures data consistency, but this approach means you do *all* of your db access through sprocs.
  
• Have your application go through a user who has *no* direct access to tables, and *only* has permissions to run specified sprocs. (You can get fancier and partition your sprocs into groups with more or less access depending on who the user is and create different db users for each of these levels).
  

Now this can *still* be prone injection attacks, but it requires an actual understanding of the underlying database procedures, and if the attackers have that already, you're probably screwed.

 

Also, simply to prevent bugs, you're going to have to parse your input for quote marks and quote them properly, so that "validate" bit never goes away.

 

The down-side is that you do have to write sprocs for everything that you want to do, and thus "ad hoc" capabilities are harder to replicate. But then again, if you think you want this sort of thing, well, go back and think again!

 

This isn't enough if you're a bank, but at least this approach will kill off the script kiddies for most small scale sites....

 

In general, shorter is better. If you can encapsulate your idea into a single captivating sentence, you're halfway home, ;)

Buffy

[alexander]

As always, buffy's yet another great post, illustrates yet another approach, though i may not quite agree as to implementing this technique increasing security standards, though complexity would bring a certain level of security from people who have never seen code in databases before.

 

Personally, though i value Buffy's input greatly, and it may be something you should look into, Cedars, i can't see why i'd want to stick my code into a database just to secure it, i could always run encryption if was really anal about it, but imho, as long as the code is up to snuff in validation, length checks, etc, there is little risk of someone discovering vulnerabilities. Then again, i like to really secure boxes with mod security and suphp. Also by disabling directory broswing, cgi exec, server-side includes, disabling following of symbolic links, turning off support for htaccess files, disabling all unnecessary modules, lowering timeout values, and last but not least, running apache in a chroot environment... then setting up PHP with suPHP, which breaks stuff, but when you make it all finally work again, suPHP does some assuring that if your page gets pwnxored, only that page gets pwnxored, php runs as a separate user (not apache), and all the directories become 644 while files become 755. I also run chrootkit, and tripwire and such, as well as generally, if i code, i use an svn or darcs on an off-site system, so if someone manages to get in and change code, i can restore to the latest version in no time (and know what they changed, just by running a comparison check, available within both structures) :phones:

[Cedars]

Buffy: what you are saying is a very interesting concept, however I think its WAY beyond my level at this time. Look at the trouble I had just figuring out like vs wildcard.

 

Alex:

 

I did turn off indexes in the htaccess but have symlinks enabled. Not sure why... Probably could turn it off and see if anything breaks. But I do use it for IP blocking, referrer blocking and hotlinking. Dont need no ads for viagra or payday anytime they find a blog or email.

 

I have yet to get a visitor from China, Thailand, Viet-nam, several eastern blocks, africa, etc that have any interest in my site other than to advertise/spam/scam.

 

I do know that htaccess can be compromised, but if they get in via some method, they can (and do) add the file themselves. So not having an htaccess vs having one really doesnt seem to impact the potential for abuse, or am I missing something?

 

Whats wrong with ssi? I use it for links and love that I dont have to update 40+ pages when I photograph a new butterfly. Keep in mind I have mostly static html pages. I have reservations about moving to dynamic pages for several reasons, skill level being primary, but also being search engine friendly.

[alexander]

I do know that htaccess can be compromised, but if they get in via some method, they can (and do) add the file themselves.

Dunnt make any difference if you disable the use of htaccess, they can make a hundred htaccess files, and the server will still not look at them :phones:

 

Problem with symbolic links is that if i compromise your box, i can set symbolic links in your WWW directory that will call up OS files in other parts of your system, and i can do it as the apache user in the www directory... example would be to symlink to your /bin, and /usr/bin, and /sbin directories and throw up a php shell that will source the symlinks... yes i can not reach /bin directly because you have disabled ../.. in your apache paths, but i can symlink to it just as easily, and have access to it without breaking your apache rules :)

 

P.S. you realize that most hackers don't come from China and Thailand, right? Do ip filtering all you want, it's your neighbor who will deface your site (not literally ofcourse, but i think you will get the gist of it)

 

when i say "i", i mean a maliciously minded person, i'm not one, i may poke around, but i won't break your box, and if i discover an exploit i would (and have in the past) notify the admin...